Subject: what needs to be done for tear-off menus?

From: Dominik Vogt <[email-masked]>
Date: Mon, 17 Jun 2002 13:36:42 +0200

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-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: parv <[email-masked]>
Date: Mon, 17 Jun 2002 14:30:53 -0400

in message <[email-masked]>,
wrote fvwm-workers thusly...
> 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

--

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jun 2002 13:54:05 +0200

> 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. :-/

> is appears in its entirety on the current page.  (that could be your

Ah, I see.  Hadn't thought of that yet.  Animated tear-off menus
are really not a good idea.

> 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 ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 19 Jun 2002 13:05:36 +0000

> > > 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.

> 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.

> To deactivate the menu, simply move the mouse away.  What do

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,

> 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.

---

From: Dan Espen <[email-masked]>
Date: Wed, 19 Jun 2002 09:34:17 -0400

>  - continuation menus ("more...")

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-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jun 2002 16:51:22 +0200

> 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.

> off menu is on the screen.
[snip]
> 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.

> ("" TearMenuOff), not ("" Nop) separator. Then mouse 2 binding on a title

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.

> 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)

> 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 ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 19 Jun 2002 10:16:42 -0400

> from within the menu code and (b) the decorations may change at

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.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 19 Jun 2002 18:55:01 +0200

> 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

---

From: parv <[email-masked]>
Date: Wed, 19 Jun 2002 14:18:53 -0400

in message <[email-masked]>,
wrote fvwm-workers thusly...
> the menu code stays in the fvwm core there is little that can be
...
> 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 <backspace>.

  - parv

--

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 19 Jun 2002 18:18:16 +0000

> fvwm_menu_style_id_of_the_window (with CopyMenuStyle) and use this

A good solution. So it would be posible to get the same menu in 5
different menu styles on the screen simultaneously. :)

> - The font used by the tear-off menu title bar should be the font

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.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jun 2002 17:05:35 +0200

> Making pushpins work would make the feature more accessible.

Meaning what?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 19 Jun 2002 21:30:53 -0400

> > Making pushpins work would make the feature more accessible.

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.

---

From: parv <[email-masked]>
Date: Wed, 19 Jun 2002 22:19:56 -0400

in message <[email-masked]>,
wrote Dan Espen thusly...
> I think its very intuitive.

much like gtk (i use gimp) tear off menus ... which have dashed line
at the top.

--