Re: a naive Xinerama question
On Wed, Aug 08, 2001 at 07:47:03PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Wed, 8 Aug 2001, Matthias Clasen wrote: On Tue, 7 Aug 2001, Olivier Chapuis wrote: Hello, I have a very naive Xinerama question: Is it possible to send to modules a M_NEW_SCREEN message when the mouse pointer change of screen? Technicaly it isn't possible -- X server wouldn't generate EnterScreenNotify events, since Xinerama screens look like a single large screen. But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Olivier -- 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 for possible if-else syntax
On 08 Aug 2001 14:57:41 +0200, Dominik Vogt wrote: On Wed, Aug 08, 2001 at 04:45:34AM +, Mikhael Goikhman wrote: In any way, this solution is more clean and extendible than the Dominik's one and it does not change any existing syntax. Hm. I'd really prefer a solution that is *not* extensible. I thought there was a common consensus that we don't want to implement a scripting language in fvwm. Are not scripting language and extensible solutions orthogonal? Maybe we speak about different meanings of extensible solution, or you really prefer to solve all new and old problems separately? For example, if there is a need to do the following 1) Add an alternative command to conditions 2) Try several file names to Read 3) Determine that a module was not started 4) Determine a timeout in some commands you suggest to alter a syntax of Next, Read, Module, ModuleSynchronous and others, instead of identifying that all these problems are actually one if-else problem and implementing an extensible solution, like command statuses and Otherwise, without a need to change any existing syntax? With this solution, solving more similar problems is done by adding a line. Or another example of extensible solution. We currently only need a command status True/False, so we go with Boolean by adding it to many places. But tomorrow we will need another Boolean, so we should add it to the same places again. An extensible solution would suggest that we will need more than a Boolean in the future and do it in the first place. So, if there are no objections I will apply the merged patch implementing this new command. And BTW, it has sense (not yet) to call this command outside of functions. Read myfile1 quiet Otherwise Read myfile2 quiet Otherwise Echo Error: No myfile1 or myfile2 found That's the best example I could think of why global variables are *not* the way to go. Whenever a command is executed outside a function, there is a chance that another command gets executed first and screws up the return code. You are right, there is a common problem with synchronizing commands from the same stream in concurrent environment. But there are no problems if these commands are Read from a file, because another command can't get executed until the file is finished. So I still think that Otherwise outside of functions is useful, although it is almost useless interactively. 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: a naive Xinerama question
On Thu, 9 Aug 2001, Olivier Chapuis wrote: Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Well, that sounds very reasonable (now I understand my mistake -- I was thinking about something similar to FvwmBacker, but for Xinerama screens, which is a nonsense ;-). We have an option to add such functionality right now, but with fvwm tracking screens itself (this is needed anyway for emulated Xinerama), and later check for real EnterScreenNotify availability in configure script. IMHO currently the best way to go is collecting various reasons for such an event, and later discuss it with X people. Looking at Xserver and libXinerama sources, I can easily work out a patch for this thingie (the server internally has a ChangeScreen event, since it has to move cursor between screens). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- 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: a naive Xinerama question
On Thu, Aug 09, 2001 at 09:37:50PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 9 Aug 2001, Olivier Chapuis wrote: Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Well, that sounds very reasonable (now I understand my mistake -- I was thinking about something similar to FvwmBacker, but for Xinerama screens, which is a nonsense ;-). We have an option to add such functionality right now, but with fvwm tracking screens itself (this is needed anyway for emulated Xinerama), and later check for real EnterScreenNotify availability in configure script. I don't think this can be solved inside fvwm to our satisfaction. Polling the mouse pointer wastes lots of CPU and tracking the pointer via MotionNotify events does not work when the pointer is grabbed. IMHO currently the best way to go is collecting various reasons for such an event, and later discuss it with X people. Looking at Xserver and libXinerama sources, I can easily work out a patch for this thingie (the server internally has a ChangeScreen event, since it has to move cursor between screens). That would be the right place to implement this functionality. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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: a naive Xinerama question
But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. All the same reasons why you want to get enter and leave events on the root window in multi-screen scenarios, I guess. Of course, the application with the strongest interest in such information is the window manager, but toolkits could also use it as a low-overhead way to find the necessary information for e.g. restricting menus to be completely onscreen (or rather onxineramascreen). In fact, I would thing that enter/leave notification would be a very natural feature and I can't think of any possible reasons for the X Xinerama group to not accept it. Matthias -- 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 for possible if-else syntax
On 08 Aug 2001 21:29:50 +0200, Dominik Vogt wrote:
On Wed, Aug 08, 2001 at 08:14:01PM +0700, Dmitry Yu. Bolkhovityanov wrote:
On Wed, 8 Aug 2001, Dominik Vogt wrote:
Is it really necessary to pass function return codes through
global variables? If we do this now we will regret it some day.
That's just a logical consequence of current CMD_fff calling
convention. I really investigated if globals can be avoided, but there is
*no* per-call structure to hold the return value.
That's why I wanted avoid function return codes. Every return
in each CMD_... function would have to be touched.
And yes, there is an obvious case when this solution would break
-- if someday fvwm will allow concurrent execution of functions (AFAIK,
currently it does so in an interrupt fashion, so that saving/restoring
the state in execute_complex_function() is enough).
What do you mean with if someday? Fvwm already supports
asynchronous execution, e.g. when modules send commands.
I think Dimitry meant asynchronous execution of _complex_ functions.
I myself often call complex functions simply functions as opposed to
functions that are commands.
Anyway, there is a fairly simple solution to save the patch: add
another parameter to the macros in fvwm.h:
#define F_CMD_ARGS XEvent *eventp, Window w, FvwmWindow *tmp_win, unsigned
long context,char *action, int *Module, Bool *ret_rc
#define F_PASS_ARGS eventp, w, tmp_win, context, action, Module, ret_rc
#define F_EXEC_ARGS char *action, FvwmWindow *tmp_win, XEvent *eventp,
unsigned long context, int Module, Bool *ret_rc
#define F_PASS_EXEC_ARGS action, tmp_win, eventp, context, *Module, ret_rc
(sorry for the long lines).
The *ret_rc would be pre-initialised with True just like the
globals in the patch. Only conditional commands ever set it to
False. Now, only the few direct calls of CMD_... functions that
do not pass the arguments via one of the macros have to be
modified. This would be good enough for me.
The patch became much longer, because all references to
old_execute_function and some other functions should be altered.
I attach the patch for reviewing. Changes other than in conditional.c and
functions.c are less interesting. The patch is somewhat different from
Dmitry's, but implements the same thing. Complex functions return the
status of the last inner command. Probably some things may be tuned.
Regards,
Mikhael.
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.226
diff -u -r1.226 add_window.c
--- fvwm/add_window.c 2001/06/23 18:30:15 1.226
+++ fvwm/add_window.c 2001/08/09 14:55:53
@@ -1497,7 +1497,7 @@
if (!IsRectangleOnThisPage(tmp_win-frame_g, Scr.CurrentDesk))
{
SET_STICKY(tmp_win, 0);
- handle_stick(Event, tmp_win-frame, tmp_win, C_FRAME, , 0, 1);
+ handle_stick(Event, tmp_win-frame, tmp_win, C_FRAME, , 0, NULL, 1);
}
}
@@ -1516,7 +1516,7 @@
Event.xbutton.y = (tmp_win-frame_g.height1);
Event.xbutton.subwindow = None;
Event.xany.window = tmp_win-w;
-CMD_Resize(Event , tmp_win-w, tmp_win, C_WINDOW, , 0);
+CMD_Resize(Event , tmp_win-w, tmp_win, C_WINDOW, , 0, NULL);
}
/** window colormap **/
Index: fvwm/builtins.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/builtins.c,v
retrieving revision 1.313
diff -u -r1.313 builtins.c
--- fvwm/builtins.c 2001/08/01 15:22:51 1.313
+++ fvwm/builtins.c 2001/08/09 14:55:57
@@ -1861,7 +1861,7 @@
if (!*s)
return;
Scr.cur_decor = decor;
- old_execute_function(s, NULL, Event, C_ROOT, -1, 0, NULL);
+ old_execute_function(s, NULL, Event, C_ROOT, -1, NULL, 0, NULL);
Scr.cur_decor = NULL;
}
@@ -1968,7 +1968,8 @@
fw-frame_g.height -= fw-decor-title_height;
fw-decor = NULL;
old_execute_function(
- ChangeDecor Default, fw, eventp, C_WINDOW, *Module, 0, NULL);
+ ChangeDecor Default, fw, eventp, C_WINDOW, *Module, NULL, 0,
+ NULL);
}
}
}
@@ -3267,7 +3268,8 @@
usleep(20);
UngrabEm(GRAB_BUSY);
}
-old_execute_function(stroke_action, tmp_win, eventp, context, -1, 0, NULL);
+old_execute_function(
+ stroke_action, tmp_win, eventp, context, -1, NULL, 0, NULL);
}
}
Index: fvwm/commands.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.1
diff -u -r1.1 commands.h
--- fvwm/commands.h 2001/03/24 15:15:21 1.1
+++ fvwm/commands.h 2001/08/09 14:55:57
@@ -114,6 +114,7 @@
void CMD_None(F_CMD_ARGS);
void CMD_Nop(F_CMD_ARGS);
void CMD_OpaqueMoveSize(F_CMD_ARGS);
+void CMD_Otherwise(F_CMD_ARGS);
void CMD_Pick(F_CMD_ARGS);
void CMD_PipeRead(F_CMD_ARGS);
void
Re: Patch for possible if-else syntax
On 09 Aug 2001 17:35:57 +0200, Dominik Vogt wrote: I'd rather rewrite the syntax 20 commands than extend the command parser in such a way. Currently it is *the* worst piece of fvwm code: not extensible, hard to understand, undpredictable, buggy. I am not sure why do you think so. I see no reasons. It is actually not hard to understand if you understood the original smaller patch. Granted, I didn't tested it fully, only maybe 5-6 cases, But if you don't use the new stuff (command Otherwise or last status $?) there should not be any reduction in stability. This may wait for 2.5.0. You are right: it can only work inside complex functions and Read files and fail from modules and the command line. I guess then my proposal is still the most sound one: easy to implement, the patches are limited to a single file, helps with the most basic needs some users have and does not encourage difficult to implement enhancement requests. In my eyes, we can only think about scripting support in the command parser if we are prepared to throw away the whole code in functions.c and write it from scratch - which explicitly means that the most central part of fvwm becomes incompatible to older versions. Concurrent command execution is already broken within + command. This is an old problem, which probably can be solved if we store all global data last_* separately for every module pipe. Will this be a solution? Dominik, you once said that a lot of harm was done by many small patches each implementing its own inconsistent syntax. The enhancement you suggest is powerful, of course, you may write a whole if-else program in one line using nested conditions. But I don't feel this is a good syntax to introduce. I would not introduce any new syntax as radical as this without thinking about consistency with other command syntaxes. The solution that does not introduce any new syntax, but solves more than one problem is more preferable to me. After 2.5.0 we may think and change syntax. Anyway, I have no any willing to force my solution without your agreement. 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]
