Subject: FVWM: Move windows in place between desktops/screens

From: "N. Dan Zou" <[email-masked]>
Date: Fri, 1 Mar 1996 11:10:02 -0800 (PST)

I've been on this list for a while, but it wasn't until recently that I 
had a chance to browse through the menu and explore some of the 
capabilities of fvwm.  Before fvwm I've been using ctwm for a long time 
(still missing some of its features, but I'll make a separate message
for that).  One capability in ctwm that I haven't found (at least no
mention of it in the menu) is the ability to move a window "in place"
from one desktop/screen to another.  By this I mean the window will snap
to the same position it had in the previous desktop/screen.  Because
using the pager I often place the window in unsatisfactory places (off
screen, to the side, etc.).  If this feature already exists I'm sorry
for taking up your time.

P.S. Chuck, there's no section for the Pager command in the menu, could
you add one for the next release?  I agree that for a general public
release it's as important to keep the doc uptodate as new features, new
features won't be too useful if people don't know they exist.

--
N. Dan Zou                           650 Castro Street, Suite 270
Systems Engineer                     Mountain View, California 94041
Stanford Management Group, Inc.      Phone: +1 (415) 903-9591
#include <std/disclaimer.h>          Fax:   +1 (415) 903-9378

--
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: "Bob Mende Pie" <[email-masked]>
Date: Fri, 1 Mar 1996 11:46:35 -0800

On Mar 1, 11:10am, N. Dan Zou wrote:
> Subject: FVWM: Move windows in place between desktops/screens

I do this ... I have my desktop setup as a 3x3 grid, and use Alt-KP_[1-9] to
move between pages.  I use Alt-Ctrl-KP_[1-9] to move windows with me...  Here
are the macros that I use...

Key KP_0	A	M	GotoPageDesk 0 0 0		# 0
Key KP_1	A	M	GotoPage 0 2			# 1
Key KP_2	A	M	GotoPage 1 2			# 2
Key KP_3	A	M	GotoPage 2 2			# 3
Key KP_4	A	M	GotoPage 0 1			# 4
Key KP_5	A	M	GotoPage 1 1			# 5
Key KP_6	A	M	GotoPage 2 1			# 6
Key KP_7	A	M	GotoPage 0 0			# 7
Key KP_8	A	M	GotoPage 1 0			# 8
Key KP_9	A	M	GotoPage 2 0			# 9

Key KP_0	WTSF	CM	StickPageDesk 0 0 0		# 0
Key KP_1	WTSF	CM	StickPage 0 2			# 1
Key KP_2	WTSF	CM	StickPage 1 2			# 2
Key KP_3	WTSF	CM	StickPage 2 2			# 3
Key KP_4	WTSF	CM	StickPage 0 1			# 4
Key KP_5	WTSF	CM	StickPage 1 1			# 5
Key KP_6	WTSF	CM	StickPage 2 1			# 6
Key KP_7	WTSF	CM	StickPage 0 0			# 7
Key KP_8	WTSF	CM	StickPage 1 0			# 8
Key KP_9	WTSF	CM	StickPage 2 0			# 9

Key KP_0	A	SM	Desk 0 0			# 0
Key KP_1	A	SM	Desk 0 1			# 1
Key KP_2	A	SM	Desk 0 2			# 2
Key KP_3	A	SM	Desk 0 3			# 3
Key KP_4	A	SM	Desk 0 4			# 4
Key KP_5	A	SM	Desk 0 5			# 5
Key KP_6	A	SM	Desk 0 6			# 6
Key KP_7	A	SM	Desk 0 7			# 7
Key KP_8	A	SM	Desk 0 8			# 8
Key KP_9	A	SM	Desk 0 9			# 9

Key KP_0	WTSF	CSM	StickDesk 0			# 0
Key KP_1	WTSF	CSM	StickDesk 1			# 1
Key KP_2	WTSF	CSM	StickDesk 2			# 2
Key KP_3	WTSF	CSM	StickDesk 3			# 3
Key KP_4	WTSF	CSM	StickDesk 4			# 4
Key KP_5	WTSF	CSM	StickDesk 5			# 5
Key KP_6	WTSF	CSM	StickDesk 6			# 6
Key KP_7	WTSF	CSM	StickDesk 7			# 7
Key KP_8	WTSF	CSM	StickDesk 8			# 8
Key KP_9	WTSF	CSM	StickDesk 9			# 9

AddToFunc GotoPageDesk		"I" Desk 0 $2
+				"I" GotoPage $0 $1

