bug: 'CopyMenuStyle' command don't copies 'TitleColorset'
Hello, I hope I'm not too late and 2.5.17 still not released. Today I found a bug in menu code: 'CopyMenuStyle' don't copies recently introduced 'TitleColorset'. Attached patch fixes this. Happy release have a good time everyone -- 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 diff -Naur fvwmCVS-orig/ChangeLog fvwmCVS-fixed/ChangeLog --- fvwmCVS-orig/ChangeLog 2006-07-17 02:45:54.0 +0400 +++ fvwmCVS-fixed/ChangeLog 2006-07-17 13:52:02.0 +0400 @@ -1,3 +1,8 @@ +2006-07-17 Serge Koksharov gentoosiast dog yandex dot ru + + * fvwm/menustyle.c (menustyle_copy): + Now 'TitleColorset' also copied by 'CopyMenuStyle' command. + 2006-07-16 Viktor Griph [EMAIL PROTECTED] * fvwm/fvwm.1.in (COMMAND EXPANSION): diff -Naur fvwmCVS-orig/fvwm/menustyle.c fvwmCVS-fixed/fvwm/menustyle.c --- fvwmCVS-orig/fvwm/menustyle.c 2006-07-17 02:45:52.0 +0400 +++ fvwmCVS-fixed/fvwm/menustyle.c 2006-07-17 13:39:14.0 +0400 @@ -1766,6 +1766,9 @@ /* MenuColorset */ ST_HAS_GREYED_CSET(destms) = ST_HAS_GREYED_CSET(origms); ST_CSET_GREYED(destms) = ST_CSET_GREYED(origms); + /* TitleColorset */ + ST_HAS_TITLE_CSET(destms) = ST_HAS_TITLE_CSET(origms); + ST_CSET_TITLE(destms) = ST_CSET_TITLE(origms); /* SelectOnRelease */ ST_SELECT_ON_RELEASE_KEY(destms) = ST_SELECT_ON_RELEASE_KEY(origms); /* PopdownImmediately */
Re: FVWM: FVWM, GNOME and preloading GNOME libs
On 7/17/06, Andrei Popov [EMAIL PROTECTED] wrote: Hello Dominik and thanks for you response. You could add some dummy Gnome application to your start function. I'm sorry, dummy Gnome application doesn't sound too clear to me, and Google didn't help me either =) Can you perhaps provide an example? Start something like the gnome calculator.. What you need is a small gnome program so that it loads the gnome libs at startup. You can then kill it.. If you want to you can make a real dummy program only with gnome_init and a few other functions tha just starts itself and then exits. I think it takes so long because the first Gnome app starts a process called gconfd-2 from some obscure library. Maybe so. After some googling I came across a GDM speedup tip that I thought could apply to my situation. I didn't see any visible improvements though after I followed the steps successfully and rebooted. http://blogs.sun.com/roller/page/jmr?entry=jds_gnome_performance_leaner_meaner This seems to be just a _gnome_ speed improvement. It doesn't start gconfd-2, so you have no real _startup_ speed improvement. It may help on the performance once all gnome libs are loaded though.. Cheers Renato -- WBR, Andrei Popov Using FVWM 2.5.16 on Debian GNU/Linux
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. -- Thomas Adam I misunderstood StippledTitleOff. Is there any way to tell sticky icons to use a normal title? Thanks, -- Leon No, there isn't. I did send a patch in last year to address this problem, but it was mostly ignored. Style only works with window/class names. So there's no easy way of telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? Finally as a personal oppinion, I see no utility in the current StippledTitle style, so maybe Thomas' patch could be re-discussed? Cheers, Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: FVWM: How to use StippledTitleOff
On Mon, Jul 17, 2006 at 03:26:32PM +0100, seventh guardian wrote: On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. Most commands should be using !Foo in the negatory sense. Style only works with window/class names. So there's no easy way of Name, Class, Resource. telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. How do you mean? It's perfectly simple to add something like: Style * StickyStipples Style * !StickyStipples ... Which might apply to windows which have been declared as sticky. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. Maybe it is, but then you can turn that around and say that stippling sticky windows in the first place is also wrong. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? I don't like this, since you would probably extend it to include things like: Style Shaded (...) Style HasTitle (...) It gets too boring, unmanagable, and ultimately wrong. The stylation of window *states* (as in the above) just doesn't make logical sense to me. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Flags - is negation prefered?
Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato
Re: Flags - is negation prefered?
On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato Yes -- I thought 2.5.X was having the !Foo syntax as the preferred one, removing any old Foo versus NoFoo options. Of course, it's currently on FVWM 2.4.X which still exhibits this. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 03:26:32PM +0100, seventh guardian wrote: On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. Most commands should be using !Foo in the negatory sense. Style only works with window/class names. So there's no easy way of Name, Class, Resource. telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. How do you mean? It's perfectly simple to add something like: Style * StickyStipples Style * !StickyStipples ... Which might apply to windows which have been declared as sticky. Yes, but then you'd end up with lots of equal styles applying to different situations.. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. Maybe it is, but then you can turn that around and say that stippling sticky windows in the first place is also wrong. Yes, I did say that :) but it's just my opinion.. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? I don't like this, since you would probably extend it to include things like: Style Shaded (...) Style HasTitle (...) It gets too boring, unmanagable, and ultimately wrong. The stylation of window *states* (as in the above) just doesn't make logical sense to me. It would allow us for instance to use a different color style for sticky windows, instead of just allowing stippling.. It would allow setting different colors to the iconified windows. This currently can only be done with the use of colorsets, which I belive is a broken behaviour. And the list goes on. It's a flexible solution that follows the same philosophy that was behindreplacing all sorts of old fvwm commands with their Style counterpart.. Cheers, Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato Yes -- I thought 2.5.X was having the !Foo syntax as the preferred one, removing any old Foo versus NoFoo options. Of course, it's currently on FVWM 2.4.X which still exhibits this. Yes, but then the 2.5 manual should be updated. I'll start doing that.. Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: FVWM: How to use StippledTitleOff
On Mon, Jul 17, 2006 at 04:01:36PM +0100, seventh guardian wrote: Yes, but then you'd end up with lots of equal styles applying to different situations.. I don't see how -- it still only applies to a specific group of windows (or a specific window, depending on the style used.) It would allow us for instance to use a different color style for sticky windows, instead of just allowing stippling.. You can do this with FvwmEvent -- although currently you can't turn the stipples off. It would allow setting different colors to the iconified windows. This currently can only be done with the use of colorsets, which I belive is a broken behaviour. Do you? An icon is just another window -- giving it its own colorset makes sense to me. And the list goes on. It's a flexible solution that follows the same philosophy that was behindreplacing all sorts of old fvwm commands with their Style counterpart.. Maybe -- I just think it adds too much verbosity. I'd much rather more work was done to look into the following idiom: Style (name=foo, class=Foo) Stick ... Which currently has its own branch in the FVWM CVS, but obviously breaks any compatibility with the way current style lines are parsed. The above is something I'd prefer to see, above and beyond changing the style states for different windows. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Yes, I know :) But in any case, I'll test things before changing the manpage.. Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On Mon, 17 Jul 2006, Thomas Adam wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Another thing to remember is that all options that still are supported, but not preferred should still be documented, or someone searching for what an option in a config file does might not find it. /Viktor
CVS renato: updated the manpage to reflect the prefered !* style negation method.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/17 10:51:34 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: updated the manpage to reflect the prefered !* style negation method. (only Title, StippledTitle and Handles for now).
Re: Flags - is negation prefered?
On 7/17/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Thomas Adam wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Another thing to remember is that all options that still are supported, but not preferred should still be documented, or someone searching for what an option in a config file does might not find it. Yes, I also adressed that. I hope the first three items are good. I'll continue tomorrow after my last exam.. :) Cheers, Renato /Viktor
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:36:08PM +0100, seventh guardian wrote: On the other hand, BackColor and ForeColor apply to both situations. Don't get too attached to those though -- they're deprecated in favour of using colorsets. :) So you can only set a specific icon color if using a colorset, and never directly like you do to a window. This is why I believe the behaviour is broken. I like this aproach. But it would be more clear if was something like: Style (name=foo | class=foo) Stick That's horrible. I really don't want to see any C idioms like that. :) Most people that use FVWM aren't programmers -- enforcing something like that on them might make them run away. :) Lol.. Yes, but how do you specify if its an and or an or? Renato The comma is a bit ambiguous.. at least for a C programmer ;) I guess these two ways of parsing could eventually be merged. I like the comma because it separates out the different clauses, just like most other commands are delimited in this way in FVWM. It also doesn't enforce a prepositional meaning with '' -- which, unless you're a programmer, you're not going to necessarily grok at first. But this idiom doesn't add anything new, it just organizes the way style works. It could be extended in the same way to accept window states as an argument: It does add something new in that the conjunctions are now considered as one, as opposed to separately, which is how FVWM would currently interpret them as. Granted it adds no new options to the styles, but think about how powerful that would be. Style (name=foo winstate=iconic) That might be a little better, yes. (Again, losing the '' syntax in preference of a comma). I might look into this if I get some time. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: FVWM: How to use StippledTitleOff
On Mon, Jul 17, 2006 at 04:56:18PM +0100, seventh guardian wrote: Lol.. Yes, but how do you specify if its an and or an or? Just have two separate lines for them? Style (title=foo, winstate=normal) . Style (title=fii, winstate=iconic) . -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Adding the possibility of not compiling deprecated code ?
Hi. This idea just came into my head: why not #ifdef'ing the deprecated code and having configure.ac option --disable-backcompat? Examples: User A has an old config. So he downloads the new package, compiles it and installs it just like he allways did. User B has a new config and wants to compile fvwm so that it doesn't waste time/space looking for deprecated options. This could make fvwm run a tiny bit faster (?), and also would allow user B to see if its config is up-to-date (i.e., not using deprecated options). He downloads the new package, runs configure --disable-backcompat and compiles it. The performance gain may not be that noticeable, but it would allow us to mark clearly deprecated code and test if things work without it. Maybe it would make it easyer to remove in the future (?). It would also be useful for users who want to make sure they have an up-to-date config, being this a way to enforce that. What do you think? Renato
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:56:18PM +0100, seventh guardian wrote: Lol.. Yes, but how do you specify if its an and or an or? Just have two separate lines for them? Style (title=foo, winstate=normal) . Style (title=fii, winstate=iconic) . Touche.. :) Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
CVS renato: another update to the man page regarding !* style negation.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/17 13:44:15 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: another update to the man page regarding !* style negation. (NoButton, NoIconTitle)
Re: Adding the possibility of not compiling deprecated code ?
On Mon, Jul 17, 2006 at 06:19:48PM +0100, seventh guardian wrote:
Hi.
This idea just came into my head: why not #ifdef'ing the deprecated
code and having configure.ac option --disable-backcompat?
Examples:
User A has an old config. So he downloads the new package, compiles it
and installs it just like he allways did.
User B has a new config and wants to compile fvwm so that it doesn't
waste time/space looking for deprecated options. This could make
fvwm run a tiny bit faster (?), and also would allow user B to see
if its config is up-to-date (i.e., not using deprecated options). He
downloads the new package, runs configure --disable-backcompat and
compiles it.
Interesting idea. The only speed increase I can see is that the
parser doesn't have to deal with those options. Above and beyond that,
there's no other speed increase that I can foresee.
Personally though, I'd much rather leave this process to the user.
There have aleady been attempts at writing small parsers such as
fvwm-convert-2.{4,6} -- although they're not briliant they do a good
enough job. I don't know of many people that use them though.
-- Thomas Adam
--
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.
Re: Adding the possibility of not compiling deprecated code ?
On Mon, Jul 17, 2006 at 07:46:24PM +0100, Thomas Adam wrote:
On Mon, Jul 17, 2006 at 06:19:48PM +0100, seventh guardian wrote:
This idea just came into my head: why not #ifdef'ing the deprecated
code and having configure.ac option --disable-backcompat?
It's all about compatibility and maintainability. We once had
*13* different configure switches, and just compiling fvwm with
any combination of two options turned on or off took hours. This
(and other reasons explained in detail in the paper #ifdef
considered harmful) is why I don't want any new #ifdefs in the
code.
Since there is so much old and weird stuff in fvwm, we planned to
clean it all up in 3.0 - although there is little hope at the
moment to start this work anytime soon.
Examples:
User A has an old config. So he downloads the new package, compiles it
and installs it just like he allways did.
User B has a new config and wants to compile fvwm so that it doesn't
waste time/space looking for deprecated options. This could make
fvwm run a tiny bit faster (?), and also would allow user B to see
if its config is up-to-date (i.e., not using deprecated options). He
downloads the new package, runs configure --disable-backcompat and
compiles it.
Interesting idea. The only speed increase I can see is that the
parser doesn't have to deal with those options. Above and beyond that,
there's no other speed increase that I can foresee.
Personally though, I'd much rather leave this process to the user.
There have aleady been attempts at writing small parsers such as
fvwm-convert-2.{4,6} -- although they're not briliant they do a good
enough job. I don't know of many people that use them though.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: bug: 'CopyMenuStyle' command don't copies 'TitleColorset'
On Mon, Jul 17, 2006 at 01:55:47PM +0400, Serge (gentoosiast) Koksharov wrote: Hello, I hope I'm not too late and 2.5.17 still not released. Today I found a bug in menu code: 'CopyMenuStyle' don't copies recently introduced 'TitleColorset'. Attached patch fixes this. Happy release have a good time everyone Thanks. I'll apply that patch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Fixed copying of TitleColorset menustyle.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/17 15:24:29 Modified files: . : ChangeLog fvwm : menustyle.c Log message: * Fixed copying of TitleColorset menustyle.
Re: Flags - is negation prefered?
On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Adding the possibility of not compiling deprecated code ?
On Mon, Jul 17, 2006 at 10:16:08PM +0200, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 07:46:24PM +0100, Thomas Adam wrote: On Mon, Jul 17, 2006 at 06:19:48PM +0100, seventh guardian wrote: This idea just came into my head: why not #ifdef'ing the deprecated code and having configure.ac option --disable-backcompat? Hehe -- I never said the above, Renato did. :) It's all about compatibility and maintainability. We once had *13* different configure switches, and just compiling fvwm with any combination of two options turned on or off took hours. This (and other reasons explained in detail in the paper #ifdef considered harmful) is why I don't want any new #ifdefs in the code. I agree. Since there is so much old and weird stuff in fvwm, we planned to clean it all up in 3.0 - although there is little hope at the moment to start this work anytime soon. To be honest, I don't really see where all the fuss is with releasing FVWM 3.0 -- I'd much rather we spent time discussing things than rushing things to satisfy a few users. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
CVS domivogt: * Allow moving windows without icons while iconified with MoveToPage and
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/17 15:40:30 Modified files: . : ChangeLog fvwm : move_resize.c Log message: * Allow moving windows without icons while iconified with MoveToPage and MoveToScreen.
Re: Flags - is negation prefered?
On Mon, 17 Jul 2006, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Should the old style negation options be deprecated in the code (give warnings) before 2.6? /Viktor
