Subject: FVWM: tabbing in fvwm?

From: David Mosberger-Tang <[email-masked]>
Date: Tue, 6 Feb 1996 09:48:26 -0700

Does fvwm v2.x support tabbing a la twm?  To make sure we're talking
about the same thing: what I'm looking for is the ability to make the
title bar just wide enough to hold the window title (and whatever
buttons end up in the title bar).  In twmrc, this is called option
"SqueezeTitle".  I find this feature invaluable in giving fast and
convenient access to multiple stacked windows.

If it hasn't been implemented yet, any chance that it will be added
soon?  If not, what's the reason for not implementing it?  I'd love to
switch to fvwm but can't do so until tabbing is supported.

Thanks in advance!

	--david
--
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: "Jeff S. Elam" <[email-masked]>
Date: Tue, 06 Feb 1996 09:11:17 -0800

> switch to fvwm but can't do so until tabbing is supported.

That sounds like a GREAT feature.  I second the request!

-- 
-Jeff E.
[email-masked]

---

From: <[email-masked]> (Charles Hines)
Date: Tue, 6 Feb 1996 14:35:29 -0500

>>>>> "David" == David Mosberger-Tang <[email-masked]> writes:

David> Does fvwm v2.x support tabbing a la twm?  To make sure we're
David> talking about the same thing: what I'm looking for is the
David> ability to make the title bar just wide enough to hold the
David> window title (and whatever buttons end up in the title bar).
David> In twmrc, this is called option "SqueezeTitle".  I find this
David> feature invaluable in giving fast and convenient access to
David> multiple stacked windows.

Fvwm doesn't have this feature of twm.

David> If it hasn't been implemented yet, any chance that it will be
David> added soon?

I doubt it...  Or if so, at least not soon.

David> If not, what's the reason for not implementing it?

Well, I'll give a few:

1. I've only browsed twm and hadn't really seen that feature until I
   tried it after your note came in.  Then I read the man page to
   get a little more info on it.

2. I'm not trying to emulate every feature of every window manager
   (this includes win95) out there.  One of fvwm's goals is to be
   (stay) small and fast, and adding more features generally
   detracts from this.  I'm pretty selective.  Generically powerful
   features that don't cost too much memory, speed, or code
   complexity have a possibility of being added to fvwm.  Other
   things should be added as modules, perhaps.  If they can be.

3. If I were to implement it, it should probably be part of the
   recently added TitleStyle stuff, and all of that moved as a parm
   under the Style command, and I'm all out of style flags for the
   moment.  Perhaps after the 'Great Style Flag Rewrite' which will
   occur shortly after the seemingly mythical 'First Official 2.xx
   Release'.  But then, do we want the added memory overhead of
   title style info added to each window?  Can it be arranged to be
   cheap as far as memory usage goes?  Possibly...

4. Doc updates, build/install process fixes, and bugfixes are more
   important to me than most other things right now, mostly to help
   reach the 'First Official 2.xx Release' goal.

David> I'd love to switch to fvwm but can't do so until tabbing is
David> supported.

That's unfortunate.  But if that's the feature that makes it for you,
and no other features of fvwm make you want to switch, you're probably
better off sticking with twm (or perhaps ctwm, vtwm, or tvtwm, which
all have this feature as well since they are more directly spawned
from twm) for the time being.  You've got to use what works for you.

>>>>> "Jeff" == Jeff S Elam <[email-masked]> writes:

Jeff> That sounds like a GREAT feature.  I second the request!

I think it sounds interesting, but never having used it I'm having a
hard time seeing how it would be more useful than having the full
sized titles, which really don't take up that much more room.

Perhaps my typical window layouts make a difference here, since I can
see that they probably wouldn't benefit at all from this feature.

I can see a potential benefit if you like to lay out your windows
overlapping horizontally.  Do you do this?  Do a lot of people out
there do this?

I'll have to think about this feature...  I'll add it to the TO-DO
list with a question mark to remind me to investiage it when I get a
chance, but I can't make any guarantees.

If people can provide examples to sway me one way or the other, that'd
be helpful.

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