AddToFunc StickDesk		"I" Stick
+				"I" Desk 0 $0
+				"I" Stick

AddToFunc StickPage		"I" Stick
+				"I" GotoPage $0 $1
+				"I" Stick

AddToFunc StickPageDesk		"I" Stick
+				"I" GotoPageDesk $0 $1 $2
+				"I" Stick

-- 
				      /Bob...			 [email-masked]
				http://reality.sgi.com/mende/

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 1 Mar 1996 15:54:44 -0500

>>>>> "NDZ" == N Dan Zou <[email-masked]> writes:

NDZ> I've been on this list for a while, but it wasn't until recently
NDZ> that I had a chance to browse through the menu and explore some
NDZ> of the capabilities of fvwm.  Before fvwm I've been using ctwm
NDZ> for a long time (still missing some of its features, but I'll
NDZ> make a separate message for that).  One capability in ctwm that I
NDZ> haven't found (at least no mention of it in the menu) is the
NDZ> ability to move a window "in place" from one desktop/screen to
NDZ> another.  By this I mean the window will snap to the same
NDZ> position it had in the previous desktop/screen.  Because using
NDZ> the pager I often place the window in unsatisfactory places (off
NDZ> screen, to the side, etc.).  If this feature already exists I'm
NDZ> sorry for taking up your time.

If you make the window Sticky, it will stay in place as you switch
pages or desks, then you make it UnSticky again, and it will stay
there.  And the function WindowsDesk will move the window to a new
desktop directly.

NDZ> P.S. Chuck, there's no section for the Pager command in the menu,
NDZ> could you add one for the next release?  I agree that for a
NDZ> general public release it's as important to keep the doc uptodate
NDZ> as new features, new features won't be too useful if people don't
NDZ> know they exist.

I'm not sure what you mean there.  The sample rc file included
certainly does need beefing up (I plan to do that for the next release
as yet another prelude to officially releasing it) but it does
currently reference the pager in several places:

----------------------------------------------------------------------

Style "Fvwm Pager"  StaysOnTop
Style "FvwmPager"   StaysOnTop

....

AddToMenu Module-Popup  "Modules"       Title
+                       "Button-Bar"    Module  FvwmButtons
+                       "Clean-Up"      Module  FvwmClean
+                       "Identify"      Module  FvwmIdent
+                       "SaveDesktop"   Module  FvwmSave
+                       "Debug"         Module  FvwmDebug
+                       "Pager"         Module  FvwmPager 0 1
+                       "WinList"       Module  FvwmWinList
+                       "Background"    Module  FvwmBacker
+                       "IconBox"       Module  FvwmIconBox
+                       "Banner"        Module  FvwmBanner
+                       "Talk"          Module  FvwmTalk
+                       "Prompt"        Module  FvwmPrompt "hello" raise

....

*FvwmButtons(4x1) - whatever Swallow "FvwmPager" Module FvwmPager 0 3

....

########################### Pager #########################################
*FvwmPagerBack #908090
*FvwmPagerFore #484048
*FvwmPagerFont -adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*
*FvwmPagerHilight #cab3ca
*FvwmPagerGeometry -1-1
*FvwmPagerLabel 0 Misc
*FvwmPagerLabel 1 Maker
*FvwmPagerLabel 2 Mail
*FvwmPagerLabel 3 Matlab
*FvwmPagerSmallFont 5x8

----------------------------------------------------------------------

Chuck

---

From: "N. Dan Zou" <[email-masked]>
Date: Tue, 5 Mar 1996 16:14:34 -0800 (PST)

> >>>>> "NDZ" == N Dan Zou <[email-masked]> writes:
[...]
> there.  And the function WindowsDesk will move the window to a new

Thanks to Bob and Chuck for the helpful hints.  Actually I was aware of
the WindowDesk function to move windows around.  But I was hoping to
achieve the desired effect by dragging the window in the pager, so I
guess my original request was directly more at the pager rather than
fvwm itself.  The ability to move windows in place would be a nice
addition to the pager, if I knew more about Xlib hacking I'd probably 
take a stab at it myself, but alas, I'm still at the Hello World stage
with even Xt/Motif, so it's probably going to be a while (like in the
next century) before I can produce something up to the usual high-
quality of fvwm.  But I still want to throw out these ideas, maybe 
someone will find them interesting enough to hack on:

1) define a *FvwmPagerMoveWindowInPlace option that will take the
options none, screen, desktop, none means the window will not snap to
the same location when dragged to a new screen/desktop, this should be
the default for compatibility.  The screen and desktop option can be
specified independently or in combination to cause windows to snap to
the same location when dragged to a different screen/desktop.

