mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (06/22/87)
In article <668@unicus.UUCP> craig@unicus.UUCP (Craig D. Hubley) writes:
<Also in this vein, pop-up menus quite desperately need to be supported.
Amen, brother. Especially with one of the AutoPoint/SunMouse daemons.
<Need comment from Sun and Smalltalk folks.
I've only played with SmallTalk. I've made fairly heavy use of two Sun
window managers (X and Suntools), and am in the process of learning
another (NeWS - pronounced knee whiz).
Forget X. It's a server, with a collection of window managers you can
choose from. The window managers are so poor that people run without
one. Problems like having to drive them with two hands, no border or
gadgets on windows from the managers, so each tool does window
management type things in it's own way. Yuck.
Suntools is a little better. There's a border, which (along with the
bucky keys) lets you do most things you want. It also implements the
"point to an object, now get a pop-up menu of things that will happen
to this object" you described (at least, I think that's what you
described). The result is very nice. Wish the Amiga had it.
NeWS I'm still learning. It looks like someone took the best features
of Suntools + the Amiga interface, and melded them. So far, I haven't
found anything that would contribute to this discussion (except I'd
like round windows). It's a server (like X), so other window managers
incorporating new features will probably appear in the future.
Both NeWS and Suntools support something that I miss a lot on the
Amiga: there are function keys to circulate or iconify the current
window. [circulate: If the window is partially covered by another
window, act like WindowToFront. Otherwise, act like WindowToBack.]
Both Suntools and X have the concept of a standard way to describe
where to put a window that you can use at command startup. My
placewindow command is an attempt to move in that direction.
NeWS and X also support "user-placable" windows. You point and click
on what will be the upper left hand corner, then get a rubber band
square with the cursor as the lower right hand corner. Click again and
you've just described the window. I don't use that much, but it's
kinda cute.
Those three things, pop-up menus, window management on the function
keys (which you can do with daemons), and more control over window
placement at program startup, are what I'd like to see added.
JimM has provided a way to put window management on function keys;
placewindow does half the window placement magic (hmm - maybe I could
hack it to do the other half....). Anyone want to try writing a
function to do popup menus that you use to replace SetMenuStrip?
< - it has multiple screens analogous to a "rooms" metaphor,
< to support multiple classes of user tasks. That is, Workbench
< for doing file handling, VT100 for talking to big boxes, Hack while
< waiting for downloads, a fake spreadsheet to fool the boss, etc.
< All with a very convenient way to move them around. This approach
< is JUST NOW being picked up by the research community, and the Mac II
< missed it by going to a large "virtual desktop" which Xerox studied
< (as "Bigscreen" I believe) and discarded because "rooms" was cleaner.
I'm sorry, I have to disagree. I'd much rather have everything on the
same screen. I figure the support for multiple screens is a hack to
get around other things that were done to keep the cost down. In other
words, doing it right would involve enough chip memory, enough
bandwidth and a screen to allow everything run on a single INTERLACED,
HIRES, morerowed screen. Since that's a bit expensive for my blood, I
appreciate what they did.
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@berkeley.edu
How many times do you have to fall ucbvax!mwm
Before you end up walking? mwm@ucbjade.BITNETbryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/22/87)
> Both NeWS and Suntools support something that I miss a lot on the > Amiga: there are function keys to circulate or iconify the current > window. [circulate: If the window is partially covered by another > window, act like WindowToFront. Otherwise, act like WindowToBack.] Conman does this for it's windows. Unfortunatly this is "incremental" meaning you get to watch the window move, then size. Here's a wish for a way to set all the window parameters at once, THEN have Intuition figure out what to do with it. (V1.3?) If I can learn a bit more about Layers and/or Intuition, my ClickToFront program would like to be expanded to: 1> Verify that for both clicks that the pointer is over the same Layer (Window) 2> Discover if that layer is the upfront Layer for circulating. 3> Verify that the first click was an "activate" click. All this stuff is really the realm of Intuition. Unless I can ask Intuition which window the pointer is over, it won't happen. << - it has multiple screens analogous to a "rooms" metaphor, << to support multiple classes of user tasks. << [This approach] << is JUST NOW being picked up by the research community, and the Mac II << missed it by going to a large "virtual desktop" which Xerox studied << (as "Bigscreen" I believe) and discarded because "rooms" was cleaner. < < I'm sorry, I have to disagree. I'd much rather have everything on the < same screen. And I'd rather have the separate screens. The "rooms" or "screens" reduce clutter and give a complete isolation if that is wished. MWB (Multi-WorkBench) is a great tool for uncluttering the workbench and dumping the excess windows into other screens. At any one moment 10-15 programs are avaiable on my Amiga. Most in screens so they don't bother whatever I'm doing elsewhere. > I figure the support for multiple screens is a hack to > get around other things that were done to keep the cost down. I think the reason is the vast flavors of video that are available. The copper does a complete screen context-switch at the top border. Imagine trying to open a H.A.M. window in the standard workbench screen. If there was just one video mode, and say 24 bitplanes of depth (so there can be no argument about the pallete) then this would not be as much of an issue. > In other words, doing it right would involve enough chip memory, enough > bandwidth and a screen to allow everything run on a single INTERLACED, > HIRES, morerowed screen. Since that's a bit expensive for my blood, I > appreciate what they did. The more space available, the more that can be said for doing it on one screen. 704*464 pixels is just not enough for my windows to be comfortable in just one place. Talk to me at 4096*8192 and I'll reconsider. --------- Ack! (NAK,EOT,SOH) |\ /| . {o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce ( " ) U Single tasking? Just say *NO!*