IBM Internal email:                        "Go back to sleep, Chuck.  You're
  [email-masked],              just havin' a nightmare--of course,
  HINESC at FISHKILL, HINESC at FSHVMFK1    we are still in Hell." Gary Larson
*******************************************************************************
--
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: David Mosberger-Tang <[email-masked]>
Date: Tue, 6 Feb 1996 13:12:25 -0700

>>>>> On Tue, 6 Feb 1996 14:35:29 -0500, <[email-masked]> (Charles Hines) said:

  Chuck> I think it sounds interesting, but never having used it I'm
  Chuck> having a hard time seeing how it would be more useful than
  Chuck> having the full sized titles, which really don't take up that
  Chuck> much more room.

  Chuck> Perhaps my typical window layouts make a difference here,
  Chuck> since I can see that they probably wouldn't benefit at all
  Chuck> from this feature.

  Chuck> I can see a potential benefit if you like to lay out your
  Chuck> windows overlapping horizontally.  Do you do this?  Do a lot
  Chuck> of people out there do this?

Yes, that's exactly what I'm using it for.  My typical layout consists
of about half a dozens xterms and one emacs window spread along the
screen bottom.  Graphically, it looks something like this (assuming
xterm1 is on top of the other xterms and emacs is on top of xterm4):

	+--------+ +--------+ +--------+ +--------+ +--------+
	| xterm1 | | xterm2 | | xterm3 | | xterm4 | | emacs  |
	+--------+-----------------------------+--+-+--------+-------//
	|				       |    |
	|				       |    |
        |				       |    |
        |       			       |    |
	|				       |    |
	|				       |    |
	+--------------------------------------+----+---------------//

Thus, the tabs give direct access to any window.  With full title
bars, the above configuration would imply that xterm2 and xterm3 would
be hidden behind xterm1.

  Chuck> I'll have to think about this feature...  I'll add it to the
  Chuck> TO-DO list with a question mark to remind me to investiage it
  Chuck> when I get a chance, but I can't make any guarantees.

I *do* appreciate your efforts to avoid bloating fvwm.  However, I
also believe that tabbing is not just another "feature"---it really
can improve efficiency in interacting with a windowing system.

	--david

---

From: Olly Stephens <[email-masked]>
Date: Tue, 06 Feb 1996 13:33:01 -0800

David Mosberger-Tang <[email-masked]> writes:
|> 
|> Yes, that's exactly what I'm using it for.  My typical layout consists
|> of about half a dozens xterms and one emacs window spread along the
|> screen bottom.  Graphically, it looks something like this (assuming
|> xterm1 is on top of the other xterms and emacs is on top of xterm4):
|> 
|> 	+--------+ +--------+ +--------+ +--------+ +--------+
|> 	| xterm1 | | xterm2 | | xterm3 | | xterm4 | | emacs  |
|> 	+--------+-----------------------------+--+-+--------+-------//
|> 	|				       |    |
|> 	|				       |    |
|>      |				       |    |
|>      |       			       |    |
|> 	|				       |    |
|> 	|				       |    |
|> 	+--------------------------------------+----+---------------//
|> 
|> Thus, the tabs give direct access to any window.  With full title
|> bars, the above configuration would imply that xterm2 and xterm3 would
|> be hidden behind xterm1.

It's easy to see what benefit this would have to people adopting this style
of layout.

However, I have a few points/questions:

  1. How would you handle the identification of sticky windows?  If you
     squeeze the title bar real tight, they'll be no room left for the
     stripes.  I guess you could add a few pixels either side and stripe
     those.

  2. Don't you think it may look a little silly with fvwm's mwm-style 3d
     borders.  twm has very simple window decorations and I agree that this
     type of title suits it well.  I thought it would so I got out my trusty
     gif editor (xpaint) and modified a current window grab.  I've included
     the result at the end of this message.  It doesn't look as bad as I
     thought it would, but I still don't know whether I like it.

  3. Looking at the fvwm code, it would probably require a bunch more windows
     (internal windows, not user windows) to model this.  That would add a
     fair overhead per user window which would increase the footprint of
     fvwm.  I think that twm's simplistic styling avoids much of this and
     so can get away with it.

