Subject: FVWM: Changes from .42 to .43 (WarpToWindow?!?)

From: [email-masked]
Date: Tue, 06 Aug 1996 10:28:43 -0400 (EDT)

Hello all, 
	Does anyone know what happen from .42 to .43 when you, I believe, 
warp to a window, that the cursor does not goto the upper left hand coner 
of the selected window.  
	For example, I select a window from winlist.  Under .42 it would 
warp to that window and the cursor would be in the upper left hand 
corner.  Now under .43 the window is focused, but the cursor is not in 
the ULHC.  What happened.  The Changelog only talks about WarpToWindow, 
What am I lacking?
					Thanks,
					Jason
--
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: Kai Grossjohann <[email-masked]>
Date: 06 Aug 1996 18:02:30 +0200

>>>>> jason howk writes:

  Jason> 	Does anyone know what happen from .42 to .43 when you,
  Jason> I believe, warp to a window, that the cursor does not goto
  Jason> the upper left hand coner of the selected window.

The Focus function has been split in two.

Old behavior:
  Focus warps the mouse pointer into the window and gives the window
  focus.

New behavior:
  Focus gives the window focus, WarpToWindow warps the mouse pointer
  into the window (without giving focus -- but there may be a side
  effect with MouseFocus).

hth,
kai
-- 
What's a signature?

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Tue, 6 Aug 1996 13:04:42 -0400

>>>>> "KG" == Kai Grossjohann
>>>>> <[email-masked]> writes:

    KG> New behavior: Focus gives the window focus, WarpToWindow warps
    KG> the mouse pointer into the window (without giving focus -- but
    KG> there may be a side effect with MouseFocus).

There's a side affect with Focus now too.  At least I see that using
WindowList to select another window does indeed move the focus to
it... temporarily.  It quickly reverts to the window with the cursor.
Drag.

-Barry

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 6 Aug 1996 15:42:00 -0400

>>>>> "BAW" == Barry A Warsaw <[email-masked]> writes:

BAW> There's a side affect with Focus now too.  At least I see that using
BAW> WindowList to select another window does indeed move the focus to
BAW> it... temporarily.  It quickly reverts to the window with the cursor.
BAW> Drag.

Damn.

Ok, this can be fixed, but we now have another problem - how to do it
and keep everyone happy.

Currently The built in window list has hard coded call to 'Raise_it'
(a built in function especially for the built in winlist it seems)
when it builds the menu.

I think I should make it call something like WinListFunc instead, and
make that be an interpreted function (with a default built up inside
of fvwm that just calls Focus and uniconifies if necessary).  That way
WinListFunc could be added to or destroyed and recreated just like any
other interpreted function, and if people need or want the warp in
there (or would rather have the winlist execute a FvwmIdent or
something else) that could be added.

Does this solution sound acceptable to everyone?  It might be
overkill, but I'd hate to just put an explicit warp in there and have
lots of people yell about it again.

Chuck

---

From: Kai Grossjohann <[email-masked]>
Date: 07 Aug 1996 08:53:57 +0200

>>>>> Charles Hines writes:

  Charles> Does this solution sound acceptable to everyone?

Yes, I say do it.  Good idea!

kai

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Fri, 9 Aug 1996 17:49:45 -0400

Me> There's a side affect with Focus now too.  At least I see that
    Me> using WindowList to select another window does indeed move the
    Me> focus to it... temporarily.  It quickly reverts to the window
    Me> with the cursor. Drag.

    Chuck> I think I should make it call something like WinListFunc
    Chuck> instead, and make that be an interpreted function (with a
    Chuck> default built up inside of fvwm that just calls Focus and
    Chuck> uniconifies if necessary).  That way WinListFunc could be
    Chuck> added to or destroyed and recreated just like any other
    Chuck> interpreted function, and if people need or want the warp
    Chuck> in there (or would rather have the winlist execute a
    Chuck> FvwmIdent or something else) that could be added.

Sounds like that would be very cool.  I'd like more control over what
happens when I select a window in the window list so this would kill
two birds with one stone.

-Barry

