Re: tear off menus
Dominik Vogt writes: > On Wed, Oct 15, 2003 at 09:12:09PM -0400, Dan Espen wrote: > > > > Anyone have any ideas about a syntax for disabling button 2 doing > > a menu tear off? > > > > It doesn't look like we have any comands for controlling button > > or key action on menus. > > > > It looks like context M (menu) could be used: > > > > Mouse 2 M N TearOff > > Mouse 2 M N - > > > > Key BackSpace M N TearOff > > Key BackSpace M N - > > > > But that would create a pretty substantial change in the menu code. > > Yes - as the menu code is unable to handle normal bindings. I > once made an attempt to make the menu code able to run > concurrently to the normal event loop. In the end I concluded > that it's better to dump fvwm and write something new. Is something like this too brutal for your tastes: menu.patch Description: Binary data -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: tear off menus
On Wed, Oct 15, 2003 at 09:12:09PM -0400, Dan Espen wrote: > > Anyone have any ideas about a syntax for disabling button 2 doing > a menu tear off? > > It doesn't look like we have any comands for controlling button > or key action on menus. > > It looks like context M (menu) could be used: > > Mouse 2 M N TearOff > Mouse 2 M N - > > Key BackSpace M N TearOff > Key BackSpace M N - > > But that would create a pretty substantial change in the menu code. Yes - as the menu code is unable to handle normal bindings. I once made an attempt to make the menu code able to run concurrently to the normal event loop. In the end I concluded that it's better to dump fvwm and write something new. Ciao Dominik ^_^ ^_^ -- Visit the official FVWM web page at 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]
tear off menus
Anyone have any ideas about a syntax for disabling button 2 doing a menu tear off? It doesn't look like we have any comands for controlling button or key action on menus. It looks like context M (menu) could be used: Mouse 2 M N TearOff Mouse 2 M N - Key BackSpace M N TearOff Key BackSpace M N - But that would create a pretty substantial change in the menu code. -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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: CVS domivogt: * Documented tear off menus. Could someone plaese prof raed the man page (I
On Tue, Jul 08, 2003 at 09:45:37PM +, Mikhael Goikhman wrote: > On 08 Jul 2003 15:04:20 -0500, FVWM CVS wrote: > > > > Log message: Documented tear off menus. Could someone plaese prof raed > > * the man page (I rewrote the whole MENUS section). > > Seems very good to me. > > Minor things: > > * I would add a word "usually" when you say a menu should be bound using > Key/Mouse, because there are a lot of other ways to open a menu, like > a command from a module, Schedule, PipeRead or another menu item. > > * Typo "selcted". > > * The following sentence is not strictly correct, replace: > > Clicking anywhere or pressing any key unposts the menu and reverts back > to normal operation. > > with: > > To unpost the menu wither click any key or press the same submenu > again. All done. > * The second "Ctrl-B" should be replaced with "b", the second "Ctrl-F" > with "f". There were numerous other mistakes in that list. Bye Dominik ^_^ ^_^ -- Visit the official FVWM web page at 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: CVS domivogt: * Documented tear off menus. Could someone plaese prof raed the man page (I
On 08 Jul 2003 15:04:20 -0500, FVWM CVS wrote: > > Log message: Documented tear off menus. Could someone plaese prof raed > * the man page (I rewrote the whole MENUS section). Seems very good to me. Minor things: * I would add a word "usually" when you say a menu should be bound using Key/Mouse, because there are a lot of other ways to open a menu, like a command from a module, Schedule, PipeRead or another menu item. * Typo "selcted". * The following sentence is not strictly correct, replace: Clicking anywhere or pressing any key unposts the menu and reverts back to normal operation. with: To unpost the menu wither click any key or press the same submenu again. * The second "Ctrl-B" should be replaced with "b", the second "Ctrl-F" with "f". I may fix these if needed. Regards, Mikhael. -- Visit the official FVWM web page at 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: * Documented tear off menus. Could someone plaese prof raed the man page (I
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt03/07/08 15:04:20 Modified files: . : ChangeLog NEWS todo-2.6 fvwm : fvwm.1.in Log message: * Documented tear off menus. Could someone plaese prof raed the man page (I rewrote the whole MENUS section). -- Visit the official FVWM web page at 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 drbob fvwm-web: Removed "Developers' note" line about tear-off menus and the "Window Managers for X" site.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: drbob 03/04/24 14:54:42 Modified files: . : ChangeLog links.php Log message: Removed "Developers' note" line about tear-off menus and the "Window Managers for X" site. -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
in message <[EMAIL PROTECTED]>, wrote Dan Espen thusly... > > In Openwin, a tear off menu is torn off by clicking on a pushpin > which changes appearance to a pushed in pushpin when you click on it. > > In effect, the menu is pinned to the desktop. > To dismiss the menu, you click on the pushpin again. > I think its very intuitive. much like gtk (i use gimp) tear off menus ... which have dashed line at the top. -- -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
Dominik Vogt writes: > On Wed, Jun 19, 2002 at 09:34:17AM -0400, Dan Espen wrote: > > Making pushpins work would make the feature more accessible. > > Meaning what? In Openwin, a tear off menu is torn off by clicking on a pushpin which changes appearance to a pushed in pushpin when you click on it. In effect, the menu is pinned to the desktop. To dismiss the menu, you click on the pushpin again. I think its very intuitive. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
On Wed, Jun 19, 2002 at 09:34:17AM -0400, Dan Espen wrote: > Making pushpins work would make the feature more accessible. Meaning what? 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 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 needs to be done for tear-off menus?
On 19 Jun 2002 18:55:01 +0200, Olivier Chapuis wrote: > > I like the tear-off menus. I am agree with Mikhael that tear-off > menu should not forbid MenuStyle (and Colorset) commands. What about > copying the menu style which should be use to a new menu style name as > fvwm_menu_style_id_of_the_window (with CopyMenuStyle) and use this > style. A good solution. So it would be posible to get the same menu in 5 different menu styles on the screen simultaneously. :) > Also, I see two problems: > - if the menu is transparent (ParentRelative colorset) we should > set automatically the ParentalRelativity style. > - The font used by the tear-off menu title bar should be the font > of the menu. I am not sure about the last one. Theoretically, yes, but practically... Other problems. Tear off windows should probably supply no-iconify, no-maximize MwmDecor hints. Titlebar buttons make it hard to read a window title. You added Style fvwm_menu WindowListSkip, I added CirculateSkip. (Because NeverFocus windows should usually have CirculateSkip.) But is WindowListSkip needed here? I am not sure tear offs should not be listed in window lists. Of course, there are pro and contr arguments for both WindowListSkip and CirculateSkip. What other think? One more problem is that "Module" or "Exec" items start to work only after a pointer leaves an item (module starts, but either it opens a window or sends a command and module messages are not processed I guess). But probably there is nothing to do with this? Regards, Mikhael. -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
in message <[EMAIL PROTECTED]>, wrote fvwm-workers thusly... > > On Mon, Jun 17, 2002 at 02:30:53PM -0400, parv wrote: > > > > menu items always seem to be in "MouseFocus" mode even if > > "fvwm_menu" class was assigned "ClickToFocus" policy. well, the > > torn-off window does respect the "ClickToFocus" but menu items do > > not. (that's seem like your first point.) > > Tear-off menus don't care about their focus policy. They take the > focus on their own when the pointer enters and release it when the > poointer leaves. It's confusing and uncomfortable, but as long as > the menu code stays in the fvwm core there is little that can be > done about it. :-/ ... > > pressing "escape" on torn off menu's window title doesn't make it > > disappear, only on the actual menu (items). > > Should it? Closing tear-off menus should be more difficult that > closing normal menus so that you don't close them accidentally. > To deactivate the menu, simply move the mouse away. dominik, from your post i get the idea that you do agree w/ menu-focus policy is annoying & not much could be done currently. right? in that case, there is nothing new below. i agree that closing tear-off menu should be difficult, but then the behaviour should be consistent as mikhael pointed. to reiterate ... problem w/ just moving mouse away to deactivate them is that they "don't care about their focus policy" as you said. while a aterm window, for example, is active, so is the torn-off menu window (when mouse moves on the menu). but ... the torn-off menu (window) remains underneath the aterm window; menu window doesn't get raised over the aterm, at least not until the menu [window] as a whole gets raised in the normal fashion. this mixed tear-off menu focus policy is what is so irritating. anyway, i do like fvwm tear-off menu facility in development, and middle mouse button click on a menu title works like a . - parv -- -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
On Mon, Jun 17, 2002 at 01:36:42PM +0200, Dominik Vogt wrote: > I'm not quite happy with the tear-off menu code yet: > > - Torn off menus have a strange focus policy. > - There is no good way to handle tear off menus with the mouse. > - Placement and sizing of the menus is not perfect. > > What do others think about tear-off menus? What should be done? > How can we improve usability? Are there other issues I missed? > I like the tear-off menus. I am agree with Mikhael that tear-off menu should not forbid MenuStyle (and Colorset) commands. What about copying the menu style which should be use to a new menu style name as fvwm_menu_style_id_of_the_window (with CopyMenuStyle) and use this style. Also, I see two problems: - if the menu is transparent (ParentRelative colorset) we should set automatically the ParentalRelativity style. - The font used by the tear-off menu title bar should be the font of the menu. Olivier -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
Dominik Vogt writes: > On Wed, Jun 19, 2002 at 01:05:36PM +, Mikhael Goikhman wrote: > > On 19 Jun 2002 13:54:05 +0200, Dominik Vogt wrote: > > Hmm, really, "More..." does not work now in tear-off menus. > > Is it possible to get a decoration height into account when creating > > continuation menus as Dan previously suggested? > > No, because (a) the decoration height can not easily be calculated > from within the menu code and (b) the decorations may change at > any time. Just subtracting 3 times the font height will cover almost every case. Even ignoring the case when the menu doesn't have a "more..." but would with the subtraction still covers almost every case. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at 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 needs to be done for tear-off menus?
On Wed, Jun 19, 2002 at 01:05:36PM +, Mikhael Goikhman wrote:
> On 19 Jun 2002 13:54:05 +0200, Dominik Vogt wrote:
> >
> > On Mon, Jun 17, 2002 at 02:30:53PM -0400, parv wrote:
> > > in message <[EMAIL PROTECTED]>,
> > > wrote fvwm-workers thusly...
> > > >
> > > > I'm not quite happy with the tear-off menu code yet:
> > > >
> > > > - Torn off menus have a strange focus policy.
> > > > - There is no good way to handle tear off menus with the mouse.
> > > > - Placement and sizing of the menus is not perfect.
> > > >
> > > > What do others think about tear-off menus? What should be done?
> > > > How can we improve usability? Are there other issues I missed?
>
> First, tear menus are great.
>
> Of course they should be implemented as a module not to cause problems,
> but until then the current implementation solves most of the needs.
Module or not, as long as menus grab about every key on the
keyboard, they won't cooperate nicely with the rest of fvwm.
> My problems. I am not sure MenuStyle should not be allowed when a tear
> off menu is on the screen.
[snip]
> Is it possible to just automatically recapture all affected tear offs
> after MenuStyle is changed?
Hm, this would mean to unmap all affected tear off menus, tear
out from scratch but don't modify their position. Sure, that's
not easy but possible. And then, it would be nice to create
tear-off menus from scratch, without posting the menu normally
first.
> Another issue, I think the top menu title should be separated using
> ("" TearMenuOff), not ("" Nop) separator. Then mouse 2 binding on a title
> may be removed.
Can't remember what this is about right now. I'll look it up in
the code later.
> And finally. It would be nice to document tear offs and TearMenuOff.
Once we have found a nice solution. I don't want to spend a lot
of time documenting features that are thrown away again.
> > > pressing "escape" on torn off menu's window title doesn't make it
> > > disappear, only on the actual menu (items).
> >
> > Should it? Closing tear-off menus should be more difficult that
> > closing normal menus so that you don't close them accidentally.
> > To deactivate the menu, simply move the mouse away. What do
> > others think of this?
>
> I agree about making it harder to be close. I am not even sure that
> Escape on items should close a tear off, but it may,
This brings up a simplle question: What are the right keys to
- tear off a posted menu (currently Backspace)
- destroy a tear off menu (currently Escape)
> > Well, to sum it up, I can think of at least three features that
> > do not work well with tear-off menus:
> >
> > - menu animation
> > - continuation menus ("more...")
> > - sub menus
> >
> > I don't see a good solution for either of these, except
> > recommending not to use any of these features with tear-off menus.
>
> Hmm, really, "More..." does not work now in tear-off menus.
> Is it possible to get a decoration height into account when creating
> continuation menus as Dan previously suggested?
No, because (a) the decoration height can not easily be calculated
from within the menu code and (b) the decorations may change at
any time.
> As for menu animation and sub menus I don't see a problem.
It works, but it is confusing.
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 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 needs to be done for tear-off menus?
Dominik Vogt writes:
> Well, to sum it up, I can think of at least three features that
> do not work well with tear-off menus:
>
> - menu animation
> - continuation menus ("more...")
> - sub menus
I find tear-off menus useful for invoking my root images.
Since I have about 1000 images, lots of my image menus have "more..."
entries.
Making pushpins work would make the feature more accessible.
I think moving all the menu logic into a permanently loaded module
would reduce Fvwm's resident memory size.
With documentation, I think the feature is good enough
for release as it is.
--
Dan Espen E-mail: [EMAIL PROTECTED]
444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570
Piscataway, NJ 08854
--
Visit the official FVWM web page at 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 needs to be done for tear-off menus?
On 19 Jun 2002 13:54:05 +0200, Dominik Vogt wrote:
>
> On Mon, Jun 17, 2002 at 02:30:53PM -0400, parv wrote:
> > in message <[EMAIL PROTECTED]>,
> > wrote fvwm-workers thusly...
> > >
> > > I'm not quite happy with the tear-off menu code yet:
> > >
> > > - Torn off menus have a strange focus policy.
> > > - There is no good way to handle tear off menus with the mouse.
> > > - Placement and sizing of the menus is not perfect.
> > >
> > > What do others think about tear-off menus? What should be done?
> > > How can we improve usability? Are there other issues I missed?
First, tear menus are great.
Of course they should be implemented as a module not to cause problems,
but until then the current implementation solves most of the needs.
My problems. I am not sure MenuStyle should not be allowed when a tear
off menu is on the screen. This forces a user (or fvwm-themes) to close
all tear off menus first (that may be on different desks) and only then
switch menustyle. It would be nice if there was no such limit. When
there was a bug with a usage counter recently, MenuStyle was allowed
before a tear off menu is closed for the first time. It looked not very
perfect (font changed when you point to an item), but it was acceptable.
Is it possible to just automatically recapture all affected tear offs
after MenuStyle is changed?
Another issue, I think the top menu title should be separated using
("" TearMenuOff), not ("" Nop) separator. Then mouse 2 binding on a title
may be removed.
And finally. It would be nice to document tear offs and TearMenuOff.
> > other problem is when the torn off menu (window) is placed on two
> > pages, the menu doesn't behave like it does w/ "Animation" style
> > when there is no enough space to fit the whole menu (in non-torn
> > off mode). i would expect the menu to slide on focus such that it
> > is appears in its entirety on the current page. (that could be your
> > 3d point.)
>
> Ah, I see. Hadn't thought of that yet. Animated tear-off menus
> are really not a good idea.
I think animations in tear-offs work well. I don't think anything should
be changed. When a user placed a window between 2 pages, he wants it to be
there. But probably I just don't understand the problem, it works for me
as expected with or without animation.
> > pressing "escape" on torn off menu's window title doesn't make it
> > disappear, only on the actual menu (items).
>
> Should it? Closing tear-off menus should be more difficult that
> closing normal menus so that you don't close them accidentally.
> To deactivate the menu, simply move the mouse away. What do
> others think of this?
I agree about making it harder to be close. I am not even sure that
Escape on items should close a tear off, but it may,
> Well, to sum it up, I can think of at least three features that
> do not work well with tear-off menus:
>
> - menu animation
> - continuation menus ("more...")
> - sub menus
>
> I don't see a good solution for either of these, except
> recommending not to use any of these features with tear-off menus.
Hmm, really, "More..." does not work now in tear-off menus.
Is it possible to get a decoration height into account when creating
continuation menus as Dan previously suggested?
As for menu animation and sub menus I don't see a problem.
Regards,
Mikhael.
--
Visit the official FVWM web page at 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 needs to be done for tear-off menus?
On Mon, Jun 17, 2002 at 02:30:53PM -0400, parv wrote:
> in message <[EMAIL PROTECTED]>,
> wrote fvwm-workers thusly...
> >
> > I'm not quite happy with the tear-off menu code yet:
> >
> > - Torn off menus have a strange focus policy.
> > - There is no good way to handle tear off menus with the mouse.
> > - Placement and sizing of the menus is not perfect.
> >
> > What do others think about tear-off menus? What should be done?
> > How can we improve usability? Are there other issues I missed?
>
> based on v2.5.1 experience...
>
> menu items always seem to be in "MouseFocus" mode even if
> "fvwm_menu" class was assigned "ClickToFocus" policy. well, the
> torn-off window does respect the "ClickToFocus" but menu items do
> not. (that's seem like your first point.)
Tear-off menus don't care about their focus policy. They take the
focus on their own when the pointer enters and release it when the
poointer leaves. It's confusing and uncomfortable, but as long as
the menu code stays in the fvwm core there is little that can be
done about it. :-/
> other problem is when the torn off menu (window) is placed on two
> pages, the menu doesn't behave like it does w/ "Animation" style
> when there is no enough space to fit the whole menu (in non-torn
> off mode). i would expect the menu to slide on focus such that it
> is appears in its entirety on the current page. (that could be your
> 3d point.)
Ah, I see. Hadn't thought of that yet. Animated tear-off menus
are really not a good idea.
> pressing "escape" on torn off menu's window title doesn't make it
> disappear, only on the actual menu (items).
Should it? Closing tear-off menus should be more difficult that
closing normal menus so that you don't close them accidentally.
To deactivate the menu, simply move the mouse away. What do
others think of this?
Well, to sum it up, I can think of at least three features that
do not work well with tear-off menus:
- menu animation
- continuation menus ("more...")
- sub menus
I don't see a good solution for either of these, except
recommending not to use any of these features with tear-off menus.
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 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 needs to be done for tear-off menus?
in message <[EMAIL PROTECTED]>, wrote fvwm-workers thusly... > > I'm not quite happy with the tear-off menu code yet: > > - Torn off menus have a strange focus policy. > - There is no good way to handle tear off menus with the mouse. > - Placement and sizing of the menus is not perfect. > > What do others think about tear-off menus? What should be done? > How can we improve usability? Are there other issues I missed? based on v2.5.1 experience... menu items always seem to be in "MouseFocus" mode even if "fvwm_menu" class was assigned "ClickToFocus" policy. well, the torn-off window does respect the "ClickToFocus" but menu items do not. (that's seem like your first point.) other problem is when the torn off menu (window) is placed on two pages, the menu doesn't behave like it does w/ "Animation" style when there is no enough space to fit the whole menu (in non-torn off mode). i would expect the menu to slide on focus such that it is appears in its entirety on the current page. (that could be your 3d point.) pressing "escape" on torn off menu's window title doesn't make it disappear, only on the actual menu (items). - parv -- -- Visit the official FVWM web page at 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]
what needs to be done for tear-off menus?
I'm not quite happy with the tear-off menu code yet: - Torn off menus have a strange focus policy. - There is no good way to handle tear off menus with the mouse. - Placement and sizing of the menus is not perfect. What do others think about tear-off menus? What should be done? How can we improve usability? Are there other issues I missed? 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 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 "More..." entries in tear off menus.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/05/22 06:12:06 Modified files: . : ChangeLog fvwm : menucmd.c menuitem.c menuitem.h menus.c menus.h windowlist.c Log message: * Fixed "More..." entries in tear off menus. * Fixed MST_USAGE_COUNT w/ tear off menus. * Fixed core dump w/ MISSING_SUBMENU_FUNCTION and tear off menus. -- Visit the official FVWM web page at 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: Tear off menus stop module messages
fvwm-workers@fvwm.org wrote: Fixed. Thanks, that's much better. Cheers, Tim. -- Visit the official FVWM web page at 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: Tear off menus stop module messages
On Thu, Apr 25, 2002 at 12:24:25PM +0100, Tim Phipps wrote: > fvwm-workers@fvwm.org wrote: > > >On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: > > > >>If I'm on the right track, then I think the menu would have to release > >>the grab once the menu is torn off > >> > >Well, it does release the grabs. But as it is now, whenever the > >pointer enters a tear off menu, fvwm makes the grabs again. As > >long as fvwm is in the menu loop it doesn't really matter if the > >grabs are made or not - it can't handle module input anyway in > >that code. > > > I think there might be a bug in the grabbing and it may be the reason > I'm seeing it as a problem. I don't mind fvwm stopping module messages > when the pointer is on the torn-off menu but it seems to keep the grab > when the pointer moves off and it only releases it when the pointer > enters another window. > Normally the grab is released when the pointer leaves the torn off menu > but if you use the keyboard to go from the torn off menu to a sub-menu > and the use the keyboard to go back to the torn off menu and then move > the pointer off the torn off menu the grab remains. You can see the grab > is active because the cursor stays the same as on the menu. Fixed. The although the grab was released, the pointer was immediately regrabbed because the menu code did not remove EnterNotify events from the queue. These were processed later by the main loop although the window had long been left again. 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 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 leaving tear off menus.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/04/25 07:56:12 Modified files: . : ChangeLog fvwm : events.h menus.c Log message: * Fixed leaving tear off menus. -- Visit the official FVWM web page at 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: Tear off menus stop module messages
fvwm-workers@fvwm.org wrote: On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: If I'm on the right track, then I think the menu would have to release the grab once the menu is torn off Well, it does release the grabs. But as it is now, whenever the pointer enters a tear off menu, fvwm makes the grabs again. As long as fvwm is in the menu loop it doesn't really matter if the grabs are made or not - it can't handle module input anyway in that code. I think there might be a bug in the grabbing and it may be the reason I'm seeing it as a problem. I don't mind fvwm stopping module messages when the pointer is on the torn-off menu but it seems to keep the grab when the pointer moves off and it only releases it when the pointer enters another window. Normally the grab is released when the pointer leaves the torn off menu but if you use the keyboard to go from the torn off menu to a sub-menu and the use the keyboard to go back to the torn off menu and then move the pointer off the torn off menu the grab remains. You can see the grab is active because the cursor stays the same as on the menu. Cheers, Tim. -- Visit the official FVWM web page at 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: Tear off menus stop module messages
On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Mon, Apr 22, 2002 at 03:05:26PM -0400, Dan Espen wrote: > > > Dominik Vogt writes: > > > > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > > > > Why can't the menu code be in a module? > > > > > > > > Of course menus *can* be a module. It's just that the menu code > > > > was not written to run independently of fvwm and is thus > > > > interwoven tightly with fvwm's data structures. > > > > Well, and as long > > > > as menus grab the pointer and the keyboard, processing module > > > > messages is pointless since the function execution code needs (?) > > > > to grab the pointer too. > > > > > > I don't think I understand the point about the grab. > > > Its OK for menus to freeze FVWM so the grab should be OK. > > > > When any client grabs the pointer, fvwm basically stops processing > > most module messages too, at least if modules call complex > > functions. > > I know that, but don't see that as a problem. We want FVWM > to freeze when a menu is popped up. > > > > I think putting the menu code in a module might simplify tear > > > off menus. I'm not sure of all the details but it just seems > > > like it might. Perhaps another copy of the menu module could be > > > started to handle the torn off menu (without grabs once its torn > > > off). > > > > Fvwm menus need to grab the keyboard to work properly. Pure mouse > > operable menus would be useless to me. > > I'm sorry if I'm wasting your time. Nonsense. > Maybe I don't understand what > a tear off menu is. I thought it was like one of those Openwin > menus that you use a pushpin to make it stay visible. Exactly. They are sometimes called pin up menus. I expect that torn off menus behave as any other application window does. This is very difficult to do if the torn off menus are handled directly in the fvwm code. > If I'm on the right track, then I think the menu would have to release > the grab once the menu is torn off. Well, it does release the grabs. But as it is now, whenever the pointer enters a tear off menu, fvwm makes the grabs again. As long as fvwm is in the menu loop it doesn't really matter if the grabs are made or not - it can't handle module input anyway in that code. > What I thought would happen > is the menu code would send a description of the menu to another > module and the module would create a normal window that looked > like the menu except that FVWM could reparent it, and if desired > frame, title and do other good things to it. Yes, I agree. In theory this sounds all very good. It's only that the menu code is woven into the fvwm framework so tightly that it's very hard to separate it and put it into a module. I don't like the idea of duplicationg the complete menu code either. I'm open to any ideas how to do this. 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 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: Tear off menus stop module messages
Dominik Vogt writes: > On Mon, Apr 22, 2002 at 03:05:26PM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > > > Why can't the menu code be in a module? > > > > > > Of course menus *can* be a module. It's just that the menu code > > > was not written to run independently of fvwm and is thus > > > interwoven tightly with fvwm's data structures. > > > Well, and as long > > > as menus grab the pointer and the keyboard, processing module > > > messages is pointless since the function execution code needs (?) > > > to grab the pointer too. > > > > I don't think I understand the point about the grab. > > Its OK for menus to freeze FVWM so the grab should be OK. > > When any client grabs the pointer, fvwm basically stops processing > most module messages too, at least if modules call complex > functions. I know that, but don't see that as a problem. We want FVWM to freeze when a menu is popped up. > > I think putting the menu code in a module might simplify tear > > off menus. I'm not sure of all the details but it just seems > > like it might. Perhaps another copy of the menu module could be > > started to handle the torn off menu (without grabs once its torn > > off). > > Fvwm menus need to grab the keyboard to work properly. Pure mouse > operable menus would be useless to me. I'm sorry if I'm wasting your time. Maybe I don't understand what a tear off menu is. I thought it was like one of those Openwin menus that you use a pushpin to make it stay visible. If I'm on the right track, then I think the menu would have to release the grab once the menu is torn off. What I thought would happen is the menu code would send a description of the menu to another module and the module would create a normal window that looked like the menu except that FVWM could reparent it, and if desired frame, title and do other good things to it. At that point the menu could be operated with the keyboard or the mouse just like any other window. (Using enter, leave, keypress events and the like.) It could still popup a submenu with a grab, but you wouldn't need a grab for the torn off menu itself. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at 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: Tear off menus stop module messages
On Mon, Apr 22, 2002 at 03:05:26PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > > Why can't the menu code be in a module? > > > > Of course menus *can* be a module. It's just that the menu code > > was not written to run independently of fvwm and is thus > > interwoven tightly with fvwm's data structures. > > Well, and as long > > as menus grab the pointer and the keyboard, processing module > > messages is pointless since the function execution code needs (?) > > to grab the pointer too. > > I don't think I understand the point about the grab. > Its OK for menus to freeze FVWM so the grab should be OK. When any client grabs the pointer, fvwm basically stops processing most module messages too, at least if modules call complex functions. > I think putting the menu code in a module might simplify tear > off menus. I'm not sure of all the details but it just seems > like it might. Perhaps another copy of the menu module could be > started to handle the torn off menu (without grabs once its torn > off). Fvwm menus need to grab the keyboard to work properly. Pure mouse oparable menus would be useless to me. 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 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: Tear off menus stop module messages
Dominik Vogt writes: > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > On Fri, Apr 19, 2002 at 04:01:48PM +0100, tim phipps wrote: > > > > Configuration Information [Automatically generated, do not change]: > > > > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > > > > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > > > Description: > > > > When the pointer is on a tear off menu item fvwm stops processi > > > > module messages. > > > > > > Yes, that's by design of the tear off menu code. I have no idea > > > what to do about it (other that creating a separate instance of > > > fvwm for each tear off menu). > > > > Why can't the menu code be in a module? > > Of course menus *can* be a module. It's just that the menu code > was not written to run independently of fvwm and is thus > interwoven tightly with fvwm's data structures. > Well, and as long > as menus grab the pointer and the keyboard, processing module > messages is pointless since the function execution code needs (?) > to grab the pointer too. I don't think I understand the point about the grab. Its OK for menus to freeze FVWM so the grab should be OK. I think putting the menu code in a module might simplify tear off menus. I'm not sure of all the details but it just seems like it might. Perhaps another copy of the menu module could be started to handle the torn off menu (without grabs once its torn off). I think it might have a beneficial effect on memory use too. More of the menu logic might swap out while the menus are not in use. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at 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: Tear off menus stop module messages
On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Fri, Apr 19, 2002 at 04:01:48PM +0100, tim phipps wrote: > > > Configuration Information [Automatically generated, do not change]: > > > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > > > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > > > > > FVWM Version: 2.5.1 > > > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > > > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > > > FVWM_USERDIR: /u/phippst/.fvwm > > > > > > Description: > > > When the pointer is on a tear off menu item fvwm stops processing > > > module messages. > > > > Yes, that's by design of the tear off menu code. I have no idea > > what to do about it (other that creating a separate instance of > > fvwm for each tear off menu). > > Why can't the menu code be in a module? Of course menus *can* be a module. It's just that the menu code was not written to run independently of fvwm and is thus interwoven tightly with fvwm's data structures. Well, and as long as menus grab the pointer and the keyboard, processing module messages is pointless since the funtion execution code needs (?) to grab the pointer too. 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 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: Tear off menus stop module messages
Dominik Vogt writes: > On Fri, Apr 19, 2002 at 04:01:48PM +0100, tim phipps wrote: > > Configuration Information [Automatically generated, do not change]: > > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > > > FVWM Version: 2.5.1 > > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > > FVWM_USERDIR: /u/phippst/.fvwm > > > > Description: > > When the pointer is on a tear off menu item fvwm stops processing > > module messages. > > Yes, that's by design of the tear off menu code. I have no idea > what to do about it (other that creating a separate instance of > fvwm for each tear off menu). Why can't the menu code be in a module? To retain compatibility, there could be commands like this: OnCommand Popup SendToModule FvwmMenu P $* OnCommand MenuSendToModule FvwmMenu M $* OnCommand AddToMenu SendToModule FvwmMenu A $* OnCommand DestroyMenu SendToModule FvwmMenu D $* # Make "SendToModule Module" load FvwmMenu, LoadOnDemand FvwmMenu The first time fvwm encountered a "SendToModule" for a LoadOnDemand module, it would load it. As long as the module stays loaded, the menus should be fast enough. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at 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: Tear off menus stop module messages
On Fri, Apr 19, 2002 at 04:01:48PM +0100, tim phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > When the pointer is on a tear off menu item fvwm stops processing > module messages. Yes, that's by design of the tear off menu code. I have no idea what to do about it (other that creating a separate instance of fvwm for each tear off menu). 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 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]
Tear off menus stop module messages
Configuration Information [Automatically generated, do not change]: uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 compiler flags: gcc -g -O2 -Wall -Wno-implicit-int FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: When the pointer is on a tear off menu item fvwm stops processing module messages. The same thing happens when a normal menu is popped up but it's less noticeable since the menu is short lived. Repeat-By: Arrange for a shell script to update an FvwmButtons title every second via FvwmCommand. Tear off a menu. Put the mouse over then torn off menu item. Look at the button which should be updating. Move the pointer off. Watch the button catch up with the updates. -- Visit the official FVWM web page at 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: Tear off menus
On Sun, Mar 10, 2002 at 12:05:26PM +, Mikhael Goikhman wrote: > On 10 Mar 2002 09:34:25 +0100, Dominik Vogt wrote: > > > > On Sun, Mar 10, 2002 at 12:13:46AM +, Mikhael Goikhman wrote: > > > It is hard to see what you already did about first titles, because the > > > current cvs can't be compiled. > > > > > > Flocale.c: In function `FlocaleUnloadFont': > > > Flocale.c:506: structure has no member named `fftfont' > > > > I do not understand this. Clean sources checked out from CVS into > > a new directory compile well for me (without enabling fribidi and > > xft which I don't have on that machine). Did you perhaps make a > > check out in the short period of time between my first commit and > > the second? As always, I forgot to cvs add some files in the > > first one. > > Ok, if you don't HAVE_XFT, this explains why it compiles well for you. > > - FftFontClose(dpy, flf->fftfont); > + FftFontClose(dpy, flf->fftf.fftfont); > > Also in event.c, menuitem.c and several modules in order to compile I > temporarily did: > > -#ifdef HAVE_XFT > +#if 0 && HAVE_XFT > > There are still warnings: > ... Fixed (at least for XFree-4.2.0). Olivier -- Visit the official FVWM web page at 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: Tear off menus
On 10 Mar 2002 09:34:25 +0100, Dominik Vogt wrote: > > On Sun, Mar 10, 2002 at 12:13:46AM +, Mikhael Goikhman wrote: > > It is hard to see what you already did about first titles, because the > > current cvs can't be compiled. > > > > Flocale.c: In function `FlocaleUnloadFont': > > Flocale.c:506: structure has no member named `fftfont' > > I do not understand this. Clean sources checked out from CVS into > a new directory compile well for me (without enabling fribidi and > xft which I don't have on that machine). Did you perhaps make a > check out in the short period of time between my first commit and > the second? As always, I forgot to cvs add some files in the > first one. Ok, if you don't HAVE_XFT, this explains why it compiles well for you. - FftFontClose(dpy, flf->fftfont); + FftFontClose(dpy, flf->fftf.fftfont); Also in event.c, menuitem.c and several modules in order to compile I temporarily did: -#ifdef HAVE_XFT +#if 0 && HAVE_XFT There are still warnings: Fft.c: In function `FftDrawString': Fft.c:168: warning: assignment from incompatible pointer type Fft.c:197: warning: passing arg 1 of `XftDrawString8' from incompatible pointer type Fft.c:201: warning: passing arg 1 of `XftDrawDestroy' from incompatible pointer type I don't commit these compilation fixes, because they don't really fix XFT. Regards, Mikhael. -- Visit the official FVWM web page at 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: Tear off menus
On Sun, Mar 10, 2002 at 12:13:46AM +, Mikhael Goikhman wrote: > It is hard to see what you already did about first titles, because the > current cvs can't be compiled. > > Flocale.c: In function `FlocaleUnloadFont': > Flocale.c:506: structure has no member named `fftfont' I do not understand this. Clean sources checked out from CVS into a new directory compile well for me (without enabling fribidi and xft which I don't have on that machine). Did you perhaps make a check out in the short period of time between my first commit and the second? As always, I forgot to cvs add some files in the first one. 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-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Tear off menus
I moved this thread to here. On 09 Mar 2002 21:55:40 +0100, Dominik Vogt wrote: > > On Sat, Mar 09, 2002 at 07:50:09PM +, Mikhael Goikhman wrote: > > On 09 Mar 2002 16:54:21 +0100, Marcus Lundblad wrote: > > > > > > > I'm not yet finished with the implementation yet. There are some > > > > quirks that bug me. Any input is welcome. > > > > > > Another option I would like is to be able to let the title of the window > > > be the title of the menu, and not show the title in the menu itself. > > > > And what to do about menus with 0 or 2 titles? Or with one title in the > > middle of the menu. > > > > On the other hand we already have "Title top", that may be only one per > > menu. "Title top" may be used for a window title and be removed. > > > > Also two possible options to MenuStyle: > > > > MenuStyle * FirstTitleIsAlwaysTop # the name may be different > > What should this style do? The intention is for every menu to always have one main title (usually undefined). "Title top" argument may identify the main title. In addition this option would assign the first Title to be the main one. The main title as opposed to regular Title items is removed from the torn off menu. It is hard to see what you already did about first titles, because the current cvs can't be compiled. Flocale.c: In function `FlocaleUnloadFont': Flocale.c:506: structure has no member named `fftfont' > > MenuStyle * ForceTearOffSeparator # add dashed separator at the top > > That can't be done easily. It requires modifying the menu itself. > It's simple to add additional items to menus that are already torn > off, but not to regular menus. The solution may be to always add a tear-off separator item at the top (probably after the main title) that has a boolean state (visible or not). > > I suggest to remove the current Mouse 2 binding on menu titles. > > I didn't know what else to do. I agree that it's not a good idea. > > > In the future I would like to have configurable mouse or keys bindings > > for menu items. > > I hope you're not talking about bindings with modifiers, mouse > motion and such ... Different actions for the mouse buttons might > be good start. I have been thinking about that for quite a while. Well, I did think about real bindings, but this is probably not needed. I agree with you that something like this would be a good start, but the syntax for this is problematic. Maybe something like this: AddToMenu my-menu + "item label" (DefaultCommand0 Args0), (3 CommandOnButton3 Args3) There was a request to enhance fvwm-menu-directory so it does different actions on different mouse buttons (view file, edit file, run file). I would bind a file operation submenu for mouse button 3. Regards, Mikhael. -- Visit the official FVWM web page at 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: * Strip the menu title of tear off menus and place it in the window title.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/03/09 14:20:24 Modified files: . : ChangeLog fvwm : menus.c Log message: * Strip the menu title of tear off menus and place it in the window title. -- Visit the official FVWM web page at 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 work on tear off menus.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/03/03 11:11:07 Modified files: . : ChangeLog fvwm : Makefile.am fvwm2.1 menus.c menus.h libs : Picture.c Picture.h Added files: fvwm : menucmd.c menudim.c menudim.h menuitem.c menuitem.h menustyle.c menustyle.h Log message: * More work on tear off menus. -- Visit the official FVWM web page at 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: * Some work on tear off menus, general clean up of the menu code and bug fixes.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/24 12:17:25 Modified files: . : ChangeLog fvwm : fvwm.c menus.c menus.h move_resize.c move_resize.h libs : Graphics.c Log message: * Some work on tear off menus, general clean up of the menu code and bug fixes. * Removed debug abort(). -- Visit the official FVWM web page at 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 work on tear off menus. They can now be invoked with the mouse, either
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/24 04:50:02 Modified files: . : ChangeLog fvwm : builtins.c commands.h functions.c functions.h menus.c menus.h libs : defaults.h Log message: * More work on tear off menus. They can now be invoked with the mouse, either by clicking on a title with button 2 or by defining an item with the action "MenuTearOff". It can have text or pictures as normal or neither. In the latter case, it's drawn as a bar with a dashed line. * Some fixes and a little clean up in the menu code. -- Visit the official FVWM web page at 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: Tear off menus
On Tue, Feb 05, 2002 at 08:50:38AM +, Tim Phipps wrote: > I'm just wondering if tear of menus would be better off in a module? I'd be much happier if the menu code was clean enough to be put in a module. It's too tightly woven into fvwm right now and that causes a lot of problems with tear off menus. At the moment, fvwm can not do anything useful while in a menu without risking crashes. This is one of the reasons for the brain dead focus handling with tear off menus (needs keyboard input but grabs the keyboard itself instead of using the normal focus policy). > Making fvwm create its own top level windows makes it more vulnerable to > being killed (try xkill when you don't have anything important on > screen). I seem to remember scwm having the same problem, I'm not sure > what they did. > > Is it possible to fork and reopen the display? I don't think so. The forked process loses the connection to the original fvwm and can't trigger any menu actions without interfering. No, if we need a second process it must be a regular module. I'm open for any ideas how to solve this, but we should postpone this discussion for two or three weeks. I still have to do some more basic work on tear off menus until the end of the week. After that I'll be skiing for about ten days. After that there is plenty of time to thinks about it. 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 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 leaving tear off menus when something is selected with the mouse.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/05 04:21:50 Modified files: . : ChangeLog fvwm : menus.c Log message: * Fixed leaving tear off menus when something is selected with the mouse. -- Visit the official FVWM web page at 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]
Tear off menus
Hi Dominik, I'm just wondering if tear of menus would be better off in a module? Making fvwm create its own top level windows makes it more vulnerable to being killed (try xkill when you don't have anything important on screen). I seem to remember scwm having the same problem, I'm not sure what they did. Is it possible to fork and reopen the display? Cheers, Tim. -- Visit the official FVWM web page at 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: * First draft of tear off menus. (see below for details)
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/01/31 07:39:01 Modified files: . : ChangeLog NEWS fvwm : add_window.c add_window.h builtins.c commands.h decorations.c events.c events.h functions.c functions.h fvwm.c fvwm.h fvwm2.1 menus.c menus.h window_flags.h Log message: * First draft of tear off menus. (see below for details) * New commands XSync and XSynchronize for debugging. * This already works in tear off menus: - Tearing out root menus with Backspace - Drawing the menu - Delete, Close, Destroy the menu - Iconify it - Menu title, icon title, class, resource - Placement - Menu can't be resized And this does not work: - Functionality of menu - Recapturing menus (crashes fvwm eventually) - Tearing out sub menus - Pointer and keyboard handling. -- Visit the official FVWM web page at 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]