Olly

---

From: [email-masked] (John Henders)
Date: Tue, 6 Feb 1996 13:34:20 -0800 (PST)

> sized titles, which really don't take up that much more room.

I could see it being useful as I tend to use large fonts and large
windows, so they overlap a lot. That's why I requested the smarter
drawing routines to tile the windows from a defined corner gravity.

As to implementation on fvwm, I can't see it making sense unless you use
the tab to substitute for all the features in the current title bar.
Also it would seem to me code would also be needed to make the tabs
smart, so they could reshuffle themselves around when new windows were
overlapped on old ones to make the tabs all visible. 

-- 
      Artificial Intelligence stands no chance against Natural Stupidity.
                GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v
                     b+++ e* s-/+ n-(?) h++ f+g+ w+++ y*

---

From: "Jeff S. Elam" <[email-masked]>
Date: Tue, 06 Feb 1996 13:38:06 -0800

> xterm1 is on top of the other xterms and emacs is on top of xterm4):

I agree with David.  Although I try not to let my desktops get
cluttered, I invariably have at least 6 xterms open on the same desktop by
the end of the day.  I know lots of people who like using those little 80x24
xterms, but personally I like to see as much of a file as I can, so I use lots
of nice, tall xterms that end up covering each other up.  I often find myself
"Lower"ing windows over and over again in search of a particular one.

I would LOVE to have a "tab" feature like this one to help me quickly pull
up the xterm I'm looking for.

However, I also agree that fvwm should be kept nice and small, so if this
feature impacts the size or speed of fvwm significantly and it can't be done
in a module, than punt it.

---

From: "Brian E. Gallew" <[email-masked]>
Date: Tue, 6 Feb 1996 16:55:46 -0500 (EST)

I think lots of people are missing the point of fVwm.  Tabs are essential, when
you are limited to a single desktop.  With multiple desktops, tabs are kinda
silly.  Admittedly, someone who has acquired their organizational habits from
twm will desire tabs no matter how many desktops/windows they have configured,
BUT that individual is probably better off sticking with twm if they aren't
interested in trying new organizational methods.

Personally, if I wanted to organize things in that manner, I'd bind FvwmWinList
to the right mouse button (done it), and use *that* to pull the appropriate
window to the fore.  I'd also use styles so that my "per machine" windows
grouped themselves together on a common desktop.

A current window count shows 23 open windows on my machine right now.  This is
hardly maximal for me.

=====================================================================
| It's nice to be important, but it's *important* to suck up to the |
| sysadmin  -- Me                                                   |
=====================================================================
| Finger [email-masked] for my public key.                            |
=====================================================================

---

From: Grant McDorman <[email-masked]>
Date: Tue, 06 Feb 1996 16:58:30 EST

On 20:55:54 Brian E. Gallew wrote:
>I think lots of people are missing the point of fVwm.  Tabs are essential,
>when you are limited to a single desktop.  With multiple desktops, tabs are
>kinda silly.

FvwmWinList also provides something almost exactly like what has been
described, albeit vertically instead of horizontally and not attached
to the windows. Perhaps an enhancement to allow FvwmWinList to be
horizontal as well as vertical will give people what they want?

Grant McDorman <[email-masked]>
				ISG Technologies, Inc.
--
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: Tue, 6 Feb 1996 17:17:37 -0500

Hope y'all don't mind - I consolidated my responses to everyone in
this same note....

>>>>> On Tue, 6 Feb 1996 14:35:29 -0500, <[email-masked]> (Charles Hines) said:

David> Yes, that's exactly what I'm using it for.  My typical layout consists
David> of about half a dozens xterms and one emacs window spread along the
David> screen bottom.  Graphically, it looks something like this (assuming
David> xterm1 is on top of the other xterms and emacs is on top of xterm4):

David>  +--------+ +--------+ +--------+ +--------+ +--------+
David>  | xterm1 | | xterm2 | | xterm3 | | xterm4 | | emacs  |
David>  +--------+-----------------------------+--+-+--------+-------//
David>  |                                      |    |
....
David>  +--------------------------------------+----+---------------//

