Re: Problems with using SelectOnRelease
On Mon, Mar 03, 2003 at 02:31:29AM +, Mikhael Goikhman wrote: On 02 Mar 2003 22:48:01 +0100, [EMAIL PROTECTED] wrote: On Sat, Mar 01, 2003 at 04:33:11PM +, Mikhael Goikhman wrote: On 28 Feb 2003 16:25:28 +0100, Dominik Vogt wrote: [SelectOnFull[Modifier]Release suggestion skipped] I think it would be more convinient for a user. What do you think? I don't know, I think this is overkill. The typical user wants one of two things: either use the default as it is or turn off SelectOnRelease. The case that she releases Alt first and still holds down the tab key is irrelevant in my eyes. Wh do not have to care so much about redifining the key to trigger selection. A clear description of how to remove the binding should be enough. In any case, I can't easily think of a reliable method to check whether all keys are released or not. What about state toggling keys like num-lock? Strange you think it is overkill, for me it is much simplier and clean than SelectOnRelease. By SelectOnFullRelease I mean the release of all modifiers, i.e. left or right Alt in our case, not Tab. I even think the original modifiers should not be really passed to the menu code; if IgnoreModifiers is global, a menu knows itself when no modifiers are pressed anymore. It's only simpler if you do indeed use a *modifier*. For non-modifier key you have to call XQueryKeymap and scan through the key vector for for relevant set bits. It only makes sence to do something on a modifier release. Doing anything on a non-modifier release is simply too confusing and can't work, I can think of at least two uses: 1) A kind of randomizer with SelectOnRelease (crsr-down) key. Open your xlock menu, press cursor down and select a more or less random item when you release the key. 2) An alternate select key. Open the menu normally and mark an item, then press e.g. F1 to trigger. because a user can't navigate a menu if a non-modifier is still pressed. That depends on the key. Anyway, I don't really care too much about this feature. Bye Dominik ^_^ ^_^ -- 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: Problems with using SelectOnRelease
On Sat, Mar 01, 2003 at 04:33:11PM +, Mikhael Goikhman wrote: On 28 Feb 2003 16:25:28 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 02:42:59PM +, Mikhael Goikhman wrote: Actually, if we speak about the whole idea, I don't think it is very usable as it is now. It is not very easy to setup, because it requires knowing the modifier keysym. Additionally, only one modifier like Meta_L works, not any Alt (there are two). Um, your keyboard has two Alt keys? I have never seen such a keyboard. Well, I never seen a keyboard with only one Alt, thinking about this German has more letters than latin, so this is probably what captured the right Alt. I have worked probably on more different keyboards with US layout than with German layout, and thy all had an Alt Gr key (usually directly right of the space bar). Well, of course I do not recall what was printed on the keys, but they definitely worked like the typical Alt Gr key. Funny. And if a binding does not include the modifier configured in MenuStyle SelectOnRelease, this unrelated modifier still works like Enter, this is a bad side effect. I think that instead of SelectOnRelease it would be much better to have SelectOnFullRelease option (the exact name could be shorter). The default is !SelectOnFullRelease. So the following bindings work without auto-release: Key Tab A CS WindowList Key F1 A CS Menu FvwmMenuRoot and the following select an item when both Ctrl and Shift are released: Key Tab A CS WindowList SelectOnFullRelease Key F1 A CS Menu FvwmMenuRoot SelectOnFullRelease Here any left/right Ctrl and Shift would work, not just one Ctrl_L. I would like not to have any MenuStyle options related to auto-release, because it is pretty trivial to set/unset this per a binding, but MenuStyle is not an issue here. This requires passing all modifiers that the menu was called with to that menu, the auto-release is processed when all original modifiers are not pressed anymore. I hope it is not a big problem to pass the modifiers. I think it would be more convinient for a user. What do you think? I don't know, I think this is overkill. The typical user wants one of two things: either use the default as it is or turn off SelectOnRelease. The case that she releases Alt first and still holds down the tab key is irrelevant in my eyes. Wh do not have to care so much about redifining the key to trigger selection. A clear description of how to remove the binding should be enough. In any case, I can't easily think of a reliable method to check whether all keys are released or not. What about state toggling keys like num-lock? Strange you think it is overkill, for me it is much simplier and clean than SelectOnRelease. By SelectOnFullRelease I mean the release of all modifiers, i.e. left or right Alt in our case, not Tab. I even think the original modifiers should not be really passed to the menu code; if IgnoreModifiers is global, a menu knows itself when no modifiers are pressed anymore. It's only simpler if you do indeed use a *modifier*. For non-modifier key you have to call XQueryKeymap and scan through the key vector for for relevant set bits. 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: Problems with using SelectOnRelease
On 02 Mar 2003 22:48:01 +0100, [EMAIL PROTECTED] wrote: On Sat, Mar 01, 2003 at 04:33:11PM +, Mikhael Goikhman wrote: On 28 Feb 2003 16:25:28 +0100, Dominik Vogt wrote: [SelectOnFull[Modifier]Release suggestion skipped] I think it would be more convinient for a user. What do you think? I don't know, I think this is overkill. The typical user wants one of two things: either use the default as it is or turn off SelectOnRelease. The case that she releases Alt first and still holds down the tab key is irrelevant in my eyes. Wh do not have to care so much about redifining the key to trigger selection. A clear description of how to remove the binding should be enough. In any case, I can't easily think of a reliable method to check whether all keys are released or not. What about state toggling keys like num-lock? Strange you think it is overkill, for me it is much simplier and clean than SelectOnRelease. By SelectOnFullRelease I mean the release of all modifiers, i.e. left or right Alt in our case, not Tab. I even think the original modifiers should not be really passed to the menu code; if IgnoreModifiers is global, a menu knows itself when no modifiers are pressed anymore. It's only simpler if you do indeed use a *modifier*. For non-modifier key you have to call XQueryKeymap and scan through the key vector for for relevant set bits. It only makes sence to do something on a modifier release. Doing anything on a non-modifier release is simply too confusing and can't work, because a user can't navigate a menu if a non-modifier is still pressed. 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: Problems with using SelectOnRelease
On 28 Feb 2003 16:25:28 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 02:42:59PM +, Mikhael Goikhman wrote: Actually, if we speak about the whole idea, I don't think it is very usable as it is now. It is not very easy to setup, because it requires knowing the modifier keysym. Additionally, only one modifier like Meta_L works, not any Alt (there are two). Um, your keyboard has two Alt keys? I have never seen such a keyboard. Well, I never seen a keyboard with only one Alt, thinking about this German has more letters than latin, so this is probably what captured the right Alt. And if a binding does not include the modifier configured in MenuStyle SelectOnRelease, this unrelated modifier still works like Enter, this is a bad side effect. I think that instead of SelectOnRelease it would be much better to have SelectOnFullRelease option (the exact name could be shorter). The default is !SelectOnFullRelease. So the following bindings work without auto-release: Key Tab A CS WindowList Key F1 A CS Menu FvwmMenuRoot and the following select an item when both Ctrl and Shift are released: Key Tab A CS WindowList SelectOnFullRelease Key F1 A CS Menu FvwmMenuRoot SelectOnFullRelease Here any left/right Ctrl and Shift would work, not just one Ctrl_L. I would like not to have any MenuStyle options related to auto-release, because it is pretty trivial to set/unset this per a binding, but MenuStyle is not an issue here. This requires passing all modifiers that the menu was called with to that menu, the auto-release is processed when all original modifiers are not pressed anymore. I hope it is not a big problem to pass the modifiers. I think it would be more convinient for a user. What do you think? I don't know, I think this is overkill. The typical user wants one of two things: either use the default as it is or turn off SelectOnRelease. The case that she releases Alt first and still holds down the tab key is irrelevant in my eyes. Wh do not have to care so much about redifining the key to trigger selection. A clear description of how to remove the binding should be enough. In any case, I can't easily think of a reliable method to check whether all keys are released or not. What about state toggling keys like num-lock? Strange you think it is overkill, for me it is much simplier and clean than SelectOnRelease. By SelectOnFullRelease I mean the release of all modifiers, i.e. left or right Alt in our case, not Tab. I even think the original modifiers should not be really passed to the menu code; if IgnoreModifiers is global, a menu knows itself when no modifiers are pressed anymore. 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]
Problems with using SelectOnRelease together with other options in WindowList
When writing WindowList Root c c NoDeskSort, ShowPage, SelectOnRelease ShowPage works. When writing WindowList Root c c NoDeskSort, SelectOnRelease, ShowPage ShowPage does not work. The Problem here is that SelectOnRelease calls a function to get Options. And I think that ShowPage is calles as an option? This is an FVWM Current. Thomas -- 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: Problems with using SelectOnRelease together with other options in WindowList
On 28 Feb 2003 12:55:06 +0100, Thomas Glanzmann wrote: When writing WindowList Root c c NoDeskSort, ShowPage, SelectOnRelease ShowPage works. When writing WindowList Root c c NoDeskSort, SelectOnRelease, ShowPage ShowPage does not work. The Problem here is that SelectOnRelease calls a function to get Options. And I think that ShowPage is calles as an option? This is an FVWM Current. The parsing of SelectOnRelease option is not good. Use this instead: WindowList Root c c NoDeskSort, SelectOnRelease , ShowPage I think we already received enough complains to rethink this idea. I vote for WindowList not to be defaulting to SelectOnRelease Meta_L. This is only (supposedly/questionably) good for Alt-Tab, but not for other key and mouse combinations that include Alt modifier. It is ok for me if ConfigFvwmDefaults includes this binding: Key Tab A M WindowList Root c c NoDeskSort, SelectOnRelease Meta_L 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: Problems with using SelectOnRelease together with other options in WindowList
On Fri, Feb 28, 2003 at 12:07:06PM +, Mikhael Goikhman wrote: On 28 Feb 2003 12:55:06 +0100, Thomas Glanzmann wrote: When writing WindowList Root c c NoDeskSort, ShowPage, SelectOnRelease ShowPage works. When writing WindowList Root c c NoDeskSort, SelectOnRelease, ShowPage ShowPage does not work. The Problem here is that SelectOnRelease calls a function to get Options. And I think that ShowPage is calles as an option? This is an FVWM Current. The parsing of SelectOnRelease option is not good. Use this instead: WindowList Root c c NoDeskSort, SelectOnRelease , ShowPage I think we already received enough complains to rethink this idea. I vote for WindowList not to be defaulting to SelectOnRelease Meta_L. This is only (supposedly/questionably) good for Alt-Tab, but not for other key and mouse combinations that include Alt modifier. It is ok for me if ConfigFvwmDefaults includes this binding: Key Tab A M WindowList Root c c NoDeskSort, SelectOnRelease Meta_L Then the SelectOnRelease MenuStyle can not be used for the WindowList. That may be even more confusing. Bye Dominik ^_^ ^_^ -- 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: Problems with using SelectOnRelease together with other options in WindowList
On 28 Feb 2003 13:16:36 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 12:07:06PM +, Mikhael Goikhman wrote: On 28 Feb 2003 12:55:06 +0100, Thomas Glanzmann wrote: When writing WindowList Root c c NoDeskSort, ShowPage, SelectOnRelease ShowPage works. When writing WindowList Root c c NoDeskSort, SelectOnRelease, ShowPage ShowPage does not work. The Problem here is that SelectOnRelease calls a function to get Options. And I think that ShowPage is calles as an option? This is an FVWM Current. The parsing of SelectOnRelease option is not good. Use this instead: WindowList Root c c NoDeskSort, SelectOnRelease , ShowPage I think we already received enough complains to rethink this idea. I vote for WindowList not to be defaulting to SelectOnRelease Meta_L. This is only (supposedly/questionably) good for Alt-Tab, but not for other key and mouse combinations that include Alt modifier. It is ok for me if ConfigFvwmDefaults includes this binding: Key Tab A M WindowList Root c c NoDeskSort, SelectOnRelease Meta_L Then the SelectOnRelease MenuStyle can not be used for the WindowList. That may be even more confusing. Do you mean a user will want to leave the default Alt-Tab binding and set MenuStyle WindowList SelectOnRelease to something like Ctrl_R? I think this does not make a sence, it is easier just to redefine his Alt-Tab or Ctrl-Tab or Super-Shift-F2 binding for WindowList without a need to change MenuStyle. Also I am not convinced that having MenuStyle SelectOnRelease is a good idea. A modifier defined in SelectOnRelease is related to a specific key/mouse binding, not to the whole menu that one may want to invoke with or without auto-release on different bindings. But although I think that SelectOnRelease is a property of a binding, I don't suggest to remove MenuStyle SelectOnRelease if you think it is needed, only unbind WindowList from Alt that is currently hardcoded. 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: Problems with using SelectOnRelease together with other options in WindowList
On Fri, Feb 28, 2003 at 12:56:23PM +, Mikhael Goikhman wrote: On 28 Feb 2003 13:16:36 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 12:07:06PM +, Mikhael Goikhman wrote: On 28 Feb 2003 12:55:06 +0100, Thomas Glanzmann wrote: When writing WindowList Root c c NoDeskSort, ShowPage, SelectOnRelease ShowPage works. When writing WindowList Root c c NoDeskSort, SelectOnRelease, ShowPage ShowPage does not work. The Problem here is that SelectOnRelease calls a function to get Options. And I think that ShowPage is calles as an option? This is an FVWM Current. The parsing of SelectOnRelease option is not good. Use this instead: WindowList Root c c NoDeskSort, SelectOnRelease , ShowPage I think we already received enough complains to rethink this idea. I vote for WindowList not to be defaulting to SelectOnRelease Meta_L. This is only (supposedly/questionably) good for Alt-Tab, but not for other key and mouse combinations that include Alt modifier. It is ok for me if ConfigFvwmDefaults includes this binding: Key Tab A M WindowList Root c c NoDeskSort, SelectOnRelease Meta_L Then the SelectOnRelease MenuStyle can not be used for the WindowList. That may be even more confusing. Do you mean a user will want to leave the default Alt-Tab binding and set MenuStyle WindowList SelectOnRelease to something like Ctrl_R? It is more likely that a user wants to remove it with a MenuStyle. I think this does not make a sence, it is easier just to redefine his Alt-Tab or Ctrl-Tab or Super-Shift-F2 binding for WindowList without a need to change MenuStyle. It may be easier if you already know how to do it. But don't forget that the default binding is hidden in some cryptic file the average user knows nothing about. Also I am not convinced that having MenuStyle SelectOnRelease is a good idea. A modifier defined in SelectOnRelease is related to a specific key/mouse binding, not to the whole menu that one may want to invoke with or without auto-release on different bindings. But although I think that SelectOnRelease is a property of a binding, I don't suggest to remove MenuStyle SelectOnRelease if you think it is needed, only unbind WindowList from Alt that is currently hardcoded. It's a matter of usability. Bye Dominik ^_^ ^_^ -- 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: Problems with using SelectOnRelease
On 28 Feb 2003 14:32:17 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 12:56:23PM +, Mikhael Goikhman wrote: On 28 Feb 2003 13:16:36 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 12:07:06PM +, Mikhael Goikhman wrote: I vote for WindowList not to be defaulting to SelectOnRelease Meta_L. This is only (supposedly/questionably) good for Alt-Tab, but not for other key and mouse combinations that include Alt modifier. It is ok for me if ConfigFvwmDefaults includes this binding: Key Tab A M WindowList Root c c NoDeskSort, SelectOnRelease Meta_L Then the SelectOnRelease MenuStyle can not be used for the WindowList. That may be even more confusing. Do you mean a user will want to leave the default Alt-Tab binding and set MenuStyle WindowList SelectOnRelease to something like Ctrl_R? It is more likely that a user wants to remove it with a MenuStyle. We don't have a way to inherit MenuStyle's, so this creates more problems than just redefining a binding. I think this does not make a sence, it is easier just to redefine his Alt-Tab or Ctrl-Tab or Super-Shift-F2 binding for WindowList without a need to change MenuStyle. It may be easier if you already know how to do it. But don't forget that the default binding is hidden in some cryptic file the average user knows nothing about. Both require reading the man page. For me learning about the default binding and removing SelectOnRelease option from it is easier than learning about MenuStyle WindowList SelectOnRelease and defining it. BTW, MenuStyle SelectOnRelease is (and always was) broken. The only way to remove this Meta_L is to define some other valid modifier like Ctrl_R or something like +; empty or no argument restores Meta_L. Also I am not convinced that having MenuStyle SelectOnRelease is a good idea. A modifier defined in SelectOnRelease is related to a specific key/mouse binding, not to the whole menu that one may want to invoke with or without auto-release on different bindings. But although I think that SelectOnRelease is a property of a binding, I don't suggest to remove MenuStyle SelectOnRelease if you think it is needed, only unbind WindowList from Alt that is currently hardcoded. It's a matter of usability. Actually, if we speak about the whole idea, I don't think it is very usable as it is now. It is not very easy to setup, because it requires knowing the modifier keysym. Additionally, only one modifier like Meta_L works, not any Alt (there are two). And if a binding does not include the modifier configured in MenuStyle SelectOnRelease, this unrelated modifier still works like Enter, this is a bad side effect. I think that instead of SelectOnRelease it would be much better to have SelectOnFullRelease option (the exact name could be shorter). The default is !SelectOnFullRelease. So the following bindings work without auto-release: Key Tab A CS WindowList Key F1 A CS Menu FvwmMenuRoot and the following select an item when both Ctrl and Shift are released: Key Tab A CS WindowList SelectOnFullRelease Key F1 A CS Menu FvwmMenuRoot SelectOnFullRelease Here any left/right Ctrl and Shift would work, not just one Ctrl_L. I would like not to have any MenuStyle options related to auto-release, because it is pretty trivial to set/unset this per a binding, but MenuStyle is not an issue here. This requires passing all modifiers that the menu was called with to that menu, the auto-release is processed when all original modifiers are not pressed anymore. I hope it is not a big problem to pass the modifiers. I think it would be more convinient for a user. What do you think? 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: Problems with using SelectOnRelease
On Fri, Feb 28, 2003 at 02:42:59PM +, Mikhael Goikhman wrote: On 28 Feb 2003 14:32:17 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 12:56:23PM +, Mikhael Goikhman wrote: On 28 Feb 2003 13:16:36 +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 12:07:06PM +, Mikhael Goikhman wrote: I vote for WindowList not to be defaulting to SelectOnRelease Meta_L. This is only (supposedly/questionably) good for Alt-Tab, but not for other key and mouse combinations that include Alt modifier. It is ok for me if ConfigFvwmDefaults includes this binding: Key Tab A M WindowList Root c c NoDeskSort, SelectOnRelease Meta_L Then the SelectOnRelease MenuStyle can not be used for the WindowList. That may be even more confusing. Do you mean a user will want to leave the default Alt-Tab binding and set MenuStyle WindowList SelectOnRelease to something like Ctrl_R? It is more likely that a user wants to remove it with a MenuStyle. We don't have a way to inherit MenuStyle's, so this creates more problems than just redefining a binding. Good point. I think this does not make a sence, it is easier just to redefine his Alt-Tab or Ctrl-Tab or Super-Shift-F2 binding for WindowList without a need to change MenuStyle. It may be easier if you already know how to do it. But don't forget that the default binding is hidden in some cryptic file the average user knows nothing about. Both require reading the man page. For me learning about the default binding and removing SelectOnRelease option from it is easier than learning about MenuStyle WindowList SelectOnRelease and defining it. BTW, MenuStyle SelectOnRelease is (and always was) broken. The only way to remove this Meta_L is to define some other valid modifier like Ctrl_R or something like +; empty or no argument restores Meta_L. I know; this certainly adds to the confusion. Maybe the only way to reduce the possibility of misunderstandings is to write a better text in the man page. Also I am not convinced that having MenuStyle SelectOnRelease is a good idea. A modifier defined in SelectOnRelease is related to a specific key/mouse binding, not to the whole menu that one may want to invoke with or without auto-release on different bindings. But although I think that SelectOnRelease is a property of a binding, I don't suggest to remove MenuStyle SelectOnRelease if you think it is needed, only unbind WindowList from Alt that is currently hardcoded. It's a matter of usability. Actually, if we speak about the whole idea, I don't think it is very usable as it is now. It is not very easy to setup, because it requires knowing the modifier keysym. Additionally, only one modifier like Meta_L works, not any Alt (there are two). Um, your keyboard has two Alt keys? I have never seen such a keyboard. And if a binding does not include the modifier configured in MenuStyle SelectOnRelease, this unrelated modifier still works like Enter, this is a bad side effect. I think that instead of SelectOnRelease it would be much better to have SelectOnFullRelease option (the exact name could be shorter). The default is !SelectOnFullRelease. So the following bindings work without auto-release: Key Tab A CS WindowList Key F1 A CS Menu FvwmMenuRoot and the following select an item when both Ctrl and Shift are released: Key Tab A CS WindowList SelectOnFullRelease Key F1 A CS Menu FvwmMenuRoot SelectOnFullRelease Here any left/right Ctrl and Shift would work, not just one Ctrl_L. I would like not to have any MenuStyle options related to auto-release, because it is pretty trivial to set/unset this per a binding, but MenuStyle is not an issue here. This requires passing all modifiers that the menu was called with to that menu, the auto-release is processed when all original modifiers are not pressed anymore. I hope it is not a big problem to pass the modifiers. I think it would be more convinient for a user. What do you think? I don't know, I think this is overkill. The typical user wants one of two things: either use the default as it is or turn off SelectOnRelease. The case that she releases Alt first and still holds down the tab key is irrelevant in my eyes. Wh do not have to care so much about redifining the key to trigger selection. A clear description of how to remove the binding should be enough. In any case, I can't easily think of a reliable method to check whether all keys are released or not. What about state toggling keys like num-lock? Bye Dominik ^_^ ^_^ -- 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: Problems with using SelectOnRelease
I know; this certainly adds to the confusion. Maybe the only way to reduce the possibility of misunderstandings is to write a better text in the man page. I do this. But after understanding the whole WindowList stuff and fixing the Source Code if needed. Many Options if WindowList are not mentioned in the manpage at all. I am making a list of them at the moment. -- 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: Problems with using SelectOnRelease
Dominik Vogt spake unto us the following wisdom: only one modifier like Meta_L works, not any Alt (there are two). Um, your keyboard has two Alt keys? I have never seen such a keyboard. Virtually all US keyboards have two alt keys which produce Alt_L and Alt_R, and no meta key at all... Typically the X clients are configured to recognize Alt_L as Meta_L. Ethan -- Happiness is a belt-fed weapon. pgp3SElUbJpH6.pgp Description: PGP signature
Re: Problems with using SelectOnRelease
On Fri, Feb 28, 2003 at 12:00:18PM -0500, Ethan Blanton wrote: Dominik Vogt spake unto us the following wisdom: only one modifier like Meta_L works, not any Alt (there are two). Um, your keyboard has two Alt keys? I have never seen such a keyboard. Virtually all US keyboards have two alt keys which produce Alt_L and Alt_R, and no meta key at all... Typically the X clients are configured to recognize Alt_L as Meta_L. Um, I have seen many US keyboard, but none had a second Alt key. Do you by any chance mean the Alt Gr key? That one is usually used to compose characters, not like the normal Alt key. Bye Dominik ^_^ ^_^ -- 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: Problems with using SelectOnRelease
Dominik Vogt spake unto us the following wisdom: On Fri, Feb 28, 2003 at 12:00:18PM -0500, Ethan Blanton wrote: Dominik Vogt spake unto us the following wisdom: Virtually all US keyboards have two alt keys which produce Alt_L and Alt_R, and no meta key at all... Typically the X clients are configured to recognize Alt_L as Meta_L. Um, I have seen many US keyboard, but none had a second Alt key. Do you by any chance mean the Alt Gr key? That one is usually used to compose characters, not like the normal Alt key. No, we don't have Alt Gr keys. If I went to CompUSA right now and looked at every keyboard they have, they would virtually all have: 2 Ctrl keys 2 Windows keys 2 Alt keys 1 Menu key ... and that's pretty much it for modifiers. For some reason our US keyboards are modifier-starved. If I wanted an Alt+Gr or Meta key (one that produced those keysyms, finding a keyboard where the keytop says that is nearly impossible) I would have to either choose a non-US keyboard layout or break out xmodmap/xkb/et al. Ethan -- Happiness is a belt-fed weapon. pgp3CZjeSCdbB.pgp Description: PGP signature
Re: Problems with using SelectOnRelease
Ethan Blanton [EMAIL PROTECTED] writes: Dominik Vogt spake unto us the following wisdom: On Fri, Feb 28, 2003 at 12:00:18PM -0500, Ethan Blanton wrote: Dominik Vogt spake unto us the following wisdom: Virtually all US keyboards have two alt keys which produce Alt_L and Alt_R, and no meta key at all... Typically the X clients are configured to recognize Alt_L as Meta_L. Um, I have seen many US keyboard, but none had a second Alt key. Do you by any chance mean the Alt Gr key? That one is usually used to compose characters, not like the normal Alt key. No, we don't have Alt Gr keys. If I went to CompUSA right now and looked at every keyboard they have, they would virtually all have: 2 Ctrl keys 2 Windows keys 2 Alt keys 1 Menu key =2E.. and that's pretty much it for modifiers. For some reason our US keyboards are modifier-starved. If I wanted an Alt+Gr or Meta key (one that produced those keysyms, finding a keyboard where the keytop says that is nearly impossible) I would have to either choose a non-US keyboard layout or break out xmodmap/xkb/et al. http://mywebpages.comcast.net/despen/junk/keyboard1.jpg http://mywebpages.comcast.net/despen/junk/keyboard2.jpg -- Dan Espen E-mail: [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]
