Re: FVWM: Still slight cosmetic problem with HGradient menus
> Date: Fri, 6 Sep 2002 12:11:17 + > From: Mikhael Goikhman <[EMAIL PROTECTED]> ... > > Perhaps, ultimately, the window buttons could be given a ButtonStyle option > > so > > the user can decide which is most appropriate? Or is there already some way > > to > > control this? > > Just always bind a complex function, then you have a lot of options. > "I" to execute a command on press, "C" or "D" - on release (but there > are some issues), "M" and "H" change the "feel" as well. Try to omit > or add "C", "M", "H" to get different combinations of "feel". The minute after I sent the last message it occurred to me I should try out different function action triggers. I had, of course, just used "I" without any thought. Doh! Still it's nice to have your bit of general advice aired and you have stated it so succintly. Thank you. I think "C" looks like the best default for a complex which is bound to a button. > > Regards, > Mikhael. Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On 06 Sep 2002 12:56:39 +0100, John Latham wrote: > > This has also made me realise something, perhaps worth suggesting. It appears > that the window buttons are activated either on press or release, depending on > what they are bound to. It seems they are activated on release if they are > bound to a builtin, and on press if they are bound to a Menu or Function. I > can see why some would argue it is good for them to activate on press if they > are bound to a menu. But I'm not sure this behaviour is the right one for a > function. > > Generally I would say that activation on release should be the default for all > buttons, in any GUI, so that if the user has pressed the wrong button, s/he > can move the mouse away before releasing, to avoid the activation. Any > exception to this should be for convenience and only for something which is > safe, e.g. a Menu that has no default operation. > > I have just changed my maximize buttons so that they invoke a function to do > an animated maximize, using FvwmAnimate instead of a simple Maximize X Y. Now > they activate on press instead of release! > > Perhaps, ultimately, the window buttons could be given a ButtonStyle option so > the user can decide which is most appropriate? Or is there already some way to > control this? Just always bind a complex function, then you have a lot of options. "I" to execute a command on press, "C" or "D" - on release (but there are some issues), "M" and "H" change the "feel" as well. Try to omit or add "C", "M", "H" to get different combinations of "feel". Regards, Mikhael. -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
> Date: Thu, 5 Sep 2002 23:20:14 +0200 > From: Dominik Vogt <[EMAIL PROTECTED]> > > On Thu, Sep 05, 2002 at 06:31:34PM +, Mikhael Goikhman wrote: > > > 2)I was able to get a maximize button to become `stuck', in the > > > sense > > This problem is not known. I don't quite understand what "every thing I > > clicked would be toggle maximised" means. Please post all ButtonStyle and > > other related lines. > > It's known to me and also caused by the event handling rewrite. > If you are curious, press the maximize/shade/whatever button on a > window, move the pointer out of the button and release it. > Regardless of where you click now the action on the window button > is triggered. Yes I discovered this more general behaviour last night when I tried again. Sorry about the PerlTk application Red Herring. (Actually I'm pleased it wasn't being caused by that.) This has also made me realise something, perhaps worth suggesting. It appears that the window buttons are activated either on press or release, depending on what they are bound to. It seems they are activated on release if they are bound to a builtin, and on press if they are bound to a Menu or Function. I can see why some would argue it is good for them to activate on press if they are bound to a menu. But I'm not sure this behaviour is the right one for a function. Generally I would say that activation on release should be the default for all buttons, in any GUI, so that if the user has pressed the wrong button, s/he can move the mouse away before releasing, to avoid the activation. Any exception to this should be for convenience and only for something which is safe, e.g. a Menu that has no default operation. I have just changed my maximize buttons so that they invoke a function to do an animated maximize, using FvwmAnimate instead of a simple Maximize X Y. Now they activate on press instead of release! Perhaps, ultimately, the window buttons could be given a ButtonStyle option so the user can decide which is most appropriate? Or is there already some way to control this? > > Bye > > Dominik ^_^ ^_^ Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On 05 Sep 2002 23:20:14 +0200, Dominik Vogt wrote: > > On Thu, Sep 05, 2002 at 06:31:34PM +, Mikhael Goikhman wrote: > > > 2) I was able to get a maximize button to become `stuck', in the sense > > > that every thing I clicked would be toggle maximised -- not even just > > > the window that the button belonged to! Clicking on the root window > > > would make it look like everything was normal, but as soon as the > > > mouse was even moved the original ``sticky button'' would display it's > > > ActiveDown mini-icon again. Even killing the program which the sticky > > > button window belonged to (via another console) did not resolve the > > > problem: the skeleton of it remained on the screen. Only killing X > > > could stop it. I was able to invoke this feature twice, but did not > > > spend a long time working out exactly what magic sequence was needed. > > > I think it involves the window being resized by itself, and/or moved > > > by itself prior to clicking the button. > > > > > > Would you like me to try to find a more definitive sequence of events, > > > or is somebody already onto this bug? > > > > This problem is not known. I don't quite understand what "every thing I > > clicked would be toggle maximised" means. Please post all ButtonStyle and > > other related lines. > > It's known to me and also caused by the event handling rewrite. > If you are curious, press the maximize/shade/whatever button on a > window, move the pointer out of the button and release it. > Regardless of where you click now the action on the window button > is triggered. Ok, I wondered whether this may be caused by my InactiveUp/InactiveDown enhancement. If a complex functions is bound (like in my case), nothing bad happens, but, yes, if some command is bound a very bad thing happens. A possible workaround for this may be to bind ComplexMaximize instead of Maximize: AddToFunc ComplexMaximize + C Maximize #+ H Nop # this cancels Maximize after some timeout Regards, Mikhael. -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On Thu, Sep 05, 2002 at 06:31:34PM +, Mikhael Goikhman wrote: > > 2) I was able to get a maximize button to become `stuck', in the sense > > that every thing I clicked would be toggle maximised -- not even just > > the window that the button belonged to! Clicking on the root window > > would make it look like everything was normal, but as soon as the > > mouse was even moved the original ``sticky button'' would display it's > > ActiveDown mini-icon again. Even killing the program which the sticky > > button window belonged to (via another console) did not resolve the > > problem: the skeleton of it remained on the screen. Only killing X > > could stop it. I was able to invoke this feature twice, but did not > > spend a long time working out exactly what magic sequence was needed. > > I think it involves the window being resized by itself, and/or moved > > by itself prior to clicking the button. > > > > Would you like me to try to find a more definitive sequence of events, > > or is somebody already onto this bug? > > This problem is not known. I don't quite understand what "every thing I > clicked would be toggle maximised" means. Please post all ButtonStyle and > other related lines. It's known to me and also caused by the event handling rewrite. If you are curious, press the maximize/shade/whatever button on a window, move the pointer out of the button and release it. Regardless of where you click now the action on the window button is triggered. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
> Date: Thu, 5 Sep 2002 20:07:22 +0100 > From: John Latham <[EMAIL PROTECTED]> > ... > I suspect that one of the steps needed to > invoke the feature is to ask this application to move itself: I have bound the > right mouse button to act as a `grab and move' function for this application > (because it has lots of little windows). > ... I did not make it clear, sorry: the binding I speak of is a PerlTk binding, not an FVWM binding. So as far as FVWM is concerned, I presume, the PerlTk application is asking to be moved, quite a lot of move requests in fact, as I drag the mouse. (I hope this is Red Herring.) Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
> Date: Thu, 5 Sep 2002 18:31:34 + > From: Mikhael Goikhman <[EMAIL PROTECTED]> > On 05 Sep 2002 18:55:26 +0100, John Latham wrote: > > > > Possible bad news -- maybe you are aware of these, but just in case: > > > > 1) Menus do not stay up like they used to. With > > > > Mouse 1 R A Menu StartMenu Nop > > > > a single click on the root window used to make the menu stay up. Now, > > it appears and disappears as soon as you let go of the mouse. > > > > And > > > > AddToMenu XXX > > + "blah blah" PopUp SubMenuYYY > > > > used to make SubMenuYYY stay up if you clicked on the item in XXX. > > (This was with PopupAsRootMenu style.) > > If you use the cvs or daily snapshots regularly you should subscribe to > the fvwm-workers list to be up to date with what happens. > > You would see that this problem was reported and answered, but not fixed. > > You would also see the Dominik's request not to use the today's cvs > because it will crash. Ooops, sorry. I don't regularly use the snapshots, though I might start doing at some point, so I might be of more help to you. Dominic asked me to try his latest menu patch to check if the cosmetic problem was gone, and I figured the snapshot was the easiest way to get it. > > > 2) I was able to get a maximize button to become `stuck', in the sense > > that every thing I clicked would be toggle maximised -- not even just > > the window that the button belonged to! Clicking on the root window > > would make it look like everything was normal, but as soon as the > > mouse was even moved the original ``sticky button'' would display it's > > ActiveDown mini-icon again. Even killing the program which the sticky > > button window belonged to (via another console) did not resolve the > > problem: the skeleton of it remained on the screen. Only killing X > > could stop it. I was able to invoke this feature twice, but did not > > spend a long time working out exactly what magic sequence was needed. > > I think it involves the window being resized by itself, and/or moved > > by itself prior to clicking the button. > > > > Would you like me to try to find a more definitive sequence of events, > > or is somebody already onto this bug? > > This problem is not known. I don't quite understand what "every thing I > clicked would be toggle maximised" means. Please post all ButtonStyle and > other related lines. Imagine a new feature (which might even be useful!) called ``PointerIsAMagicWand'' which when set would be given a function and would then apply that function to every window you clicked on. (I don't know how you could turn it off!) Anyway, the behaviour I was getting was as though I had asked for PointerIsAMagicWand Maximise 100 97 The button I originally pressed was bound to Maximise 100 97. I mean, every window I left-clicked on was maximized / de-maximized and nothing could stop it. This included pager, buttons, task bar, etc.. Also, the mini-icon decoration for the ActiveDown of the button I had originally pressed was showing all the time. Left clicking on the root window did nothing except make the ActiveDown mini-icon be replaced by the normal one. But when the mouse was moved, even slightly, the ActiveDown mini-icon reappeared. I attach the ButtonStyles and Mouse bindings which I think were in use at the time. I'll try to make it happen again, to search for a minimal sequence of steps from start up to invoke it. Both times it happened it was with the same particular PerlTk application. I suspect that one of the steps needed to invoke the feature is to ask this application to move itself: I have bound the right mouse button to act as a `grab and move' function for this application (because it has lots of little windows). Both times I had done that shortly before pressing the maximise button. > > Regards, > Mikhael. > Best wishes, John Latham == Here are the ButtonStyle, Mouse and Syle NoButton settings. These are generated from M4 defines which explains some of the strangeness in them. (E.g. ButtonStyles for buttons which are not used). ButtonStyle 1 ActiveUpPixmap /home/jtl/XFILES/DEVEL/etc/X11/AnotherLevel/BUTTONS/White/menu.xpm -- UseTitleStyle Sunk ButtonStyle 1 ActiveDown Pixmap /usr/share/icons/mini/mini-ray.xpm -- UseTitleStyle Sunk ButtonStyle 1 InactiveSimple -- UseTitleStyle Sunk ButtonStyle 2 ActiveUpPixmap /home/jtl/XFILES/DEVEL/etc/X11/AnotherLevel/BUTTONS/White/close.xpm -- UseTitleStyle Sunk ButtonStyle 2 ActiveDown Pixmap /usr/share/icons/mini/mini-ray.xpm -- UseTitleStyle Sunk ButtonStyle 2 InactiveSimple -- UseTitleStyle Sunk ButtonStyle 3 ActiveUpPixmap /home/jtl/XFILES/DEVEL/etc/X11/AnotherLevel/BUTTONS/White/stick.xpm -- UseTitleStyle Sunk ButtonStyle 3 ActiveDown Pi
Re: FVWM: Still slight cosmetic problem with HGradient menus
On 05 Sep 2002 18:55:26 +0100, John Latham wrote: > > Possible bad news -- maybe you are aware of these, but just in case: > > 1)Menus do not stay up like they used to. With > > Mouse 1 R A Menu StartMenu Nop > > a single click on the root window used to make the menu stay up. Now, > it appears and disappears as soon as you let go of the mouse. > > And > > AddToMenu XXX > + "blah blah" PopUp SubMenuYYY > > used to make SubMenuYYY stay up if you clicked on the item in XXX. > (This was with PopupAsRootMenu style.) If you use the cvs or daily snapshots regularly you should subscribe to the fvwm-workers list to be up to date with what happens. You would see that this problem was reported and answered, but not fixed. You would also see the Dominik's request not to use the today's cvs because it will crash. > 2)I was able to get a maximize button to become `stuck', in the sense > that every thing I clicked would be toggle maximised -- not even just > the window that the button belonged to! Clicking on the root window > would make it look like everything was normal, but as soon as the > mouse was even moved the original ``sticky button'' would display it's > ActiveDown mini-icon again. Even killing the program which the sticky > button window belonged to (via another console) did not resolve the > problem: the skeleton of it remained on the screen. Only killing X > could stop it. I was able to invoke this feature twice, but did not > spend a long time working out exactly what magic sequence was needed. > I think it involves the window being resized by itself, and/or moved > by itself prior to clicking the button. > > Would you like me to try to find a more definitive sequence of events, > or is somebody already onto this bug? This problem is not known. I don't quite understand what "every thing I clicked would be toggle maximised" means. Please post all ButtonStyle and other related lines. Regards, Mikhael. -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
> Date: Tue, 3 Sep 2002 11:58:18 +0200 > From: Dominik Vogt > On Thu, Aug 29, 2002 at 07:55:51PM +0100, John Latham wrote: > > This is probably one for Dominic... > > > > You may recall a few weeks ago you fixed a bug in the menus when they have a > > HGradient -- certain menu items left `up' after scanning over them? It works > > much better now in 2.5.3, thanks very much, but I have noticed one little > > imperfection that I didn't notice before. Say you put the pointer on a menu > > item which causes a sub-menu to pop up. Then move the pointer up one place. > > The sub-menu is cleared away, however, it also wipes off the bottom edge of > > the 3D `up' relief of the item at the new pointer position (i.e. what was > > the > > top of the 3D relief of the previous position). This `absent bottom' feature > > is disabled if there is a NOP between the two items. > > Could you try with my latest patch? I couldn't reproduce this > myself (probably because of SaveUnders or something). > > Bye > > Dominik ^_^ ^_^ I tried yesterday's snapshot this morning. Good news: I think the cosmetic menu problem has gone, thanks. Possible bad news -- maybe you are aware of these, but just in case: 1) Menus do not stay up like they used to. With Mouse 1 R A Menu StartMenu Nop a single click on the root window used to make the menu stay up. Now, it appears and disappears as soon as you let go of the mouse. And AddToMenu XXX + "blah blah" PopUp SubMenuYYY used to make SubMenuYYY stay up if you clicked on the item in XXX. (This was with PopupAsRootMenu style.) 2) I was able to get a maximize button to become `stuck', in the sense that every thing I clicked would be toggle maximised -- not even just the window that the button belonged to! Clicking on the root window would make it look like everything was normal, but as soon as the mouse was even moved the original ``sticky button'' would display it's ActiveDown mini-icon again. Even killing the program which the sticky button window belonged to (via another console) did not resolve the problem: the skeleton of it remained on the screen. Only killing X could stop it. I was able to invoke this feature twice, but did not spend a long time working out exactly what magic sequence was needed. I think it involves the window being resized by itself, and/or moved by itself prior to clicking the button. Would you like me to try to find a more definitive sequence of events, or is somebody already onto this bug? Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Still slight cosmetic problem with HGradient menus
On Thu, Aug 29, 2002 at 07:55:51PM +0100, John Latham wrote: > This is probably one for Dominic... > > You may recall a few weeks ago you fixed a bug in the menus when they have a > HGradient -- certain menu items left `up' after scanning over them? It works > much better now in 2.5.3, thanks very much, but I have noticed one little > imperfection that I didn't notice before. Say you put the pointer on a menu > item which causes a sub-menu to pop up. Then move the pointer up one place. > The sub-menu is cleared away, however, it also wipes off the bottom edge of > the 3D `up' relief of the item at the new pointer position (i.e. what was the > top of the 3D relief of the previous position). This `absent bottom' feature > is disabled if there is a NOP between the two items. Could you try with my latest patch? I couldn't reproduce this myself (probably because of SaveUnders or something). Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Still slight cosmetic problem with HGradient menus
This is probably one for Dominic... You may recall a few weeks ago you fixed a bug in the menus when they have a HGradient -- certain menu items left `up' after scanning over them? It works much better now in 2.5.3, thanks very much, but I have noticed one little imperfection that I didn't notice before. Say you put the pointer on a menu item which causes a sub-menu to pop up. Then move the pointer up one place. The sub-menu is cleared away, however, it also wipes off the bottom edge of the 3D `up' relief of the item at the new pointer position (i.e. what was the top of the 3D relief of the previous position). This `absent bottom' feature is disabled if there is a NOP between the two items. Here is a bit of ascii art in case my description is not clear. -> marks pointer position I* are menu items -- [..] is 3d 1up' effect -- Before: I1 I2 -- -> [I3] -> Sub-menu -- I4 Then move the pointer up one place. After: I1 -- -> [I2] I3 I4 MenuStyle settings: MenuStyle * mwm MenuStyle * Font *helvetica*medium-r*12* MenuStyle * Greyed grey35 MenuStyle * Foreground #FF MenuStyle * MenuFace HGradient 128 2 #D2E1F5 30 #2D61F5 70 #D2E1F5 MenuStyle * PopupAsRootMenu Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