David> Thus, the tabs give direct access to any window.  With full title
David> bars, the above configuration would imply that xterm2 and xterm3 would
David> be hidden behind xterm1.

David> I *do* appreciate your efforts to avoid bloating fvwm.  However, I
David> also believe that tabbing is not just another "feature"---it really
David> can improve efficiency in interacting with a windowing system.

With a window layout like that, I agree that it would help.  But in
the meantime, are there other alternatives?  Let's see what others
have to say:

>>>>> "John" == John Henders <[email-masked]> writes:

John> I could see it being useful as I tend to use large fonts and large
John> windows, so they overlap a lot. That's why I requested the smarter
John> drawing routines to tile the windows from a defined corner gravity.

John> As to implementation on fvwm, I can't see it making sense unless you use
John> the tab to substitute for all the features in the current title bar.
John> Also it would seem to me code would also be needed to make the tabs
John> smart, so they could reshuffle themselves around when new windows were
John> overlapped on old ones to make the tabs all visible.

The 'tab' is really just a shrunk down version of the title bar, so it
would theoretically retain all the old properties, just be smaller.

>>>>> "Olly" == Olly Stephens <[email-masked]> writes:

Olly> It's easy to see what benefit this would have to people adopting
Olly> this style of layout.

Olly> However, I have a few points/questions:

Olly>   1. How would you handle the identification of sticky windows?
Olly>      If you squeeze the title bar real tight, they'll be no room
Olly>      left for the stripes.  I guess you could add a few pixels
Olly>      either side and stripe those.

Those extra pixels would be needed to indicate that, yes.  On a
related note, I'd like to bring back the alternate color for sticky
windows as an option too, if possible.  Although that might not be
possible, since I know Rob removed it because getting it to work
required some unclean code.

Olly>   2. Don't you think it may look a little silly with fvwm's
Olly>      mwm-style 3d borders.  twm has very simple window
Olly>      decorations and I agree that this type of title suits it
Olly>      well.  I thought it would so I got out my trusty gif editor
Olly>      (xpaint) and modified a current window grab.  I've included
Olly>      the result at the end of this message.  It doesn't look as
Olly>      bad as I thought it would, but I still don't know whether I
Olly>      like it.

I didn't look at your picture, but I looked at what it looks like in
ctwm, and yes I think it looks pretty silly that way.  And it would
probably look about the same in fvwm, although maybe it could be
cleaned up.

Olly>   3. Looking at the fvwm code, it would probably require a bunch
Olly>      more windows (internal windows, not user windows) to model
Olly>      this.  That would add a fair overhead per user window which
Olly>      would increase the footprint of fvwm.  I think that twm's
Olly>      simplistic styling avoids much of this and so can get away
Olly>      with it.

Depending on how it's done, I would have to agree here.  But if the
titlebar window were just shrunk and the borders just followed it and
left the top of the actual window bare (which is what ctwm does) then
it wouldn't require any more additional windws (at least I don't think
it would).

But it would still require other info to be in the FvwmWindow
structure, and it would require more calculations and checking when
bordering windows.  It might be rather complex to add.  I won't know
until I look through the code some more and play a little with it.

>>>>> "Jeff" == Jeff S Elam <[email-masked]> writes:

Jeff> I agree with David.  Although I try not to let my desktops get
Jeff> cluttered, I invariably have at least 6 xterms open on the same
Jeff> desktop by the end of the day.  I know lots of people who like
Jeff> using those little 80x24 xterms, but personally I like to see as
Jeff> much of a file as I can, so I use lots of nice, tall xterms that
Jeff> end up covering each other up.  I often find myself "Lower"ing
Jeff> windows over and over again in search of a particular one.

I'm one of those small font small xterm people myself, but I have a
button on my title bar to maximize the window vertically if need be,
which I sometimes do.  But then I shrink 'em back down again.

Jeff> I would LOVE to have a "tab" feature like this one to help me
Jeff> quickly pull up the xterm I'm looking for.

