Re: FVWM: Still slight cosmetic problem with HGradient menus

From: John Latham <jtl_at_cs.man.ac.uk>
Date: Thu, 5 Sep 2002 18:55:26 +0100

> Date: Tue, 3 Sep 2002 11:58:18 +0200
> From: Dominik Vogt <fvwm_at_fvwm.org>

> 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 <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu Sep 05 2002 - 12:56:21 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST