The initial plan was to give xpce, the SWI-Prolog GUI library, a boost to keep it alive. As a result, xpce is now being moved to SDL+Cairo+Pango, providing an excellent cross-platform basis. See Home · SWI-Prolog/packages-xpce Wiki · GitHub. Besides making xpce portable, no longer tight to X11 or Win32 and ready for modern graphics (Unicode text, scaling, rotation, alpha channel, audio, video, gaming devices, etc), this changed the overall prospect.
XPCE is about to replace swipl-win.exe and the Qt based swipl-win used for the MacOS and Linux “App”. The core code for swipl-win.exe as been ported to the SDL+Cairo+Pango framework and wrapped into an xpce class. On top of that, I wrote Epilog, an XPCE/Prolog class that is a bit like swipl-win.exe, but
portable
Supports horizontal and vertical spitting and multiple windows.
Provides a VT100/xterm compatible console.
We now use the BSD libedit both in the swipl commandline version and the Epilog windows. The Windows version is based on a modified version of this library to run on a Windows console (for swipl.exe) as well as on plain pipes for Epilog. That implies we have the same commandline editor in all contexts.
Plan
The overall plan is to move to one coherent system on all platforms. This provides the non-gui swipl that provides libedit commandline editing and can run GUI applications if xpce is available as library. Next to that, we a version that opens as a GUI window, so it can be used as desktop “app”.
Use the Epilog version as app for all platforms. I wonder about the name of the app. We could keep swipl-win or change this to swipl-gui or swipl-epilog. Opinions?
Drop library(readline), providing the GNU readline commandline editor. It is currently non-functional and cannot be used in the context of epilog as it allows for only one instance in a process (its state is stored in a lot of global variables).
Drop Windows swipl-win and Qt package swipl-win on MacOS/Linux
Drop 32-bit support, except for the WASM version as long as needed. The non-gui commandline version can for now still be compiled for 32-bits.
Consequences
Linux Gets support for Wayland. We also get proper support for multiple consoles rather than relying on some tricky interaction with xterm. Building gets simpler as the dependencies are easier. The footprint does not change much as all dependencies are in use on the typical system anyway. We are ready when X11 gets really deprecated.
MacOS Gets support for native GUI, i.e., no need for XQuartz any more. Better international text support, better looking fonts. For now, no color glyphs (emoji) due to some limitation in Cairo+Pango for MacOS. Footprint is probably similar, replacing the bundled X11 client libraries and Qt libraries for SDL+Cairo+Pango.
Windows Console commandline editing, better swipl-win, better font handling. Eventually, probably, full Unicode support. As is, XPCE does not handle UTF-16 in most places. Footprint rises considerably as we replace direct binding to Win32 by SDL+Cairo+Pango.
Please share your thoughts. Any areas where this will be problematic? Opportunities?
XPCE apps run on my machine (as they do for many others, as has been the case for longer than I know). Yet, I cannot find any 3rd party apps built with XPCE, no 3rd party tutorials, books. Searching for XPCE in the packs shows nothing.
I suspect this is related to the fact that existing documentation and (lack of) examples make it very challenging to get started. This is not a technical problem.
Also, I suspect (if they are like me) many users of the apps built using XPCE, are using them for the (excellent) features that have nothing to do with XCPE in particular (syntax/error highlighting, code navigation, code formatting, tracing, profiling, etc).
What I’ve seen in new languages, is that the core distribution includes an LSP and/or TreeSitter, formatter, etc. And developers wire these into the IDEs/editors/tools of their choosing.
So I think there are a few things to clear up:
who wants XPCE to have a future beyond bare maintenance-mode.
who wants the functionality currently in the XPCE apps, but doesn’t need it IN an XPCE app?
who wants to build UI’s in Prolog in a way that doesn’t (necessarily) have anything to do with XPCE.
Note: I say all the above with deep reverence, gratitude, and appreciation for the vast amount work that has gone into SWI-Prolog and its ecosystem. And folly accepting that I might be the only person who feels this way about any of the above.
This sounds all great to me. Personally, I see a lot of potential in XPCE. To give it a sound, modern technical base may take XPCE even further. I’ve used PROLOG in a public founded project, implementing an algorithm including visualization. If I’d have good graphic capabilities inside SWI, many things were be easier. The solution these days was to go over Websocket/Browser and JS libraries. But I don’t want to to bother with JS or other procedural worlds, I’d like to stay in my declarative PROLOG world. And I’m sure, XPCE as of today is only the beginning.
Having said this, of course it is work, and it has to be assessed if the effort is valuable or appreciated by users. But for me, to a powerful programming knowledge system a modern looking and powerful GUI/Graphics possibilities is a big plus . Maybe I’m wrong.
So for me, SDL sounds good, Cairo and Pango too. I would be glad if it would possible to go the way on.
Thanks for your insights. XPCE was quite popular in the 90s and a bit later. It was an important asset of SWI-Prolog back then. Quite a bit of large academic, but also commercial stuff was written in it and it was even sold commercially. Around 2005, SWI-Prolog’s focus switched from local GUI to (web) services and web applications.
For nearly 20 years the plan was to eventually move the IDE tools elsewhere and the communication was that xpce was deprecated, but not expected to die any time soon. Quite a bit of the logic has been decoupled from the GUI to support several other IDE projects.
Moving to a new GUI platform never got real traction though. Developed in the 80s and early 90s, xpce is extremely lightweight by today’s standards The new version now runs on top of SDL+Pango+Cairo, a platform that is supposed to be fairly lightweight and portable, but a lot bigger than xpce itself I now also have a much better replacement for swipl-win, both the native Windows and Qt version. It is heavier than the native Windows version, but lighter than the Qt version. I’m fairly sure this is a future proof and good basis for the IDE tools.
Whether it has any value as a Prolog GUI platform, I don’t know. It should be fairly trivial to revive the old LaTeX manual. It is also pretty trivial to extend it, for example to support audio and video or a drawing canvas by wrapping the Cairo drawing primitives.
I expect a public release within a month. Building and packaging on Windows is resolved. I can build it on MacOS, but creating a MacOS app needs a bit more work. Linux works fine from source on distros that have SDL3, but that is really new I’ not sure how to resolve that. Is seems there is a header-only wrapper that provides SDL3 functionality on top of SLD2. Alternatively, there is flatpak or building SDL3 from source as part of the project.
ECLiPSe Prolog uses Tk, cross-platform widget toolkit that
provides a library of basic elements of GUI widgets for building a
graphical user interface (GUI) in many programming languages.
It has some features that XPCE doesn’t have. Like turning a
drop down menu into tool window. Just click on the - - - - -:
This can be useful if you have a large number of debugger
commands, and if the icons are not obvious. And hoovering over
icons to see what they say can be annonying.
But having detachable tool windows or document windows
(often called “tear-off” or “dockable” windows) is a little neglect
UX design I guess. Making things “dockable” is for example not
These are definitely not a good reason to switch away from xpce. Switching away requires reimplementing most of the IDE tools, which is quite a bit of work. Providing tear-off menus would be fairly trivial. A popup/pulldown menu is just a menu that pops up in a new window, so all you have to do is clone the menu and put it in a new toplevel window.
Tiling a toplevel window into multiple windows is implemented in xpce, also dynamically adding and removing tiled windows. The new swipl-win window uses this to implement splitting the console and create more of them. Drag and drop inside xpce is implemented (from outside only receiving drops and not yet in the SDL version). It should be fairly trivial to drag/drop windows to other toplevel windows. The main thing is feedback on where window drops in the tiles. This probably requires transparent windows that were never part of xpce, but SDL supports them. That would allow creating a semi-transparent window with an image of the thing you drop that you resize and move while dragging.
What is not implemented is to display multiple tiled windows inside a tab. As tiles are general layout managers that merely divide a rectangular area into multiple tiles while they are pretty agnostic about what they manage, this should not be too hard.
Implementing a docking/undocking mechanism for the IDE tools is surely on my wish list as the current GUI with zillions of floating small windows is a quite dated
No. You have to write the file using the menu or Emacs ^X^S command. If you quit Prolog it will check whether there are unsaved buffers (if you do not crash too badly). PceEmacs checks during editing whether the file is modified externally and if so prompts what to do. All pretty much the same as GNU emacs. Edit buffers stay around as long as the process lives (unless killed explicitly) and maintain an edit history that is limited by a memory area per buffer allocated for this purpose.
I never felt the urge for integrating a version management system into the editor. It is a free world, so anyone can do this by writing a bit of Prolog. If deemed useful, I’m happy to merge it.
And ideally the installed system is write protected for the normal user
Prolog is a different language edit/1 uses reflection on the loaded Prolog program. It is based on a multifile hook that, given some term, generates candidate locations. After that it merges duplicates and either says it cannot find anything, edits the only candidate or presents a menu. With the command line editor completing on atoms, this is pretty efficient for finding things. In addition there is explain/1 that, given a term, tells you everything it knows about it, using the hyperlink capabilities of the terminal to create links if possible. This notably exposes references to objects.
So, it does not look at any file and files that are not loaded are not considered except that one rule considers files in the current directory candidates. If you want to look through files there are the Emacs commands M-x grep and M-x git-grep. I use them rarely when programming in Prolog.
Yes I’d like to see the day we can stop this as it would seriously simplify things. This is slowly approaching as WASM64 is approaching and most small devices get 64 bits.
On my personal wish list, I would love to have a drawing canvas with svg like path drawing capabilities.
Unfortunately, even after poking a lot at the pcedraw program, I still cannot understand how the framework works.
For example, I tried to switch ellipses to arcs but failed to make any meaningful changes.
The code is so foreign that I couldn’t understand what I needed to do.
What would that mean? Yes, class ellipse could have been arc with a start and end angle, but as is they are two classes.
That requires some thought. I think cairo can do the basics for you, but we’d have to think about a way to wrap that. You probably want a path class that contains a list of things that map to cairo’s lineto(), etc. That might be a extension of the current path that is merely a sequence of points through which you draw a line, either using straight fragments or bezier curves (if I recall well).
I just meant that pcedraw uses the xpce class ellipse to draw ellipse and I tried to switch the xpce arc class to back the ellipse drawing.
Would you consider a breaking change of the path xpce class to support svg like path or would it be safer to create a new class ?
As it stands, I don’t think that the current path xpce class is very useful, I suppose it is only used in pcedraw.
To implement svg like path, I think we should follow the svg spec: SVG Path which shouldn’t be too hard as cairo has all the corresponding primitives.
That will indeed be non-trivial. The specification is different (area vs. center+radius+start/end angle) and thus the whole interaction would be different. You get there, but it would require to subclass arc and add the area-based interface (which requires some arithmetic). Next you could extend the property menu to include start/end angle, etc. That is not a starter job
Probably a new class. It is not clear how you should unite them. Might be possible though. It is now a list of points, which translates to moveto for the first point and lineto for each subsequent point. If you allow for other objects in the list, it might work. The role might be different though. xpce defines graphical objects. An SVG path is something you use for subsequent operations. Up to writing text along it if I’m not mistaken.
As is, you can create arbitrary graphical objects by subclassing class graphical and redefine ->_redraw_area. Wrapping cairo in methods on class graphical would allow defining new graphical objects in terms of cairo drawing operations.
We could also look for a (partial) SVG renderer and create a class to wrap that.
There are quite a few options, each with their pros and cons. It is not on my priority list, but if your or someone else wants to work on it, I welcome it.
My priority is to be able to create a SWI-Prolog release based on the SDL/cairo/pango based xpce. I reached a new milestone: a universal binary MacOS app That is indeed smaller (30Mb vs 42Mb) and no longer needs X11 on the Mac. Text looks cleaner and supports full Unicode including color glyphs (emoji, etc). No more Qt and the confusion about two graphics systems in one application
Okay, maybe I’ll try to work on it if I have some free time in the coming weeks.
One thing I also want to support is to be able to do path filling like in svg, so that I can render musical glyphs ^^
Yes, of course. I am rooting for your work. Let me know if you want some user testing or small PR I can help you with.
You are now using the Linux version, no? Does that run reliable? On Fedora I experience two crashes with some frequency (once or twice a day), one with getRootGraphical() near the top. That is most likely a bug in xpce. For the other is less clear who is to blame as it happens deep in the Gtk code for the window decoration while waiting for an event.
I’ll probably put the MacOS and possibly the Windows installers online shortly to get feedback.
Unfortunately, my use of xpce is almost exclusively through the debugger, since I don’t use the builtin editor.
But, yes, things are mostly stable for me, although one annoying thing is that I can’t kill the debugger with a ctrl-c from the toplevel in the terminal.
I see. It works fine if you use swipl-win. This can hopefully be fixed. In general, I’d expect the user experience to drop a little when using the IDE tools from swipl. That is because it is not portable to run xpce on a background thread as we were used to using X11.
My hope is to get swipl-win good enough such that most people will use it as the primary interface. I’ve done so for the past couple of weeks and I’m pretty happy with it.
If this lands fairly well, I’d like to replace the old xpce and Qt console ASAP. Next steps will be to consolidate this and after that start a new stable/devel release cycle.
Besides improving this initial version there is a serious issue wrt. notably Linux distributions. Only a few distros already support SDL3. Almost all support SDL2. Unlike some indications I got before though, there seems to be no reasonable way to run the SDL3 code on SDL2 systems. This means we have various options
Build SDL3 and SDL3_image from source to satisfy the dependency. It seems these packages can be compiled happily on most systems. Including the sources into the source distribution seems unreasonable though. What are the implications for the distro package managers?
Ditch support for the IDE tools and app for older versions. They can still use the flatpak version for that.
For some time provide two source tar-balls, one providing the old xpce and one the new version. Seems doable, but rather confusing.
… Ideas?
If we can continue this, the plan is also to
Ditch the GNU readline interface package. The two commandline editors are mostly confusing IMO.
The new version now runs on top of SDL+Pango+Cairo, a platform that is supposed to be fairly lightweight and portable, but a lot bigger than xpce itself 
I’ not sure how to resolve that. Is seems there is a header-only wrapper that provides SDL3 functionality on top of SLD2. Alternatively, there is flatpak or building SDL3 from source as part of the project.
