Yeah, I just found that - it needs 0.7 to be close to my other apps, but the default font doesn’t seem to render very well, and I can’t figure out the syntax to specify my preferred font (Bitstream Vera Sans). Oh, and the fontviewer app no longer works either:
$ swipl fontviewer.pl
?- fontviewer.
ERROR: @font_class/class: No implementation for: <-font_families
ERROR: @font_class/class: No implementation for: <-font_families
false.
“Not ready yet” seems to sum up the SDL3+Cairo+Pango support?
Yes, this much is clear, this is only in the development release. 9.2 has got none of this.
Yes, I can no longer figure it out either. I have once figured it out for MacOS, see this post:
I don’t know if this is supposed to still work; I no longer remember what I did to get these names specifically; and when I try it I see the following warning when I start:
$ swipl-win
Fontconfig warning: using without calling FcInit()
9.3.26 was to see how things are going 
A lot of stuff happened since. Please use git to get the current source. That should:
I think we are getting close. Lack of SDL3 and SDL3_image in most Linux distros is an issue. I’m afraid we have to live with that. The stable releases appearing now seem to have SDL3. On older versions the choice will be between using the flatpak and compiling SDL3 from source. That seems to work quite well.
9.3.27 should be around the corner
The issues I reported were with the current source.
I pulled the latest sources for swipl and all its submodules, and did a clean build:
$ swipl /home/peter/src/swipl-devel/packages/xpce/prolog/demo/fontviewer.pl
Welcome to SWI-Prolog (threaded, 64 bits, version 9.3.26-57-g68c7886ce-DIRTY)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit https://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).
?- fontviewer.
ERROR: @font_class/class: No implementation for: <-font_families
ERROR: @font_class/class: No implementation for: <-font_families
false.
Thanks. That makes things a bit curious. For the libraries, did you run ldconfig? I should think installing a library in /usr/local/ should work out of the box. At least, it did for me on Debian Bookworm and Ubuntu 24.04.
Is this using Wayland or X.org? And, if Wayland, which compositor? I’ve been doing the development using Fedora 42 using Wayland under Gnome. Wayland behaves quite different wrt window placement as it does not support the application to place the window, i.e., all is in the hands of Wayland.
It works quite different now. The good news is that it now works the same on all platforms and is much simpler. The resource is below. The values given here are the defaults for Linux. For MacOS and Windows other defaults apply. You can use the fontviewer (see below) to find a nice looking font.
font.pango_families: [ sans := "Noto Sans,sans", \
serif := "Noto Serif,serif", \
mono := "Noto Sans Mono,monospace" \
]
Probably the choices on MacOS and Windows work fairly well out of the box. I’m not sure how much variation there is in the set of installed fonts on Linux. Possibly we need to add some fonts. The Noto family seems popular with Gnome.
Yes, I managed to reproduce this. It is caused by a lazy initialization issue. Works fine if some font was created before opening the tool. I have a fix in the making.
I didn’t run ldconfig, as you say I would expect anying under /usr/local to “just work”, I’ve not had to run it before. It should be just a case of adding -L /usr/local/lib to the right place in the build files, but the current build mechanism is a black box to me.
This is Debian 12.11 + latest updates, Xorg and XFCE with the compositor enabled. I’ll fiddle with the window placement options and see if that makes any difference.
Does that go in the existing xpce/Defaults config file? Is there a corresponding font size directive?
Thanks,
Normally you must run ldconfig after adding files on the global libraries. CMake deals with the LDFLAGS and I suspect it will not create an RPATH if the library comes from a “default” directory. I’d prefer not to add any special tricks unless really needed and I think that should not be the case here.
No. If you use swipl-win, you have a menu Settings/GUI preferences. That gets you the GUI config file. If it does not exist it asks to copy the default that has just a lot of commented entries. You need to restart Prolog after editing.
I understand the “Noto” fonts are not present? According to ChatGPT, I should include the DejaVu fonts. I’ll do that for the release.
I’ve rebuilt after running ldconfig and things seem to work now - it might be worth adding a note to the build instructions?
Umm, that just seems to open the default ~/.config/swi-prolog/xpce/Defaults file?
The font.pango_families seems to work with Bitstream Vera Sans, but I’m still not clear how to specify the font sizes, is that still with font.system_fonts?
Twiddling with the XFCE compositor settings has no effect on the (mis)placement of child windows - the swipl-win main window placement seems ok, but the placement of ones opened from within it is not.
They do seem to be present on my Debian system but I’ve installed a lot of additional fonts, so I wouldn’t take that as being representative. As for ChatGPT, Debian & DejaVu - Caveat emptor 
UPDATE: I’ve just noticed 9.3.27 is out, as I’ve retested the above using a fresh clone of HEAD, all the above comments are still valid.
I updated the wiki page Building XPCE for SDL3 and Cairo · SWI-Prolog/packages-xpce Wiki · GitHub
No. If all is ok, this edits ~/.config/swi-prolog/xpce/Defaults. If this file does not exist, it asks to copy swipl('xpce/Defaults.user') first. As quite a few things have changed to the default file it might be wise to compare to the system version if you already have one.
Could you be a bit more specific on where xpce-win is, what child you open and what happens? Not sure what can be done. Pretty much nothing on Wayland probably as any placement hint is ignored. There may be more options when using the X11 backend.
If fonts are in general to small/big, adjust font.scale. If you want to rescale a font relative to the other fonts, change the size for that font in font.system_fonts. The tools mostly use the fixed and normal font aliases.
I’m happy to overrule I have the impression that ChatGPT is better than any alternative I can think of to answer the question what is the best default for a large variety of systems.
Yes, I filemerged my old version with the new one.
I’ve done some tinkering. From the console window, dialogs such as File->Open, Save etc all seem ok, they are created centred over the parent window. The windows opened by the Settings submenus, Split window etc seem positioned sensibly. However all the windows created from the Tools menu are mis-positioned off the right of the screen. And if I drag them back onto the screen, any children they create are mis-positioned as well, e.g. Thread Monitor Settings. So this seems to be specific to Tools - hope that helps.
That has done the trick, thanks. With that, I don’t have to fiddle with font.scale. With the help of the now-working fontviewer, what I’ve ended up with is:
font.system_fonts: [ normal := font(sans, normal, 8), \
bold := font(sans, bold, 8), \
italic := font(sans, italic, 8), \
small := font(sans, normal, 8), \
large := font(sans, normal, 12), \
boldlarge := font(sans, bold, 12), \
huge := font(sans, normal, 12), \
boldhuge := font(sans, bold, 14), \
fixed := font(mono, normal, 9), \
tt := font(mono, normal, 9), \
boldtt := font(mono, bold, 9) \
]
font.pango_families: [ sans := "Bitstream Vera Sans, sans", \
serif := "Bitstream Vera Serif, serif", \
mono := "Bitstream Vera Sans Mono, monospace" \
]
EDIT: The windows created by the File -> Show Buffer Menu and File -> Properties menu items in the editor are also mispositioned. Other similar ones such as Show Bookmarks seem fine.
At least a little I do have some more questions though.
The difference is that the Tools menu opens new toplevel windows, while the others create “transient” windows. The Windows from Tools use xpce’s persistent frame class, which restores the window position and layout remembered from the last time it was used. That does not work on wayland, but when I use
SDL_VIDEODRIVER=x11 swipl-win
that does work. It also works on MacOS and Windows. I’ve played a bit with this, but all seems to work reasonably. Well, if the remembered position is half on one and half on the other display, that is what is restored.
It makes no difference, in both cases the child window is positioned so the bulk of it is off the right hand side of the display the swipl-win main window is running on, with just enough left visible to drag it back onto the screen. My primary display is to the right of my secondary display, both monitors are identical. If I move the swipl-win main window between displays, the child is placed off the right side of whatever display the main window is currently on.
I’m running X11 and that’s not what’s happening for me. The vertical placement of the child window seems to be saved, but not the horizontal. On reopening the child window is still mostly off the RHS of the display. If the misplacement was a one-off it would be tolerable to just drag it back, but you have to do that every time you open the child.
If I remap my displays so that my primary is “logically” to the left of the secondary rather than the right, where it physically is, apart from making my head hurt, it does seem to (mostly) fix the problem. After opening and closing the errant windows a couple of times, they seem to reopen in the same position they were closed in. And if I drag the main window between displays and reopen the children, they are reopened on the same display as the main window.
At a guess, I’d say something is assuming that the physical display order is Primary:Secondary horizontally, in my case it’s Secondary:Primary and of course they could even be stacked vertically…
None of that reproduces 
Here is a bit of code that shows display layout and toplevel window layout details. In addition, you may use
?- debugpce(frame).
which will print various messages to the console. That might give a clue.
:- use_module(library(pce)).
show_displays :-
get_chain(@display_manager, members, Displays),
maplist(show_display, Displays).
show_display(D) :-
get(D, name, Name),
get_object(D, work_area, WA),
get(D, primary, IsPrimary),
ansi_format(bold, 'Display ~w~n', [Name]),
format(' Primary: ~w~n', [IsPrimary]),
format(' Work area: ~w~n', [WA]),
send(D?frames, for_all, message(@prolog, show_frame, @arg1)).
show_frame(F) :-
get(F, name, Name),
get(F, status, Status),
get_object(F, area, A),
ansi_format(fg(green), ' Frame ~w (~w, ~p)~n', [Name, Status, F]),
format( ' Area: ~w~n', [A]).
?- show_displays.
Display LEN T2424pA 24"
Primary: @on
Work area: area(1920,21,1920,1038)
Frame main (window, @11758009885808/epilog_frame)
Area: area(2636,98,839,768)
Display LEN T2424pA 24"
Primary: @off
Work area: area(0,21,1920,1038)
true.
?- debugpce(frame).
true.
% Main window on primary display, Tools -> Navigator, displays mostly off RHS.
?- Making @11758010637849/dialog part of @11758010637951/frame
Making @11758010637849/dialog part of @11758010642656/prolog_navigator
Making @11758010777009/window_decorator part of @11758010294557/frame
Making @11758010777009/window_decorator part of @11758010642656/prolog_navigator
Making @11758010298818/report_dialog part of @11758010642656/prolog_navigator
@11758010642656/prolog_navigator: passing position 3808,280
$ xrandr -q --screen 0 | grep Screen
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384
So it looks like the window is being placed where requested, it’s just that the place that’s being requested is wrong?
xwininfo: Window id: 0x4800066 "Prolog Navigator"
Absolute upper-left X: 3808
Absolute upper-left Y: 265
Relative upper-left X: 4
Relative upper-left Y: 22
Width: 208
Height: 564
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x4800065 (not installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +3808+265 --176+265 --176-251 +3808-251
-geometry 208x564+3804+243
Looks like it. Possibly the geometry tracking fails? While Prolog is running, this is kept in pce_config:config_store/4 and updated when you close the window. If you quit Prolog, this is saved to ~/.config/swi-prolog/xpce/Geometry.cnf.
?- pce_config:config_store(persistent_frame,
history/geometry/prolog_navigator,
G,
geometry).
G = '352x576--746+256'.
This uses good old X geometry notation. Not sure we’ll keep that, but for now it should be enough. If I recall well, this ix WxH-X+Y, where X,Y is the top-left corner. These values are negative if the window is closer to the right/bottom.
If I delete ~/.config/swi-prolog/xpce/Geometry.cnf then sanity is restored - at least temporarily. But if I open / close enough windows and then exit, the “Off the RHS” problem reappears, until I delete the file again.
Here’s what I see when it’s in the broken state:
- debugpce(frame).
true.
?- Making @11762263629936/dialog part of @11762263630038/frame
Making @11762263629936/dialog part of @11762263633651/prolog_navigator
Making @11762263636881/window_decorator part of @11762263821240/frame
Making @11762263636881/window_decorator part of @11762263633651/prolog_navigator
Making @11762263832798/report_dialog part of @11762263633651/prolog_navigator
@11762263633651/prolog_navigator: passing position 3808,234
?- pce_config:config_store(persistent_frame,
| history/geometry/prolog_navigator,
| G,
| geometry).
G = '208x564--1770+213'.
And here’s what I see save in Geometry.cnf if I immediately exit:
history/geometry/prolog_navigator = '208x564--1770+213'.
So if I’m reading it right, there’s a mismatch between where the persistency mechanism thinks the window has been placed and where it actually got placed. I don’t really understand what’s going on in sdlframe.c:ws_create_frame() but some of that fiddling with (x,y) coordinates looks a bit strange to me.
A geometry of -1770 is wrong on a 1920 wide screen. It should decide between positive and negative depending which edge is closer. -1770 is almost left, so this should have been 150.
Most of this code has not been reconsidered. In part because Wayland ignores this anyway and for it still works pretty much ok. I’ll see whether that also holds for all intermediate results. It could well be that two bugs cancel each other in my setup.