On the current unstable, the status bar at the bottom on windows shows the date on the left side. When I click on a menu, the date disappears and the height shrinks by about half. When you start scrolling over some of the menu options that have a tip (is that the correct term), that text shows in the status bar at the bottom of the screen and it's height goes back to normal. As you move and hover over different options, the height of the bar is changing between small and big which also means the register is jumping around. This is distracting and even if no text is on the status bar, it should be the same height.
Forgot to mention, this is when a register view is open. When the account screen is open, the bar still changes heights, but only moves the summary bar up and down because the accounts view is pinned to the top of the view, versus the bottom like a register.
I can not see this on my Windows 10 machine so I think this could be local to you. Are you using any custom CSS, if so disable it and see what happens. If it is down to your CSS then I think you may have to fix so report back so the bug can be closed.
I see it on Fedora 31 as well. I noticed this a few days ago but didn't have time to dig deeper. Just to confirm it does exist. The jump is only one or two pixels so you have to pay attention to notice it. It probably has something to do with the status label being shown/hidden and that affecting the toolbar layout.
Oh, I have a fedora VM so can try that. The reason I suggested a CSS problem was I had kept a CSS file some one had created and used that and it is very noticeable on that, I think they were playing about with reducing the height of the bar by using negative numbers.
Mine is about 6-8 pixels of change when I do it (about half the height). I do have a .css file to increase the font size. Here are the entire contents of my css file: * { font: 10pt arial, sans-serif; } What's very strange is that when I have my css file loaded and the text disappears it actually gets shorter than with no css file and a slightly smaller font. With no css file, I see the bar does not shrink and stays the same height. The font size is pretty similiar between with and without. It looks like about a 9 without the css in the summary bar. If we decide it's working as intended and just a css update needs to be made, we probably need to update the wiki as this is the exact example given there.
Are you able to try the last nightly, I got rid of all the GTK version sections that are no longer required, here is the link.. https://code.gnucash.org/builds/win32/master/gnucash-3.902-2020-05-04-git-3.902-13-ge5e7b30f7+.setup.exe
I have just rebuilt with latest master on Fedora 31. It still shows this behavior...
I did wonder about Gtk version, just updated my windows build system from 3.24.14 to 3.24.17 and that has the obvious changes Matt was seeing with his CSS changes. Strangely on my Gentoo Linux VM I see no issue and that is using 3.24.18 Matt could you try adding this after the code above... statusbar { min-height: 25px; } You may need to alter the number to find minimum required. Geert, You may also like to try and see if it works for you, not sure if this a good fix or maybe status bar updates need to have a 'space' for empty text, not sure if that is the case now or not.
To confirm, the latest nightly still shows the problem, though it's different. It appears there is less padding on the bottom with the text, so the height doesn't change quite as much, but the problem is still there. Adding a minimum height into the css file does keep the status bar at a fixed height and the problem is not present. Don't know whether that is the proper fix or not either. I think using a space for an empty status bar text might be a better option as it would scale better with different resolutions, font sizes, layouts, etc.
Sorry, the version I have are 3.24.17 on my Windows 10 PC, 3.24.17 on my Gentoo Linux VM and now on Fedora31 I have 3.24.13 I do not see this on my Gentoo VM and I do not know why. On my fresh upgrade of Fedora31 the value for only the statusbar change above needed to be 28 It could also be fixed in gnc-main-window.c, setting the height of the status bar with this... gtk_widget_set_size_request (priv->statusbar, -1, 30); the 30 being some default value but I do not think overrideable. The space for an empty status entry does not work as it fails for a menu separator and also a disabled menu option. Will see if Geert has any thoughts.
Arbitrary fixed sizes are not a solution. As Matt suggests the minimum size we'd need depends on the font settings chosen by the user. I don't understand what you mean exactly with a space not working ? Don't we control the code that sets or removes the status bar message ? (I haven't checked). I thought it would just be a matter of checking of the status message being entered is empty and then replace it with a blank.
Adding a space to a menu option that does not have an entry, currently the entries are NULL does work but once the menu item is disabled / greyed out it seems the space has no bearing on the height any more. Also it there is no way to do the same on a separator menu item. The only other way I thought of was to grab the height of an entry with text and use that to set the height. That should be possible as the file name / date last opened is displayed first on open. Maybe I will give that a shot.
For each plugin page we create we set a status bar. Updating messages in this status bar seems to happen via gtk_statusbar_push. I found this function to be used in a few places. Two relevant ones are gnc_window_update_status and set_tip. Using gdb I found the latter is the one responsible for updating the status message when hovering menu items. Both functions have a guard for empty messages and replace a NULL string message with an empty string "". If I change this in both places to use a space " " instead, the status bar stops jumping up and down. Shall I push these changes ?
By the way I still think it's a workaround for the actual bug. To my mind this should not matter and it's gtk's widget positioning logic that's flawed. It may be theme dependent as well. However as the workaround is trivial, I don't care that much.
Yes if it is that trivial, did you try on a menu that on the Transaction menu where there are separators and disabled menu items.
Should of reread before saving, did you try that on the 'Transaction' menu where there are separators and disabled menu items.
It seems to work for me on the Transaction menu as well, both on the separators as on the disabled menu items.
Fix pushed. Changes will appear in tomorrow's nightlies and in 3.11 and 3.903.
