Subject: Popup menus not "sticking" on click

From: [email-masked] (Paul D. Smith)
Date: 11 Aug 1999 12:53:04 -0400

Back in the fvwm 2.2 series (?) we had a problem where clicking a Popup
submenu item caused the parent to disappear and the child to become the
"top-level" menu.  We didn't like that and Dominik changed it back to
work "normally" where if you click a submenu item it "posts" and stays
even if you move the mouse off of it.

Anyway, I thought he did...

But either way, it doesn't work now (latest CVS, and yesterday too but I
don't know how long before that).

Clicking on a submenu item has no effect; if you move the mouse down off
the item it moves the selection to the next item, instead of keeping the
"clicked on" item selected.

Did anyone understand that? :)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Thu, 12 Aug 1999 07:32:15 +0200

On Wed, Aug 11, 1999 at 12:53:04PM -0400, [email-masked] wrote:
> work "normally" where if you click a submenu item it "posts"

This far it's correct.

> and stays even if you move the mouse off of it.

Nope, I never implemented something like this.

> Clicking on a submenu item has no effect;

Not if the submenu was already posted.

> if you move the mouse down off

Yes. That is what I wanted. Why do you say the normal way was that the
submenu would stay posted until you press the button on a different
item of the parent menu? I can't think of menu implementation that
does it this way. Windoze and KDE for example have a short delay before
the submenu pops down when you enter a new item on the parent, but it
*will* pop down eventually.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
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: [email-masked] (Paul D. Smith)
Date: 12 Aug 1999 01:48:55 -0400

%% Dominik Vogt <[email-masked]> writes:

  >> if you move the mouse down off the item it moves the selection to
  >> the next item, instead of keeping the "clicked on" item selected.

  dv> Yes. That is what I wanted. Why do you say the normal way was that the
  dv> submenu would stay posted until you press the button on a different
  dv> item of the parent menu? I can't think of menu implementation that
  dv> does it this way. Windoze and KDE for example have a short delay before
  dv> the submenu pops down when you enter a new item on the parent, but it
  dv> *will* pop down eventually.

I don't have Windoze handy at the moment; I thought it did "permanent
posting" too, not a short delay.

But at any rate this is the way all Motif apps I've ever used behave,
for example.  I _thought_ this is how menus used to behave in fvwm, as
well, but I'd have to go back and try it to be sure.

Go try it in Netscape, for instance: if you click a submenu line that
menu stays posted no matter _where_ the mouse goes; you can move it to
the other side of the screen.

I really like this behavior because I often get deeply cascading menus
and it's truly, truly frustrating to try to maneuver the mouse over to
the submenu without having it slip off the current menu pick, up or
down.  I click my way through all my menus, it's just so much easier
that way.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 12 Aug 1999 08:04:21 +0200

> the other side of the screen.

Hm, yes. Clearly a matter of personal taste. Unfortunately the selected
menu item and the visible submenu are linked closely together at the
moment. I tried to separate both once but failed. 

> down.  I click my way through all my menus, it's just so much easier

That's the reason why KDE and Windoze have this delay. You can move off
the menu for a second or so when navigating around with the mouse
without bringing down the menu. As I said, I tried to rewrite the
menu code to allow something like this, for the same reason once.

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 12 Aug 1999 02:17:14 -0400

%% Dominik Vogt <[email-masked]> writes:

  >> Go try it in Netscape, for instance: if you click a submenu line
  >> that menu stays posted no matter _where_ the mouse goes; you can
  >> move it to the other side of the screen.

  dv> Hm, yes. Clearly a matter of personal taste. Unfortunately the selected
  dv> menu item and the visible submenu are linked closely together at the
  dv> moment. I tried to separate both once but failed. 

I'm no expert on the menu code, but I'm not sure this matters?  In the
Motif method it's not really that you select other items as the mouse
moves, but have the old popup still visible.  Once you click, nothing
else is selected by moving the mouse.

Think of it like this: when you click on a submenu item you enter a
different "mode" of selection.  Once you click, you can no longer select
any item merely by moving the mouse.  Moving the mouse has no effect on
the section after that.  If you want to select another menu, you have to
explicitly click on it.  Then that becomes the selected item.

There's no way to get back to the initial state of selecting by simple
mouse movement in a particular menu, once you click in it (except by
getting rid of the menu and starting again).

It doesn't seem like you'd need to separate selection from popup menu
display in any way to implement this... but again, I don't know much
about the menu code so I could be wrong :).

  >> down.  I click my way through all my menus, it's just so much easier

  dv> That's the reason why KDE and Windoze have this delay. You can
  dv> move off the menu for a second or so when navigating around with
  dv> the mouse without bringing down the menu. As I said, I tried to
  dv> rewrite the menu code to allow something like this, for the same
  dv> reason once.

Personally, I much prefer the Motif method.  It's simpler to use and
much simpler to code, more deterministic for the user, etc. etc.
Generally I really dislike time delays like that--the fact that I use
FvwmAuto is merely the exception that proves the rule ;).

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 12 Aug 1999 09:36:26 +0200

On Thu, Aug 12, 1999 at 02:17:14AM -0400, [email-masked] wrote:
...

> FvwmAuto is merely the exception that proves the rule ;).

What I don't like about this method is that you can't hilight items
on the parent menu anymore.

Bye

Dominik ^_^

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 12 Aug 1999 06:39:09 -0400

> FvwmAuto is merely the exception that proves the rule ;).

Another reason to disklike time delays is solaris does a poor job of
implementing usleep, because that is the only place I where fvwm can
consistenttly lock up on me.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Thu, 12 Aug 1999 13:02:27 +0200

> about the menu code so I could be wrong :).

Yup, you *are* wrong. I just spent four unhappy hours trying to hack this
in, but the recursive structure of the menu code prevents me from
getting very far. :-(

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 13 Aug 1999 11:11:39 -0400

>> FvwmAuto is merely the exception that proves the rule ;).

  dv> What I don't like about this method is that you can't hilight items
  dv> on the parent menu anymore.

I guess it's a matter of point of view, or maybe I'm misunderstanding
what you mean.

I think the selected item _should_ always be the one that's
highlighted--and since you select a particular one when you click, that
one should be highlighted and no others, even when you move the mouse.

What am I missing?  I don't have any fancy highlighting (background
colors, etc.) on my menus, they just get 3d borders, then go flat again.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 14 Aug 1999 01:36:53 +0300 (IDT)

> one should be highlighted and no others, even when you move the mouse.

This is the Motif method. Qt (KDE) behaves very similar (at least ver1).
Gtk (Gnome) method is different. It is a subset of fvwm. There is a
hilighting of menu item whenever a mouse moves over them, not only when
you click on the item, like in fvwm.

> colors, etc.) on my menus, they just get 3d borders, then go flat again.

This is a matter of feel, not only look. Something like previewing first
of what will be executed when clicked.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 13 Aug 1999 19:55:43 +0200

> colors, etc.) on my menus, they just get 3d borders, then go flat again.

I don't have either. It just irritates me that the menus don't react
to my mouse or keyboard movements.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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]