Subject: FVWM: Automatically raise certain windows on mouse enter, flickering of windows and widgets

From: Tom Alsberg <[email-masked]>
Date: Thu, 4 Jul 2002 22:04:01 +0300

Hi there.
I would like to automatically raise and lower some certain windows,
like for example XClock, FvwmButtons, icon managers, etc. - raise when
the mouse pointer enters them, and lower when the mouse pointer leaves
them.
I asked this already in a previous thread at the end of last year, and
some-when in that thread Dominik Vogt told that he implemented
enter_window and leave_window events in FvwmEvent, and suggested that
I use those.
Since I started using FVWM 2.5, I have the following in my .fvwm2rc:

# Functions to auto-raise / auto-lower only some specific windows:
DestroyFunc	SelectiveRaise
AddToFunc	SelectiveRaise
	+ I WindowId $0 (!raised "FvwmIconMan") Raise
	+ I WindowId $0 (!raised "FvwmButtons") Raise
	+ I WindowId $0 (!raised "xclock") Raise
	+ I WindowId $0 (!raised "xexec") Raise

DestroyFunc	SelectiveLower
AddToFunc	SelectiveLower
	+ I WindowId $0 (raised "FvwmIconMan") Lower
	+ I WindowId $0 (raised "FvwmButtons") Lower
	+ I WindowId $0 (raised "xclock") Lower
	+ I WindowId $0 (raised "xexec") Lower

# Pass ID of window to actions:
*FvwmEvent:	PassId

# For auto-raise:
*FvwmEvent:	enter_window	"Silent SelectiveRaise"
*FvwmEvent:	leave_window	"Silent SelectiveLower"

But then I started having the problem of some windows/widgets
flickering (acting like losing and getting the focus very fast). For
example buttons in GTK+ applications, Netscape's toolbars, and most
noticable for me - Ghostview (gv), which shows the zoom menu (when
selecting an area with the middle button) for only a very short time,
a fraction of a second, and that menu disappears. Also sometimes
"balloon" labels in the pager flicker in the same way, just as some
other windows sometimes.

I started a thread in the FVWM mailing list then, and was told that my
solution - way to do the raising and lowering with enter_window and
leave_window events is the problem. I was told to look up some more.

Since then I looked up, and did not find a solution yet. CTWM (and
partially TWM) let me do that (automatically raise some windows on
mouse entering and leaving) with the AutoRaise and AutoLower settings,
which worked fine, just as I needed, and didn't cause those kinds of
problems.

I want to use FVWM, though, as it is the best window manager for
me. Except this one thing.
Any idea for a solution for me? Can't such AutoRaise and AutoLower
settings (or styles) or the like be implemented in FVWM too?

This is really the main thing that I have a problem with in FVWM right
now... And I would be happy if that issue would be solved.

  Thank you, any help appreciated,
  -- Tom

-- 
  Tom Alsberg - certified insane, complete illiterate.
        e-mail: <[email-masked]>
	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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Jul 2002 15:13:22 +0200

> now... And I would be happy if that issue would be solved.

I can't remember exactly right now, but I think I posted a better
solution when I added the Schedule command.  It boils down to
scheduling the raise lower commands instead of executing them
directly.  When a command is finally executed, it cleans up the
schedule queue.  This eliminates the race condition if done
correctly.  Perhaps someone else can come up with a link to my
original post?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Tom Alsberg <[email-masked]>
Date: Fri, 5 Jul 2002 17:13:36 +0300

> correctly.  Perhaps someone else can come up with a link to my

I remember your last post then, and found it archived on the web at:
http://www.hpc.uh.edu/fvwm/archive/0204/msg00248.html

At the end of that message, you noted that this race condition can be
avoided using the new Schedule and Deschedule commands. Since then I
have made various experiments and tried many possibilities with it
(Schedule and Deschedule), and today I tried some more... But nothing
seemed to work as I expect... Mostly it just got FVWM stuck (waiting
for a click, with a cross-hair pointer) whenever entering a window
which should be raised.

You did not tell exactly how this can be solved with the Schedule and
Deschedule commands. I have been struggling with it and for some
reason just did not manage to get it right... Maybe I am missing
something obvious... Could you please provide some example, or more
detail on how exactly to do it?

