Hi there...
Comments below, again:
On Sat, Jul 06, 2002 at 05:40:55PM +0200, Dominik Vogt wrote:
> On Sat, Jul 06, 2002 at 03:02:01PM +0300, Tom Alsberg wrote:
> > <snip />
> > Well, there are other examples, like I noted, with GTK+ buttons,
> > Netscape toolbars, balloon titles in FvwmPager...
>
> But what *are* the problems? I'm not a psychic.
Well, with GTK+ buttons, sometimes the buttons act like the pointer
enters and leaves them a lot of times in a short time period, getting
highlighted and un-highlighted - the same with Netscape's toolbars.
With FvwmPager, when the pointer goes over a window, and then over
another window, in a short period of time, sometimes the balloon
showing the title of the window starts to flicker - appears and
disappears continuously for a short time.
> > And sometimes
> > windows being automatically raised (e.g. FvwmButtons) start
> > flickering - getting raised and lowered over and over again frequently
> > in a short time...
> > I do not have exact tests for those examples, though, as they do not
> > always happen - only once in a while...
>
> Then please try to pin it down. I have no such problems with the
> functions.
I could only pin those problems down to the actual lines in the
.fvwm2rc which do the automatic raising and lowering.
As I said, it does not always happen... But in some time with this
setup, you notice it...
> > But if you use this setup for
> > a while, with some activity with automatically raised and lowered
> > windows, then you'll probably see it a few times.
>
> Uh, but I won't. I hate auto raising. I can't use my desktop
> with it. :-)
Oh... Well, I don't really like auto raising of my windows either... I
just use it for some little windows like the icon manager,
FvwmButtons, XClock, etc. which I want to see without "effort"
(clicking, etc.) at times but I don't want them to consume space all
the time...
> > <snip />
> > I would ask now - why does this have to be a complex function?
> > Couldn't it be, instead of a complex function, just some
> > AutoRaise/AutoLower style?
>
> Well, what would you win with that? You'd still need a complex
> function to select the windows to use.
Well, I suppose just use those windows with the style applied to
them...
> No. Either you give up most of the flexibility or you have to use
> complex functions.
>
> > <snip />
> > By enter and leave events, do you mean events of FVWM (FvwmEvent), or
> > events in the level of X?
>
> It's roughly the same.
>
> > After all, FVWM does a lot of things on
> > enter and leave, including focus, changing window styles, etc etc.
>
> Yes, but it *does not* restack windows triggered by these events.
> That's the one thing that does not work
Why should that be the one thing that does not work, though?
> <snip />
> Let me explain. You probably think that one EnterNotify event is
> sent when a window is entered and one LeaveNotify event when the
> window is left. But that's not true. Let's assume we have two
> overlapping windows A and B. The most simple case would be
> windows without any children. In fvwm, the visible window still
> consists of a lot of sub windows: The top level window (frame),
> the Wparent" window which contains the client window, and more
> than a dozen decorative windows. Let's assume the pointer is in
> the client window of A and is moved across the title bar into
> window B:
>
> - pointer moves into the titlebar of A
> Events:
> leave client A
> leave parent A
> enter title window A
> - Pointer moves into the border of A
> Events:
> leave title window A
> enter border A
> - Pointer moves directly into the client window of B.
> Events:
> leave border A
> leave frame A
> enter frame B
> enter parent B
> enter clent B
>
> And it get's much worse if pointer grabs are considered: when an
> application grabs the pointer, it can specify a grab context
> window. For example, if you open a menu (by a key stroke), the
> client, parent and frame of B are left and the menu window is
> entered, *even* if the pointer is not over the menu. The reverse
> events occur when the grab is released (leave menu, enter frame/
> parent/client). The old window even gets enter events if the
> pointer is no longer over it - immediately followed by the usual
> leave events and the enter events on the new window hierarchy.
Wow... I didn't know it's that complicated... (I hardly ever dealt
with those aspects of X - which do not draw in some client window or
the root window, or something)
> (BTW, this grabbing issue is what makes the gv zoom window vanish:
> the pointer is grabbed by fvwm ==> zoom window receives a leave
> event and closes. It should ignore events triggered by grabs).
Why does the pointer being grabbed cause the window to receive a leave
event?
> <snip />
> > (and *slow*)?
>
> Because enter and leave events are by fare the most common events
> (apart from mouse events). When they are actually communicated to
> a module, a lot of useless traffic is created.
Oh... understood... Not that I know that there are a lot more enter
and leave events than I thought...
> > <snip />
> > Well, might be... But, well... I still find this a bit weird,
> > considering that some other window managers handle that quite well,
> > also with gv... And, as I said, the problem is not only with gv... gv
> > is just a test that always shows the problem.
>
> No, let's get this straigt: the gv problem is *completely*
> different from any problem with windows competing for the top
> position on the window hierarchy. It's really just a gv bug. The
> developers forgot to grab the pointer when that popup window
> opens.
I got it now... For some reason I had the idea that it was the same
problem, but now I see it...
> > <snip />
> > I tried FvwmAuto for that, and those were exactly my problems... I do
> > have my focus following the pointer, except windows which have the
> > ClickToFocus style enabled... And mostly, those are the windows I want
> > to automatically raise and lower...
> > That was what my first post on this subject (back near the end of
> > 2001) was to say... That I need a bit more than FvwmAuto can do, at
> > that time...
>
> (much later)
>
> I've made a patch to FvwmAuto so that it can handle enter and
> leave events instead of focus events. Try this with the latest
> cvs code:
>
> FvwmAuto 0 -passid -enterleave \
> "Silent selective_raiselower raise" \
> "Silent selective_raiselower lower"
>
> DestroyFunc selective_raiselower
> AddToFunc selective_raiselower
> + I WindowId $1 (FvwmIconMan) $0
> + I WindowId $1 (FvwmButtons) $0
> + I WindowId $1 (xclock) $0
> + I WindowId $1 (xexec) $0
>
> (You need the file libs/Flocale.c from the 4th of July - the
> current one is buggy and may crash fvwm).
Wow... That works great... Almost.
It does it as expected, responsive, and there seems to be no
flickering with it...
But, the problem with gv, which I now completely realize that it is a
different problem, is still there - it doesn't happen when I just
automatically raise and lower all windows... Apparently because of the
pointer grabbing deal... But I don't want to have all windows
automatically raised...
Could there be a way to not have to use a function for that? Make it a
style that FvwmAuto checks or something? That would be perfect then...
Or maybe there could be a way to cause that specific function
(selecting the window) not to grab the pointer...
> Bye
>
> Dominik ^_^ ^_^
Thanks very much, again... Some of the problem is already solved...
-- Tom
--
Tom Alsberg - certified insane, complete illiterate.
e-mail: <alsbergt_at_softhome.net>
Homepage: http://www.cs.huji.ac.il/~alsbergt/
* An idea is not responsible for the people who believe in it.
--
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 Sun Jul 07 2002 - 06:43:59 BST