Subject: more menu problems

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 9 Jan 2001 12:47:55 -0600

Dominik, your latest commit fixed incorrect places of submenus, but there
are still other problems with the new code.

If you have a menu with submenus it is very slow to navigate in it,
it is fast to navigate over regular (non-submenu) items.

There is a core dump. Start FVWM as: fvwm2 -cmd "Mouse 2 R A WindowList"
Press middle button -> crash:

(gdb) where
#0  0x401d48ad in memmove (dest=0x8096ee0, src=0xb, len=96)
    at ../sysdeps/generic/memmove.c:72
#1  0x804d9d5 in MenuInteraction (pmp=0xbfffee30, pmret=0xbfffed60,
    pdkp=0xbfffebc0, pdo_warp_to_title=0x80950e8) at menus.c:1436
#2  0x804cd7e in do_menu (pmp=0xbfffee30, pmret=0xbfffed60) at menus.c:787
#3  0x8080a96 in do_windowList (eventp=0x8096ee0, w=42, tmp_win=0x0,
    context=8, action=0x80ad31a "", Module=0xbfffef64) at windowlist.c:534
...

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 09 Jan 2001 23:46:24 +0100

> it is fast to navigate over regular (non-submenu) items.

I think this come because of the new menu style PopdownDelayed which is
a default. I think that using PoupdownImmediately menu style will fix the
problem. Moreover, I think that PoupdownImmediately must be the default
and that may be it will good to add this to win, mwm and fvwm menu style.

> Press middle button -> crash:

I've noted the same problem.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 8 Jan 1904 01:21:48 +0100

On Tue, Jan 09, 2001 at 11:46:24PM +0100, Olivier Chapuis wrote:
> problem.

Yes, exactly.  There is a noticeable delay (150 ms) before a
sub-menu pops down when you leave the item.  During this delay the
new item will not be hilighted.  The idea is that when you try to
move the pointer into the sub-menu, you can pass over other items
without popping down the sub-menu.  The reason why it's so
sluggish is the length of the delay.  The default PopupDelay is
150 ms.  I chose the default PopdownDelay to be the same so that
when the sub-menu is finally popped down, a new sub-menu will be
mapped in a way so that you won't see the background windows to
reduce redrawing.  If PopdonDelay were shorter that PopupDelay,
this would not be the case.  I would prefer a shorter default
PopdownDelay too, especially if nobody objects lowering the
default PopupDelay too.

> Moreover, I think that PoupdownImmediately must be the default

I disagree.  I think the biggest flaw of the old menu code was
that sub-menus pop down when the pointer strays from the
corresponding item.  I'd rather break backwards compatibility
(well, it's only a default) than tire new users with the old,
uncomfortable code.

> > Press middle button -> crash:

I'll look into it.

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: Dominik Vogt <[email-masked]>
Date: Fri, 8 Jan 1904 01:42:04 +0100

>     context=8, action=0x80ad31a "", Module=0xbfffef64) at windowlist.c:534

I don't see this, but obviously I overlooked a dirty hack that
destroys the event pointer that is the src in the memmove()
operation.  Please try this after my next commit.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 10 Jan 2001 10:16:49 -0600

> operation.  Please try this after my next commit.

Still the same problem as before.

#0  0x804d9d2 in MenuInteraction (pmp=0xbfffee30, pmret=0xbfffed60,
    pdkp=0xbfffebc0, pdo_warp_to_title=0x8095188) at menus.c:1436
1436          memcpy(&Event, pmp->event_propagate_to_submenu, sizeof(XEvent));

(gdb) p pmp->event_propagate_to_submenu
$1 = (XEvent *) 0xb
(gdb) p *(pmp->event_propagate_to_submenu)
Cannot access memory at address 0xb

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 10 Jan 2001 12:33:39 -0600

> PopdownDelay too, especially if nobody objects lowering the

Ok, with both PopupDelay and PopdownDelay 100 it makes more sence to me.
Still I would make PopdownImmediately the default, not PopdownDelayed,
at least with the current implementation. Because in the first case plain
items and submenu items are processed consistently, they are hilighted
immediately even if submenus are not open immediately. In the second case
submenu items (only) are not hilighted immediately causing a unresponsive
or jumpy effect. Maybe they should be shown hilighted while the latest
submenu is still up (and when entering the submenu the father item should
be rehilighted if needed)? IMHO. Sounds complex, but it is already complex
and I see some synchronization bugs already with the PopdownDelayed.

On a slightly different topic. I think your previous idea about posting
submenus by a click (works with PopupAsSubmenu only) was good and arguably
preferable over this new PopdownDelayed idea. But 2 "features" in it make
it unconvinient and unfunctional:

* Once entered into posting mode, it is impossible to return to the
  original mode on the first main menu poping up. I think that the second
  click on the same submenu item should "unpost" the submenu, i.e. return
  menus to the original browsing mode.
* Clicking on items not in the same or in the son levels does not work.
  Well, while trying to reproduce it, it seems you fixed this problem
  in one of your latest commits. Very good. :)

> (well, it's only a default) than tire new users with the old,

Overall, I think this is a good functionality to have. I don't really care
about the exact default (we almost not rely on defaults in fvwm-themes).

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 8 Jan 1904 21:23:47 +0100

> and I see some synchronization bugs already with the PopdownDelayed.

I'm quite unhappy with items not being hilighted too.  The problem
is that hilighting interferes with the caching of the hilighted
item for gradient backgrounds.  The old item can only be
unselected after its menu has been unmapped.  Otherwise the copy
operation may store an undefined part of the gradient (B and D
gradients only).  I have modified the code so that it can cope
with this situation, but only at the cost of a complete menu
redraw, although it's clipped to the corresponding item.  But it
still triggers (menuwidth + menuheight - 1) drawing requests which
have to be sent over the network.

>   original mode on the first main menu poping up.

Any keystroke will bring the menu back into unposted mode.

>   I think that the second

Good idea and probably trivial to implement.

>   in one of your latest commits. Very good. :)

Yup.

> about the exact default (we almost not rely on defaults in fvwm-themes).

It still needs some tuning, but I think it's good to have as a
default.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 8 Jan 1904 21:25:14 +0100

> Cannot access memory at address 0xb

I thought so.  Can you try to find out where the 0xb is stored in
the event pointer?  I have no idea where this could happen.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 11 Jan 2001 13:35:39 +0100

> the event pointer?  I have no idea where this could happen.

I've a "different" core dump:

#0  DispatchEvent (preserve_Tmp_win=0) at events.c:2570
2570      if (EventHandlerJumpTable[Event.type])
(gdb) where
#0  DispatchEvent (preserve_Tmp_win=0) at events.c:2570
#1  0x804e42b in MenuInteraction (pmp=0xbfffeea0, pmret=0xbfffede4, 
    pdkp=0xbfffec70, pdo_warp_to_title=0x8098f08) at menus.c:1750
#2  0x804cf17 in do_menu (pmp=0xbfffeea0, pmret=0xbfffede4) at menus.c:787
#3  0x8083214 in do_windowList (eventp=0x809ab60, w=38, tmp_win=0x0, 
    context=8, action=0x80d8a8a "", Module=0xbfffefc0) at windowlist.c:534
#4  0x8071db8 in execute_function (efa=0xbfffefac) at functions.c:1084
#5  0x8071f17 in old_execute_function (action=0x80b30c0 "WindowList", 
    tmp_win=0x0, eventp=0x809ab60, context=8, Module=-1, exec_flags=0, 
    args=0xbffff090) at functions.c:1153
#6  0x807283f in execute_complex_function (eventp=0x809ab60, w=0, tmp_win=0x0, 
    context=8, action=0x80d4779 "WindowList-Func", Module=0xbffff1b4, 
    desperate=0xbffff128) at functions.c:1620
#7  0x8071e03 in execute_function (efa=0xbffff1a0) at functions.c:1101
#8  0x804d075 in do_menu (pmp=0xbffff278, pmret=0xbffff268) at menus.c:837
#9  0x8054174 in menu_func (eventp=0x809ab60, w=38, tmp_win=0x0, context=8, 
    action=0x80d4a35 "TestMenu", Module=0xbffff400, fStaysUp=1) at menus.c:5367
#10 0x8054213 in staysup_func (eventp=0x809ab60, w=38, tmp_win=0x0, context=8, 
    action=0x80d4a35 "TestMenu", Module=0xbffff400) at menus.c:5383
#11 0x8071db8 in execute_function (efa=0xbffff3ec) at functions.c:1084
#12 0x8071f17 in old_execute_function (action=0x80d3338 "Menu TestMenu", 
    tmp_win=0x0, eventp=0x809ab60, context=8, Module=-1, exec_flags=0, 
    args=0x0) at functions.c:1153
#13 0x8066ab1 in HandleButtonPress () at events.c:1529
#14 0x8067dee in DispatchEvent (preserve_Tmp_win=0) at events.c:2572
#15 0x8067e88 in HandleEvents () at events.c:2625
#16 0x8084e91 in main (argc=1, argv=0xbffff914) at fvwm.c:747

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 12 Jan 2001 21:59:59 +0100

>     context=8, action=0x80ad31a "", Module=0xbfffef64) at windowlist.c:534

Fixed.

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]