I am using FVWM (2.5.3) from CVS, latest as for yesterday (last
updated yesterday).

> Dominik ^_^  ^_^

  Thank you very much, any further help appreciated,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Jul 2002 16:30:42 +0200

> detail on how exactly to do it?

Sure, just give me a little more time.

> I am using FVWM (2.5.3) from CVS, latest as for yesterday (last

BTW, don't update to today's CVS - the code dumps core at startup.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Jul 2002 17:52:58 +0200

> I am using FVWM (2.5.3) from CVS, latest as for yesterday (last

Here we go:

-------------------------- snip -------------------------
SetEnv AUTO_HIDE_GROUP 101
SetEnv AUTO_HIDE_DELAY 0

DestroyFunc hide_window
AddToFunc hide_window
+ I Lower $w
+ I State 8 off

DestroyFunc hide_all
AddToFunc hide_all
+ I All (state 8) hide_window

DestroyFunc show_window
AddToFunc show_window
+ I echo show $[AUTO_WINDOW_TO_RAISE]
+ I WindowId $[AUTO_WINDOW_TO_RAISE] State 8 off
+ I Next (State 8) echo hiding $w ...
+ I Next (State 8) hide_window
+ I WindowId $[AUTO_WINDOW_TO_RAISE] Raise
+ I WindowId $[AUTO_WINDOW_TO_RAISE] State 8 on
+ I Deschedule $[AUTO_HIDE_GROUP]

DestroyFunc schedule_raise
AddToFunc schedule_raise
+ I Deschedule $[AUTO_HIDE_GROUP]
+ I SetEnv AUTO_WINDOW_TO_RAISE $w
+ I Schedule $[AUTO_HIDE_DELAY] $[AUTO_HIDE_GROUP] show_window

DestroyFunc autohide_window
AddToFunc autohide_window
+ I Schedule $[AUTO_HIDE_DELAY] $[AUTO_HIDE_GROUP] hide_all
+ I PointerWindow (FvwmIconMan) schedule_raise
+ I PointerWindow (FvwmButtons) schedule_raise
+ I PointerWindow (xclock) schedule_raise
+ I PointerWindow (xexec) schedule_raise

DestroyModuleConfig FvwmEvent-Auto: *
*FvwmEvent-Auto: PassId
*FvwmEvent-Auto: enter_window "autohide_window"
*FvwmEvent-Auto: leave_window "autohide_window"

AddToFunc StartFunction
+ I All State 8 off
+ I Module FvwmEvent FvwmEvent-Auto
-------------------------- snip -------------------------

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Jul 2002 18:03:25 +0200

> + I echo show $[AUTO_WINDOW_TO_RAISE]

  ^---- remove this line

> + I Next (State 8) echo hiding $w ...

  ^---- this one too

Bye

Dominik ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Fri, 5 Jul 2002 19:20:40 +0300

On Fri, Jul 05, 2002 at 05:52:58PM +0200, Dominik Vogt wrote:
> <snip />

Thank you very much for your reply and efforts to help... This setup
behaves a bit differently than my expected setup, but I suppose that
when I look at it I will be able to hack it a bit to what I want
exactly...
There is one problem, though... This does not solve the problem I have
with flickering windows/widgets... I removed all my setup related to
it, tested that it does not happen, then inserted your snippet, and
tested, and the flickering happens again...

A simple test to check the problem, which always shows it for me if it
is there, is with gv (Ghostview). If you have it installed, try the
following with this setup - open some PostScript file in Ghostview,
then select some area by dragging with the middle mouse button (or
equivalent). A zoom menu is supposed to show up. Without those
auto-raise setups, it works fine. With either your snippet, or my
previous setup, you will see the menu for a fraction of a second, and
then it will disappear. This should not happen.

So I still have this problem...

> Dominik ^_^  ^_^

  Thanks much for the help, any further help appreciated,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 Jul 2002 22:41:51 +0200

> On Fri, Jul 05, 2002 at 05:52:58PM +0200, Dominik Vogt wrote:
[snip]
> then it will disappear. This should not happen.

Ah yes.  Ghostview probably wants to grab the pointer when the
zoom window is opened, but since fvwm is in a complex function,
the pointer is already grabbed.  Instead or retrying, gv gives up
immediately and closes the window.  On my machine, the problem
goess away when I add this line at the front of the
autohide_window function:

  + I PointerWindow (gv) break

so the complete function looks like this:

  + I PointerWindow (gv) break

Fvwm breaks out of the function fast enough so that gv can grab
the pointer.  Unfortunately, the pattern (gv) applies to all
ghostview windows, somewhat negating the effect of the autohide
setup.

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tom Alsberg <[email-masked]>
Date: Sat, 6 Jul 2002 01:46:42 +0300

Hi there.
Please read my comments below:

On Fri, Jul 05, 2002 at 10:41:51PM +0200, Dominik Vogt wrote:
> the pointer is already grabbed.

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.

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.

> Instead or retrying, gv gives up immediately and closes the window.
> On my machine, the problem goess away when I add this line at the
> front of the autohide_window function:
> 

This is a workaround for gv, which also reduces a bit from the
functionality of the auto-raise and auto-lower (disabling them on that
window), but I wouldn't apply this workaround wherever I see such a
problem... I think this should just be fixed.

> ghostview windows, somewhat negating the effect of the autohide

This really sounds like a sub-optimal specific workaround for
me. Couldn't this problem be fixed?
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...
Couldn't there just be added two styles - AutoRaise and AutoLower,
which would do that, and just that, and do it simple without
flickering and problems, needing scheduling and the like?

I apologize for this style of critique... FVWM is really great and I
love it, by far the best window manager I know now. I just would
really like to have auto-raise and auto-lower working fine and simple
with FVWM already...

> Dominik ^_^  ^_^

  Thank you, any further help still appreciated,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 6 Jul 2002 03:28:09 +0200

On Sat, Jul 06, 2002 at 01:46:42AM +0300, Tom Alsberg wrote:
> The problem is not only with gv.

> The whole problem of flickering is

Unfortunately, the gv problem I saw had little to do with
flickering.  If other apps have this problem, I need more
examples.

> problems. I don't see exactly why FVWM should grab the pointer for

Because fvwm is executing a complex function.  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*).  Moving the
pointer across the desktop can trigger dozens of enter and leave
events.

> me. Couldn't this problem be fixed?

No.  Complex function = pointer grabbed.  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.

> causing problems with pointer grabbing with gv, I suppose that could

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.

> flickering and problems, needing scheduling and the like?

That would just move the problem into the fvwm core.  CTWM might
also have an auto-raise feature, but I bet it's based on *focus*
changes too and not on the pointer entering or leaving the window.
It's much easier to code, but it doesn't work with ClickToFocus.

Anyway, I think it's possible to modify the lines I posted to
disable and scheduling of commands while the pointer is outside
any of the autoraise/lower windows.  Will take some time.

Bye

Dominik ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Sat, 6 Jul 2002 15:02:01 +0300

Hi there...
Comments below, again:

> flickering.  If other apps have this problem, I need more

Well, there are other examples, like I noted, with GTK+ buttons,
Netscape toolbars, balloon titles in FvwmPager... 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... 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.

> 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?

> 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
> 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? After all, FVWM does a lot of things on
enter and leave, including focus, changing window styles, etc etc.

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...

Also, why a real hack (and *slow*)?

> Moving the pointer across the desktop can trigger dozens of enter
> and leave events.
> 
> > <snip />
> > 
> No.  Complex function = pointer grabbed.

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.

> 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...

> That would just move the problem into the fvwm core.

Why would it? If the problem is that FVWM grabs the pointer in a
complex function, than be it a simple style, and some of it is solved
already...

> CTWM might also have an auto-raise feature, but I bet it's based on
> *focus* changes too and not on the pointer entering or leaving the
> window.

No, actually it is based on the pointer entering and leaving the
window... As I said, that was one thing that CTWM did just well, fine
without problems as I expect it...

> It's much easier to code, but it doesn't work with ClickToFocus.

By the way, what is actually the big difference for that matter
between the mouse entering the window and the window getting focus?
Originally you said that it is a problem with the synchronization
between FVWM and X, so that while FVWM gets the event from X another
window has the pointer in it already... Can't FVWM just check that the
pointer is still in the window it got the event for from X before
applying such a function?

> any of the autoraise/lower windows.  Will take some time.

Well, that will probably help a lot, but still, some of that problem
("flickering", etc.) happens also with windows that are automatically
raised and lowered... So this would still leave some of the
problem...

> Dominik ^_^  ^_^

  Thanks again for the efforts in helping and the reply, I really hope
  that some-when I'll get it working as I expect...

  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 6 Jul 2002 17:40:55 +0200

On Sat, Jul 06, 2002 at 03:02:01PM +0300, Tom Alsberg wrote:
> Netscape toolbars, balloon titles in FvwmPager...

But what *are* the problems?  I'm not a psychic.

> And sometimes
> 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

Uh, but I won't.  I hate auto raising.  I can't use my desktop
with it.  :-)

> 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.

> events in the level of X?

It's roughly the same.

> After all, FVWM does a lot of things on

Yes, but it *does not* restack windows triggered by these events.
That's the one thing that does not work

> 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.

> 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.

> 2001) was to say... That I need a bit more than FvwmAuto can do, at

(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 ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Sun, 7 Jul 2002 14:43:02 +0300

Hi there...
Comments below, again:

> 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.

> Then please try to pin it down.  I have no such problems with the

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...

> Uh, but I won't.  I hate auto raising.  I can't use my desktop

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...

> 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 />

Why should that be the one thing that does not work, though?

> 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)

> event and closes.  It should ignore events triggered by grabs).

Why does the pointer being grabbed cause the window to receive a leave
event?

> 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...

> developers forgot to grab the pointer when that popup window

I got it now... For some reason I had the idea that it was the same
problem, but now I see it...

> 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...

> Dominik ^_^  ^_^

  Thanks very much, again... Some of the problem is already solved...
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 8 Jul 2002 11:03:39 +0200

> (selecting the window) not to grab the pointer...

I've made it as bulletproof as I could, but I found no way to
prevent the gv problem and have the full functionality at the same
time.  At least no reliable way.  You can try either this one:

  FvwmAuto 0 -passid -enter \
                     ^^^^^^
    "Silent selective_raiselower raise" \
    "Silent selective_raiselower lower"