True, but then again so does the builtin window list (or the
FvwmWindowList module for that matter).  And that doesn't matter what
your current window setup is or what the titlebars look like.

Jeff> However, I also agree that fvwm should be kept nice and small,
Jeff> so if this feature impacts the size or speed of fvwm
Jeff> significantly and it can't be done in a module, than punt it.

I couldn't have said it better myself...

Hey - another related note came in.  Let's follow that up here too...

>>>>> "Brian" == Brian E Gallew <[email-masked]> writes:

Brian> I think lots of people are missing the point of fVwm.  Tabs are
Brian> essential, when you are limited to a single desktop.  With
Brian> multiple desktops, tabs are kinda silly.

This (multiple virtual desktops) is the very reason why I switched to
fvwm in the first place originally.  My mwm screen was just too
littered with windows (and too slow on my rather pitiful machine at
work).

Right now I have about 33 windows spread across 4 pages of one 2x2
virtual desktop.  Alternately I could have chosen 4 individual
desktops to achieve the same effect.  And this way, I agree, no need
for tab style titlebars.

Although switching windows this way could be slower than just clicking
on the tabs.

Brian> Admittedly, someone who has acquired their organizational
Brian> habits from twm will desire tabs no matter how many
Brian> desktops/windows they have configured, BUT that individual is
Brian> probably better off sticking with twm if they aren't interested
Brian> in trying new organizational methods.

Or perhaps ctwm, vtwm, or tvtwm, which have similiar virtual
capabilities plus the old SqueezeTitle tabs.

Brian> Personally, if I wanted to organize things in that manner, I'd
Brian> bind FvwmWinList to the right mouse button (done it), and use
Brian> *that* to pull the appropriate window to the fore.  I'd also
Brian> use styles so that my "per machine" windows grouped themselves
Brian> together on a common desktop.

Very similiar to what I suggested above.  These are some good ideas to
work with the large window styles without the tabs.  And that is
probably just as fast and easy as the tabs would be.

Another way would be to use Prev/Next Focus to switch between windows.
This would be real good for large windows, especially if there weren't
too many of them (say <10).  That way you wouldn't even need to reach
for the mouse.

Brian> A current window count shows 23 open windows on my machine
Brian> right now.  This is hardly maximal for me.

And my count of 33 above was much larger earlier too.  But still very
usable and not too hard to find any particular window.  Even easier if
I were to rename a few of my xterms uniquely.

Chuck

---

From: <[email-masked]> (Charles Hines)
Date: Tue, 6 Feb 1996 17:19:49 -0500

>>>>> "Grant" == Grant McDorman <[email-masked]> writes:

Grant> FvwmWinList also provides something almost exactly like what
Grant> has been described, albeit vertically instead of horizontally
Grant> and not attached to the windows. Perhaps an enhancement to
Grant> allow FvwmWinList to be horizontal as well as vertical will
Grant> give people what they want?

I don't know - whether the text were shrunk, or rotated, or wrapped
around the buttons, that'd be pretty hard to read, wouldn't it?

Chuck

---

From: David Mosberger-Tang <[email-masked]>
Date: Tue, 6 Feb 1996 15:38:11 -0700

>>>>> On Tue, 06 Feb 1996 13:33:01 -0800, Olly Stephens <[email-masked]> said:

  Olly>   1. How would you handle the identification of sticky
  Olly> windows?  If you squeeze the title bar real tight, they'll be
  Olly> no room left for the stripes.  I guess you could add a few
  Olly> pixels either side and stripe those.

Sounds allright to me.  In fact, twm does the same to mark the window
with the mouse focus.

  Olly>   2. Don't you think it may look a little silly with fvwm's
  Olly> mwm-style 3d borders.  twm has very simple window decorations
  Olly> and I agree that this type of title suits it well.  I thought
  Olly> it would so I got out my trusty gif editor (xpaint) and
  Olly> modified a current window grab.  I've included the result at
  Olly> the end of this message.  It doesn't look as bad as I thought
  Olly> it would, but I still don't know whether I like it.

