Many updates to the dark theme. Dark theme is selected by default if DL claims this to be the system theme. There should be a nice way to overrule. As is, you can overule on the commandline using -Dtheme=<theme>. If the theme does not exist it uses the default (light) theme.
Console: added triple-click for line selection and select all (Ctrl-Shift-A or Cmd-A (Apple)
Change the XPCE “GIL” to be more like the Python one: rather than being a full (recursive) lock, the XPCE lock is now released if XPCE does a callback to Prolog. This implies that multiple Prolog threads can make progress communicating to the graphics. Notably, this allows running multiple instances of the debugger from different consoles and it allows GUI debugging XPCE itself. It should generally avoid many deadlocks.
Please test and provide feedback. Next planned steps:
Release 9.3.26 based on this
Planned binary releases
MacOS Bundle (as in the preview download)
Windows .exe installer (in the preview download)
Flatpak through flathub
discontinue the snap package. Flatpak is simpler to manage, is more widely supported (AFAIK) and serves the same purpose.
PPA for Ubuntu 25.04 only as older versions to not support SDL3. PPAs for older versions without GUI (if feasible).
Update Macports to build this version
Source release
Tar-ball will contain the new xpce. Everything need to support the old will still be in the Prolog part and packages.
You can stull build the old version by using the GIT source and checkout xpce on a branch X11.
Further plans (probably next version)
Remove starting an xterm console from the core. Xterm is old and the xpce based consoles do much better multi-console interaction.
Simpifly threadutil.pl utilities for multiple consoles.
Remove sources for building native swipl-win.exe from core
Remove Qt swipl-win package
Remove GNU readline package
As a consequence the GUI version support on notably Linux/*BSD and similar systems will be a bit handicapped for several years. Users of such systems can choose between the flatpak, building SDL and SDL_image from source and next the whole system from source or take the GIT source and use the X11 branch of xpce. The latter route probably deteriorates quickly.
Please comment if you see any problems in this.
edit It seems something went wrong with the Windows version. Hold on.
I am running on archlinux, with sdl3 and sdl-image installed (arch has packages for them). But the build doesn’t seem to use them (swipl-win just runs in the terminal).
Could it be that you did not switch packages/xpce to the branch sdl? Or checkout swipl-devel.git to the branch sdl. This branch is the same as master, except for the submodule commit for xpce.
Fixed. Pushed new versions for all platforms as it was mostly luck that only Windows was affected. Also added a resource display.theme to xpce to overrule SDLs theme detection. So, to select a theme regardless of what SDL claims, do
Open Setting/GUI preferences
Add one of the two lines below. The first is to force the dark theme and the second to force the (default) light theme.
display.theme: dark
display.theme: default
You can also create a new theme file and set this to the basename of this file.
Thanks. Updated the wiki. pkgconf is probably also required on Macports, but was probably already installed.
That is benign. I think I should add an empty light theme file.
Note that you can also start swipl-win. Then you do not get the main thread toplevel, only SWI-Prolog’s console.
SDL refuses to tell the DPI or physical screen size, claiming there is no portable reliable way to get this. I have to set the scale to 1.2 to get what I want. At least, the default should be readable as SDL works with logical pixels that are two physical pixels on hi-res displays.
Thanks. At least on Linux and the Mac it seems a real step forwards. It is a bit sluggish on my Windows VM, but that was also the case for the old version. I hope it works nice on bare metal Windows …
I have just tested the profiler and it is more legible now.
I noticed that the theme remains white if I launch xpce from a cmd top level ?
Unfortunately, I got one freeze with the debugger but can’t manage to reproduce the issue.
I also find the touchpad scrolling incredibly sensitive, but I suppose it is the same issue with lack of dpi information ?
Yes. That is probably wrong. It goes dark if you first launch a console, e.g.
swipl
?- epilog.
If XPCE’s theme is set to dark we should probably load this always …
If you manage to get something reproducible, please report …
I don’t think so. There are several translation steps between the SDL event and what happens in xpce. I don’t know how to interpret these. The simplest first step is probably to make one of them a class variable, so users can adjust.
Ok. SDL gives mouse wheel events from the touchpad. We merely use the direction, ignoring the amount and translate that into a rotation event. The scrollbar then translates this by default in a 20% page up/down. If shift is depressed it is translated into 1 line up/down and if control is depressed in 1 page up/down.
This works pretty much ok on my M1 Macbook (touchpad) and desktop (mouse).
I pushed a patch that allows for
?- debugpce(wheel).
That prints the parameters we get from SDL. From my mouse I get dy=+/-1 on every “click”.
While on the topic, the scroll direction is opposite to the rest of the window environment on MacOS. I have set the “natural” scroll direction for both scrollpad and mouse in the OS configuration.
Is there an option to either reverse the direction or respect the OS choice?
It appears that it says the direction is flipped, but also changes the reported direction. Pushed a fix that makes this work as expected, at least on MacOS.
Please keep reporting such issues. It greatly improves usability to get these things right.
