Re: FVWM: DjView fullscreen issue
On Thu, Aug 10, 2006 at 01:56:48PM +0100, seventh guardian wrote: After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. BTW, DjView can also be initially started in fullscreen mode: djview -fs /path/to/document.djvu. Unfortunately, it is also not working under FVWM. http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote I think MOTIF hints are implemented in FVWM as Style 'MwmDecor': MwmDecor makes fvwm attempt to recognize and respect the mwm decoration hints that applications occasionally use. To switch this style off, use the NoDecorHint style. But setting it on/off don't have any effect on discussed application. Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On 8/11/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 01:56:48PM +0100, seventh guardian wrote: After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. BTW, DjView can also be initially started in fullscreen mode: djview -fs /path/to/document.djvu. Unfortunately, it is also not working under FVWM. Yes it is! I tryed the above command and it went fullscreen without any problem. The problem appeared when I tryed to exit fullscreen mode, because then fvwm reparented the window, and it kept its full screen size.. So, the question remains, why did fvwm reparent the window.. Dominik can you help us with this? Cheers Renato http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote I think MOTIF hints are implemented in FVWM as Style 'MwmDecor': MwmDecor makes fvwm attempt to recognize and respect the mwm decoration hints that applications occasionally use. To switch this style off, use the NoDecorHint style. But setting it on/off don't have any effect on discussed application. Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On 8/11/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 01:56:48PM +0100, seventh guardian wrote: After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. BTW, DjView can also be initially started in fullscreen mode: djview -fs /path/to/document.djvu. Unfortunately, it is also not working under FVWM. Yes it is! I tryed the above command and it went fullscreen without any problem. The problem appeared when I tryed to exit fullscreen mode, because then fvwm reparented the window, and it kept its full screen size.. So, the question remains, why did fvwm reparent the window.. Dominik can you help us with this? Cheers Renato http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote I think MOTIF hints are implemented in FVWM as Style 'MwmDecor': MwmDecor makes fvwm attempt to recognize and respect the mwm decoration hints that applications occasionally use. To switch this style off, use the NoDecorHint style. But setting it on/off don't have any effect on discussed application. Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On 8/10/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, On Wed, Aug 09, 2006 at 02:21:12PM +0100, seventh guardian wrote: On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? See attached source file. It is very simple, but it proves that showFullScreen() method of Qt toolkit works fine with FVWM. See its description in Qt documentation: file:///usr/qt/3/doc/html/qwidget.html#showFullScreen After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote Can someone more comfortable with fvwm's internals give their opinion on the implications of this? On the other hand and after looking at djview's code, things get a bit messy because djview also uses direct X calls! The problem can be an interaction between these calls and those from qt. So lets first check why is fvwm reparenting the window, and only then consider submitting a report upstream. Any ideas on how to check this out? It would be best to deal with this in the workers list now. Cheers Renato Bye Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On 8/10/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, On Wed, Aug 09, 2006 at 02:21:12PM +0100, seventh guardian wrote: On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? See attached source file. It is very simple, but it proves that showFullScreen() method of Qt toolkit works fine with FVWM. See its description in Qt documentation: file:///usr/qt/3/doc/html/qwidget.html#showFullScreen After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote Can someone more comfortable with fvwm's internals give their opinion on the implications of this? On the other hand and after looking at djview's code, things get a bit messy because djview also uses direct X calls! The problem can be an interaction between these calls and those from qt. So lets first check why is fvwm reparenting the window, and only then consider submitting a report upstream. Any ideas on how to check this out? It would be best to deal with this in the workers list now. Cheers Renato Bye Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? Cheers Renato Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On 8/9/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? OOps.. kate was already using qt3.. My mistake. So why the heck is fvwm reparenting djview? :( Cheers Renato Cheers Renato Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_DESKTOP(CARDINAL) = 0 XdndAware(ATOM) = ATOM _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xe1, 0xbf, 0x10, 0x0, 0x0, 0x0 _NET_WM_USER_TIME(CARDINAL) = 241838058 _WIN_AREA(CARDINAL) = 0, 0 _WIN_WORKSPACE(CARDINAL) = 0 _WIN_LAYER(CARDINAL) = 4 _WIN_STATE(CARDINAL) = 0 _NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 24, 4 _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 4, 4, 24, 4 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK _NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = 0x44, 0x6a, 0x56, 0x69, 0x65, 0x77, 0x20, 0x2d, 0x20, 0x2f, 0x68, 0x6f, 0x6d, 0x65, 0x2f, 0x67, 0x65, 0x6e, 0x74, 0x6f, 0x6f, 0x73, 0x69, 0x61, 0x73, 0x74, 0x2f, 0x64, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x73, 0x2f, 0x65, 0x62, 0x6f, 0x6f, 0x6b, 0x73, 0x2f, 0x54, 0x65, 0x72, 0x6d, 0x63, 0x61, 0x70, 0x5f, 0x61, 0x6e, 0x64, 0x5f, 0x54, 0x65, 0x72, 0x6d, 0x69, 0x6e, 0x66, 0x6f, 0x2e, 0x64, 0x6a, 0x76, 0x75, 0x2f, 0x49, 0x4d, 0x47, 0x30, 0x30, 0x30, 0x30, 0x31, 0x5f, 0x30, 0x30, 0x30, 0x31, 0x2e, 0x64, 0x6a, 0x76, 0x75 _NET_WM_VISIBLE_NAME(UTF8_STRING) = 0x44, 0x6a, 0x56, 0x69, 0x65, 0x77, 0x20, 0x2d, 0x20, 0x2f, 0x68, 0x6f, 0x6d, 0x65, 0x2f, 0x67, 0x65, 0x6e, 0x74, 0x6f, 0x6f, 0x73, 0x69, 0x61, 0x73, 0x74, 0x2f, 0x64, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x73, 0x2f, 0x65, 0x62, 0x6f, 0x6f, 0x6b, 0x73, 0x2f, 0x54, 0x65, 0x72, 0x6d, 0x63, 0x61, 0x70, 0x5f, 0x61, 0x6e, 0x64, 0x5f, 0x54, 0x65, 0x72, 0x6d, 0x69, 0x6e, 0x66, 0x6f, 0x2e, 0x64, 0x6a, 0x76, 0x75, 0x2f, 0x49, 0x4d, 0x47, 0x30, 0x30, 0x30, 0x30, 0x31, 0x5f, 0x30, 0x30, 0x30, 0x31, 0x2e, 0x64, 0x6a, 0x76, 0x75 _NET_WM_NAME(UTF8_STRING) = 0x44, 0x6a, 0x56, 0x69, 0x65, 0x77, 0x20, 0x2d, 0x20, 0x2f, 0x68, 0x6f, 0x6d, 0x65, 0x2f, 0x67, 0x65, 0x6e, 0x74, 0x6f, 0x6f, 0x73, 0x69, 0x61, 0x73, 0x74, 0x2f, 0x64, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x73, 0x2f, 0x65, 0x62, 0x6f, 0x6f, 0x6b, 0x73, 0x2f, 0x54, 0x65, 0x72, 0x6d, 0x63, 0x61, 0x70, 0x5f, 0x61, 0x6e, 0x64, 0x5f, 0x54, 0x65, 0x72, 0x6d, 0x69, 0x6e, 0x66, 0x6f, 0x2e, 0x64, 0x6a, 0x76, 0x75, 0x2f, 0x49, 0x4d, 0x47, 0x30, 0x30, 0x30, 0x30, 0x31, 0x5f, 0x30, 0x30, 0x30, 0x31, 0x2e, 0x64, 0x6a, 0x76, 0x75 WM_CLIENT_LEADER(WINDOW): window id # 0x1e2 WM_WINDOW_ROLE(STRING) = main_window _NET_WM_PID(CARDINAL) = 31458 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING WM_NAME(STRING) = DjView - /home/gentoosiast/downloads/ebooks/Termcap_and_Terminfo.djvu/IMG1_0001.djvu WM_LOCALE_NAME(STRING) = ru_RU.koi8r WM_CLASS(STRING) = djview, Djview WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x1ef bitmap id # of mask for icon: 0x1ed window id # of group leader: 0x1e2 WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: -4, 8 program specified location: -4, 8 user specified size: 1272 by 964 program specified size: 1272 by 964 program specified minimum size: 400 by 202 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = breeze
Re: FVWM: DjView fullscreen issue
Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FVWM: DjView fullscreen issue
On Tue, Aug 08, 2006 at 04:45:49PM +0100, Thomas Adam wrote: Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy So, is it some unimplemented functionality on our side, or bugs of 3rd party application? If second case, I'll try to convince its authors to make it FVWM compatible. BTW, I looked in its code, I'm not a C++ guru, but it seems to me it simply calling showFullScreen() function of Qt toolkit. I've written compiled test Qt application using this function and it worked fine under FVWM. So it's really strange why it not working... Thanks for workaround. Also, while switching to and from fullscreen it periodically spits following warning to the console: QT Warning: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x8018cc Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Re: FVWM: DjView fullscreen issue
On Tue, 8 Aug 2006 23:02:40 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:45:49PM +0100, Thomas Adam wrote: Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy So, is it some unimplemented functionality on our side, or bugs of 3rd party application? If second case, I'll try to convince its authors to make it FVWM compatible. BTW, I looked in its code, I'm not a C++ guru, but it seems to me it simply calling showFullScreen() function of Qt toolkit. I've written compiled test Qt application using this function and it worked fine under FVWM. So it's really strange why it not working... Thanks for workaround. I am not too sure who's to blame for this. Whilst not all the EWMH are supported in FVWM, given the error you have below, I can only assume this to be an error on behalf of the application. Also, while switching to and from fullscreen it periodically spits following warning to the console: QT Warning: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x8018cc This makes sense to me. I don't have my Xlib programming book -- so I hope someone will correct me if I am a little inaccurate. As far as I know, BadWindow errors are typically thrown from functions that manipulate things like XSizeHints (hence as an example, the XSetWMSizeHints() function). In this case, what I assuming to tbe the error is that the window is probably trying to keep a track of its size, but fails because the parameters passed to whichever function is being used fails to specify the correct Window parameter. That being the case, I can only conclude it's a bug with the application. How correct am I with that, anyone? -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FVWM: DjView fullscreen issue
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 23:02:40 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:45:49PM +0100, Thomas Adam wrote: Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy So, is it some unimplemented functionality on our side, or bugs of 3rd party application? If second case, I'll try to convince its authors to make it FVWM compatible. BTW, I looked in its code, I'm not a C++ guru, but it seems to me it simply calling showFullScreen() function of Qt toolkit. I've written compiled test Qt application using this function and it worked fine under FVWM. So it's really strange why it not working... Thanks for workaround. I am not too sure who's to blame for this. Whilst not all the EWMH are supported in FVWM, given the error you have below, I can only assume this to be an error on behalf of the application. Also, while switching to and from fullscreen it periodically spits following warning to the console: QT Warning: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x8018cc This makes sense to me. I don't have my Xlib programming book -- so I hope someone will correct me if I am a little inaccurate. As far as I know, BadWindow errors are typically thrown from functions that manipulate things like XSizeHints (hence as an example, the XSetWMSizeHints() function). In this case, what I assuming to tbe the error is that the window is probably trying to keep a track of its size, but fails because the parameters passed to whichever function is being used fails to specify the correct Window parameter. In this case major opcode 3 means the BadWindow error was thrown in a GetWindowAttributes request to the X server. I also get some opcode 20 (GetPropery), opcode 15 (QueryTree) and opcode 40 (TranslateCoords). I found a thing that might be the cause of the problem. When the window requests full screen it gets reparented by fvwm. (is this the correct behaviour?) But some calls are still made regarding the old fvwm parent window, which doesn't exist anymore. So the window doesn't get resized at all. You probably don't see this in a sample app because it doesn't have 7 (seven!) sub-windows :) (just do a xwininfo -children on djview) That being the case, I can only conclude it's a bug with the application. The problem is the interaction between fvwm and qt.. it's probably a matter of timing, as it gets reparented as it is being fullscreened. The app gets the parent's ID, fvwm reparents it and it then uses the outdated ID.. It can be a fvwm bug, or a qt one.. Can someone shed some light over this? Cheers Renato How correct am I with that, anyone? -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FVWM: DjView fullscreen issue
On 8/9/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/9/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 23:02:40 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:45:49PM +0100, Thomas Adam wrote: Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy So, is it some unimplemented functionality on our side, or bugs of 3rd party application? If second case, I'll try to convince its authors to make it FVWM compatible. BTW, I looked in its code, I'm not a C++ guru, but it seems to me it simply calling showFullScreen() function of Qt toolkit. I've written compiled test Qt application using this function and it worked fine under FVWM. So it's really strange why it not working... Thanks for workaround. I am not too sure who's to blame for this. Whilst not all the EWMH are supported in FVWM, given the error you have below, I can only assume this to be an error on behalf of the application. Also, while switching to and from fullscreen it periodically spits following warning to the console: QT Warning: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x8018cc This makes sense to me. I don't have my Xlib programming book -- so I hope someone will correct me if I am a little inaccurate. As far as I know, BadWindow errors are typically thrown from functions that manipulate things like XSizeHints (hence as an example, the XSetWMSizeHints() function). In this case, what I assuming to tbe the error is that the window is probably trying to keep a track of its size, but fails because the parameters passed to whichever function is being used fails to specify the correct Window parameter. In this case major opcode 3 means the BadWindow error was thrown in a GetWindowAttributes request to the X server. I also get some opcode 20 (GetPropery), opcode 15 (QueryTree) and opcode 40 (TranslateCoords). I found a thing that might be the cause of the problem. When the window requests full screen it gets reparented by fvwm. (is this the correct behaviour?) But some calls are still made regarding the old fvwm parent window, which doesn't exist anymore. So the window doesn't get resized at all. You probably don't see this in a sample app because it doesn't have 7 (seven!) sub-windows :) (just do a xwininfo -children on djview) That being the case, I can only conclude it's a bug with the application. The problem is the interaction between fvwm and qt.. it's probably a matter of timing, as it gets reparented as it is being fullscreened. The app gets the parent's ID, fvwm reparents it and it then uses the outdated ID.. It can be a fvwm bug, or a qt one.. Can someone shed some light over this? Making a small test with kate (the smallest qt full-screening app I could remember) it shows that the problem is specific to djview. Even though the app window ID is the same, fvwm chooses to reparent the djview window (for no reason? There must be a reason..) and not kate. Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Renato Cheers Renato Cheers Renato How correct am I with that, anyone? -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FVWM: DjView fullscreen issue
On Tue, 8 Aug 2006 00:11:08 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, I have problems when DjView (http://djvu.sourceforge.net) goes fullscreen. When I start this application, open ebook and select from its menu Display - Full Screen, DjView's window flickers, menu scrollbar are removed, but borders and window's title are left in place. Also, if I use 'EwmhBaseStruts' in the config, DjView's window in fullscreen mode don't overlap this reserved space. I tested it under IceWM and KWin and it works fine under this WMs. Can you attach a full xprop output for this fullscreened window, please? -- Thomas Adam -- ThisWindow (thomas_adam) Destroy