CVS griph: * use ewmh allowed actions to track window movability in pager
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager * removed my #if 0:ed code
Re: CVS griph: * use ewmh allowed actions to track window movability
On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager Hm, I guess that works, but it ties pager actions to the configuration of the ewmh stuff. I have long been planning to allow the user to disable specific ewmh features. If a user did that, the pager would break. Would an option to disable allowed actions really be useful to a user? All it does it to tell applications what actions are possible on a window. The only thing I can think of that can break it is if a EWMHFixedPosition style was added, that makes the ewmh allowed actions differ from the fvwm allowed actions. In event of that allowed actions could be made part of the configure window package. If that's the only pitfall, then currently a comment in is_function_allowed warning about it would be ennough to avoid unintended breakage. /Viktor
Re: CVS griph: * use ewmh allowed actions to track window movability
On Thu, Aug 10, 2006 at 12:58:06PM +0200, Viktor Griph wrote: On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager Hm, I guess that works, but it ties pager actions to the configuration of the ewmh stuff. I have long been planning to allow the user to disable specific ewmh features. If a user did that, the pager would break. Would an option to disable allowed actions really be useful to a user? I meant an option to disallow window movement via EWMH messages. EWMH applications could be disallowed to move windows this way, but the pager should still be allowed to. it does it to tell applications what actions are possible on a window. The only thing I can think of that can break it is if a EWMHFixedPosition style was added, that makes the ewmh allowed actions differ from the fvwm allowed actions. In event of that allowed actions could be made part of the configure window package. If that's the only pitfall, then currently a comment in is_function_allowed warning about it would be ennough to avoid unintended breakage. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * use ewmh allowed actions to track window movability
On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 12:58:06PM +0200, Viktor Griph wrote: On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager Hm, I guess that works, but it ties pager actions to the configuration of the ewmh stuff. I have long been planning to allow the user to disable specific ewmh features. If a user did that, the pager would break. Would an option to disable allowed actions really be useful to a user? I meant an option to disallow window movement via EWMH messages. EWMH applications could be disallowed to move windows this way, but the pager should still be allowed to. The reason why I did the ewmh implementation in the pager was that it was simple, and I didn't have to mess with the configure message. I'm not yet comfortable with the module interface code, and don't really know the best way to send allowed actions. Straightforward would be to just add them to window_flag, but that feels wrong. Another way would be to add a struct with allowed actions to the package and send it after the flags part of the message. Both these ways should I probably be able to do. I'm not sure if it's possible to add some function call result directly to the CONFIGARGS package, and that was when I started to look at other 'easier' solutions. The change to the pager is minimal to move it to use flags sent by fvwm instead of read via ewmh once the flags are sent. /Viktor
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
