Re: A naive Xinerama question
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. If this behaviour is really needed, fvwm itself should always check if XineramaScreen(curx,cury)!=XineramaScreen(oldx,oldy), which can be time consuming. And there's another pitfall -- screens may overlap, so that screen where the pointer on concept becomes somewhat dubious (but that's a pathological case, and we use this concept anyway for determining a rectangle to clip menus etc. to). BTW, Olivier, can you please tell where this behaviour can be useful? I tried to imagine such situations with no results, but something tells me they *must* exist. _ 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 Tue, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
BTW, I think that the change Xinerama{Enable,Disable} - Xinerama
is not very good: it is difficult to a configuration tool or a user
new to Xinerama to know if Xinerama is enabled or not.
Er, what is the big difference between
XineramaEnable
XineramaDisable
and
Xinerama on
Xinerama off
? It just saves the additional commands. And I can't think of
any fvwm command that has an off and an on version. On the
other hand it makes module configuration a lot easier. Fvwm can
simply send the whole string after Xinerama to the module which
in turn passes it to a Xinerama library function to configure
itself. Also, many commands already use the boolean argument
type, so why not this one?
With
Xinerama{Enable,Disable} we know where we go as with the Xinerama
command even an experimented user should try a command or an action
to see if Xinerama is enabled or not and predict the effect of this
command.
It almost never makes sense to turn off Xinerama anyway. If there
is only one screen it is a no-op. If you have more than one
screen, not using Xinerama support is a pain. The only situation
I can think of where this is not desirable is with a very big,
tiled screen composed of many monitors, e.g. on a trade fair. In
this case we can expect that the tech people are able to read the
man page.
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: Patch for possible if-else syntax
On Wed, Aug 08, 2001 at 12:27:18AM +0700, Dmitry Yu. Bolkhovityanov wrote: Content-Description: Mail message body Hi! I've made a patch which implements a simple if-else syntax. A new Otherwise command is introduced (wouldn't clash with possible future syntax enhancements, right?), which executes supplied command only if previous command was unsuccessful. So the syntax is: AddToFunc Do-this-or-that + I Next (SomeProggie) Close + I Otherwise SomeProggie (this implements Dominik's example of if some window exists, kill it, otherwise start it). Each command may return a True/False value, which defaults to True. This logic is implemented in execute_complex_function(), which sets the current return value to True before calling a command. There's no change in command calling conventions, since return value of this command and return value of previous command are global variables (sic!). Changed are only conditional commands, which set return value to False when unsuccessful. I also investigated if it would be possible to place these two vars into exec_func_args_type, but those structs aren't passed between *execute*function(). Since return values are stored in global vars, execute_complex_function() saves previous state and restores it on exit. Unfortunately, it contained a number of returns, which had to be replaced with goto END_OF_FUNCTION (I wish C had Ada/Perl break from a block feature...). Of course, calling Otherwise outside a complex function is senseless. Man page modification isn't included. Is it really necessary to pass function return codes through global variables? If we do this now we will regret it some day. 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: Patch for possible if-else syntax
On Wed, Aug 08, 2001 at 04:45:34AM +, Mikhael Goikhman wrote: On 08 Aug 2001 00:27:18 +0700, Dmitry Yu. Bolkhovityanov wrote: I've made a patch which implements a simple if-else syntax. A new Otherwise command is introduced (wouldn't clash with possible future syntax enhancements, right?), which executes supplied command only if previous command was unsuccessful. So the syntax is: AddToFunc Do-this-or-that + I Next (SomeProggie) Close + I Otherwise SomeProggie (this implements Dominik's example of if some window exists, kill it, otherwise start it). Each command may return a True/False value, which defaults to True. This logic is implemented in execute_complex_function(), which sets the current return value to True before calling a command. There's no change in command calling conventions, since return value of this command and return value of previous command are global variables (sic!). Changed are only conditional commands, which set return value to False when unsuccessful. I also investigated if it would be possible to place these two vars into exec_func_args_type, but those structs aren't passed between *execute*function(). Since return values are stored in global vars, execute_complex_function() saves previous state and restores it on exit. Unfortunately, it contained a number of returns, which had to be replaced with goto END_OF_FUNCTION (I wish C had Ada/Perl break from a block feature...). Of course, calling Otherwise outside a complex function is senseless. Grr... :) Before reading the mail I did my own patch that happens to be almost equivalent to yours, except for minor things. Say, I used interface functions instead of global variables (there is only one static variable). Also in my intention, functions may return more than just success or failure. We may have in the future such failure codes like: timeout, window mismatch, timeout, incorrect usage, and the Otherwise command may have an optional parameter to distinguish between different failures. In the future all CMD_* functions may return this value, that is success in most of cases. Currently it is not needed to minimize changes. I called the function Else, because I hoped to have If in the future (for non-window conditions). But I have no objections to call it Otherwise. 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. 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. 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: What to do for next release?
On Wed, Aug 08, 2001 at 06:08:06PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Sun, 5 Aug 2001, Dominik Vogt wrote: On Sat, Aug 04, 2001 at 08:36:27PM +0700, Dmitry Yu. Bolkhovityanov wrote: BTW, would it be possible to make --enable-multibyte a default in 2.4.1? As I understand, most of the people are lucky with 8859-1, but that's not the case for us, koi8-r'ers. In most of the modern apps (Netscape is most popular) russian titles are displayed as raw 2022 strings, i.e. the titles are interweaved with koi8-r strings and 2022 escapes. (Sure, my students now better understand how i18n works in X, but I'd prefer them to use their time for other work.) Is there something critical and untested in multibyte code? The whole multibyte support is basically untested :-) I can't remember the minute details, but there are several places where internationalised strings are not yet handled. Then there was this font problem you reported a while ago. Finally, it's implemented using dozens of ifdefs all over the code. This can not be the final solution. A library like implementation like the Xinerama library is needed. This includes a font/fontlist management module that hides the details from the caller. Okay, this answers the question I haven't asked yet -- regarding antialiased text. The Xft library becomes very polular, and is already used in Qt, Gtk and some other WMs. I've skimmed through fvwm code, and it has too close relations with X core fonts. But if a dedicated library is already planned for i18n, adding support for antialiased text will be easy. Planned is perhaps not the right term. Needed urgently might be a better one. We don't have anyone here on the list who is experienced in mb support *and* willing to do the work. 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
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. _ 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]
Notification: incoming/756
FVWM Bug Tracking notification new message incoming/756 Message summary for PR#756 From: [EMAIL PROTECTED] Subject: maximize hold bug w/ xterm Date: Wed, 08 Aug 2001 15:40:57 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Wed Aug 08 15:40:58 2001 Received: from karazm.math.uh.edu ([129.7.128.1]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15Ua8P-00026M-00 for [EMAIL PROTECTED]; Wed, 08 Aug 2001 15:40:57 -0500 Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id PAA00977 for [EMAIL PROTECTED]; Wed, 8 Aug 2001 15:40:57 -0500 (CDT) From: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15Ua8P-00026I-00 for [EMAIL PROTECTED]; Wed, 08 Aug 2001 15:40:57 -0500 To: [EMAIL PROTECTED] Subject: maximize hold bug w/ xterm Message-Id: [EMAIL PROTECTED] Date: Wed, 08 Aug 2001 15:40:57 -0500 Full_Name: Jacek Kopecky Version: 2.4.0 CVS_Date: OS: X_Server: Submission from: (NULL) (194.213.203.154) When you maximize a window and the window tries to resize itself, it is kept maximized. An example could be an xterm window, when it's maximized and you change the font size, it is resized to more or less match the maximized state. But I've noticed that if you keep changing to various font sizes, the window is actually shrinking. It seems like the new size is computed to be the biggest allowable by the window's resize step (like a character size in xterm) but smaller than the previous size, instead of the intended maximized state, for example the whole screen. -- 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: Notification: incoming/756
On Wed, Aug 08, 2001 at 03:40:58PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/756 Message summary for PR#756 From: [EMAIL PROTECTED] Subject: maximize hold bug w/ xterm Date: Wed, 08 Aug 2001 15:40:57 -0500 0 replies 0 followups Full_Name: Jacek Kopecky Version: 2.4.0 CVS_Date: OS: X_Server: Submission from: (NULL) (194.213.203.154) When you maximize a window and the window tries to resize itself, it is kept maximized. An example could be an xterm window, when it's maximized and you change the font size, it is resized to more or less match the maximized state. But I've noticed that if you keep changing to various font sizes, the window is actually shrinking. It seems like the new size is computed to be the biggest allowable by the window's resize step (like a character size in xterm) but smaller than the previous size, instead of the intended maximized state, for example the whole screen. Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [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]
Re: Patch for possible if-else syntax
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. 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. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [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]