This works fine with gv, but windows are not lowered when the
pointer enters the root window, only when it moves into another
window.  Or you can break out of the function for gv windows
again:

  DestroyFunc selective_raiselower
  AddToFunc selective_raiselower
  + I WindowId $1 (gv) break
  ^^^^^^^^^^^^^^^^^^^^^^^^^^
  + I WindowId $1 (FvwmIconMan) $0
  + I WindowId $1 (FvwmButtons) $0
  + I WindowId $1 (xclock) $0
  + I WindowId $1 (xexec) $0

I'm interested in more feedback about this.

Bye

Dominik ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Tue, 9 Jul 2002 21:15:50 +0300

Hi there.
Comments below, as before:

On Mon, Jul 08, 2002 at 11:03:39AM +0200, Dominik Vogt wrote:
> time.  At least no reliable way.

How about what I suggested - making it a style - if the window has
that style applied, FvwmAuto will automatically raise and lower it,
otherwise it won't? Or maybe make the list of windows to automatically
raise and lower a parameter for FvwmAuto? Is there a problem doing so?
And also, it would be useful to provide some option to disable the
grabbing of the pointer in specific functions.

> You can try either this one:
> 

I suppose you mean -menter here, as in the FvwmAuto manual page I see
no mention of an option named '-enter'...

> pointer enters the root window, only when it moves into another

I do not know what it might be, but here this behaves really weird.
I replaced the '-menterleave' option with '-menter', and do not see
any change. Auto-raised windows are still lowered when the pointer
enters the root window, and the problem with gv isn't solved.

> Or you can break out of the function for gv windows
> again:

I tried that too. Does not make any difference either. The menu still
immediately disappears.

> I'm interested in more feedback about this.

Another weird thing, since updating from CVS a few days ago, FvwmPager
behaves a bit weird. Inactive windows (windows not having the focus)
have a black background, and look rather different than they used to
(they used to have the background color defined in the BackColor
style).

> Dominik ^_^  ^_^

  Thank you, any further help appreciated,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Jul 2002 00:12:25 +0200

> grabbing of the pointer in specific functions.

