Re: Patch to allow multiple window names in conditions
Mikhael Goikhman [EMAIL PROTECTED] wrote:
Like other posters, I don't quite like that names are sudently work
using logical OR while all other options in conditional commands work
using logical AND. And the nagations of names work using AND again.
Here is the proposal that should solve all these ambiguities, but it is
a bit backward incompatible in that one character is treated specially.
I don't think there is any fvwm user that has a conditional in his config
that will be broken however, so this is mostly the theoretical problem.
1) All condition options always work using logical AND, as usual.
2) Any option is either keyword or window name/resource/class, as usual.
3) Options (with possible argument) are separated by commas, as usual.
4) In the future we will have (Name name1, Class name2) syntax.
5) The leading character ! means logical NOT of that option, as usual.
6) Any name may contain a spacial character | meaning logical OR.
Here are examples:
Next (Netscape|konqueror|Mozilla*) WarpToWindow 99 90 # go to browser
All (CurrentPage, xterm|rvxt, !Iconified) Iconify # iconify terminals
Next (!FvwmPager|FvwmForm*|FvwmButtons) Raise # raise next non-module
Next (!FvwmPager, !FvwmForm*, !FvwmButtons) Raise
The last 2 commands are equivalent. So basically, we don't really need
to support more than one name options like in the last example. I am
not against to add such extended support though.
I think this syntax naturally extends the current syntax and allows most
of the logical expressions a user may want to have. This can't be said
about the original proposed syntax.
Thanks for the proposal. I was contemplating adding full boolean
expressions, but looking at the code, that gets a bit complicated if
backwards compatibility is to be preserved. The code change required by
your proposal is not much bigger than my original patch; and it doesn't
have the user interface weirdness that mine did. So I implemented it.
Here's the patch:
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2518
diff -u -u -r1.2518 ChangeLog
--- ChangeLog 10 Jul 2004 09:13:25 - 1.2518
+++ ChangeLog 10 Jul 2004 17:47:13 -
@@ -1,3 +1,11 @@
+2004-07-10 Norman Yarvin [EMAIL PROTECTED]
+
+ * fvwm/conditional.c:
+ * fvwm/fvwm.h:
+ * fvwm/fvwm.1.in:
+ modified the code for conditions so that multiple window names may
+ be specified in each condition
+
2004-07-09 Dominik Vogt [EMAIL PROTECTED]
* fvwm/module_interface.c (CONFIGARGS):
Index: fvwm/conditional.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/conditional.c,v
retrieving revision 1.95
diff -u -u -r1.95 conditional.c
--- fvwm/conditional.c 8 Jul 2004 10:08:09 - 1.95
+++ fvwm/conditional.c 10 Jul 2004 17:47:14 -
@@ -376,22 +376,31 @@
}
/*
- * The name field of the mask is allocated in CreateConditionMask.
+ * The name_condition field of the mask is allocated in CreateConditionMask.
* It must be freed.
* NOTE - exported via .h
*/
void FreeConditionMask(WindowConditionMask *mask)
{
- if (mask-my_flags.needs_name)
- {
- free(mask-name);
- }
- else if (mask-my_flags.needs_not_name)
+ struct name_condition *pp,*pp2;
+ struct namelist *p,*p2;
+
+ for (pp=mask-name_condition; pp; )
{
- free(mask-name - 1);
+ for (p=pp-namelist; p; )
+ {
+ p2=p-next;
+ if(!p2)
+ {
+ free(p-name - (pp-invert ? 1 : 0));
+ }
+ free(p);
+ p=p2;
+ }
+ pp2=pp-next;
+ free(pp);
+ pp=pp2;
}
-
- return;
}
/* Assign the default values for the window mask
@@ -614,21 +623,36 @@
}
mask-my_flags.needs_same_layer = on;
}
- else if (!mask-my_flags.needs_name
-!mask-my_flags.needs_not_name)
- {
- /* only 1st name to avoid mem leak */
- mask-name = condition;
- condition = NULL;
- if (on == 0)
- {
- mask-my_flags.needs_not_name = 1;
- mask-name++;
- }
- else
- {
- mask-my_flags.needs_name = 1;
+ else
+ {
+ struct name_condition *pp;
+ struct namelist *p;
+ char *condp;
+
+ pp = (struct name_condition *)
+
Re: Patch to allow multiple window names in conditions
Hi Norman, About a month ago, I sent in a patch to allow multiple window names in conditions. I think being able to specify multiple windows in conditions is very useful. It's 2:30am ... let me see if I understand your patch correctly: If you have: Next (mozilla dillo netscape) Function ... The relationship b/w mozilla, dillo netscape is a LOGICAL OR. but if I have: Next (!mozilla !dillo !netscape) Function ... the relationship is a LOGICAL AND. Have I got that right? If I have, I'm concerned users might get confused. (I'm sure other people edit their .fvwm2rc at 2:30am too! :) I'll sleep on it. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch to allow multiple window names in conditions
On Wed, Jul 07, 2004 at 02:28:23AM +1000, Scott Smedley wrote: Hi Norman, About a month ago, I sent in a patch to allow multiple window names in conditions. I think being able to specify multiple windows in conditions is very useful. It's 2:30am ... let me see if I understand your patch correctly: If you have: Next (mozilla dillo netscape) Function ... The relationship b/w mozilla, dillo netscape is a LOGICAL OR. but if I have: Next (!mozilla !dillo !netscape) Function ... the relationship is a LOGICAL AND. Have I got that right? Yes. If I have, I'm concerned users might get confused. (I'm sure other people edit their .fvwm2rc at 2:30am too! :) If you think that's confusing, think about what happens if there's a mixture of inverted (with '!') and non-inverted window names. The line: Next (a !b c !d) Function ... means (a OR c) AND NOT b AND NOT d. This isn't anything I'd plan to use; it's just a side effect of the way I implemented it. In any case, point taken: it'd be easier to do this right than to repeatedly explain to users why it was done in a half-assed way. To me, right means a full-blown boolean expression parser, with AND, OR, NOT, and parentheses. In coding, it'd probably be best to make the individual conditions (the leaf nodes of the parse tree) be the entire WindowConditionMask structure, not just the window name, so that conditions like CurrentScreen and Raised could be used as part of the boolean expression. I think that could still be backward-compatible with current .fvwm2rc files; the current implicit operator for conditions like CurrentScreen is AND, and that could be preserved. I don't think parentheses inside the expression have any current meaning, nor do (AND) or | (OR); and ! (NOT) could keep its current meaning. A recursive-descent parser for boolean expressions isn't that big a deal to write. But as my current patch satisfies my own needs, I'd write such a parser only if it'd be accepted into the mainline fvwm code. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch to allow multiple window names in conditions
On 31 May 2004 21:53:51 -0400, Norman Yarvin wrote: This is a small patch that allows multiple window names to be specified in conditions. I've tried to write it with the same style used in the rest of the code, although some variable names may be a bit terse by your standards. The patch keeps the window names in a linked list. It includes updates to the man page and ChangeLog. The patch is against the current CVS code. What exactly it does is best described by the modified portion of the man page: [...] Examples: Next (Netscape konqueror Mozilla*) WarpToWindow 99 90 This goes to the next web browser window, no matter which of the three named web browsers is being used. Like other posters, I don't quite like that names are sudently work using logical OR while all other options in conditional commands work using logical AND. And the nagations of names work using AND again. Here is the proposal that should solve all these ambiguities, but it is a bit backward incompatible in that one character is treated specially. I don't think there is any fvwm user that has a conditional in his config that will be broken however, so this is mostly the theoretical problem. 1) All condition options always work using logical AND, as usual. 2) Any option is either keyword or window name/resource/class, as usual. 3) Options (with possible argument) are separated by commas, as usual. 4) In the future we will have (Name name1, Class name2) syntax. 5) The leading character ! means logical NOT of that option, as usual. 6) Any name may contain a spacial character | meaning logical OR. Here are examples: Next (Netscape|konqueror|Mozilla*) WarpToWindow 99 90 # go to browser All (CurrentPage, xterm|rvxt, !Iconified) Iconify # iconify terminals Next (!FvwmPager|FvwmForm*|FvwmButtons) Raise # raise next non-module Next (!FvwmPager, !FvwmForm*, !FvwmButtons) Raise The last 2 commands are equivalent. So basically, we don't really need to support more than one name options like in the last example. I am not against to add such extended support though. I think this syntax naturally extends the current syntax and allows most of the logical expressions a user may want to have. This can't be said about the original proposed syntax. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch to allow multiple window names in conditions
About a month ago, I sent in a patch to allow multiple window names in
conditions. It was developed for my own use, but since I am a lazy guy,
I was hoping the fvwm workers would pick it up, so I wouldn't have to
keep maintaining it. That doesn't seem to have happened. Perhaps I
should have mentioned that the patch is backward-compatible with old
fvwm2rc files. It is mildly half-assed in the sense that it doesn't
implement a full boolean expression parser, but in exchange it is small
and simple. It assumes that the boolean operator the user wants is OR,
or in the case of a window name prefixed with '!', AND NOT. The
following is a rehash of the patch against the current CVS tree.
ChangeLog and man page updates are included. If something's wrong with
it, I'd appreciate hearing what.
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2512
diff -u -u -r1.2512 ChangeLog
--- ChangeLog 1 Jul 2004 14:34:22 - 1.2512
+++ ChangeLog 4 Jul 2004 19:23:31 -
@@ -1,3 +1,11 @@
+2004-07-04 Norman Yarvin [EMAIL PROTECTED]
+
+ * fvwm/fvwm.1.in:
+ * fvmw/fvwm.h:
+ * fvwm/conditional.c:
+ modified the code for conditions so that multiple window names may
+ be specified in each condition
+
2004-07-01 Dominik Vogt [EMAIL PROTECTED]
* fvwm/move_resize.c (GetResizeArguments):
Index: fvwm/conditional.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/conditional.c,v
retrieving revision 1.93
diff -u -u -r1.93 conditional.c
--- fvwm/conditional.c 9 May 2004 12:59:55 - 1.93
+++ fvwm/conditional.c 4 Jul 2004 19:23:33 -
@@ -382,13 +382,14 @@
*/
void FreeConditionMask(WindowConditionMask *mask)
{
- if (mask-my_flags.needs_name)
- {
- free(mask-name);
- }
- else if (mask-my_flags.needs_not_name)
- {
- free(mask-name - 1);
+ struct namelist *p,*p2;
+
+ for (p=mask-namelist; p;)
+ {
+ free(p-name);
+ p2=p-next;
+ free(p);
+ p=p2;
}
return;
@@ -614,21 +615,16 @@
}
mask-my_flags.needs_same_layer = on;
}
- else if (!mask-my_flags.needs_name
-!mask-my_flags.needs_not_name)
- {
- /* only 1st name to avoid mem leak */
- mask-name = condition;
- condition = NULL;
- if (on == 0)
- {
- mask-my_flags.needs_not_name = 1;
- mask-name++;
- }
- else
- {
- mask-my_flags.needs_name = 1;
- }
+ else
+ {
+ struct namelist *p;
+
+ p = (struct namelist *)
+ safemalloc(sizeof(struct namelist));
+ p-name = condition;
+ p-next = mask-namelist;
+ mask-namelist = p;
+ condition = NULL;
}
if (prev_condition)
@@ -663,6 +659,9 @@
int is_on_page;
int is_on_global_page;
FvwmWindow *sf = get_focus_window();
+ struct namelist *p;
+ char *name;
+ Bool invert,tried,matched;
/* match FixedSize conditional */
/* special treatment for FixedSize, because more than just
@@ -822,27 +821,52 @@
}
}
- /* Yes, I know this could be shorter, but it's hard to understand then
-*/
- does_name_match = matchWildcards(mask-name, fw-name.name);
- does_icon_name_match = matchWildcards(mask-name, fw-icon_name.name);
- does_class_match =
- (fw-class.res_class matchWildcards(
- mask-name,fw-class.res_class));
- does_resource_match =
- (fw-class.res_name matchWildcards(
- mask-name, fw-class.res_name));
- does_match =
- (does_name_match || does_icon_name_match || does_class_match ||
-does_resource_match);
- if (mask-my_flags.needs_name !does_match)
- {
- return False;
- }
- if (mask-my_flags.needs_not_name does_match)
- {
- return False;
- }
+ tried = False;
+ matched = False;
+
+ for(p=mask-namelist; p; p=p-next)
+ {
+ name = p-name;
+ invert = False;
+ if(*name == '!')
+ {
+ name++;
+ invert = True;
+ }
+
+ /* Yes, I know this could be
Re: Patch to allow multiple window names in conditions
Craig wrote: Next (Netscape konqueror Mozilla*) WarpToWindow 99 90 This is a nice implementation of an OR rule, is there any way of specifying and AND rule? For example, a rule to match a window with Class Netscape and Title local*. Now that multiple window names can be read, why not include one. For example, i would want these to this expression All (Netscape) ThisWindow (local*) ... to be reduced to All (Netscape local*) But this is exactly the syntax used by this patch, hence it means OR. By default, all other conditions must be true, so i propose an alternate syntax for window name/class/resource OR conditions: All (Netscape |konqueror |Mozilla*) ... Perhaps it's not worth the effort? I just thought it was a little counter-intuitive. Once you add the possibility of AND as well as OR, you get into the realm of boolean expressions, which require a parser. For instance, if someone can write the above, he'd naturally expect to be able to write Netscape local* |konqueror |Mozilla* which presumably would be parsed with the normal boolean precedence, as (Netscape AND local*) OR konqueror OR Mozilla* That sort of parser would be about thirty times as much work for me; and I figured OR was far more useful than AND -- it was certainly the only thing I wanted for my own use. This also works well with not commands: All (Netscape |konqueror |Mozilla* !Opera) ... will match all browsers except opera if !Opera is read as an AND NOT (which is subtly different to the patch syntax's implied OR NOT) Actually NOTs are all AND NOT, in the patch; just leave off the '|'s, and that line'll work fine. (Yeah, the logic for mixing wanted window-names with unwanted window-names is a bit confusing; my first version of the patch, which was implemented differently, simply refused to accept such mixtures.) Perhaps a better way of describing it would be to say that NOTs take priority: if any name with '!' in front of it matches, then the condition fails, no matter what else matches or doesn't match. I guess one could implement an OR NOT rule, but i strongly doubt the usefulness of it. Yeah, I too figured AND NOT was much more useful than OR NOT. The way I've used this patch is to program a bunch of hotkeys for specific windows or classes of windows, and then add one final hotkey for all other windows: Key F1 A NNext (CurrentGlobalPage xterm1) goto-window Key F2 A NNext (CurrentGlobalPage xterm2) goto-window Key F3 A NNext (CurrentGlobalPage xterm3) goto-window Key F4 A NNext (CurrentGlobalPage emacs) goto-window Key F5 A NNext (CurrentGlobalPage Netscape konqueror Mozilla \ mozilla-bin) goto-window Key F6 A NNext (CurrentGlobalPage xdvi xpdf Xpdf gv acroread) \ goto-window Key F7 A NNext (CurrentGlobalPage xv ee Gimp) goto-window Key F8 A NNext (CurrentGlobalPage !xterm1 !xterm2 !xterm3 \ !emacs !Netscape !konqueror \ !xdvi !xpdf !gv !acroread !xv !ee \ !Gimp !Mozilla !mozilla-bin) \ goto-window I'd imagine a _full_ implementation of this would require a linked list of linked lists so one can specify multiple OR conditions eg.: All (Netscape |konqueror http* |file* !http://www.google*) would match all netscape and konqueror windows with titles that start with either http or file but not showing google. Note the not google rule needn't be applied to a specific list as its evaluation to true anywhere negates the rule. Uh, there you're reversing the normal rule of boolean precedence, which gives AND a higher precedence than OR. With the normal rule, that'd be parsed as Netscape OR (konqueror AND http*) OR (file* AND NOT http://www.google*) whereas you want (Netscape OR konqueror) AND (http* OR file*) AND NOT http://www.google* This sort of thing is why I think the only sensible next step would be a full-blown boolean-expression parser, which would accept parentheses as well as AND, OR, and NOT operators, and store the boolean expression as a tree structure. (No, I'm too lazy to write such a thing; I don't have any use for it.) -- Norman Yarvin http://yarchive.net -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch to allow multiple window names in conditions
Next (Netscape konqueror Mozilla*) WarpToWindow 99 90 This is a nice implementation of an OR rule, is there any way of specifying and AND rule? For example, a rule to match a window with Class Netscape and Title local*. Now that multiple window names can be read, why not include one. For example, i would want these to this expression All (Netscape) ThisWindow (local*) ... to be reduced to All (Netscape local*) But this is exactly the syntax used by this patch, hence it means OR. By default, all other conditions must be true, so i propose an alternate syntax for window name/class/resource OR conditions: All (Netscape |konqueror |Mozilla*) ... Perhaps it's not worth the effort? I just thought it was a little counter-intuitive. This also works well with not commands: All (Netscape |konqueror |Mozilla* !Opera) ... will match all browsers except opera if !Opera is read as an AND NOT (which is subtly different to the patch syntax's implied OR NOT) I guess one could implement an OR NOT rule, but i strongly doubt the usefulness of it. I'd imagine a _full_ implementation of this would require a linked list of linked lists so one can specify multiple OR conditions eg.: All (Netscape |konqueror http* |file* !http://www.google*) would match all netscape and konqueror windows with titles that start with either http or file but not showing google. Note the not google rule needn't be applied to a specific list as its evaluation to true anywhere negates the rule. But of course a simpler (perhaps better too) method would just implement: All (Netscape |konqueror |http |file !opera) Of course, these are all just suggestions :) Great patch though, - Craig -- [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