Well, it looks perfectly fine to me.  I included a variant below.
Right now, I prefer the looks of your version, but it may be that with
a little work on the 3d decorations, the version below could be made
to look just as good.  I included it mainly because I thought it might
be easier to implement.

  Olly>   3. Looking at the fvwm code, it would probably require a
  Olly> bunch more windows (internal windows, not user windows) to
  Olly> model this.  That would add a fair overhead per user window
  Olly> which would increase the footprint of fvwm.  I think that
  Olly> twm's simplistic styling avoids much of this and so can get
  Olly> away with it.

Could this be implemented so that the additional X windows are
necessary only when using squeezed titles?

	--david

--===_0_Tue_Feb__6_13:31:46_PST_1996
Content-Type: image/gif
Content-Description: squeeze-window.gif
Content-Transfer-Encoding: base64

--===_0_Tue_Feb__6_13:31:46_PST_1996--
--
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: Grant McDorman <[email-masked]>
Date: Tue, 06 Feb 1996 17:28:22 EST

>around the buttons, that'd be pretty hard to read, wouldn't it?

Huh?  Perhaps I didn't express myself clearly. I was thinking that FvwmWinList
could have an Orientation, say, which would be either "horizontal" or "vertical"
>.
"Vertical" would be like it is now; "horizontal" would be a horizontal row of
buttons (take the current FvwmWinList and layout the buttons side-by-side instea
d
of on top of each other).

I wasn't thinking of having tall, thin buttons, which by your reply seems to
be what you though of.

---

From: Olly Stephens <[email-masked]>
Date: Tue, 06 Feb 1996 15:01:37 -0800

David Mosberger-Tang <[email-masked]> wrote:
|>
|> >>>>> On Tue, 06 Feb 1996 13:33:01 -0800, Olly Stephens <[email-masked]
|> d.com> said:
|> 
|>   Olly> ..............................  I've included the result at
|>   Olly> the end of this message.  It doesn't look as bad as I thought
|>   Olly> it would, but I still don't know whether I like it.
|> 
|> Well, it looks perfectly fine to me.  I included a variant below.
|> Right now, I prefer the looks of your version, but it may be that with
|> a little work on the 3d decorations, the version below could be made
|> to look just as good.  I included it mainly because I thought it might
|> be easier to implement.

Yep, much easier.  It wouldn't require any additional windows or structures.
Just a bit of re-arrangement.

|>   Olly>   3. Looking at the fvwm code, it would probably require a
|>   Olly> bunch more windows (internal windows, not user windows) to
|>   Olly> model this.  That would add a fair overhead per user window
|>   Olly> which would increase the footprint of fvwm.  I think that
|>   Olly> twm's simplistic styling avoids much of this and so can get
|>   Olly> away with it.
|> 
|> Could this be implemented so that the additional X windows are
|> necessary only when using squeezed titles?

Yes, but you'd still probably need place-holders which would inflate the
actual window structure and the code would be quite complex (as pointed out
by Chuck).  Of course, I'm looking at it (as always) from the point of view
of having it a configurable option rather than a #ifdef compile alternative.

I think if you're happy with the look of your modified image you sent,
you should go with that.  It should be fairly trivial to implement compared
to anything more intricate.

Now, it's a question of actually doing it.  I'll put it on my list of
"fvwm hacks to attempt" but it would be down at number 3 at least.
Chuck has also implied that it would be low down on his list.

A while back on this list, there was a discussion about implementing
window styling in a module.  It's definitely the thing to do if we
can figure some way of doing it without slowing things down too much.
Maybe through dynamic loading rather than piping between separate
executables...

It's got to be the logical way to satisfy the look- half of everyone's
look-and-feel tastes.

Olly

---

From: [email-masked] (John Henders)
Date: Tue, 6 Feb 1996 15:11:29 -0800 (PST)

For an interesting look at how someone else has implemented a motif
looking tab, check out the BeBox's desktop at

http://www.be.com/Art/desk.GIF

---

From: David Mosberger-Tang <[email-masked]>
Date: Tue, 6 Feb 1996 16:33:31 -0700