It's like taking a sledgehammer to crack a nut.  All this
additional code just because of *one* buggy application?  Complex
functions already provide a far better solution.

> no mention of an option named '-enter'...

Yes.

> enters the root window, and the problem with gv isn't solved.

Right.  The hack I made to inform FvwmAuto of the pointer entering
the root window was too aggressive.  I've modified it a bit and it
should now cooperate nicely with gv.

> I tried that too. Does not make any difference either. The menu still

It depends on timing.  It was worth a try.

> (they used to have the background color defined in the BackColor

Please update to the latest cvs.  I've been working on the pager
drawing code.

Bye

Dominik ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Wed, 10 Jul 2002 22:22:33 +0300

Hi there.
Comments below, again:

On Wed, Jul 10, 2002 at 12:12:25AM +0200, Dominik Vogt wrote:
> additional code just because of *one* buggy application?

Well, I suppose this isn't the only buggy application.
Is it that much code to add for that?

> Complex functions already provide a far better solution.

Yeah, I suppose... But they don't provide a solution for what I need
here, yet...

> should now cooperate nicely with gv.

Cool... This seems to cooperate nicely with gv now, working just the
way I like it... This still does lower auto-raised windows when the
pointer leaves them for the root window though, but that's actually
what I want... So when that is fixed, I will want something to have
the current behavior again.

> It depends on timing.  It was worth a try.

Well, in my case, I use FVWM on more than one machine, quite many,
actually, in some different sites, so timing can vary...

> Please update to the latest cvs.  I've been working on the pager

I updated from CVS now, but it is still the same problem...

> Dominik ^_^  ^_^

  Thank you very much... I'm advancing (with lots of help from you and
the FVWM team) somewhat here...

  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Jul 2002 22:37:41 +0200

> Is it that much code to add for that?

Yes.  First a new style, the code to update windows on style
changes, next we would probably add options to conditional
commands, then someone will want to use the style in the
WindowList and some of the modules, and so on.  Just look at the
flood of options to the conditinal commands compared with the
options of the WindowList command and you know what I mean.  Such
things tend to grow without limits.

> Yeah, I suppose... But they don't provide a solution for what I need

That may be so.  I'm readily willing to enhance the feature set of
complex function, conditional commands and the like.  This way,
*all* the modules and the fvwm core benefit, not just one feeble
module.  For example, take the PointerWindow command.  Before I
added it, there was no way to run functions on the window below
the pointer.  Today it's one of the most important conditional
commands in my config.  Without it, we could only dream of the
autoraise functionality based on enter/leave events.  But with it
plus the new ENTER/LEAVE packets, implementing autoraising reduced
to a couple of code lines.  That's the way I like new features:
small, doing a single task well, very flexible.  Much better than
ten new module options.

> the current behavior again.

You're pulling my leg, right? ;-)

> I updated from CVS now, but it is still the same problem...

Hm, you're probably running an old version of the module against
a newer fvwm.  Similar things often happen to me when module and
fvwm version don't match.  Are you sure FvwmPager got installed
correctly?

> the FVWM team) somewhat here...

Discussions of this kind are one of the best ways to find out what
we really need in fvwm.  I wish everyone had the patience and
endurance to continue them to a satisfying end.  I appreciate your
a lot.  Not only could we find a nice solution, but also came up
with a valuable addition to the FAQ and perhaps even fvwm-theme.

Bye

Dominik ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Thu, 11 Jul 2002 21:17:41 +0300

Hi there...
Comments below:

> things tend to grow without limits.

Oh... Well... Sounds logical...

> module.

That's true...

> For example, take the PointerWindow command.  Before I added it,
> there was no way to run functions on the window below the pointer.
> Today it's one of the most important conditional commands in my
> config.  Without it, we could only dream of the autoraise
> functionality based on enter/leave events.  But with it plus the new
> ENTER/LEAVE packets, implementing autoraising reduced to a couple of
> code lines.  That's the way I like new features: small, doing a
> single task well, very flexible.  Much better than ten new module
> options.

Also true...

> You're pulling my leg, right? ;-)

Well, what do you mean - pulling your leg?