---

From: [email-masked] (Albrecht Kadlec)
Date: Tue, 13 Aug 96 08:46:53 +0200

>>>>> B = Barry A Warsaw writes:
>>>>> Chuck can only be Chuck Hines
>>>>> Me = ????? (lost in time & space & archive) Kai Grossjohann ???

B> Sounds like that would be very cool.  I'd like more control over what
B> happens when I select a window in the window list so this would kill
B> two birds with one stone.

how about giving a function name as an argument to FvwmWinlist.
This Function would then be called with the selected window.

One could then use FvwmWinList as a generic Selection mechanism for any
kind of operation (focus as well as close, kill, ...)

albrecht
-- 
So I open my door to my enemies
And I ask could we wipe the slate clean
But they tell me to please go fuck myself
You know you just can't win	-- Pink Floyd
--
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: Jason L Tibbitts III <[email-masked]>
Date: 13 Aug 1996 02:49:03 -0500

>>>>> "A" == Albrecht Kadlec <[email-masked]> writes:

A> how about giving a function name as an argument to FvwmWinlist.  This
A> Function would then be called with the selected window.

A> One could then use FvwmWinList as a generic Selection mechanism for any
A> kind of operation (focus as well as close, kill, ...)

You know, that's a really neat idea.  Kind of makes me wish that I'd
thought of it.  You could do any window selection this way.

 - J<

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Tue, 13 Aug 1996 11:41:00 -0400

A> how about giving a function name as an argument to
    A> FvwmWinlist. This Function would then be called with the
    A> selected window.

Very cool idea!

---

From: Brady Montz <[email-masked]>
Date: 13 Aug 1996 10:38:31 -0700

> kind of operation (focus as well as close, kill, ...)

First off, I think that this discussion has migrated from talking about
the builtin WindowList, to the module FvwmWinList. They are two
different things.  If people confuse them, it causes confusion to
spread. If I'm confused, then hopefully my confusion will be contained
here.

Before hacking on FvwmWinList for all of this, I'd like to suggest that
interested people check out the latest release of FvwmIconMan
(ftp://mahler.cs.arizona.edu/pub/FvwmIconMan/FvwmIconMan-0.7.tar.gz, and
in the next fvwm2 release whenever that happens) I've added the ability
to run transiently with this in mind. If you like it, cool. If you
don't, then you've made your job slightly easier by trying and
discarding one possible way to do things (I also wouldn't mind
constructive criticism).

Just so people know, I don't have anything against FvwmWinList. While
similar, the two programs are very different, and while I like the
differences in FvwmIconMan's favor, others may (and surely will) not. If
niftiness gets added to FvwmWinList, then you can be sure I'll be
watching with curiosity how it gets done, and will freely admit to
copying it. But, in this case, I think that you might look towards what
I've been doing. Making a program more configurable is always a slippery
slope, since once you open the door to new features, it sparks ideas for
ways to make them more general, logical, powerful, etc. FvwmWinList will
be no different, and since I've been sliding down that slope for some
time, it would make sense to check out any mistakes I've made. For
example, when adding the ability to bind arbitrary functions to the
selection of a window in FvwmWinList, the logical next step is to want
to be able to bind various functions to various types of events, and
then you may want functions that modify the state of the window list,
and then keeping control over the syntax starts taking some mental
effort.

I think that adding a functional parameter to WindowList makes good
sense though, but I think that extending it much further would lead to
the duplication of work in two other modules, and would violate the
basic priciple of modularity in fvwm.

Here's how I see the world of window lists in fvwm:

WindowList: small, guaranteed to work, lightweight, requires minimal
            amount of thought from Chuck Hines. 
FvwmWinList: more heavyweight. Mainly useful as a transient module.
FvwmIconMan: highly configurable. No point in using it if you're just 
             going to configure it to act like WindowList of
             FvwmWinList. Until now only usable as a long running
             module, but now can run transiently. On my machine at
             least, it seems to start up faster than FvwmWinList, but
             I wouldn't expect that to be universal.

-- 
 Brady Montz
 [email-masked]