CVS griph: * corrected typo in All Reverse option manpage description
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/04/14 01:51:48 Modified files: fvwm : fvwm.1.in Log message: * corrected typo in All Reverse option manpage description
Inconsistency during resizing shaded windows
Hi, Yesterday I've noticed little inconsistency during resizing shaded windows under fvwm 2.5.16 and current CVS version: I have in my ~/.fvwm/config `Style * ResizeOpaque'. But during resizing of any shaded window this style ignored and window resized as rubberband outline. I propose two possible solutions: 1) Solve this inconsistency. Maybe unshade the window before resizing, resize it, then shade it again. 2) If this problem can't be solved without much hassle I think we should make it clear in documentation that ResizeOpaque style don't applies to shaded windows. Best wishes -- 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: Inconsistency during resizing shaded windows
On Fri, 14 Apr 2006, Serge (gentoosiast) Koksharov wrote: Hi, Yesterday I've noticed little inconsistency during resizing shaded windows under fvwm 2.5.16 and current CVS version: I have in my ~/.fvwm/config `Style * ResizeOpaque'. But during resizing of any shaded window this style ignored and window resized as rubberband outline. I propose two possible solutions: 1) Solve this inconsistency. Maybe unshade the window before resizing, resize it, then shade it again. You can actually do this yourself, given that you don't use different shading directions. Just define your own resize function: AddToFunc ResizeFunc + I ThisWindow (Shaded) WindowShade off + I Resize + I TestRc (Match) WindowShade on 2) If this problem can't be solved without much hassle I think we should make it clear in documentation that ResizeOpaque style don't applies to shaded windows. I like it the way it is. I'm really not interested in the content of shaded windows. Vote for a change of documentaion, possible together with an option to the WindowShade command to use the last shade direction. /Viktor
Re: On my recent commits.
On Thu, Apr 13, 2006 at 05:56:52PM +0200, Viktor Griph wrote: * should the options be allowed in any order. Now Reverse has to precede UseStack. If I understood your changes correctly, UseStack and Reverse options are not directly related to each other. In this case I think they should be allowed in any order. If I'm wrong, leave it as is, but please make a note about order in the `fvwm' manpage. Best wishes -- 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: On my recent commits.
On Sat, 15 Apr 2006, Serge (gentoosiast) Koksharov wrote: On Thu, Apr 13, 2006 at 05:56:52PM +0200, Viktor Griph wrote: * should the options be allowed in any order. Now Reverse has to precede UseStack. If I understood your changes correctly, UseStack and Reverse options are not directly related to each other. In this case I think they should be allowed in any order. If I'm wrong, leave it as is, but please make a note about order in the `fvwm' manpage. The options are not depending on each other. However the reason for the current order requirement was that it was easier to write up in the man page. All [Reverse] [UseStack] [(Conditions)] command implies an order. To allow any order requires some more generic means of documenting the options. Something like All [options] [(Conditions)] command and then state the possible values for options. /Viktor
