On Sat, Jul 06, 2002 at 03:02:01PM +0300, Tom Alsberg wrote:
> On Sat, Jul 06, 2002 at 03:28:09AM +0200, Dominik Vogt wrote:
> > On Sat, Jul 06, 2002 at 01:46:42AM +0300, Tom Alsberg wrote:
> > > <snip />
> > > The problem is not only with gv.
> >
> > > The whole problem of flickering is
> > > still there, including the problems with buttons in GTK+ applications,
> > > Netscape toolbar, borders of some windows being automatically raised
> > > like XClock and FvwmIconMan, FvwmPager balloon titles, etc. I only
> > > gave gv as an example which always shows the problem.
> >
> > Unfortunately, the gv problem I saw had little to do with
> > flickering. If other apps have this problem, I need more
> > examples.
>
> 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.
> 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.
> 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. :-)
> > > I do not see why gv trying to grabbing the pointer should be a
> > > problem, especially that other window managers (e.g. CTWM) have such
> > > a feature (automatically raise and lower) which doesn't cause those
> > > problems. I don't see exactly why FVWM should grab the pointer for
> > > that.
> >
> > Because fvwm is executing a complex function.
>
> 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. No. Either you give up
most of the flexibility or you have to use complex functions.
> > The pointer is always grabbed during function execution (and has to
> > be to prevent funny and hard to debug problems). Don't forget we're
> > not using well tested, documented features here. After all, using
> > enter and leave events is a real hack (and *slow*).
>
> 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
> If we are talking about X events here... Then, well, I find it hard to
> believe that it is not well tested and documented... As it is used a
> lot and seems to have not principle problems...
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.
(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).
> Also, why a real hack
Because the typical fvwm user won't be able to use this feature in
a sensible way. You have to have a lot of experience in X
programming to use it. Just look at me: I've been hacking fvwm
for four years and know X event handling very well and I still
can't easily come up with a good solution.
> (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.
> Again, why do automatically raising and lowering have to be
> implemented using a complex function?
>
> > Any application that is stupid enough to not retry grabbing the
> > pointer when it's needed and unlucky enough to try it at the wrong
> > time has a problem.
> > Correct fix = fix gv.
>
> 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 am not enough of an expert in X11 to tell exactly... But since other
> > > window managers, like CTWM (I keep giving it as an example because
> > > that's one I used lot beside and before FVWM) have this function
> > > (auto-raise and auto-lower) working fine, without flickering, and not
> > > causing problems with pointer grabbing with gv, I suppose that could
> > > be done with FVWM too...
> >
> > Sure. Use FvwmAuto. Of course you'd have to switch to
> > SloppyFocus or MouseFocus and lose ability to enable the feature
> > only for selected windows.
>
> 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).
[snip]
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 Sat Jul 06 2002 - 10:41:00 BST