Re: Quite old patch adding new Test condition
On Tue, Aug 09, 2005 at 11:16:05AM +, Mikhael Goikhman wrote:
> On 09 Aug 2005 08:47:10 +0200, Rafal Bisingier wrote:
> >
> > On Mon, Aug 08, 2005 at 10:59:16AM +, Mikhael Goikhman wrote:
> > > On 08 Aug 2005 11:27:16 +0200, Rafal Bisingier wrote:
> > > >
> > > > This patch ads new test-condition to the Test function named
> > > > Compare.
> > > > With it one can do simple comparisions of numbers or strigs
> > > > without
> > > > using PipeRead and shell subprocesses.
> > >
> > > I don't really like this verbose syntax:
> > >
> > > Test (Compare "string 1" strcmp "string 2") DoSomething
> > >
> > > The following syntax is better:
> > >
> > > Compare ("string 1" eq "string 2") DoSomething
> >
> > Well, this syntax is strightly derived from existing syntax and this
> > is
> > the only reason of it's form.
>
> Sure. My point is we may go with a better/simplier syntax instead.
And I agree with you. This was just the simplest way to get what I
needed at that time. But we can of course make it better now. ;-)
At least if it will not take next 10 months... ;-)
> > > Perl's operators (eq, ne, lt, gt, le, ge and cmp) are string
> > > equivalents of numerical operators (==, !=, <, >, >=, <=, <>).
> > > Not sure there is a need for 2 sets of operators rather than
> > > just string operations, but ok.
> >
> > I need it only for integer comparision, so didn't take much care
> > about
> > string operations. I've added strcmp only for completness and
> > because it
> > was easy to do ;-)
> > I personaly don't like perl's string operators (eq, ne, etc.)
>
> Is it because of "perl" or because of "eq", "ne" names? These names
> are
> also tcl's expr operators, and you may find them in the test(1) man
> page.
I don't like "eq","ne" names. It's hard to tell them apart from compared
strings. I don't care if it's "perl's" or anything else, I just want to
have clear and easy to read syntax. Standard mathematical operators are
for me more natural and so easier to read.
> > and I don't see any reason to have le, lt, ge and gt operators other
> > than completness.
>
> These may be useful for those who use test(1) and sort(1).
I don't see the usefulness of them, but that's not important. I just
don't care if they'll be there or not.
> But again, I don't see a good reason to have different operators for
> "12" == "12" and "string" == "string", unless you also add
> mathematical
> operators. Numbers are normal strings in most of the scripting
> languages.
I agree there should be only one set of operators, so numbers can be
compared just the same as strings, but I'm not sure if we really need
so extended functionality in core fvwm...
> > I think much more useful would be case insensitive comparision
>
> I agree, but I don't think C functions (C does not have string
> operators)
> are a good model for a new scripting language. And, well, lowercased
> (or any other) comparisions are already available in FVWM (try it):
>
> Eval cmd("GotoDesk 2") if "something" eq lc("SomeThing")
>
> After:
>
> AddToFunc Eval I SendToModule FvwmPerl eval $*
> Module FvwmPerl
I didn't knew it, but that's not a solution for me anyway, because I
need only simple comparisions for choosing right config options. I don't
want to run FvwmPerl just for that. It's almost the same as PipeRead'ing
shell scripts doing comparision.
> > > Having separate command for this is not really a problem, just
> > > like we
> > > have separate command for TestRc. And if already do this, then
> > > simply:
> > >
> > > If ("string 1" eq "string 2") DoSomething
> >
> > When I made this patch I wanted it to make as little changes to fvwm
> > source as possible and make the patch as simple as I only can in the
> > hope that this can help in merging it into fvwm...
> >
> > > But then we had another similar "If" patch by Scott, IIRC.
> >
> > Yes, there is a patch from Scott adding a complete
> > if-elseif-else-endif
> > syntax, but it's far more bigger, much more complicated and adds
> > completely new syntax. From the other side Scott's patch is more
> > functional and probably simpler to use in complicated configuration.
> >
> > I don't care which patch can be included into fvwm now (it could be
> > even
> > both of them)
>
> I think the ideas in these two patches are ok. There is a place for
> both.
> For example, if we have a "Compare" command that supports different
> operators, it may be used together with "If".
>
> Still, I would prefer to design one clean syntax rather than to have
> many random additions that are "easy to implement".
I can't disagree with you, but I also want to have this simple
comparision functionality ASAP (so preferably before 2.6).
> > aviable in fvwm config file without the need of external commands
> > run by PipeRead.
>
> I guess you don't consider FvwmPerl as an option for string operations
> or mathematics.
As I said before runing FvwmPerl for couple of simple com
CVS migo: * perllib: fix minor but annoying warning in certain module situations
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo05/08/09 19:23:51 Modified files: perllib: ChangeLog perllib/FVWM : Module.pm.in Log message: * perllib: fix minor but annoying warning in certain module situations _ about DESTROY creating a new reference to the object being destroyed
Re: Quite old patch adding new Test condition
On 09 Aug 2005 08:47:10 +0200, Rafal Bisingier wrote:
>
> On Mon, Aug 08, 2005 at 10:59:16AM +, Mikhael Goikhman wrote:
> > On 08 Aug 2005 11:27:16 +0200, Rafal Bisingier wrote:
> > >
> > > This patch ads new test-condition to the Test function named Compare.
> > > With it one can do simple comparisions of numbers or strigs without
> > > using PipeRead and shell subprocesses.
> >
> > I don't really like this verbose syntax:
> >
> > Test (Compare "string 1" strcmp "string 2") DoSomething
> >
> > The following syntax is better:
> >
> > Compare ("string 1" eq "string 2") DoSomething
>
> Well, this syntax is strightly derived from existing syntax and this is
> the only reason of it's form.
Sure. My point is we may go with a better/simplier syntax instead.
> > Perl's operators (eq, ne, lt, gt, le, ge and cmp) are string
> > equivalents of numerical operators (==, !=, <, >, >=, <=, <>).
> > Not sure there is a need for 2 sets of operators rather than
> > just string operations, but ok.
>
> I need it only for integer comparision, so didn't take much care about
> string operations. I've added strcmp only for completness and because it
> was easy to do ;-)
> I personaly don't like perl's string operators (eq, ne, etc.)
Is it because of "perl" or because of "eq", "ne" names? These names are
also tcl's expr operators, and you may find them in the test(1) man page.
> and I don't see any reason to have le, lt, ge and gt operators other
> than completness.
These may be useful for those who use test(1) and sort(1).
But again, I don't see a good reason to have different operators for
"12" == "12" and "string" == "string", unless you also add mathematical
operators. Numbers are normal strings in most of the scripting languages.
> I think much more useful would be case insensitive comparision
I agree, but I don't think C functions (C does not have string operators)
are a good model for a new scripting language. And, well, lowercased
(or any other) comparisions are already available in FVWM (try it):
Eval cmd("GotoDesk 2") if "something" eq lc("SomeThing")
After:
AddToFunc Eval I SendToModule FvwmPerl eval $*
Module FvwmPerl
> > Having separate command for this is not really a problem, just like we
> > have separate command for TestRc. And if already do this, then
> > simply:
> >
> > If ("string 1" eq "string 2") DoSomething
>
> When I made this patch I wanted it to make as little changes to fvwm
> source as possible and make the patch as simple as I only can in the
> hope that this can help in merging it into fvwm...
>
> > But then we had another similar "If" patch by Scott, IIRC.
>
> Yes, there is a patch from Scott adding a complete if-elseif-else-endif
> syntax, but it's far more bigger, much more complicated and adds
> completely new syntax. From the other side Scott's patch is more
> functional and probably simpler to use in complicated configuration.
>
> I don't care which patch can be included into fvwm now (it could be even
> both of them)
I think the ideas in these two patches are ok. There is a place for both.
For example, if we have a "Compare" command that supports different
operators, it may be used together with "If".
Still, I would prefer to design one clean syntax rather than to have many
random additions that are "easy to implement".
> aviable in fvwm config file without the need of external commands run by
> PipeRead.
I guess you don't consider FvwmPerl as an option for string operations or
mathematics.
Maybe we should have "Eval" (or PerlEval) command built-in?.. That will
fetch FvwmPerl on the first use, so there is no overhead for other users.
I thought about such generic autoload-module-on-demand idea, but the
current module interface is not flexible enough to implement it cleanly.
A quick hack would be to add definition of Eval in ConfigFvwmDefaults.
Regards,
Mikhael.
Re: Problem with edge commands raising windows
On Tue, 9 Aug 2005, Viktor Griph wrote:
I've run into an event race when having the following configuration:
DestroyFunc LowerPager
AddToFunc LowerPager
+ I PointerWindow (FvwmPager) Break
+ I All (FvwmPager) Lower
EdgeCommand North All (FvwmPager) Raise
EdgeCommand West All (FvwmPager) Raise
EdgeLeaveCommand North Function LowerPager
EdgeLeaveCommand West Function LowerPager
The problem is when moving from the north pan frame to the west. While being
at the upper left corner the pager will keep raising and lowering all the
time. This is due to the pan frame being raised under the pointer, thus
creating new EnterNotify and LeaveNotify events.
/Viktor
I've found that throwing away LeaveNotify events with a matching
EnterNotify (just as EnterNotify does with LeaveNotify) solves the
problem. I don't know if that would break anything else thou.
/ViktorIndex: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2609
diff -u -r1.2609 ChangeLog
--- ChangeLog 7 Aug 2005 09:48:29 - 1.2609
+++ ChangeLog 9 Aug 2005 09:30:28 -
@@ -1,3 +1,10 @@
+2005-08-09 Viktor Griph <[EMAIL PROTECTED]>
+
+ * fvwm/events.c (HandleLeaveNotify):
+ throws away LeaveNotify events with matching EnterNotify (fixes
+ issue with raisePanFrames generating LeaveNotify + EnterNotify
+ after a Raise command issued by an edge command)
+
2005-08-07 Dominik Vogt <[EMAIL PROTECTED]>
* fvwm/menustyle.c (menustyle_copy):
Index: fvwm/events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.515
diff -u -r1.515 events.c
--- fvwm/events.c 7 Aug 2005 09:39:56 - 1.515
+++ fvwm/events.c 9 Aug 2005 09:30:28 -
@@ -2515,6 +2515,8 @@
{
const XEvent *te = ea->exc->x.etrigger;
FvwmWindow * const fw = ea->exc->w.fw;
+ XEvent d;
+ Bool is_tear_off_menu;
DBUG("HandleLeaveNotify", "Routine Entered");
@@ -2553,6 +2555,23 @@
#endif
return;
}
+
+ /* look for a matching EnterNotify which would nullify this LeaveNotify
+*/
+ is_tear_off_menu =
+ (fw && IS_TEAR_OFF_MENU(fw) &&
+te->xcrossing.window == FW_W(fw));
+ if (!fFvwmInStartup && !is_tear_off_menu &&
+ FCheckTypedWindowEvent(dpy, te->xcrossing.window, EnterNotify, &d))
+ {
+ if (d.xcrossing.mode == NotifyNormal &&
+ d.xcrossing.detail != NotifyInferior)
+ {
+ENTER_DBG((stderr, "en: exit: found EnterNotify\n"));
+ return;
+ }
+ }
+
/* CDE-like behaviour of raising the icon title if the icon
gets the focus (in particular if the cursor is over the icon) */
if (fw && IS_ICONIFIED(fw))
Problem with edge commands raising windows
I've run into an event race when having the following configuration: DestroyFunc LowerPager AddToFunc LowerPager + I PointerWindow (FvwmPager) Break + I All (FvwmPager) Lower EdgeCommand North All (FvwmPager) Raise EdgeCommand West All (FvwmPager) Raise EdgeLeaveCommand North Function LowerPager EdgeLeaveCommand West Function LowerPager The problem is when moving from the north pan frame to the west. While being at the upper left corner the pager will keep raising and lowering all the time. This is due to the pan frame being raised under the pointer, thus creating new EnterNotify and LeaveNotify events. /Viktor
Re: Quite old patch adding new Test condition
Hi there, On 09 Aug 2005 at 11:47:58 +1000, Scott Smedley wrote: > Yes, see: > > http://article.gmane.org/gmane.comp.window-managers.fvwm.devel/1026 > > The plan was to wait until 2.6 - I didn't think it would > be such a long wait however! :) I wait for this functionality impatiently. I maintain the fvwm config at work where we have got different machines with different operating systems and different applications. The presented syntax would be very helpful to handle that. Cheers, Uwe -- ,_, For personal reply/mail put "fvwm" (O,O) in the subject. ( ) Otherwise your mail is discarded by a filter. =-"-"-= http://www.tu-chemnitz.de/~uwpp
