jsparkes@bwdls49.bnr.ca (Jeff Sparkes) (12/10/90)
In <TOML.90Dec6133404@ninja.Solbourne.COM> toml@ninja.Solbourne.COM (Tom LaStrange) writes: >The problem with xwd not working correctly under swm or tvtwm is due to the >fact that the subwindow member of the of the button press event comes back >with the window id of the virtual desktop window. XmuClientWindow() >is called with this window id which simply looks through the descendants >for a client window (one with WM_STATE set). This of course results in >getting some window rather than the one under the pointer. Perhaps >we need a new Xmu routine that takes an xy coordinate pair and returns >the topmost client window at that location? I think the time has come to standardize this, and get it put into Xlib so everything works again. We need a standard property name (how about VIRTUAL_ROOT?) that the window manager sets as appropriate. The RootWindow macro can be replaced with a function similar to the one that Andreas Stolcke posted. I suspect that a more efficient way could be done with property change events and a little addition to XNextEvent. I realize that this has probably been discussed in the ICCCM mailing lists; will somebody point out how naive I am? This would be a good thing for patch 19..... -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 Another feature is that the seats float, so that the airline can recover them if the plane crashes into the ocean. -- Dave Barry BOB drives a TuRBO!
tom@bears.ucsb.edu (Tom Weinstein) (12/11/90)
In article <jsparkes.660841506@bwdls49>, jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: > I think the time has come to standardize this, and get it put into Xlib > so everything works again. We need a standard property name (how about > VIRTUAL_ROOT?) that the window manager sets as appropriate. The > RootWindow macro can be replaced with a function similar to the one that > Andreas Stolcke posted. I suspect that a more efficient way could be done > with property change events and a little addition to XNextEvent. Why bother doing this? It would be so much simpler to just extend the Protocol slightly to allow resizing and moving the root window. Yes, it may be a bit ugly, but it's better than another special case programs have to look for. I can't see any major problems with it, but I haven't really thought about it much. So, am I wrong, or what? -- He is Bob...eager for fun. | Tom Weinstein tom@bears.ucsb.edu He wears a smile... Everybody run! | tweinst@polyslo.calpoly.edu
jsparkes@bwdls49.bnr.ca (Jeff Sparkes) (12/12/90)
In <7781@hub.ucsb.edu> tom@bears.ucsb.edu (Tom Weinstein) writes: >In article <jsparkes.660841506@bwdls49>, jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: >> I think the time has come to standardize this, and get it put into Xlib >> so everything works again. We need a standard property name (how about >> VIRTUAL_ROOT?) that the window manager sets as appropriate. The >> RootWindow macro can be replaced with a function similar to the one that >> Andreas Stolcke posted. I suspect that a more efficient way could be done >> with property change events and a little addition to XNextEvent. >Why bother doing this? It would be so much simpler to just extend the >Protocol slightly to allow resizing and moving the root window. Yes, >it may be a bit ugly, but it's better than another special case programs >have to look for. I can't see any major problems with it, but I haven't >really thought about it much. So, am I wrong, or what? I figured it would be the easiest way to do it. I think that changing the protocol at this point would be harder than changing one or two functions in Xlib. -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 Another feature is that the seats float, so that the airline can recover them if the plane crashes into the ocean. -- Dave Barry BOB drives a TuRBO!
dce@smsc.sony.com (David Elliott) (12/12/90)
In article <jsparkes.660841506@bwdls49>, jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: |> I think the time has come to standardize this, and get it put into Xlib |> so everything works again. We need a standard property name (how about |> VIRTUAL_ROOT?) that the window manager sets as appropriate. The |> RootWindow macro can be replaced with a function similar to the one that |> Andreas Stolcke posted. I suspect that a more efficient way could be done |> with property change events and a little addition to XNextEvent. |> |> I realize that this has probably been discussed in the ICCCM mailing lists; |> will somebody point out how naive I am? |> |> This would be a good thing for patch 19..... Besides the low probability of there being a patch 19, this isn't a simple change. I talked to rws about this a couple of months back, and he didn't want to make changes of this nature until there was an ICCCM decision on virtual root windows and rooms. I gave some thought to changing Xlib so that all requests for the root window id would do the virtual root chasing, but I came up with one problem: How do you deal with cases where the root window changes? How do applications that are using the old root window id react? One big question is whether or not the virtual root model is the right way to go. Specifically, are the things you use the virtual root for adequately or better taken care of by a rooms implementation builtin to a window manager? (In my case, having the ability to iconify/deiconify all windows in a given icon manager could do most of the work I use tvtwm for.) -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."It's like his pants were confused..." - Lynda Barry
rmtodd@servalan.uucp (Richard Todd) (12/12/90)
dce@smsc.sony.com (David Elliott) writes: >One big question is whether or not the virtual root model is >the right way to go. Specifically, are the things you use the >virtual root for adequately or better taken care of by a rooms >implementation builtin to a window manager? (In my case, having >the ability to iconify/deiconify all windows in a given icon >manager could do most of the work I use tvtwm for.) The main thing I find the virtual root useful for is making useful all those X programs written by people who assume everyone has a 1000x1000 monitor on their computer (the "All the world's a Sun" syndrome). GhostScript or similar programs become a lot more useful when you can actually pan around and see all of the window :-). For those of us with small monitors, virtual root window managers like tvtwm are a major convenience, and provide functionality (allowing ready use of windows bigger than the physical monitor) that, as I understand it, isn't addressed at all by the "rooms" programs. I do occasionally use the virtual desktop to provide rooms-like functionality, but it's definitely a side issue--it's not the big thing that inspired me to pull tvtwm off the net and install it here, it's the ability to not have to buy a megapixel display just to run GhostScript. (I'm not deliberately slagging on GhostScript here; it's hardly the only program with large-window-syndrome, just one I happen to use a lot.) In short, there is one thing (emulating a bigger display) that the virtual root scheme does, that isn't done *at all* by a "rooms"-type WM. So, as John Cleese said in the petshop, "It's scarcely a replacement then, is it?" As an aside, one of the things I find interesting about X is that it was possible to implement such a thing as a virtual root window manager purely in user-level client code, without having to do any strange hacking to Xlib or the X server. While there do exist "expanded desktop" programs for other systems (Stepping Out for the Macintosh being perhaps the most widely known example), such programs generally can't be implemented on those systems without all sorts of exceedingly messy patching of low-level internals of the window system. On X it falls out as a natural usage of the existing calls to re-arrange window structure. Says something about the level of generality in the Xlib interface, I think. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Try looking in the Yellow Pages under 'Psychotics'." -- Michael Santana
toml@ninja.Solbourne.COM (Tom LaStrange) (12/13/90)
>The problem with xwd not working correctly under swm or tvtwm is due to the >fact that the subwindow member of the of the button press event comes back >with the window id of the virtual desktop window. XmuClientWindow() >is called with this window id which simply looks through the descendants >for a client window (one with WM_STATE set). This of course results in >getting some window rather than the one under the pointer. Perhaps >we need a new Xmu routine that takes an xy coordinate pair and returns >the topmost client window at that location? I think the time has come to standardize this, and get it put into Xlib so everything works again. We need a standard property name (how about VIRTUAL_ROOT?) that the window manager sets as appropriate. The RootWindow macro can be replaced with a function similar to the one that Andreas Stolcke posted. I suspect that a more efficient way could be done with property change events and a little addition to XNextEvent. I have proposed something a little different. A WM_ROOT property on each top-level window indicating its "root" window. This would allow you to have multiple virtual roots. Each virtual root could then be reparented, iconified, moved etc. You would also be allowed to move windows between virtual roots. Don't think about all the possibilities too much, it'll give you a headache :-) There may be problems with this approach because the property will not be set until the window manager reparents the window so the RootWindow macros will reflect the actual root until the window is mapped. There are other issues dealing with override-redirect windows but I won't go into that here. This apporach would almost give you rooms capabilities. What is doesn't provide is sharing windows among virtual desktops. I realize that this has probably been discussed in the ICCCM mailing lists; will somebody point out how naive I am? Not really too much. This would be a good thing for patch 19..... I can't speak for MIT, but I don't think this issue has been discussed enough yet. And no, I'm not working on multiple virtual desktops for tvtwm, I barely have time to get my real work done :-) -- Tom (still here) LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
janssen@parc.xerox.com (Bill Janssen) (12/13/90)
In article <TOML.90Dec12133603@ninja.Solbourne.COM> toml@ninja.Solbourne.COM (Tom LaStrange) writes:
[...]
I have proposed something a little different. A WM_ROOT property on
each top-level window indicating its "root" window. This would allow you
to have multiple virtual roots. Each virtual root could then be reparented,
iconified, moved etc.
[...]
This apporach would almost give you rooms capabilities. What is doesn't
provide is sharing windows among virtual desktops.
Actually, I thought about this when I did Rooms for X, and it turned out that
things went *better* without the mechanism, just using the real root window,
but unmapping and re-mapping the windows as needed when switching rooms.
Among other things, alternate placements was reasonably easy to do. Similarly,
tvtwm could (I believe) be implemented without a virtual root window, just by
moving the windows when panning the desktop.
I'm not sure what the real values of virtual roots would be, other than as
an interesting thing to experiment with...
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304mouse@LIGHTNING.MCRCIM.MCGILL.EDU (12/16/90)
[ ...the virtual root mess... ] > One big question is whether or not the virtual root model is the > right way to go. Specifically, are the things you use the virtual > root for adequately or better taken care of by a rooms implementation > builtin to a window manager? Other posters have answered with a definite yes. However, you asked the wrong question. Instead, why not ask whether there's anything tvtwm (say) does that you need virtual roots for? I can't see anything. All the virtual root buys you is some programmer convenience when writing the window manager[%]. There is no reason the windows couldn't be direct children of the root, with the panning implemented by moving them. After all, it is entirely possible to place a window entirely outside of the boundaries of its parent. [%] As far as I can see. What other benefits can the collective imagination of the net come up with? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dme@doc.ic.ac.uk (Dave Edmondson) (12/17/90)
In article <JANSSEN.90Dec12182712@holmes.parc.xerox.com> janssen@parc.xerox.com (Bill Janssen) writes:
janssen> Among other things, alternate placements was reasonably easy
janssen> to do. Similarly, tvtwm could (I believe) be implemented
janssen> without a virtual root window, just by moving the windows
janssen> when panning the desktop.
this is what vtwm does. if you have lots of windows then this
_considerably_ slower, but it may be possible to get around that by
only moving windows that are currently visible, or will be visible
after the move. this does (of course) have other consequences.
janssen> I'm not sure what the real values of virtual roots would be,
janssen> other than as an interesting thing to experiment with...
a good reason in itself. we are sure to find a use for this when we
have it. i used to manage without a virtual desktop, but i really
struggle without it now.
dave.
--
Dave Edmondson, Systems Support. Opinions are all my own.
Department of Computing, Imperial College of Science, Technology and Medicine,
180 Queen's Gate, London SW7 1BZ. phone: 071-589-5111 x5085 fax: 071-581-8024
email: dme@doc.ic.ac.uk, ..!ukc!icdoc!dme, dme@athena.mit.edu
``Be selective, be objective, be an asset to the collective'' -- Jazzy Bdme@doc.ic.ac.uk (Dave Edmondson) (12/18/90)
In article <9012160738.AA20211@lightning.McRCIM.McGill.EDU> mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes:
mouse> [%] As far as I can see. What other benefits can the collective
mouse> imagination of the net come up with?
it's faster when you have lots of windows and you want to pan. with a
virtual root window, you move the virtual root window, without a
virtual root you must move (at least) all of the visible/to-be-visible
windows, and nieve implementations (like vtwm) move _all_ of the
windows _all_ of the time. not moving all of the windows does have
repercussions - what happens when a window that is off screen, but not
in the correct place relative to the real screen pops up a dialog box.
it presumably will pop it close to where it currently is, but that is
not really where it should be. it's a can of worms. i personally am
in favour of virtual roots, after having written code to do the `lets
just fake it all up' approach.
dave.
--
Dave Edmondson, Systems Support. Opinions are all my own.
Department of Computing, Imperial College of Science, Technology and Medicine,
180 Queen's Gate, London SW7 1BZ. phone: 071-589-5111 x5085 fax: 071-581-8024
email: dme@doc.ic.ac.uk, ..!ukc!icdoc!dme, dme@athena.mit.edu
``Be selective, be objective, be an asset to the collective'' -- Jazzy B