2) along with the above option we should probably specify a modifier key
to toggle the move behavior dynamically, if the old behavior is the
default then maybe we can define shift-button1 to move windows in place.
(This is the strategy used in ctwm, BTW)

3) another feature I'd like to see in the pager would be using pixmaps
as pager backgrounds, say *FvwmPagerPixmap 0 background1.xpm to put a
pixmap in the background of desktop 0, and so.  Maybe combine this with
*FvwmPagerLabel and merge into a *FvwmPagerStyle option that lets you
specify different style options for desktops.

4) the miniature windows in the pager can be drawn with 3D borders to
make them look nicer.

5) draw the individual desktop/screen as push-buttons like CDE (I think
this is already mentioned in the TO-DO list).

All of the above ideas come from my experience with ctwm, sorry to keep
bring it up, but it's my only frame of reference.  I certainly don't
want fvwm to try to emulate every feature and bahavior of other window
managers, but we can take the good parts from other systems to make fvwm
even better.  In keeping with the Unix/freeware philosophy, if you want
something done, do it yourself.  So I plan to make these my projects,
unless someone gets to them before I do, in which case I would be even
happier.

> NDZ> P.S. Chuck, there's no section for the Pager command in the menu,
[...]
> currently reference the pager in several places:

Sorry for that confusing comment, I was referring to the internal pager
in fvwm 1.xx which is gone in 2.xx, I've since upgraded to 2.0.41 and
read the man pages on the pager.  My above suggestions still apply.  I
don't think the pager module change that much going from 1.xx to 2.xx.

I'm experiencing a few quicks in 2.0.41 but I'll send out a separate
message for that, this one is getting long.

	Regards,

---

From: Robert Tarrall <[email-masked]>
Date: Wed, 06 Mar 1996 19:24:15 -0700

"N. Dan Zou" wrote:
-> Some other problems I'm currently having with 2.0.41:
-> 
-> 1) clicking on a window in the pager will no longer raise the
-> corresponding window on the screen.

Works for me.  Middle mouse button raises the corresponding window
and gives it the focus, left and right buttons move left/right in
the pager.  Maybe this is a configuration issue?  I don't think I
have anything unusual regarding the pager in my .fvwm2rc.

-> 4) if the CapsLock key is on then you can not click inside a window to
-> raise it.

The mouse button has a different state when Caps Lock is on.  Change
the "modifiers" entry on whichever mouse binding this is to "A" for
"Any" and that should make CapsLock+Button1 work.  It will also of
course bind Control+Button1 and Shift+Button1...

-> Agreed, fvwm has a lot of potential, but it still has some rough edges.
-> I hope we can smooth out those rough edges before a public release.

Hmmm... seems a heck of a lot smoother than most "fully released"
window managers I've used (olwm, twm, 4Dwm, and their virtual-screen
brethren).  I think at this point the main problem is getting all
the features fully explained to the users... :-)

			-Robert Tarrall.-
			Unix System/Network Admin
			Laboratory for Computational Dynamics
			CU - Boulder
--
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: "N. Dan Zou" <[email-masked]>
Date: Wed, 6 Mar 1996 20:40:40 -0800 (PST)

> have anything unusual regarding the pager in my .fvwm2rc.

Ah, so that's it.  I was used to the behavior in 1.xx where button 1
raises while button 2 moves.

> course bind Control+Button1 and Shift+Button1...

This is a non-optimum solution so me.  If I had this binding in my
.fvwm2rc:

Mouse 1		W	A	Raise

Then control-button1, shift-button1, and meta-button1 becomes
unavailable to me.  I think it's better to change fvwm so that it raises
the window whether the caps lock key is set or not, or maybe add a new
modifier context L that's in effect when the caps lock is set?  Hmm,
that may not be a bad idea, all the other modifier keys shift, control,
meta, mod1 through mod5 are recognized, why not caps lock?

Another question, does the A (any) context include the context N
(none)?  Seems like it does.

> the features fully explained to the users... :-)

I come from a background of ctwm, which I think is the second best
window manager next to fvwm, fvwm definitely looks nicer, which is
the main reason I switched.  But ctwm is better in some areas, icon 
placement for one.  It also has loads of options (a lot of which you
don't need, like cute line warping effects, animation on the title bar,
etc.)  With fvwm's active development scene, I have no doubt that fvwm
will soon surpass most window managers in all areas.  I didn't want to
sound unappreciative of the work people have done.  In fact, I think Rob
and Chuck have done a marvelous job, I just like to see it improved even
more. ;-)  I browsed through the TO-DO list, a lot of cool ideas, but
the one that caught my eyes was the idea to iconify windows down to
their title bars, that would be extremely cool to have.

