GNOME Bugzilla – Bug 327245
Full screen mode crippled if Xinerama is used
Last modified: 2007-12-04 13:30:54 UTC
The full screen mode has recently regressed (this issue is not in the stable 2.6 series). I'm using Xinerama on my system; I have a laptop to the left of my CRT screen. Normally, a button bar appears when you hover over the image. On my system, the image appears on my CRT monitor, while the button bar appears on my smaller laptop screen (this is probably a bug, but it's a bug that I happen to like; I don't want the button bar to obscure the image). The problem is that the button bar in 2.7.2 actually obscures the image on my CRT monitor. Here's how it's supposed to look (2.6 behaved in this way): +-----------------------------+ | | | | | | +---------------+ | | (button bar) | (image on CRT monitor) | |---------------| | | | | | (LCD desktop) | | | | | +---------------+-----------------------------+ This is what it actually looks like in 2.7.2: +-----------------------------+ | (bar with no buttons) | <-- gray wasteland covering |-----------------------------| parts of the image | | +---------------+ | | (button bar) | (image on CRT monitor) | |---------------| | | | | | (LCD desktop) | | | | | +---------------+-----------------------------+ Obviously, this is not desirable. Setting a WM hint to make the full screen window "on top" would probably fix this, although making the button bar Xinerama-aware would no doubt be more elegant. This applies to version 2.7.2, as of this writing the most recent development snapshot.
fixed in current CVS, putting the toolbar on the same screen of the image.
*** Bug 329598 has been marked as a duplicate of this bug. ***
This bug is still in 2.7.6, the version shipped with Ubuntu Dapper Drake. Reopening.
I still have the bar stretch all the way across both my monitors when using TwinView in 10.0.2. Any progress on fixing this?
I just noticed that in slideshow mode, the fade effect (which seems to be new? never seen it before) fades BOTH screens, making it extremely annoying if you're trying to work on the other screen. Is gThumb entering fullscreen mode in some way that is not xinerama-aware? It seems to be completely unaware that there are actually two monitors present...
I see that src/gs-fade.c is copied from gnome-screensaver, and it has a number of loops that cycle through "num_screens". So it probably applies the effect to all screens. I don't think any of the active gThumb contributors have a dual-screen setup, so feel free to experiment and submit patches ... - Mike
Created attachment 99940 [details] [review] Xinerama support for gThumb I've written up a patch against svn HEAD that uses GTK+'s builtin support for Xinerama to place the fullscreen-window and toolbar on the same monitor as the gThumb that requested to go into fullscreen or slideshow mode. Furthermore, now the toolbar only covers the width of the monitor, not the width of the entire X11 screen (which can be multiple monitors if Xinerama is enabled). Furthermore, the fullscreen window and toolbars will automatically resize themselves on a screen resolution change so the "full-screen" windows don't stick halfway off the screen if one uses hotkeys to change TwinView modes. It doesn't fix the fade bug though. The fading code fades on a screen basis, and since the point of Xinerama is sharing multiple monitors on a single X11 screen, even only fading a single X11 "screen" will fade both monitors if Xinerama is used. The fading code for slide show needed to be completely rewritten to fade just the image displayed and not an entire screen. This could possibly be done by rendering the GdkPixbuf with a time-varying alpha multiplier, or using something possibly hardware accelerated like OpenGL, or maybe X11's RENDER extension.
Created attachment 99942 [details] [review] Updated patch Tiny fix to make it work in Metacity. Also tested on Openbox and Compiz.
*** Bug 380932 has been marked as a duplicate of this bug. ***
Review comments: 1. I can't test this one a two-screen system, but I found one problem on one-screen with Compiz (Fedora 8 with "Desktop Effects" enabled). With this patch, the gnome-panel bars (top and bottom on my system) are visible during the slideshow (except when the whole screen fades). The gthumb window is not truly fullscreen. 2. How about some comments in the code? :-) 3. Do you experience bug 496140? - Mike
(In reply to comment #10) > Review comments: > > 1. I can't test this one a two-screen system, but I found one problem on > one-screen with Compiz (Fedora 8 with "Desktop Effects" enabled). With this > patch, the gnome-panel bars (top and bottom on my system) are visible during > the slideshow (except when the whole screen fades). The gthumb window is not > truly fullscreen. I'm assuming you were using the updated patch? Here's the issue as far as I see it: gtk_window_fullscreen is called on the window to make GTK set the _NET_WM_WINDOW_TYPE atom to _NET_WM_WINDOW_TYPE_FULLSCREEN. According to the EWMH standard, window managers should stack FULLSCREEN windows (like gThumb's window) above DOCK windows, like gnome-panel, but only when the FULLSCREEN window has focus. That said, different window managers seem to handle things differently. In the first patch, Openbox worked fine, but Metacity didn't notice the fullscreen state and placed gnome-panel docks on top. Calling gtk_window_fullscreen before the window was even shown fixed that. It works fine for me on a vanilla Compiz 0.6.2 build, so I'm not sure why it's not working for you. Two questions: a. What version of Compiz are you using? b. Open a fullscreen gThumb window, Alt-Tab to a terminal window, and run `xprop | grep _NET_WM_STATE` on the fullscreen gThumb window. Check to see if it matches this line: _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN > 2. How about some comments in the code? :-) They can be easily added. :-) > 3. Do you experience bug 496140? Yes and no. I'll attach my experiences there. > - Mike >
Another question for you Mike, Is the fullscreen issue you have with the patch just a layer-stacking issue, or are window manager decorations displayed as well? (You may have to your top-docked gnome-panel to another side of the screen, depending on it's size.) --Geoffrey
Created attachment 100000 [details] Screenshot
The above screenshot shows the fullscreen mode with your updated patch and Compiz. I moved my top panel to the right edge. Note the strange gap at the top... I am using stock Fedora 8, with compiz-0.6.2-3.fc8. xprop does report _NET_WM_STATE_FULLSCREEN. - Mike
Created attachment 100007 [details] [review] Updated Xinerama support for gThumb Oddly, what worked in Compiz using gtk-window-decorator wasn't working in Compiz using emerald. Now the patch only positions the fullscreen window on the desired monitor; it lets the WM handle resizing it, which broke both stacking and window placement when using Emerald. I've tested it on Openbox 3.4.4, Metacity 2.18.5, FVWM 2.5.21, and Compiz 0.6.2 (both with the builtin gtk-window-decorator and emerald 0.5.2). Hopefully it will now work for everybody.
OK, it works for me now (on a single-screen Compiz system), so I've committed it to trunk (svn rev 2089). It should appear in 2.11.0, whenever Paolo makes the first release from trunk. Thank you for the patch! - Mike
I have opened bug 501512 for the fade issue. - Mike