CVS domivogt: * Man page corrections.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/02/28 03:14:54 Modified files: . : ChangeLog fvwm : borders.c modules/FvwmPager: FvwmPager.1 Log message: * Man page corrections. -- 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]
CVS domivogt: * More man page corrections.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/02/28 03:15:55 Modified files: modules: ChangeLog modules/FvwmPager: FvwmPager.1 Log message: * More man page corrections. -- 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]
CVS domivogt: * Another man page correction.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/02/28 03:16:07 Modified files: modules/FvwmPager: Tag: branch-2_4 FvwmPager.1 Log message: * Another man page correction. -- 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]
CVS domivogt: * Updated for 2.5.6.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/02/28 04:10:38 Modified files: . : ChangeLog NEWS configure.in docs : ANNOUNCE ChangeLog DEVELOPERS Log message: * Updated for 2.5.6. -- 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]
CVS domivogt: * Fixed make distcheck
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/02/28 04:20:09 Modified files: tests : ChangeLog Makefile.am Log message: * Fixed make distcheck -- 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]
CVS domivogt: * Set version to 2.5.7.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/02/28 04:23:12 Modified files: . : ChangeLog NEWS configure.in Log message: * Set version to 2.5.7. -- 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]
fvwm-2.5.6 has been released and uploaded
ANNOUNCE is in the tarball, as usual. 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]
CVS domivogt fvwm-web: * Updated for 2.5.6 release.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: domivogt03/02/28 04:25:25 Modified files: . : ChangeLog download.html index.html generated : AUTHORS.html FAQ.html NEWS.html Log message: * Updated for 2.5.6 release. -- 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: FVWM: Java Swing window positioning
On Thu, Feb 27, 2003 at 12:06:42PM -0500, Tessa Lau wrote: On Thursday, Olivier Chapuis mumbled: It seems that Dan and me do not have this problem (without the FixedPPosition style). Can you send me a minimal java program which has this problem. Certainly. *Every* Java Swing program I run is displayed off the upper-left corner of the screen, but I'll attach a minimal program for you to play with. (javac Misbehave.java; java Misbehave) I suspect it's a windowmanager/JDK interaction. I'm running FVWM 2.5.5. I've tried running this program with four different JDKs, and the bug is only triggered by 1.4.1: IBMs Java 1.3.1 works correctly Blackdown Java 1.3.1-02b-FCS works correctly Blackdown Java 1.4.1-betaBUG Blackdown Java 1.4.1-01 BUG And SUN JDK 1.3.1_04 works correctly (here) Sun JDK 1.4.1-01 works correctly (Dan) Bob jdkBUG (Bob want jdk do you use?). I say works correctly because I do not understand why when you do not set any location java assumes that the location is (0,0). I imagine this is intentional. Hope that helps you to track down the problem. Can you send a bug report to Blackdown? Do you try with others window managers? If I well understand this depends on how the application think the wm will interpret a move-resize config request. Maybe, we should add a style to handle such situations (I do not think that FixedPPosition is really appropriate). Dominik, what do you think? Regards, 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: 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: FVWM: Java Swing window positioning
On Fri, Feb 28, 2003 at 04:27:15PM +0100, Olivier Chapuis wrote: On Thu, Feb 27, 2003 at 12:06:42PM -0500, Tessa Lau wrote: On Thursday, Olivier Chapuis mumbled: It seems that Dan and me do not have this problem (without the FixedPPosition style). Can you send me a minimal java program which has this problem. Certainly. *Every* Java Swing program I run is displayed off the upper-left corner of the screen, but I'll attach a minimal program for you to play with. (javac Misbehave.java; java Misbehave) I suspect it's a windowmanager/JDK interaction. I'm running FVWM 2.5.5. I've tried running this program with four different JDKs, and the bug is only triggered by 1.4.1: IBMs Java 1.3.1 works correctly Blackdown Java 1.3.1-02b-FCS works correctly Blackdown Java 1.4.1-betaBUG Blackdown Java 1.4.1-01 BUG And SUN JDK 1.3.1_04 works correctly (here) Sun JDK 1.4.1-01 works correctly (Dan) Bob jdkBUG (Bob want jdk do you use?). I say works correctly because I do not understand why when you do not set any location java assumes that the location is (0,0). I imagine this is intentional. Hope that helps you to track down the problem. Can you send a bug report to Blackdown? Do you try with others window managers? If I well understand this depends on how the application think the wm will interpret a move-resize config request. Maybe, we should add a style to handle such situations (I do not think that FixedPPosition is really appropriate). Dominik, what do you think? I tried several times to discuss that topic on the wm-spec list, but all that ever comes out of this is that people do not care and say but the ICCCM is clear about this. They seem to completely ignore that the problem has been there for a long time and can only be fixed with a clear spec. 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: FVWM: Java Swing window positioning
FWIW, Sawfish 1.2-gtk2 with Blackdown 1.4.1-01 positions the window such that the upper-left corner of the window decorations is at position 0,0. FVWM 2.5.5 with Blackdown 1.4.1-01 positions the window such that the upper-left corner of the window contents is at position 0,0 --- the window decorations are offscreen. When I say works correctly in the table below, I meant that the window appears to be positioned by FVWM rather than being placed at an absolute location. Today, IBM Java 1.3.1 also appears to exhibit the bug ... weird. --Tessa IBMs Java 1.3.1 works correctly Blackdown Java 1.3.1-02b-FCS works correctly Blackdown Java 1.4.1-betaBUG Blackdown Java 1.4.1-01 BUG SUN JDK 1.3.1_04 works correctly (here) Sun JDK 1.4.1-01 works correctly (Dan) Bob jdkBUG (Bob want jdk do you use?). -- 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]
NEWS in unstable branch
I think we have too many messages in the NEWS for the unstable branch right now. In the past, I made entries for * New features and other important user visible changes but not for * Bug fixes * Minor user visible changes * Changes in the documentation Especially, when a feature was introduced in the unstable branch and removed before the stable release, I remove any hints of that feature from the NEWS. If it is renamed before a stable release, I replace its former name in the NEWS with the new name and do not add a renamed foo to bar message in the NEWS. What do you think about that? 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: FVWM: Java Swing window positioning
On Fri, Feb 28, 2003 at 05:30:59PM +0100, Dominik Vogt wrote: On Fri, Feb 28, 2003 at 04:27:15PM +0100, Olivier Chapuis wrote: On Thu, Feb 27, 2003 at 12:06:42PM -0500, Tessa Lau wrote: On Thursday, Olivier Chapuis mumbled: It seems that Dan and me do not have this problem (without the FixedPPosition style). Can you send me a minimal java program which has this problem. Certainly. *Every* Java Swing program I run is displayed off the upper-left corner of the screen, but I'll attach a minimal program for you to play with. (javac Misbehave.java; java Misbehave) I suspect it's a windowmanager/JDK interaction. I'm running FVWM 2.5.5. I've tried running this program with four different JDKs, and the bug is only triggered by 1.4.1: IBMs Java 1.3.1 works correctly Blackdown Java 1.3.1-02b-FCS works correctly Blackdown Java 1.4.1-betaBUG Blackdown Java 1.4.1-01 BUG And SUN JDK 1.3.1_04 works correctly (here) Sun JDK 1.4.1-01 works correctly (Dan) Bob jdkBUG (Bob want jdk do you use?). I say works correctly because I do not understand why when you do not set any location java assumes that the location is (0,0). I imagine this is intentional. Hope that helps you to track down the problem. Can you send a bug report to Blackdown? Do you try with others window managers? If I well understand this depends on how the application think the wm will interpret a move-resize config request. Maybe, we should add a style to handle such situations (I do not think that FixedPPosition is really appropriate). Dominik, what do you think? I tried several times to discuss that topic on the wm-spec list, but all that ever comes out of this is that people do not care and say but the ICCCM is clear about this. They seem to completely ignore that the problem has been there for a long time and can only be fixed with a clear spec. Yes. Today I reread the threads on this subject on the wm-spec list. I am totally agree with you. The problem is that a lot of applications use now the ICCCM way for move-resize after mapping: some jdk (but the pb is more complex here), gtk and tk (and we got a lot of bug report on tk related to this pb). I do not know for qt/kde. On the other hand, I am afraid that nothing will be done on this in the EWMH spec (basically because havoc/metacity does not care about legacy app which use the gravity). So, I really think that we need a style ICCCMMoveResize / !ICCCMMoveResize The default is not really the pb I think. In any case we will have some bug reports on this. With such a style we will have a good answer. About implementation, I think I will need a lot of time and as you know perfectly the pb you can do it in a few minutes ... Moreover, feature freeze is not a pb here as this style will close some important bugs. Olivier PS: I've also read your mail on SUN Bug Parade (bug nbr. 4401846) I like it a lot. Tessa, if you want a clear explanation on the pb take a look at it (java SUN site - bug parade - register - search 4401846) -- 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: NEWS in unstable branch
Dominik Vogt fvwm-workers@fvwm.org writes: I think we have too many messages in the NEWS for the unstable branch right now. In the past, I made entries for * New features and other important user visible changes but not for * Bug fixes * Minor user visible changes * Changes in the documentation Especially, when a feature was introduced in the unstable branch and removed before the stable release, I remove any hints of that feature from the NEWS. If it is renamed before a stable release, I replace its former name in the NEWS with the new name and do not add a renamed foo to bar message in the NEWS. What do you think about that? I seem to remember, clean up NEWS as part of the 2.0, 2.2, 2.4 process. (I agree.) -- 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]
CVS olicha: * Added a workaround for for application with broken max/min size hints
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 03/02/28 15:39:55 Modified files: . : ChangeLog libs : defaults.h fvwm : events.c add_window.c Log message: * Added a workaround for for application with broken max/min size hints vs a size configure request * Check that the max size hint is not broken relatively to the the base size hint -- 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: NEWS in unstable branch
On Fri, Feb 28, 2003 at 11:08:58AM +0100, Dominik Vogt wrote: I think we have too many messages in the NEWS for the unstable branch right now. In the past, I made entries for * New features and other important user visible changes but not for * Bug fixes * Minor user visible changes * Changes in the documentation Especially, when a feature was introduced in the unstable branch and removed before the stable release, I remove any hints of that feature from the NEWS. If it is renamed before a stable release, I replace its former name in the NEWS with the new name and do not add a renamed foo to bar message in the NEWS. What do you think about that? I prefer a too long NEWS file than a too short one. Numerous package has an obsolete NEWS file This is very frustrating when you upgrade or have to decide if you want to upgrade. The NEWS file is very useful. Anyway, as our NEWS file is well maintained I think that some cuts can be done if these cuts do not suppress information for the user (important or not). Not that it seems that a lot of users use 2.5.x as its regular window manager. 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]
CVS dane fvwm-web: * screenshots/index.html: Added screenshot from Taviso.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: dane03/02/28 19:36:04 Modified files: . : ChangeLog screenshots: Ploum-desk-1152x864.html index.html Added files: screenshots: Taviso-desk-1024x768.html Taviso-desk-1024x768.png Taviso-desk-thumbnail.jpg Log message: * screenshots/index.html: Added screenshot from Taviso. -- 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]
