Built-in editor is very tiny

[maren]

After years of prolog use, today I finally decided to give the built-in editor a try. Unfortunately, it is simply unusable for me in its current state, and I’m not sure what to do about it.

The editor is so tiny that it is impossible for me to read anything. I suspect it’s not really designed to work with high density screens. I hope things can be reconfigured, but it is hard to figure out how to do that when everything is really tiny, as I just can’t see what any of the menu options actually are.

Is there some option or setting I can use to make everything bigger?

Edit: it is not just the editor. The graphical debugger is doing the same thing.

[maren]

After a lot of sitting really close to my monitor I think I got it.
~/.config/swi-prolog/xpce/Defaults can be supplied with font information, including default font sizes.
A default config can be generated in this location by going to Edit->Editor Preferences (second menu from the left, then second item from the bottom) and saving. This can then be modified in another editor that is not super tiny to increase all font sizes.

I ended up going for this

display.system_fonts:	[ normal    := font(helvetica, roman,   60), \
			  bold      := font(helvetica, bold,    60), \
			  italic    := font(helvetica, oblique, 60), \
			  small     := font(helvetica, roman,   50), \
			  large     := font(helvetica, roman,   70), \
			  boldlarge := font(helvetica, bold,    70), \
			  huge      := font(helvetica, roman,   90), \
			  boldhuge  := font(helvetica, bold,    90), \
			  fixed     := font(screen,    roman,   65), \
			  tt        := font(screen,    roman,   65), \
			  boldtt    := font(screen,    bold,    65), \
			  symbol    := font(symbol,    roman,   60)  \
			]

Which is 5 times the default size.

While that did work for the text, and that was my biggest gripe, the mouse icon is actually also very small, and I’m not sure what other issues might be lurking. A single scale option would be nice.

[maren]

Turns out there was a much better option for setting all font sizes at once:
font.scale: 5.0
Still got a tiny mouse though.

[peter.ludemann]

How to set font size on graphical debugger?

The font.scale variable in the “Editor preferences” is also used for the debugger. You can edit it in PceEmacs, just start it: ?- emacs. and then go to “Edit” --> “Editor preferences”. I don’t know how to “reload” the settings. I had to “halt” and then start the interactive interpreter again for the changes to take effect.

[maren]

I could have sworn I searched discourse before asking clearly not as there’s been several topics on this. Apologies!

[peter.ludemann]

One obvious question is: maybe the default values should be changed?

(And don’t feel bad about searching for an answer and only finding it when someone points it out – that’s happened to me a few times.)

[m_ac]

Just throwing this out there, reddit user toblotron is also working on an IDE Praxis if anyone wanted to give that a try.

[jan]

@peter.ludemann

One obvious question is: maybe the default values should be changed?

We can easily do so if we can (mostly) reliably find the dots-per-inch of the screen.

@maren

the mouse icon is actually also very small, and I’m not sure what other issues might be lurking.

Unsure about the mouse. I thought that was not under the application control. XPCE just selects one of the default X11 mouse shapes (although you can set specific icons). The other issue is about icons. These do not scale That should be “fixable”. The big problem with XPCE is that it was designed in the times that graphics was pixel based

If you are an Emacs user, sweep gives about the same functionality under GNU Emacs.

[jan]

@maren

Turns out there was a much better option for setting all font sizes at once: font.scale: 5.0 Still got a tiny mouse though.

With the latest release, I can do in Defaults:

display.dpi: 200
font.scale: @display?dpi?width/75
image.scale: when(@display?dpi?width > 150, 2, 1)

This gives me pretty much a nice interface on Asahi Linux on a Macbook air (2560x1600 at 13.3 inch). The DPI rescales some sizes (surely not all, but enough for the IDE tools). The image.scale allows scaling all built-in images and images loaded from a file. Only works on X11 right now.

As for the cursor, the cursors in the cursor theme are fine, but those not defined in the theme seem to come from the X11 cursor font and they are tiny. That is not an xpce problem but a generic X11 problem. It seems there is a work around by installing a rescaled cursor font. Most of the links on the page I found where broken though.

I just discovered that MacOS XQuartz solves this by presenting a lower res screen to the application and scale everything. Now it looks better under Asahi Linux though

[peter.ludemann]

On my Chromebook, I removed the display.dpi setting in ~/.config/swi-prolog/xpce/Defaults and replaced my font.scale: 1.2 with

font.scale: @display?dpi?width/100
image.scale: when(@display?dpi?width > 150, 2, 1)

Is there a way to find out what the default values for display.dpi, etc. are?

BTW, for some reason, this required a complete rebuild of SWI-Prolog (when I tried my usual cmake+ninja, I got compile errors).

[jan]

@peter.ludemann

Is there a way to find out what the default values for display.dpi, etc. are?

