Information missing when fullscreened #417

lefp · 2025-02-21T21:36:59Z

The marker and cursor information are in the titlebar.
The titlebar is not visible when I fullscreen the app, so neither is that information.

This is on the Sway window manager.

rfuest · 2025-02-22T02:25:32Z

I don't think this can be changed in the LTS version without recompiling the code, but I might be wrong, because I haven't used that version in a while.

If you don't mind compiling GTKWave yourself you could try the development branch, which uses a new display widget to display these values:

tbybell · 2025-02-22T19:43:21Z

Looks like another bug with that window manager. Use X11 if you can or a different window manager.

If you have to use Sway:
./gtkwave ../examples/des.gtkw --rcvar 'use_toolbutton_interface off'

You lost the screen real estate so it's not really worth it though.

Note that I noticed recently on Fedora Core that on Wayland with the GNOME window manager that the right mousebutton dragzoom doesn't display the click/drag/release cursors. These upstream toolkit bugs that appear out of nowhere on what should be stable software are annoying. On both Wayland and X11 on Fedora Core, XPM support doesn't work which is evident because the splash screen shows a blank box.

Highly disappointing QA...I guess I'm not going to reformat over my CentOS 7 box's install anytime soon. :-)

rfuest · 2025-02-22T22:32:07Z

Looks like another bug with that window manager. Use X11 if you can or a different window manager.

If you have to use Sway: ./gtkwave ../examples/des.gtkw --rcvar 'use_toolbutton_interface off'

That doesn't help to work around this issue, I can still reproduce it in GNOME/Wayland. The time display remains part of the client side window decorations (via the GtkHeaderBar) and GTK hides windows decorations for fullscreen windows. The only workaround seems to be not to use the fullscreen mode and instead just maximize the window.

Note that I noticed recently on Fedora Core that on Wayland with the GNOME window manager that the right mousebutton dragzoom doesn't display the click/drag/release cursors. These upstream toolkit bugs that appear out of nowhere on what should be stable software are annoying.

That has been a long time problem with GTKWave 3.3 and was reported multiple times. It is possible to work around the issue by setting an environment variable (GDK_BACKEND=x11) to run GTKWave via XWayland.

While it is annoying when stuff breaks because of upstream changes, I don't think this is entirely GTK's fault. The display updates in GTKWave are implemented in an unusual way and the signals aren't used the way GTK3 expects them to be used. I didn't have any problems with cursor updates in either X11 or Wayland after I changed the way redrawing is handled.

On both Wayland and X11 on Fedora Core, XPM support doesn't work which is evident because the splash screen shows a blank box.

That might be caused by a missing package. https://packages.fedoraproject.org/pkgs/gdk-pixbuf2-modules-extra/gdk-pixbuf2-modules-extra/ is required for loading XPMs and I don't think it's installed by default.

Highly disappointing QA...I guess I'm not going to reformat over my CentOS 7 box's install anytime soon. :-)

Now you just have to convince all users of GTKWave to also stay on CentOS 7. ;)

tbybell · 2025-02-22T23:55:43Z

That doesn't help to work around this issue, I can still reproduce it in GNOME/Wayland. The time display remains part of the client side window decorations (via the GtkHeaderBar) and GTK hides windows decorations for fullscreen windows. The only workaround seems to be not to use the fullscreen mode and instead just maximize the window.

The marker/cursor values should already be rendered as a text label that un-hides. When I hit F11 on my machine, that second line of header bar moves over to a text label to the right of the reload button. There is a chunk of code that does a label switcheroo:

gtk_widget_show(GLOBALS->time_mainbox);
vs the usual
gtk_widget_hide(GLOBALS->time_mainbox);

from
WAVE_GTKIFE("/View/Fullscreen", "F11", menu_fullscreen, WV_MENU_FULLSCR, "<ToggleItem>"),

If I'm double-clicking the window title instead of hitting the full screen expander button or F11, I can duplicate that missing subtitle issue on my end. I suppose that is how you duplicated the issue as well. I'll have to look, but I don't know if a signal is generated that informs client code of fullscreen status, but the menu option should work for the issue reporter.

That has been a long time problem with GTKWave 3.3 and was reported multiple times. It is possible to work around the issue by setting an environment variable (GDK_BACKEND=x11) to run GTKWave via XWayland.

