Hope y'all don't mind - I consolidated my responses to everyone in
this same note....
>>>>> "David" == David Mosberger-Tang <davidm_at_AZStarNet.com> writes:
>>>>> On Tue, 6 Feb 1996 14:35:29 -0500, <chuck_hines_at_VNET.IBM.COM> (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 <jhenders_at_bogon.com> 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 <olly_at_dylan.zycad.com> 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 <jselam_at_SSD.intel.com> 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 <geek+_at_cmu.edu> 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
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue Feb 06 1996 - 16:20:00 GMT