since some years I use SWI Prolog successfully, and all the time there was the question how to do graphics or simple visualizations. The last years I used a Web solution with Babylon.js and Websockets, but I looked at XPCE and Java integration, too. Related to XPCE, which is the base for the SWI own tools, I asking myself what the future of XPCE will be. As far as I read in some posts here, XPCE is not maintained, and in someway “dead”. But SWI uses it, so what are your thoughts about future releases of SWI (maybe for direction 10.0) ?
It won’t disappear any time soon. Even some work on it has been done recently to support hi-res displays by scaling images and (with some luck) getting the default font scaling “correct”.
Don’t expect new features or bug fixes. Portability issues, in recent times mostly due to moving the C standard and C compilers dropping K&R style declarations and getting more picky on prototypes, will be applied.
The main issue is that X11 is slowly being phased out. For Linux integration we should at some point move to Wayland and for MacOS it would be much better if you would use native MacOS graphics. I don’t know whether none, one or both will ever be done. That depends on opportunities to get funding, someone willing to implement this and how fast X11 deteriorates or disappears. Moving away from X11 is certainly doable. I’d expect it to take a month or so for an experienced C programmer.
Thank you for this answer! Just my opinion: SWI is so a great system and tool, it seems to be worth it to get a modern GUI/Graphical module (ore package). But of course, someone has to spend the work…
Anyway, some small personal remark: Since I started working on the SUN Workstations in early 90ies, I liked the X11 thing - the possibilities, and all the things on its way, PHIGS, Motif and more. Display Postscript of NeXT was a great evolution, and now we have the Web… If X11 would disappear it would be somewhat sad, even it may be logically from a technical point of view. If there is somewhere something to read about the history or technical evolution of XPCE, its roots, I would like to read it
Yes, but it is a bit hard to make a decision. XPCE’s integration with Prolog is nice. But, the system is not very memory-safe and single threaded. The latter might be good enough. It was originally written by Anjo Anjewierden for SunView. I ported it to X11 in the early 90s. Besides porting, xpce stopped using the system widgets and only used basic window and drawing facilities from the OS/Graphics. This allowed me to abstract the OS/Graphics binding in the mid 90s and create a second implementation using the Win32 native graphics API.
The advantage of do-your-own widgets is full portability. The price is that it needs a lot of work, especially if you want to stay in sync with modern GUI development and style guides. So, it still mostly looks like old Windows or old Gnome It doesn’t do proper scaling (everything is a pixel), doesn’t do alpha channel or transformations. Part of it is hopelessly complicated due to the support of all the complicated colour handling of old X11.
So, where to go? Some options:
Revive xpce. Fix all/some of the above and either find a portable abstraction over Wayland, MacOS and Windows or continue on the basis of the existing abstraction.
Conclude this is not core business and let the user find something else. E.g., using web technology, Java, Python, Electron, …
Implement something new based on current technology. Adding good libraries and guides to implement based on Electron could be an option. A good binding to e.g., Gtk could be another.
This status quo exists for a long time and nothing happens as it is not a priority. It can change if some party with resources wants to see it change and invest in these changes.
For GUI you might like to try raylib. I have been working on raylib bindings for SWI prolog. It’s been a way for me to develop my C and SWI Prolog workflows and learn more about foreign function interfaces. While raylib is mainly targeted as a “games library” it’s mostly a wrapper around openGL and SDL plus some extra game freebies you can take or leave. I know at least one person who, for example, wrote a text editor in raylib. I have some prototype examples of how to connect swi prolog and raylib, I just uploaded them to github here: Github.com/ai-robert/raylib-prolog-poc
While I’ve picked up and put down building bindings for the entirety of the raylib library, you can see from my example posted that if you only need a handful of raylib functions then it’s easy to just add a few bindings for just those functions.
I took a quick look at your code … you need to check return codes from almost all PL_() functions. If you use the C++ API instead, you don’t need to check – it throws C++ exceptions and catches them in the PREDICATEs. You can mostly mix the C and C++ APIs if you wish – if you want to minimize the conversion work, the C++ API also provides Plx_*() wrappers for the PL_*() functions, that do the error checking for you.
Instead of printf(), I suggest using Sdprintf() to use the SWI-Prolog streams.
Interesting. I had a short read into the raylib - cheatsheet. It looks like a pretty clean match to xpce’s low level binding when we look at the level. It might actually be an interesting match. If we would rebind xpce based on raylib, we’d get
Proper cross-platform, notably improving the situation on MacOS and making the Linux version more future-proof
(I guess) abstract away from pixels, paving the road for transformations.
Extend xpce to support Raylib’s more advanced features (OpenGL, audio, …)
I wonder in how far LLMs can help implementing that. They might not be bad in translating stuff.
That would be so great! I also have the impression that raylib would be a great modular and cross-platform implementation layer of XPCE - and it may be a start to evolve XPCE in direction of new concepts (camera, transformations…) and declarative ways of defining graphics (Vega…). Ok things of the future, but even a XPCE as it is with raylib as render framework would great thing.
Well, I spent some time with ChatGPT The good news that with its help I managed to create a new binding that solely consists of stubs in just a few hours. It even documented the stubs, though the quality of the docs varies between impressive to plain wrong. Well, that is what one expects. Anyway, I pushed a branch called raylib that provides src/ray holding the empty binding. The system builds for this binding as well as the x11 binding (didn’t test Windows yet).
The bad news is that raylib supports only a single window. That is not a match for xpce So, I think this route has failed before it started. Well, the empty binding with documentation is quite valuable A simple sed script should be enough to rename the binding to something else.
ChatGPT recommends SDL, GLFW or RGFW (considered less mature). Opinions?
I’m surely not going to turn this into a concrete project. I am interested in the options though and I’m particularly interested how far LLMs can help doing a lot of the work. For the first step I’m fairly happy. It took about an hour to get ChatGPT to understand what I wanted, an hour to go through the various files and another hour to adjust the build process and resolve some issues to make the thing compile and link. Without, this certainly would have taken several frustrating days of typing
I got introduced to GLFW via Ada and others. It seems to be very portable and useful, but I my knowledge is too limited to compare it to SDL or others. It’s interesting to read that LLM is such a big helper already.
I’ve been doing some experiments with quite a bit of help from ChatGPT Current state:
I have a rudimentary working xpce based on
SDL3 for window management, clipboard, etc.
Cairo for 2D graphics, i.e., the content of windows.
Currently only tested on Fedora 42 using Wayland. In theory it should work practically unmodified on almost anything, including mobile platforms. It would notably get rid of the need for XQuartz on MacOS.
You can find the source on the sdl branch of xpce. If you want to play with it, you need the git version of swipl-devel. I.e., get swipl-devel from git, go to packages/xpce and run git checkout sdl there. Next, build and install normally.
Rudimentary means that most of the IDE tools run, though not very stable, with some graphics glitches and some missing graphics.
It seems worthwhile to continue this. There is still quite some work to do though. I’m asking for your support to make this possible. Think about
Supporting using GitHub sponsors.
Supporting directly (contact me if you need a quote, invoice, …)
Help coding, porting, testing, etc.
Phase A
Complete graphics support to deal with all basic tools that are part of xpce.
Fix stability issues. Part seems related to the figuring out the correct way to interact with (Prolog) threads.
Make the build work for MacOS and Windows. MacOS should work practically out of the box, Windows needs a bit more work as dealing with async I/O is based on Unix facilities.
That would make it a viable replacement for the current state. From there, we can continue
Phase B
Cleanup a lot of rublish. Think notably about colour, image and display (monitor) handling. All that is based on X11 and horribly complicated.
Port swipl-win.exe to use this infrastructure. That would make it a better and cross-platform, so we can ditch the need for Qt (sorry, @CapelliC, getting rid of this complicated dependency seems worthwhile). One option might be to merge swipl-win into xpce.
Use Cairo’s power by adding transparency and transformations (rotate, scale) of arbitrary graphics. Move PostScript generation to Cairo and add support for PDF.
Use SDL’s features to add support for sound, video, etc.
Modernise the widget set.
Get nice looking icons. Note that it already uses SDL’s image loader, which means it can already load .PNG.
Again, opinions, but notably help is welcome. Financial help is great. Help in (C) coding, generating tests (Prolog), testing, icon design, etc. are all very welcome. Depending on feedback I’ll organise the project to facilitate cooperation.
I fully agree. By myself, I did some small experiments using Dear ImGui, but nothing worth further deepening.
Just in case, maybe I could help to port swipl-win.exe to the new architecture.
Good to know. Funny that ChatGPT also suggested Dear ImGui if native menu support was a requirement.
SDL3, nor Cairo support widgets. That is fine, as xpce has its own based on its graphics primitives. ChatGPT suggests implementing swipl-win based on the xpce low-level binding and using xpce for the menu. This is fully portable. Next, it suggests Dear ImGui or platform specific support for selected platforms. For Windows, we already have that code as part of swipl-win.exe.
That all makes sense to me ChatGPT is quite useful in evaluating design choices. Of course, it remains an unreliable tool in the sense that its answers vary from nonsense to brilliant.
Thanks and thanks. For now, the target is Linux. Mac will be next once the Linux version is usable. Of course, unless someone wants to do the porting earlier
It doesn’t do proper scaling (everything is a pixel), doesn’t do alpha channel or transformations. Part of it is hopelessly complicated due to the support of all the complicated colour handling of old X11.