I am just saying, that now with -menter, it works the way I want it,
but that isn't exactly the way it should work, as documented in the
manual page.
So I suppose some-when it will be 'fixed', to its intended behavior -
not lowering windows when the pointer leaves them for the root
window. But that is not what I want (I want those windows lowered when
the pointer leaves the root window too).
So unless something else is changed then, like the behavior with the
-menterleave option to workaround/fix the problem with gv and grabbing
the pointer, I will not have it the way I want, which is right now so
because -menter behaves a bit different than what's documented...

> fvwm version don't match.  Are you sure FvwmPager got installed

Well, I'm pretty sure... I listed the running processes after
restarting FVWM, and the FvwmPager which is running is the one
installed by the last make install (checked)...
Also now I tried building from scratch, removing any previous
installation I had locally, and installing of clean, being sure that
there wasn't any FvwmPager left somewhere before, it still looks that
way.

Doesn't it happen for you? I checked, and even with the default
configuration (running as 'fvwm -f no-rc'), and nothing done except
popping up a pager, it looks different...

> endurance to continue them to a satisfying end.

Well, I want both to have my working environment convenient for me,
and FVWM to keep being the best window manager overall - my window
manager of choice - and keep getting better. It's already great, but
it can get yet even better, and there are always possibilities for
improvement.

> I appreciate your a lot.  Not only could we find a nice solution,
> but also came up with a valuable addition to the FAQ

I should (will now) look at the FAQ again and see what has changed /
been added (except for what I see when looking at the ChangeLog
files)...

> and perhaps even fvwm-theme.

I never yet took the chance to look at fvwm-theme... I will some-when
check it out and see better what it is about...

> Dominik ^_^  ^_^

  Thanks again,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 12 Jul 2002 02:45:58 +0200

> Well, what do you mean - pulling your leg?

Pulling somebody's leg means roughly to mislead someone for fun.

> but that isn't exactly the way it should work, as documented in the

The man page is correct, but I did not mention that moving the
pointer from any window into the root window now generates an
ENTER_WINDOW packet too.  FvwmEvents needs a notice about this
behaviour too.

[snip]

> because -menter behaves a bit different than what's documented...

Er, first you say that "it works the way I want it" and a few
lines further down "So unless ... I will not have it the way I
want"?  So is the behaviour of -menter what you want or isn't it?
Automatic lowering when entering the root window can be disabled
by checking if the passed id is that of a real window or not (in
other words:  in the called functions without any changes to
FvwmAuto).

> popping up a pager, it looks different...

Hm, default configuration.  All my modules use colour sets.  That
effectively hides any windows with BackColor.  Can you give an
exact date for "a few days back"?  Originally I thought this meant
before the FvwmPager fixes I made, but I'm not so sure anymore.

> > Not only could we find a nice solution,

Nothing yet.  I'll do that later.

Bye

Dominik ^_^  ^_^

---

From: "Rob 'Feztaa' Park" <[email-masked]>
Date: Thu, 11 Jul 2002 21:02:55 -0600

> other words:  in the called functions without any changes to

My interpretation is that he is satisfied with the current behaviour,
but believes that the documentation is not consistent with the behaviour
(whether or not this is true I have no idea), and is afraid that you
will change the behaviour to match the documentation, at which point it
will no longer behave the way he likes it. And when you "fix" it (to
match the documentation), he wants you to add an option to let him
change back to the current behavior.

But I could be wrong.

-- 
Rob 'Feztaa' Park
http://members.shaw.ca/feztaa/
--
Who are you?

---

From: "Rob 'Feztaa' Park" <[email-masked]>
Date: Thu, 11 Jul 2002 20:44:57 -0600

I'm sorry, I joined this discussion late, and probably missed a bunch of
stuff.

What are you trying to accomplish, exactly? You want some windows to
autoraise, but others not?

Does setting some windows to "StaysOnBottom" while just using FvwmAuto
module not work? ;)

-- 
Rob 'Feztaa' Park
http://members.shaw.ca/feztaa/
--
The profession of book writing makes horse racing seem like a solid,
stable business.
		-- John Steinbeck
	[Horse racing *is* a stable business ...]
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Tom Alsberg <[email-masked]>
Date: Fri, 12 Jul 2002 12:31:44 +0300

Hi, again, comments below, again:

> Pulling somebody's leg means roughly to mislead someone for fun.