Normally, the server tells the screen dimensions in pixels and mm. The pixels are typically correct, but it seems that it often does not manage to get the size in mm correct. I think that it assumes 96dpi if it does not know. So, I added the resource to overrule what it gets from the X server.

@peter.ludemann

, for some reason, this required a complete rebuild of SWI-Prolog

I should have warned about that. That is due to the introduction of a new identifier in xpce. Cmake has not been setup to deal with that automatically as we do for built-in atoms for Prolog itself. I’ve been too lazy for that and as xpce is in “maintenance only” stage I did not care. This is the first part of real development in many years because I’m locked to using my Mabook air under Asahi Linux

[peter.ludemann]

@jan

Normally, the server tells the screen dimensions in pixels and mm.

Is there an “easy” way to see the values from the server? (That is, the values of display.dpi, font.scale, etc if there is no override value in the Defaults file)

[jan]

@peter.ludemann

Is there an “easy” way to see the values from the server?

From xpce by removing the dpi setting and asking for it. From X11 using xdpyinfo. That emits a lot of stuff. On this Asahi Linux on Macbook Air M1, with a bit of digging in the output, you see

screen #0:
  dimensions:    2560x1600 pixels (677x423 millimeters)
  resolution:    96x96 dots per inch

The pixels are correct, but the physical size clearly is not. It is a 13.3’’ screen, giving a 227 DPI resolution. I see some rumous that you can tell X11 about the correct sizes using xrandr.

[peter.ludemann]

xranrd will also give X11’s idea of the screen size.
Which is also wrong on my system:

$ xrandr
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 406mm x 228mm
   1920x1080     59.96*+

The actual size for a 16:9 13.3" (337mm) screen is 293mm x 165mm. And the actual resolution (which I found by looking through the message log for ArcDisplayLayoutHandler) is 168.165 dpi. (This is on a Thinkpad Chromebook)
I haven’t check this on Ubuntu.

So, these values produce a reasonable gtrace window for me:

display.dpi: 168
font.scale: @display?dpi?width/125
image.scale: when(@display?dpi?width > 150, 2, 1)

[jan]

Odd. The physical size reported by xrandr on Asahi Linux is actually correct. dpyinfo and the low-level X server requests (XDisplayWidthMM()) return the wrong value!? I wonder how that can happen …

[jan]

It seems that using the X11 Xrandr extension is the way to go to get the display properties. Added. It should also be possible to get rid of Xinerama multi-monitor extension using Xrandr. If anyone is knowledgeable or likes to sort it out, please do. You find all relevant stuff in xpce/src/x11/xdisplay.c

At least the gui scales now correct out of the box on Asahi

[peter.ludemann]

I wonder if the wrong sizes are something to do with the Wayland server? (At least, that’s what’s used on my Chromebook, according to xrandr)

[jan]

@peter.ludemann

I wonder if the wrong sizes are something to do with the Wayland server?

I don’t know. Asahi Linux (Fedora) also uses wayland. I do not know how the dimensions of the built-in display is obtained from the hardware. AFAIK, HDMI to external monitors has a protocol for this.

[ridgeworks]

Another data point in case it’s useful to anyone: when I downloaded 9.3.10, the apparent font size in X-Windows (XQuartz 2.8.5) doubled in size, so I had to alter my Defaults file to include

display.dpi: 100

to restore earlier behaviour.

The display (Dell 24-inch (3840 x 2160)) config according to xrandr:

$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1920 x 1058, maximum 3840 x 2160
default connected 1920x1058+0+0 0mm x 0mm
   3840x2160     60.00    30.00  
   1280x1024     75.00    60.00  
   1024x768      75.00    60.00  
   800x600       75.00    60.00  
   640x480       75.00    60.00  
   1600x1200     60.00  
   1920x1080     60.00    50.00    24.00     2.00  
   1280x720      60.00    50.00  
   720x576       50.00  
   720x480       60.00  
   2560x1440     60.00  
   1024x576      60.00  
   1280x960      60.00  
   1344x1008     60.00  
   1344x756      60.00  
   1600x900      60.00  
   2048x1152     60.00  
   2304x1296     60.00  
   3008x1692     60.00  
   3200x1800     60.00  
   3360x1890     60.00  
   1920x1058      1.00* 

[jan]

There is a lot said about Xquartz and hi-res displays. It seems that by default it presents a 96DPI display on the X side and scales this to the real display. I am now mostly running Asahi Linux on my Mac (except for using it to compile releases ), which presents the X11 display on the real 2560x1600 pixels. That looks a lot better!

Now, many (older) x11 applications did not properly support hi-res displays, so there is something to be said for this choice. Unfortunately it does not pass the correct dimensions.

Possibly you should look at HiDPI XQuartz - Aram's Wiki to make Xquartz behave.