Thanks for pointing that out. I've had Wayland turned off on my Fedora Core machine for a while and haven't noticed. I had Wayland turned off on that machine because of the GTK touchscreen menu bugs, and I've seen this outside of gtkwave. Interestingly, upon messing with it, it looks like menus finally work with touchscreen. I might have to fix that right mouse button bug now as it appears Wayland might be usable. (This turned out to be an instructive message thread for me after all as I had given up on Wayland...)

While it is annoying when stuff breaks because of upstream changes, I don't think this is entirely GTK's fault. The display updates in GTKWave are implemented in an unusual way and the signals aren't used the way GTK3 expects them to be used. I didn't have any problems with cursor updates in either X11 or Wayland after I changed the way redrawing is handled.

OK, thanks. Back when the toolkit was new, I got sick of bug reports that were dismissed with terse justifications such that I would have to work around toolkit issues. That was long ago, but I'm still...traumatized...by such breakages. :-)

On both Wayland and X11 on Fedora Core, XPM support doesn't work which is evident because the splash screen shows a blank box.

That might be caused by a missing package. https://packages.fedoraproject.org/pkgs/gdk-pixbuf2-modules-extra/gdk-pixbuf2-modules-extra/ is required for loading XPMs and I don't think it's installed by default.

Thanks, that was it. Fedora Core upgrade doesn't install them by default when upgrading from an old version that didn't need it.

Highly disappointing QA...I guess I'm not going to reformat over my CentOS 7 box's install anytime soon. :-)

Now you just have to convince all users of GTKWave to also stay on CentOS 7. ;)

Haha, I'm glad it's not all QA issues. That's reassuring.

I'm still stuck on 7 because the version of Quartus I need for MiSTer core builds still requires it and a lot of the EDA tools at work are still RHEL7 with extended support contracts across multiple projects and will not change.

rfuest · 2025-02-25T15:18:02Z

Thanks, that was it. Fedora Core upgrade doesn't install them by default when upgrading from an old version that didn't need it.

Do you think this is a packaging issue and we should let the Fedora project know that they should add that package as a dependency to the gtkwave package?

I'm still stuck on 7 because the version of Quartus I need for MiSTer core builds still requires it and a lot of the EDA tools at work are still RHEL7 with extended support contracts across multiple projects and will not change.

When you update your own machine you could take a look at distrobox, which is a wrapper around docker/podman to make it easy to run GUI applications inside of containers. I'm not sure how well Centos 7 works inside it, but I've successfully used it to run some stubborn software under older releases of Ubuntu. In my opinion it's a better experience than running a full VM, because it seamlessly integrates into the host environment. It also comes in handy during the development of GTKWave to quickly spin up a container that uses a different distros, e.g. to debug build issues or trying to reproduce reported bugs.

tbybell · 2025-03-01T02:16:32Z

Thanks, that was it. Fedora Core upgrade doesn't install them by default when upgrading from an old version that didn't need it.

Do you think this is a packaging issue and we should let the Fedora project know that they should add that package as a dependency to the gtkwave package?

Yes, Paul ( @pghmcfc ) should be made aware of gdk-pixbuf2-modules-extra. (I don't know if the @ mechanism on this site automatically sends him a note.) My guess is on the testing systems it might work because some other package has it installed. I didn't see the problem until I upgraded FC on my one Thinkpad somewhat recently.

I'm still stuck on 7 because the version of Quartus I need for MiSTer core builds still requires it and a lot of the EDA tools at work are still RHEL7 with extended support contracts across multiple projects and will not change.

When you update your own machine you could take a look at distrobox, which is a wrapper around docker/podman to make it easy to run GUI applications inside of containers. I'm not sure how well Centos 7 works inside it, but I've successfully used it to run some stubborn software under older releases of Ubuntu. In my opinion it's a better experience than running a full VM, because it seamlessly integrates into the host environment. It also comes in handy during the development of GTKWave to quickly spin up a container that uses a different distros, e.g. to debug build issues or trying to reproduce reported bugs.

That's a good idea. I'll experiment with it. My sysadmin friends swear by docker being handy.

pghmcfc · 2025-03-01T15:01:59Z

@tbybell Thanks, I got the message. gdk-pixbuf2-modules-extra is new in Fedora 41 so it wasn't needed before.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Information missing when fullscreened #417

Information missing when fullscreened #417

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Information missing when fullscreened #417

Information missing when fullscreened #417

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!