>>>>> On Tue, 06 Feb 1996 15:01:37 -0800, Olly Stephens <[email-masked]> said:

  Olly> Now, it's a question of actually doing it.  I'll put it on my
  Olly> list of "fvwm hacks to attempt" but it would be down at number
  Olly> 3 at least.  Chuck has also implied that it would be low down
  Olly> on his list.

OK, that sounds good.  I might try it myself but it has been a long
time since I programmed X last and it looks like I'll have plenty of
fun porting GNU libc to Linux/Alpha.  If you get to do it first, I'd
obviously be very interested in hearing about it.

	--david

---

From: Kai Grossjohann <[email-masked]>
Date: 07 Feb 1996 11:02:47 +0100

>>>>> On Tue, 6 Feb 1996 13:12:25 -0700, David Mosberger-Tang
>>>>> <[email-masked]> said:

  David> Yes, that's exactly what I'm using it for.  My typical layout
  David> consists of about half a dozens xterms and one emacs window
  David> spread along the screen bottom.

I use ctwm but don't use the tab feature.  I have many many xterms all
the very same size all at +0+0 and I use the IconManager to choose the
right xterm (I have Alt-CursorUp and Alt-CursorDown bound to moving in
the IconManager).

That would be an alternative for you tabbing-friends out there.

        kai
--
Life is hard and then you die.
--
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: Jonathan Watson <[email-masked]>
Date: Wed, 7 Feb 1996 08:07:43 -0500 (EST)

> interested in trying new organizational methods.

I don't know if the I'd go so far to say tabs are silly...But Brian makes 
a good point: Why lump all your stuff together on 1 desktop when you can 
spread it over a bunch?? I run about 5-10 xterms and applications. You 
don't need tabbing if you have multiple desktops. The other thing I do is 
bind Raise/Lower to the F1 key...If I stack related windows on a desktop I 
can tap through them quckly with that. Just use a 3x1 vitual desktop and the 
'paging' feature to jump from desktop to desktop. There's my 2 bits...

	Jon Watson

*-------------------------------------------*-------------------------------*
| The MITRE Corporation			    | Northeastern University       |
| D086 Advanced Systems - Signal Processing | Boston,  Massachussests, USA. |
| Bedford, Massachussests, USA.		    | College of Engineering (EE)   |
|        [email-masked]	 	    |    [email-masked]  |
*-------------------------------------------*-------------------------------*

---

From: [email-masked] (Robert Nation 885-9815)
Date: Wed, 7 Feb 96 09:45:36 EST

>  Olly> it would, but I still don't know whether I like it.

I can't actually look at these because they're encoded base64 instead of
uuencode, (how do you decode a base64 message?) but remember that to do
tabs, you need to invoke the shape extensions of X11. The shape extensions
have always seemed EXTREMELY slow to me. You might get away with it,
beause they are all going to rectangular shapes. To get a feel for this,
try resizing an oclock, and see how long it takes to complete (almost
a second for me).

Rob

---

From: [email-masked] (John Henders)
Date: Wed, 7 Feb 1996 07:32:04 -0800 (PST)

You, Robert Nation 885-9815 write:

> uuencode, (how do you decode a base64 message?)

You need munpack and mpack. They're on most mime support sites, so you
should be able to find them with archie or one of the web search
engines.

