X-Window XPCE debugger

I’m using: SWI-Prolog version 8.3.22

I want the code to:

I’m trying to use the graphical debugger on Linux (Kubuntu 20) but the spacing of characters at the XPCE window is too wide making the code very difficult to read.

To open the debugger I’ve done the expected:

:- spy(examples), gtrace.
:- examples.

Is this a bug?
Many thanks for any advice about how to overcome this problem.

-Francisco

Not very nice. It is probably some weird mapping from the FontConfig library specification asking for a fixed font. The way out is to start the editor (?- emacs.) and use the Edit/Editor preferences menu to create.edit a config file. Near the end you find
display.system_fonts. There you need to change the fixed and tt fonts. To what is a bit harder. There is a related discussion on Config font names, nothing happens

Looks like UTF-32. Problem with UTF-32, it can even not
read an encoding/1 directive and a BOM would be ambigious.

You can try examples here (mythology.lgt):
https://\github.com/LogtalkDotOrg/logtalk3/tree/master/examples/encodings

If you look at the BOM table, UTF-32 is not covered:

static const bomdef bomdefs[] =
{ { ENC_UTF8,       3, "\357\273\277" }, /* 0xef, 0xbb, 0xbb */
  { ENC_UNICODE_BE, 2, "\376\377" },	 /* 0xfe, 0xff */
  { ENC_UNICODE_LE, 2, "\377\376" },	 /* 0xff, 0xfe */
  { ENC_UNKNOWN,    0, NULL }
};

And I am not sure whether it would make sense, UTF-32 LE could be
FF FE 00 00, which has same start as UTF-16 LE FF FE. So byte look-a-head
would increase to 4 bytes, and assumption text doesn’t contain 00.

But even if the Prolog system would understand UTF-32, not sure whether
tooling also understands it. Although I saw that my IDE editor could
open mythology.lgt.

I have had the same problem on my Mac for a few months. Does anyone how to figure out the 4th argument to font() on a Mac so that I can try the fix described in the linked discussion?

The MacOS version uses X11, so it is the same as the Linux version. Both use XFontConfig.

1 Like

The <span style="letter-spacing:.."> look is sometimes
result of decoding an UTF-32 file with UTF-16.

If the OP would show us his Prolog text,
investigation could continue.

Thanks for the tips!

The installation for Ubuntu I was using had no ~/.config/swi-prolog/xpce/Defauts but emacs/0 created it as Jan said.

The new Defaults had all the display.system_fonts configurations commented out with !, which I deleted …

Upon restarting swipl, the system fonts were loaded, solving the spacing problem.

It works :wink:

PS: The display.system_fonts part:

display.system_fonts: [ normal := font(helvetica, roman, 12),
bold := font(helvetica, bold, 12),
italic := font(helvetica, oblique, 12),
small := font(helvetica, roman, 10),
large := font(helvetica, roman, 14),
boldlarge := font(helvetica, bold, 14),
huge := font(helvetica, roman, 18),
boldhuge := font(helvetica, bold, 18),
fixed := font(roman, roman, 13),
tt := font(roman, roman, 13),
boldtt := font(helvetica, roman, 13),
symbol := font(symbol, roman, 12)
]

This half-solved my problem (on MacOS Big Sur with an up-to-date xQuartz installed). I still had to use the 4th argument of font(), so I have something like this now:

fixed     := font(screen,    roman,   12, 'mononoki-12:Regular'), \
tt        := font(screen,    roman,   12, 'mononoki-12:Regular'), \
boldtt    := font(screen,    bold,    12, 'mononoki-12:Bold'), \

and it looks as intended.

@jan is it so that the editor tries to make “bold” by offsetting by a couple of pixels? And which of “fixed” and “tt”/“boldtt” are actually used for Prolog code?

Yes :frowning: That was from the old days. Using a proper bold font wouldn’t be hard as long as we can guaranteed the dimensions match. Probably just means a little tweaking for the style setup to match bold to changing the font.

I grep shows it uses fixed. See fundamental_mode.pl

1 Like

To be honest I never noticed it on my Linux installation, probably because that laptop has a monitor with fairly large pixels and so less pixels per glyph. I never had to set it up in any particular way either, all the XPCE GUI stuff worked perfectly out of the box.

It is still not clear to me whether we are altogether moving to a “HiDPI” aka “Retina Display” monitors. You can buy those but they are still very expensive and I don’t see people rushing to get them, unless they come with a machine someone else buys for them.

This is relevant because my experience in the past couple of years with SWI-Prolog’s GUI and high-resolution screens has been a bit mixed. It works after some setting up but it is obviously not designed for it (I think @peter.ludemann has been struggling a bit with it too?). On the other hand, many other “native” IDEs I’ve had to use had the same or even worse usability issues.

Well, the bold fonts do not use proper anti-aliasing and tend to look a bit rough on the edges. Font scaling using the Defaults file should work fairly well as there is a single place where you can scale all fonts. One problem is the icons which are all designed at the final low resolution (16x16, 24x24 or 32x32). They are searched over a path, so the simplest solution would be to have a second set for HiDPI screens. Luckily XPCE layout has been designed to avoid explicit pixel positions (they were pretty much common when xpce was designed).

I think the biggest step to make it all look a bit better would be to design proper icons and do a little work that allows for a scaling factor for icons. As scaling itself is already part of XPCE that should not be too hard.