---

From: Robert Tarrall <[email-masked]>
Date: Wed, 06 Mar 1996 22:42:00 -0700

"N. Dan Zou" wrote:
-> modifier context L that's in effect when the caps lock is set?  Hmm,
-> that may not be a bad idea, all the other modifier keys shift, control,
-> meta, mod1 through mod5 are recognized, why not caps lock?

And CapsLock + Shift, Control, etc as well? :-)

Seems like if this was supported one could use caps-lock to temporarily
toggle into some other set of mouse bindings, if you set up your .fvwm2rc
right.  I can't figure out what good this would do me but I'm sure I could
find something eventually... :-)

Personally I have no current use for the caps lock key at all,
never use it except by mistake, which is why I hadn't run into this
before.

			-Robert Tarrall.-

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 7 Mar 1996 09:16:05 -0500

>>>>> "Rob" == Robert Tarrall <[email-masked]> writes:

Rob> "N. Dan Zou" wrote:

Rob> Hmmm... seems a heck of a lot smoother than most "fully released"
Rob> window managers I've used (olwm, twm, 4Dwm, and their virtual-screen
Rob> brethren).  I think at this point the main problem is getting all
Rob> the features fully explained to the users... :-)

That is the real problem.  Fvwm will always have rough edges, but the
docs definitely needed (and still need) expanding.

I think that there will only be like one more release before the first
official one.  It'll fix a few more buglets, improve the docs a little
bit more, fixup the install process just a hair more, and it should be
about as ready as ever to be official.  Then the real fun starts...

Chuck

---

From: Mark Borges <[email-masked]>
Date: 07 Mar 1996 12:28:18 -0700

>> On Thu, 7 Mar 1996 09:16:05 -0500,
>> Charles Hines(CH) wrote:
CH> I think that there will only be like one more release before the
CH> first official one.  It'll fix a few more buglets, improve the

Is one of the buglets the broken restart (or is that classified as a
bug-gar?) ;-0

In case you forgot, I'm referring to the situation where you have a
.fvwmrc that contains pre-processor lines like

	FvwmCpp ".fvwm/fonts-cpp"

If you restart, these lines are apparently not read (at least the
settings don't take effect. I get what appear to be some system wide
defaults). So restarting is kind of pointless for me.

Also, upon restart existing XEmacs windows become useless -- they
don't accept input anymore (I usually just kill them off via
delete-frame() and make a new onw).

  -mb-

---

From: Mark Borges <[email-masked]>
Date: 07 Mar 1996 13:19:46 -0700

>> On 07 Mar 1996 12:28:18 -0700,
>> Mark Borges(mb) wrote:

mb> In case you forgot, I'm referring to the situation where you have a
mb> .fvwmrc that contains pre-processor lines like

mb> 	FvwmCpp ".fvwm/fonts-cpp"

mb> If you restart, these lines are apparently not read (at least the
mb> settings don't take effect. I get what appear to be some system wide
mb> defaults). So restarting is kind of pointless for me.

In case it matters, I forgot to mention my way of restarting. I use
the following:

AddToMenu Quit-Verify 	"Really Quit Fvwm?" Title	
+		      	"Yes, Really Quit"  Quit	
+		      	"Restart Fvwm"	    Restart fvwm
+		      	"Start twm"         Restart ctwm
+		      	"Start mwm"    	    Restart mwm
+	      	      	"Start olwm"        Restart /usr/openwin/bin/olwm
+		        "Start tvtwm"       Restart vtwm
+		      	"Start dummy"       Restart xterm
+		      	""		    Nop	
+		      	"No, Don't Quit"    Nop	