? but remember that to do
> try resizing an oclock, and see how long it takes to complete (almost

Included is a variations I like, modified from another one posted here
(uuencoded) and it's all square, so I don't think the shape extensions
would be needed.

---

From: [email-masked] (Robert Nation 885-9815)
Date: Wed, 7 Feb 96 10:40:58 EST

>(uuencoded) and it's all square, so I don't think the shape extensions

Ifd the top-level window is not rectangular, you need the shape extensions.
What you have is two rectangles which are placed together. I believe that
this would require shape extensions.

Rob

---

From: <[email-masked]> (Charles Hines)
Date: Wed, 7 Feb 1996 11:43:07 -0500

>>>>> "Rob" == Robert Nation 885-9815 <[email-masked]> writes:

>> (uuencoded) and it's all square, so I don't think the shape extensions

Rob> Ifd the top-level window is not rectangular, you need the shape
Rob> extensions.  What you have is two rectangles which are placed
Rob> together. I believe that this would require shape extensions.

Just so everyone knows what Rob is referring to here - all of the
decorations and the app window have this top level parent window
courtesy of fvwm, which if it were to contain two different sized
windows like that would require the SHAPES extension.

The SHAPES extension, as Rob noted, is definitely slow at times,
unless you have a really good machine and a graphics card optimized
for special X stuff (like the SGI machines, perhaps).

I've poked around the code somewhat, and looked at how [c]twm does
this, and based on that and these discussions, adding this 'tab'
feature would not be trivial work.

I know people out there like this feature, and if it works well for
your way of working that's great, but I have this feeling that it may
not appear.  Or if it does, definitely not for some time.

I'm sorry 'bout this, but as I've said in the past there are a lot of
cool features and ideas out there but we can't satisfy everyone all
the time.  Don't let this deter you from making suggestions and
requests though!

If people out there absolutely cannot live without this feature, you
have a few choices:

  1. Continue to use [c,tv,v]twm instead.
  2. Hack the fvwm code yourselves.  I can't guarantee that I'll add
     any patches you send, but I will at least look at them.
  3. Find an alternate way to do what you want (or as close as
     possible) with existing fvwm features, either with a small change
     in your window stacking order, multiple virtual pages and/or
     desktops, special keybindings, the winlist or winlist module
     (with Grant's proposed horizontal option perhaps), the IconMan
     module, etc.

Back to the grind...
Chuck

---

From: Lars Wirzenius <[email-masked]>
Date: Wed, 07 Feb 1996 23:26:37 +0200

> It's easy to see what benefit this would have to people adopting this style

That's what I think as well.  I tried it for a day or two, and it can
be nice, but, personally, I use too many windows of varying sizes
(xterms, xcalc, exmh, editors, file managers, xconsole, xv, games;
I've all these open at this moment) for it to be comfortable.  In
my experience, this style was suitable best when there were a lot of
independently used windows (i.e., there is no need to have many visible
at the same time).

My own solution is to use several virtual desktops (I have six: one for
system administration, one for mail/news/other comms, three for my three
most important projects, and one extra), and a per-desktop FvwmIconMan
(which I wish was included in the standard distribution).  The FvwmIconMan
is really nice for finding a window among many.  That and automatic
raising of the focused window are about the most important work boosters 
from Fvwm (fiddling around with my .fvwm2rc is not :-).  Oh, the built-in
window list is also nice, since it allows me to go directly to a window
on another desktop.

I'm not really a power user (I prefer "wannabe hacker"), so at the moment,
after two nights of using mostly e-mail, I only have 22 windows spread
on my desktops (one of them is completely empty).  I can easily have more
than three times that, but usually I avoid it since the built-in window
list no longer fits on my screen (I usually close all editor windows
for one project when I stop working it for the day).

My work habits tend to encourage many windows -- I have xfm configured so
that it starts an editor when a file is double clicked, and a typical
project has a dozen or two files, most of which are edited or viewed
at the same time.  Also my editor (my own; one of my projects :-) makes
it trivial to `clone' a window, i.e., to open a new window with the same
file and the same location as the old one (the cloning is done by a single
click -- no menus or anything).  After trying many alternatives, this is
what I've landed on.

It could be improved.  I'd like a Windows-like Alt-Tab and Alt-Shift-Tab
that circulate among windows, but re-order the list (or stack) so that the 
new window is always brought to the top.  This'd make it easier to
navigate without a mouse.  Oh, and an optional status window would
probably be preferable than directly jumping to the window; I don't know.

(I don't like Windows as a whole, but it has some nice points in its
user interface.)

>      borders.  

Personally, I prefer

	Style "*"           BorderWidth 1, HandleWidth 2, NoHandles

I used the borders only when resizing, and that's not common enough an
operation for me that I can't go select it from a menu.

> Content-Description: squeeze-window.gif

A-ha!  A fellow exmh user. :-)