Tinker uses pretty much the same highlighting design as PceEmacs (sharing the Prolog highlighter), but it is no match. Where PceEmacs can comfortably edit files of multiple MBs, the Tinker editor is merely for small files. The editor is also a much more capable clone of GNU Emacs.
Then there are all the other tools as well as the possibility for Prolog programs to easily do a little graphics. Yes, we could rebuild all of that in a JavaScript based application platform such as Electron, but that is quite a lot of work.
Updating XPCE seems a route that is less work, easier to manage and more lightweight. Using SDL, cairo and pango as basis it is easily extended with a lot of advanced graphics, gaming and multi-media stuff
SWI is already Electron, i.e. client server. Electron uses
Chromium as client and nodejs as server, SWI does simply
spawn an arbitrary browser as a client, and uses its own
HTTP module as a server. SWI has such an example app
integrated, that will show me some documentation.
Menu Item Help Browse PLDoc gives me. The same page
could also show advanced graphics, gaming and multi-media stuff:
?-
% Started server at http://localhost:57367/pldoc/
I would start from there and add the functionality of
prolog_ide/1 via a variety of HTTP served HTML pages.
There would be not much JavaScript involved, everything
Text handling is moved to Pango. This implies Pango is a new dependency. That gives better control over fonts, better support for international text and support for color glyphs (emoji, etc). Except the latter do not work on MacOS using the Quartz backend
The MacOS version seems pretty usable, using Macports for the dependencies. I assume it will also work using Homebrew. Could someone test this and report, including the dependencies?
Hi-res (retina) displays now work nicely out of the box based on SDL logical coordinates and Cairo scaling. This is also the first step to support multiple displays with different resolutions.
First step to move towards floating point coordinates has been implemented. Good thing is that that can be activated gradually on graphical classes mostly by changing the types in the involved arithmetic from int to double.
@kwon-young Fancy having a look at class arc? There are two versions, one for X11 and one for Windows. You can make a selection. I’m quite sure we’ll abandon the X11 and win32 backends.
As a vimmer (actually Neovim) and a heavy terminal user, I hope you won’t decide to stop supporting the terminal top level as it is a very important part of my workflow.
I always have a split with a neovim terminal on the right with swipl running from which I can copy and paste queries.
That is not the intend. There is a problem that SDL does not like running on a thread. This implies that for the terminal interaction we are back to the old days where the GUI runs in the main thread. For what is currently called swipl-win, the graphics frontend, the design shall be
xpce runs on the main thread
It creates a terminal with menus that runs the normal toplevel for the user.
I.e., the gui runs on the main thread and the user’s queries run in a thread. At least on no-Windows systems, the xpce-based terminal provides the usual terminal emulation, currently a good deal of xterm. That is sufficient to run the editline command line editor, less, color, bold, underline and OSC8 embedded URLs. With a bit of extra work it can probably also run vi
You can checkout the new window toplevel after building the SDL based xpce by calling
I just hope we can resolve the input delay on the cli toplevel when using xpce.
With my setup described above, I also use the graphical debugger, but the input delay makes the toplevel experience quite bad.
Let me know if you have another specific todo point I can work on, I really enjoy being able to help !
I assume so, but I prefer a desktop with a big screen to sort it out. There is a similar issue when trying to avoid the toplevel and only show the new terminal as GUI.
I’ve had a look at the todo list but most of them seems to difficult for me.
Maybe I could continue to help with the graphical part, like transitionning int to doubles ?
Or maybe this seems simple enough:
Use SDL_SetAppMetadata() and friends before SDL_init()
I have noticed something on fedora kde plasma 42.
When using an xpce sdl program, it will block sleep and screen locking after a period of inactivity.
I suppose this is the default behavior with SDL since it used a lot for games.
Maybe we should desactivate this ?
Welcome. The idea is to change the draw primitive in sdldraw.c to use doubles, change the prototype in sdldraw.h, remove the conflicting prototype in wstproto.h (this file will be cleaned at some point) and finally change the arithmetic in the graphical classes using this. Note that sizes,areas, etc. all use Int and the check is isInteger(obj), but in fact these are doubles. Use valNum() to get the double value or valInt() if you need an integer.
Go ahead
Would be better
P.s. Pushed some more fixes that causes swipl -Depilog to work pretty much as swipl-win does now.
Linux version runs pretty much ok on systems that have SDL3 installed. That are only the latest releases of distros that follow development fairly closely.
MacOS version runs fine too using Macports dependencies.
You can start what is probably becoming the new swipl-win as
(Most) fonts look ugly. Probably be fixable with better Pango specifications.
Text drawing (e.g., editor) is slow. I assume this can be fixed somehow, but as-is it would be a show-stopper.
Challenges
Integrate SDL event dispatching in swipl.exe read from console. Due to some console weirdness, this seems only possible running the console in raw mode. This means we must provide our own command line editor. I created a fork from BSD libedit that runs on Windows without a complete Unix subsystem. See GitHub - SWI-Prolog/winlibedit: Windows port for BSD libedit. Work in progress. If successful (and it looks promising) this means the Windows and non-Windows systems can get much closer in design and user experience.
Port the xpce-based Prolog terminal I/O to Windows. The Unix versions uses ptys. The hope is to be able to use Windows Pseudo consoles in a similar role and use BSD libedit as commandline editor in these terminals.
General issues
The new xpce code uses doubles for numeric properties. This blocks 32 bit support. I plan to drop the 32-bit Windows version as it got harder and harder to get 32-bit versions of the dependencies anyway.
Support older Linux distros. It seems there is a header emulation of SDL3 for SDL2 that may do the trick.
Packaging. Notably for Windows and MacOS. Use static libraries?
Distribution plan
Once the dust is settled, this should provide a much more uniform system across supported platforms. The UI experience should improve considerably. Unfortunately, we cannot compile the same source the old way and the new way, so there will be a moment that the development branch switches to this platform. Once that is stabilized it a stable version 10 should become available.
Comments, help, sponsoring, … are more than welcome.
A screen shot of the development tools under the new xpce. The lower-left window is the new “swipl-win” console. As you can see, it may be split into multiple consoles. explain/1 produces hyperlinks that can be clicked to open the built-in editor or, after configuration, the user’s preferred editor at the location found by explain/1.
I ran into the problem with stuff needing to happen in the “main” thread. According to the SFML docs, window memory management needs to happen in the main thread for Windows and MacOS, and MacOS also requires that events be polled in the main thread as well.
What exactly is the “main” thread? I guess it is a platform-specific thing in the OS thread library. But how does that work for a Prolog program, as opposed to a C/C++ program that is entered via main (int argc, char** argv)? Is the top-level the main thread? Consulting a source file does not create a new OS thread right (assuming the consulted file does not contain code that creates new threads)?
I am interested in the discussion about the console. I want to support a “REPL” style development environment for working with my graphical applications, something kind of like McCLIM.
This is where I ran into some trouble with the threading requirements: how is everything supposed to nest together? I can launch my app from the top-level, but then the top-level is blocked. I made it so I could create an xterm console by pressing “`” (à la Quake) but for development, I’d rather have a console that I can use with Emacs development tools, and then also have a more limited Quake-style console meant for user interaction with a running app.
Thanks for working on this, I will probably shift my project to be based on all the new stuff provided by this update.
SDL has similar constraints. The notion of the main thread seems to depend on the platform. It is claimed to be the thread that calls SDL_init(), which can only the first thread of the process on MacOS. Well, this now also seems to be the case for Linux, so the upcoming SWI-Prolog+xpce will respect that on all platforms.
It works now as follows
If the system is started as swipl it will nicely run the REPL loop on the terminal it was started from. At the same time, you can create GUI windows and all remains responsive. SWI-Prolog has a hook that it calls while waiting for console input to be ready. That hook runs the SDL event polling loop, watching for console input. If there is console input, the hook returns, Prolog reads the console input, acts on it and normally goes back asking for the next query, restarting the SDL event loop. So, the GUI is unresponsive while Prolog executes a query, but runs fine while Prolog is waiting in the REPL loop. That is a step back from how it was, where xpce ran on a separate thread. That can still work when using the SDL X11 driver, but not when using Wayland.
XPCE provides a class epilog that implements a VT100 terminal using a PTY on non-Windows and pipes on Windows to talk to a Prolog thread that runs a REPL loop. On non-Windows that provides a pretty decent terminal that can even run shell/1 as you are used to. On Windows there is some work in progress. Windows Pseudo Consoles are rather different beasts than Unix PTYs The Prolog REPL works mostly now. How well shell/1 will work is still unclear. The Epilog REPL has several nice properties:
Command line editing and history using libedit.
Terminals can be split horizontally or vertically or you can make new windows (all providing a new terminal in its own thread)
We can handle URLs embedded using OSC8 escape sequences in Prolog. This means that errors, etc. are clickable.
You can talk to the terminal from Prolog
You can start swipl -Depilog, which will create an Epilog terminal and make the main program hang without interaction, terminating when the last GUI window is closed.
This is all pretty hard. If you don’t mind using SDL, extending on the upcoming XPCE is probably the simplest way. Possibly you can help providing ways to integrate external SDL projects into this?