Note I have `fvwm' instead of `fvwm2' (my version of fvwm-2.0.41 is
installed as `fvwm', as I'm the only one here who uses it so
far). Should I be passing an arg to fvwm above? (Is that even
possible?) Doesn't it re-read .fvwmrc upon restarting by default?

mb> Also, upon restart existing XEmacs windows become useless -- they
mb> don't accept input anymore

Oops. Sorry. I think this one is fixed, at least for the fvwm-2.0.41 /
XEmacs-19.14 combo. I just tried it after I sent the mail and
restarted, and XEmacs seemed to respond OK (though I haven't tried
many restarts to test if it's intermittent).

  -mb-

-- .fvwmrc excerpt ---------------------------------------------------------
# Styles
FvwmCpp ".fvwm/styles-cpp"

...
# Init functions
Read ".fvwm/init"

-- .fvwm/init contents------------------------------------------------------
# Initialization Functions.
AddToFunc InitFunction 	  "I" Module FvwmButtons
+			  "I" exec xpmroot /home/mdb/misc/bitmaps/background0.xpm.gz
+			  "I" Module FvwmPager 0 2

AddToFunc RestartFunction "I" Module FvwmButtons
+			  "I" exec xpmroot /home/mdb/misc/bitmaps/background0.xpm.gz
+			  "I" Module FvwmPager 0 2
--
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: <[email-masked]> (Charles Hines)
Date: Thu, 7 Mar 1996 18:29:04 -0500

>>>>> "mb" == Mark Borges <[email-masked]> writes:

mb> Is one of the buglets the broken restart (or is that classified as a
mb> bug-gar?) ;-0

Hopefully.

Yup, I seem to recall all of that, and yes I'd like to fix it before
the official release.

mb> Also, upon restart existing XEmacs windows become useless -- they
mb> don't accept input anymore (I usually just kill them off via
mb> delete-frame() and make a new onw).

I still don't see this.  I use XEmacs constantly (as you know) and
restart a lot when I'm doing fvwm stuff between real work or
before/after hours and I've never had this problem.  I'm not sure what
to say to this.

Chuck

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 7 Mar 1996 18:35:56 -0500

>>>>> "mb" == Mark Borges <[email-masked]> writes:

mb> In case it matters, I forgot to mention my way of restarting. I use
mb> the following:

mb> +                   "Restart Fvwm"      Restart fvwm

Looks fine.

mb> Note I have `fvwm' instead of `fvwm2' (my version of fvwm-2.0.41
mb> is installed as `fvwm', as I'm the only one here who uses it so
mb> far).

It's definitely less confusing to have it renamed as fvwm2, but there
should be no harm there.

mb> Should I be passing an arg to fvwm above? (Is that even possible?)

None needed.

mb> Doesn't it re-read .fvwmrc upon restarting by default?

It should be.  I'll have to investigate this particular problem when I
get a chance.  I don't use any preprocessing myself.

mb> Oops. Sorry. I think this one is fixed, at least for the fvwm-2.0.41 /
mb> XEmacs-19.14 combo. I just tried it after I sent the mail and
mb> restarted, and XEmacs seemed to respond OK (though I haven't tried
mb> many restarts to test if it's intermittent).

Good.

Chuck

---

From: [email-masked] (Albrecht Kadlec)
Date: Fri, 8 Mar 96 15:30:30 +0100

>>>>> Robert Tarrall writes:

R> "N. Dan Zou" wrote:

R> And CapsLock + Shift, Control, etc as well? :-)

R> Seems like if this was supported one could use caps-lock to temporarily
R> toggle into some other set of mouse bindings, if you set up your .fvwm2rc
R> right.  I can't figure out what good this would do me but I'm sure I could
R> find something eventually... :-)

R> Personally I have no current use for the caps lock key at all,
R> never use it except by mistake, which is why I hadn't run into this
R> before.

for all those, not using the caps lock key (and hating to accidently invoke
it): 

xmodmap -e 'clear lock'

albrecht
-- 
I'll be seeing you again on the ricochet,
Will you show me the pieces next time on the ricochet, (ricochet) -- Marillion
--
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: [email-masked] (Stephen Riehm)
Date: Fri, 8 Mar 1996 15:46:01 +0100 (MEZ)

Hi Albrecht, fellow fvwm'ers,

> xmodmap -e 'clear lock'

Why not go one step further and turn it into something useful, I've
turned mine into a Window Manager key, by making it the Mod2 modifier,
you could map it to any modifier (Mod1 is Alt, Mod2, 3, 4, and 5 are
normally free). Then you don't have any problems with application
which want to use Alt-<something> which you just happen to have mapped
for your window manager. Now, you can have as many window manager
bindings as you want, and you'll never conflict with some dopey
application :-)

all you need is:

xmodmap -e 'clear lock'
xmodmap -e 'add Mod2 Caps_Lock'

and then you'll need to change your window manager bindings of course
:-)

Good luck,

Steve
_______________________________ ._ o  ________________________________
//   Stephen Riehm             /  //\.        [email-masked]
\\\\ pc-plus                  '  \>> |         Phone: +49 89 62030 148
//// 81539 Munich, Germany        \\ `           Fax: +49 89 62030 113
  \\
--
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].