Oh... You'll have to forgive me, I'm not a native english speaker, so
I didn't understand exactly the relation with the context until now.

> ENTER_WINDOW packet too.

So doesn't this mean that now every leave event is accompanied by an
enter event? What is the difference now, between using the -menter
option and the -menterleave option?

> FvwmEvents needs a notice about this behaviour too.
> 
> [snip]
>
> <snip />
>

Well, it works the way I want it, now. But that seems to be not
exactly the way it should work, according to the documentation /
manual page.
So when/if it will be changed, to work the way it should work, then it
won't work the way I want it, and I will be unhappy again... :-)

Or, to say it otherwise, what makes me happy now, probably should not
be that way...

The behaviour of -menter is what I want, because it seems to be the
same as the behaviour of -menterleave, only without the problem with
gv and grabbing the pointer...

On the other hand, now that you say that the pointer leaving a window
for the root window also generates an enter event for the root window,
that might be the appropriate behaviour... But then what is the
difference between the -menter option and the -menterleave option?

> exact date for "a few days back"?

"A few days back" is here since the 6th of July, to the 11th of
July... In those times, FVWM updated from CVS head (I updated about
twice a day) had that problem with FvwmPager.
On the other hand, FVWM updated from CVS a half an a hour ago (12th of
July, 2002, 12:10 AM GMT+03), seems to have fixed this...

> Originally I thought this meant before the FvwmPager fixes I made,
> but I'm not so sure anymore.

Well, back when you said you updated a lot of the FvwmPager drawing
code, some time after that it wasn't fixed yet. But apparently there
were some FvwmPager fixes today/yesterday too, and those seemed to
have fixed it...

> Nothing yet.  I'll do that later.

Oh... well, I'll check it out once in a while...

> Dominik ^_^  ^_^

  Thanks, best regards,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 12 Jul 2002 12:42:40 +0200

On Fri, Jul 12, 2002 at 12:31:44PM +0300, Tom Alsberg wrote:
> Oh... You'll have to forgive me, I'm not a native english speaker,

Neither am I, but I have a new dictionary and enjoy looking up
phrases I'd use in German :-)

> so I didn't understand exactly the relation with the context until now.
> 
> enter event?

That would be the ideal solution, but I'm not convinced this is
the case at the moment.  Handling of the corresponding X events is
very complicated.  There may still be situations where an enter or
leave event is sent without the other.

> What is the difference now, between using the -menter

With -menter FvwmAuto only handles enter events.  The LeaveCommand
is triggered for the previous window when an enter event arrives.
With -menterleave only leave events trigger the LeaveCommand.  As
long as these events arrive in pairs, -menterleave is just a waste
of resources.

> won't work the way I want it, and I will be unhappy again... :-)

Don't worry.  I've already changed the documentation to reflect
the current behaviour.

> gv and grabbing the pointer...

Yes.  But it is only the same because we specifically wrote the
function this way.  It's not an inherent feature of FvwmAuto.
There may still be situations where you might want to treat enter
and leave events separately.  If we did not want the raise-when-
root-window-entered behaviour, we could just change the function
to ignore this case.  No code in the module needs to be touched.

> difference between the -menter option and the -menterleave option?

See explanation above.

> were some FvwmPager fixes today/yesterday too, and those seemed to

I found the bug.  FvwmPager was accessing the wrong information
from the packet informing it of the new window.  That happened
because the size of a variable in the packet changed and the pager
accessed the data by byte offsets in the structure :P

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 12 Jul 2002 10:44:13 +0000

> Does setting some windows to "StaysOnBottom" while just using FvwmAuto

1) Marking a window StaysOnBottom just so it will not be auto raised is
bad, it should be raised, just not automatically.

2) FvwmAuto in all versions except for the current cvs works on focused
windows only.

This means that FvwmAuto does not work on NeverFocus or ClickToFocus
windows (most of persistent modules like FvwmButtons, FvwmPager,
FvwmTaskBar, FvwmIconMan and so on are best when marked NeverFocus).

In the latest snapshot, FvwmAuto may work on a enter-leave basis, not
on a new focus basis, this solves a problem of autoraising NeverFocus
or ClickToFocus windows.

Regards,
Mikhael.