Is the overly tall Status Bar a Windows idiosyncracy?

The status bard for Gramps on Windows 10 is as tall as the toolbar — that needs to accommodate big buttons. But it should match the text only menu bar.

Is it the same size on Linux and macOS?

It might be related to the mis-positioning of progress bars that are drawn below the font row (below the baseline, descenders & leading) rather than at the x-height. (Since Windows restores a full screen Gramps slightly offset to the right & downwards when the application is restarted, the bottom of the status bar that renders the progress bar, is typically off-screen.)

The capture above is using “Sans 12 pt.” instead of the default “Sans 10 pt.” in themes. (Due to my vision problems.) The disproportion looks even worse with the 10pt, as seen below.


Linux via GWSL to the left

Windows 11 to the right

I had to adjust the fonts for Gramps on Linux to 20 pt to match the size 11 pt on Windows.

The fonts and all the bars adjust with the font size.

This PrtSc is on Windows with 12 pt. and on Linux 22 pt.

I changed the font to “Liberation Sans” for both installations to have the same “Sans” font.

This is on a 4k monitor and I don’t think the GWSL has support for “native Windows High DPI support”, it’s a X-Server so the ppi is directly output from Linux so if I use 11pt or 12 pt the fonts and bars are incredible small (se under).

This is 10pt on Windows 11 on 1/4 of a 4K monitor, e.g., approx. 1024 ppi

This is full real estate 4K, Liberation Sans 10pt.

This is Sans 12 pt (After a reset to default on Windows and resized the font):

I cannot recreate that padding on my installation, but I do run the “Override the High DPI scaling” setting for the grampsw.exe (“System (Enhanced)” or “Application” is nearly identical in the scaling):

1 Like

Thanks for doing all those checks… and the reminder about the High DPI compatibility setting.

A question about when you run a backup, does the progress bar appear below the status text?

The size of my status bar is wasteful of screen real estate. But the off-screen progress bar has occasionally mislead me into thinking the application had locked up.

The progress bar for the backup is just over the bottom external edge, just like on your image, it is really smal and on the dark theme, the dark blue color is not that visible.

My backup is over in a few seconds, so difficult to create a screen capture of it, sorry.

But I can see that it can be difficult to see.
Maybe it should be red or really bright green, or at least a brighter blue color.
a centered progress bar with double height might also be an alternative…

1 Like

@emyoulation which Gramps version are you using. Gramps 5.1.5 should no longer have this issue. See here:

1 Like

Just another tips…

I find the “Liberation Sans Regular” a better font at 12 pt than the standard “Windows Sans” on Windows 11 with 4K monitor, it might seem that the padding is a little less on that font than on the default Sans, and that it is a little “crispier”

Thanks for searching for that. That particular bug 12373 has similar screen capture but is about a different (and resolved) bug.

Gramps was posting an extra warn and leaving a progress bar on-screen after the startup task was completed. This no longer occurs (thanks @prculley !)

The capture was during a backup… so having a progress bar was right. I just mistimed my screen capture and didn’t get the color portion showing a percentage.

But the screen capture does show that it is drawn lower (as compared to the text) than expected.

Cool! I’ve been limiting myself because of doing so many wiki illustration screen captures. Resetting was too much trouble.

But now that I’m addicted to the extra functionality of CardView, my GUI is too different. I have to launch the PortableApps instance anyway. (And the issues in this thread affect both … and a fresh install too.)

May have discovered the reason for the excessive height of the Status Bar…

It might be a Glade interaction related to locating the origin of the Ctrl+F Find box?

Nothing to do with the find box.
Nothing to do with the font size.
It is related to the margin top and bottom added to Gtk.Box, Gtk.frame, …

1 Like