toml@morgul.Solbourne.COM (Tom LaStrange) (06/12/91)
Patchlevel 6 of tvtwm is now available from export.lcs.mit.edu in
contrib/tvtwm.tar.Z. Nothing real new, mainly fixes for some fairly nasty
bugs that were introduced in the last patch. The most significant new thing
in the tar file is a new utility that we've been shipping with swm. It's
called swmxlate and it converts relative corrdinates to virtual desktop
absolute coordinates. A sample use would be
xterm -geom `swmxlate -geom +100+200`
The xterm would be placed at +100+200 relative to where you are currently
positioned in the virtual desktop.
Here's the blurb from the patch file which has been sent to comp.sources.x:
tvtwm patch 6
This patch fixes the following problems:
1. Fixes "phantom window frame" problems.
2. Bug fixes to window move cleanup.
3. Added gridded movement in panner. Try starting a pan operation and then
hold down the shift key. (Salvador Pinto Abreu spa@fct.unl.pt)
4. Fixes the crash problem when multiple mouse buttons are pressed.
--
Tom LaStrange toml@Solbourne.COMswick@athena.mit.EDU (Ralph Swick) (06/13/91)
xterm -geom `swmxlate -geom +100+200` So, the window manager is Trivial but the user&system have to do more work? Can anyone tell me why I should want to suffer through *wmxlate/vroot.h/ non-interleavable_nailed_windows_and_un-nailed_windows rather than what seems to me to be the much more natural feeling provided by Williams and Edmondson's vtwm? -Ralph (speaking with his user's hat on for a change :-)
tar@math.ksu.edu (Tim Ramsey) (06/14/91)
swick@athena.mit.EDU (Ralph Swick) writes: [ ... ] >Can anyone tell me why I should want to suffer through *wmxlate/vroot.h/ >non-interleavable_nailed_windows_and_un-nailed_windows rather than what >seems to me to be the much more natural feeling provided by Williams >and Edmondson's vtwm? The advantage of tvtwm seems to be that it moves the overhead of the virtual desktop to the server, where vtwm forces every client to notice that they have moved (virtually). However, it takes a lot more memory in the server than vtwm. Personally, I prefer vtwm. I don't like my background pictures spread out over the entire virtual root window. :-) -- Tim Ramsey/system administrator/tar@math.ksu.edu/(913) 532-6750/2-7004 (FAX) Department of Mathematics, Kansas State University, Manhattan KS 66506-2602
toml@marvin.Solbourne.COM (Tom LaStrange) (06/14/91)
> So, the window manager is Trivial but the user&system have to do more work? > Can anyone tell me why I should want to suffer through *wmxlate/vroot.h/ > non-interleavable_nailed_windows_and_un-nailed_windows rather than what > seems to me to be the much more natural feeling provided by Williams > and Edmondson's vtwm? > -Ralph > (speaking with his user's hat on for a change :-) ji.had \ji-'ha:d, -'had\ n [Ar jiha-d] 1: a holy war waged on behalf of Islam as a religious duty 2: a crusade for a principle or belief I'll give a two part answer, one as a user and the other as a developer If I put my user's hat on and ignore the other minor things that vtwm and tvtwm can do, I think there are two classes of users: 1. I use vtwm because it works and it doesn't break anything. 2. I use tvtwm because it works and its performance is better. Depending on your workstation/network, you can determine for yourself which class you want to fall in. If you have a fast server and use tvtwm, you "suffer" through the vroot.h stuff. If you have a slow server and use vtwm, you "suffer" every time you pan the desktop. When I put on my toolkit/wm developer's hat, it gets a little more religious. I know 90% of the users out there aren't going to care how the underlying mechanism works, they just want it to work. Here's the problem we're trying to solve: Look through a viewport onto a much larger object and be able move the viewport to see various portions of the underlying object. Right? If you were trying to solve this problem with a toolkit, wouldn't you use something like the Athena Viewport widget? I certainly would. As a user, vtwm may seem more natural, but with my developer hat on, the vtwm approach seems like trying to move a big pile of dirt (the client windows) with a shovel rather than a wheelbarrow. It can be done, it's just a lot more work. Use the right tool for the job. The arguments that "the user&system have to do more work" or as another mail message put it, that tvtwm is more "stressful on the whole X environment" don't hold much water with me either. If we have that attitude, we probably wouldn't even have reparenting window managers because they require clients to have to do more work. It took 2.5 years and 4 version of X11 to get the ICCCM and standard reparenting window managers. I sincerely hope that's not where it ends. If we stop trying to push technology, what are we all going to do for a living? :-) Sorry for the heavy dose of religion. -- Tom LaStrange toml@Solbourne.COM
cross@eng.umd.edu (Chris P. Ross) (06/17/91)
In article <1991Jun14.010121.16472@maverick.ksu.ksu.edu>, tar@math.ksu.edu (Tim Ramsey) writes: > swick@athena.mit.EDU (Ralph Swick) writes: > > [ ... ] > > > [- complaints about tvtwm's way of dealing with the virtual desktop -] > > [- comparison argument -] > > Personally, I prefer vtwm. I don't like my background pictures spread > out over the entire virtual root window. :-) Neither do I, but I don't have a problem with it. I use tvtwm religiously, and I load a fullscreen image, and it duplicates throughout the desktop. So, When I'm on each screen, it looks perfectly normal. I admit, if I place the panner select between an even duplication of screens, I get parts of it, but that's no worse than loading an image that's a little smaller than your window in a non-virtual WM. As for my argument for tvtwm vs. vtwm, I've found that I like tvtwm alot more, cause it let's me do more. Though, I think that tvtwm should incorporate a panner context, resembling the virtual context in vtwm. How hard is this? Tom? (Sure, push the work on someone else, Chris... :-) -- Chris P. Ross University Of Maryland cross@eng.umd.edu Engineering Computer Facility Work#: (301)/405-3689 Project GLUE
stripes@eng.umd.edu (Joshua Osborne) (06/18/91)
In article <9106131641.AA19511@lyre.MIT.EDU> swick@athena.mit.EDU (Ralph Swick) writes: > > xterm -geom `swmxlate -geom +100+200` > >So, the window manager is Trivial but the user&system have to do more work? X only provides one way to set the grom., tvtwm makes user specifyed locations relitave to the vert. root, that way you can have your .xinitrc (or .twmrc) start things up off the current root. In vtwm you can't start things relitave to the vert. root window, just the current one. This makes some things easyer, some harder. In vtwm how would I start up a xtank in the lower left root no matter where my current root is? What about starting xfoo in the upper right root no matter what the current root is? >Can anyone tell me why I should want to suffer through *wmxlate/vroot.h/ >non-interleavable_nailed_windows_and_un-nailed_windows rather than what >seems to me to be the much more natural feeling provided by Williams >and Edmondson's vtwm? You can interleave sticky and non-sticky (nailed) windows. You need to set an option to do it (because it is slower that way). I would prefer that tvtwm would re-parent sticky windows to the vert. root only when needed, and re-parent them back to the real root when possable, but I havn't been able to figure out how to do that (yet). -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
x-window@uni-paderborn.de (X-Window Betreuung) (06/18/91)
Hello,
I had some problems with the new tvtwm. In my .tvtwmrc I have the line
VirtualDesktopBackgroundPixmap "/usr/lib/X11/gwm/grainy.xbm"
This leads to an error while reading the init file. There seems to be
an error in gram.y which causes this behaviour. Below is a patch for
gram.y which prevents this error. Ok, I could change the entry to
Pixmaps {
VirtualDesktopBackgroundPixmap "/usr/lib/X11/gwm/grainy.xbm"
}
but this is not the old behaviour and the man page does not say that
this is required. So here is the patch to get the old behaviour.
Regards, Swen
--------------------8< cut here >8--------------------
*** gram.y.orig Tue Jun 18 15:04:56 1991
--- gram.y Tue Jun 18 14:46:28 1991
***************
*** 109,114 ****
--- 109,115 ----
| sarg
| narg
| squeeze
+ | PKEYWORD string { do_pixmap_keyword($1,$2); }
| ICON_REGION string DKEYWORD DKEYWORD number number
{ AddIconRegion($2, $3, $4, $5, $6); }
| ICONMGR_GEOMETRY string number { if (Scr->FirstTime)
--------------------------------------------------
--
----> Swen Thuemmler * X-Betreuung * <swen@uni-paderborn.de> <----bsp10@duts.ccc.amdahl.com (Byong Pak) (06/25/91)
Has anyone else had problems using framemaker under tvtwm? I seem to be having a problem bringing up a document if I am not in the uppermost left hand quadrant of the virtual window. Every time I try and bring up a new document outside of that quadrant, it crashes framemaker. As a sideline, xwininfo also seems to give wrong information... or at least is not looking in the right place when I use it interactivly. It tends to think that every window that is not sticky is either the console or the icon manager. Any ideas??? Are these two related??? -- * Byong "the pakman" Pak * These opinions are my own and do * * aka * not reflect the opinions or * * email: bsp10@duts.ccc.amdahl.com * policies of Amdahl Corp. * * phone: 408-746-7871 * *