Subject: FVWM: Ideas for focusing

From: Tim Phipps <[email-masked]>
Date: Thu, 21 Nov 1996 16:49:43 GMT

Now that the furore surrounding modal dialogs has died down I would like to ask 
a few questions and maybe make some suggestions for focus handling.  I really 
like sloppy focus but some applications I use insist on popping up dialogs. 
These applications work better with clicktofocus but turning it on for 
particular apps is not something I want to do.

Questions:
1) If a module requests to be informed of every window creation what information 
gets passed?
2) Is transient_for status available to modules?
3) Is modality status available to modules?
4) If newly created/mapped windows got the focus but sloppyfocus was active 
would that quell the complaints of the modality-is-important brigade?

What I'm thinking of is that maybe a module could be written that moves the 
focus to newly created windows.  I'm pretty sure that it's doable and it would 
make applications that pop up dialogs easier to use.

Just focusing on new windows might be too simple so a further refinement may be 
to only switch focus if the new window is a transient_for the currently focused 
window.  E.g. you have an application performing a task and you move to another 
apps window, if the first app pops up a window the focus would not switch.  This 
would be my option but I don't know if the module protocol would be able to pass 
enough information.

Real modality might be supportable with a module if modality info could be 
passed to modules.  On every focus event a check of the windowlist could be done 
to see if any transient_for windows have modality on, if one does the focus 
could be switched.  This would allow modality in a sloppyfocus environment.

Any comments
Tim Phipps.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Allen Brady Montz <[email-masked]>
Date: 21 Nov 1996 10:42:52 -0700

Tim Phipps <[email-masked]> writes:

...
> focus to newly created windows.  I'm pretty sure that it's doable and it
> would make applications that pop up dialogs easier to use.
> 
> Just focusing on new windows might be too simple so a further refinement may
> be to only switch focus if the new window is a transient_for the currently
> focused window.  E.g. you have an application performing a task and you move
> to another apps window, if the first app pops up a window the focus would
> not switch.  This would be my option but I don't know if the module protocol
> would be able to pass enough information.
> 
> passed to modules.  On every focus event a check of the windowlist could be
> done to see if any transient_for windows have modality on, if one does the
> focus could be switched.  This would allow modality in a sloppyfocus
> environment.
> 
> Any comments Tim Phipps.

Sounds like a good idea. 

A while back I asked about whether others like this idea I had for a general
module that would basically keep an eye on what fvwm does for the purpose of
keeping lots of state about windows (so for exmaple you could keep a stack of
sizes that a window has had so you maximize a window horizonatally, maximize
vertically, and then be able to get back to it's original size). Then Barry
Warsaw (hope I spelled that right) and others pointed out that python is the
way to go here, and I agreed, and then I haven't done anything with it since
(damn grad school). 

But I've been thinking about it since. Basically it would be a module (could
be writting in python or C) and you could send python code to it (or have it
read the code from a startup file) along the lines of: when you see fvwm event
X, run python code Y. Where the fvwm event could be something like NewWindow,
or a command that fvwm sent to the module via SentToModule (which lets you
send an arbitrary string to a module). 

If we had such a module, it would be trivial to do what you want.

I think that I'll get cracking on it now. There already is a python "module"
out there, but it's pretty minimal. I think it's basically a Class that
interfaces python code to fvwm. Does anybody have more information?

-- 
 Brady Montz
 [email-masked]

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Thu, 21 Nov 1996 14:34:25 -0500

>>>>> "ABM" == Allen Brady Montz <[email-masked]> writes:

    ABM> Then Barry Warsaw (hope I spelled that right)

You did!

    ABM> But I've been thinking about it since. Basically it would be
    ABM> a module (could be writting in python or C) and you could
    ABM> send python code to it (or have it read the code from a
    ABM> startup file) along the lines of: when you see fvwm event X,
    ABM> run python code Y. Where the fvwm event could be something
    ABM> like NewWindow, or a command that fvwm sent to the module via
    ABM> SentToModule (which lets you send an arbitrary string to a
    ABM> module).

    ABM> If we had such a module, it would be trivial to do what you
    ABM> want.

    ABM> I think that I'll get cracking on it now. There already is a
    ABM> python "module" out there, but it's pretty minimal. I think
    ABM> it's basically a Class that interfaces python code to
    ABM> fvwm. Does anybody have more information?

I think the next version of my Fvwm.py module could easily support
something like this.  I have a module called Tracker.py to which you
can pass any packet object received from Fvwm (the Python module
transforms each message packet into an object).  The tracker then
sucks out relevent information from these packet objects and maintains
a database of the desktop and window states.

I'm very nearly ready for the next release, but have just been too
busy at work to finish things up.  I really hope to have it ready
RSN.  If you're really anxious to have a look, let me know because I
could probably send you something to peek at, even if it's not
quuuuiiiite ready for a more general release.

-Barry