Slashdot Mirror
The Waning of the Overlapping Window Paradigm?
Bingo Foo asks: "The paradigm of movable, overlapping windows on the desktop has been around, and indeed dominant, for a long time. The original motivation for this was to mimic sheets of paper on a desktop. This is a useful metaphor, but may be a bit limiting given the capacity a computer has for automation of the layout and display of "desktop" objects. Lately, I have been pleased to see an increase in 'framing,' 'docking,' 'stacking,' and 'tabbing' being used, starting most conspicuously with frames in the web. More significantly, it has shown up as an application workspace paradigm that improved previously crappy MDI implementations in programs like Visual Studio and KDevelop. In my opinion, the most promising experimental application, even if still immature, is one of the neatest window managers around, ion. Does anyone else see a time when movable, tear-off docking and automated full-time tiling completely take over from the free-floating manually arranged desktops of today?"
would be nice to have transparent windows that you could see thru with an easy way of increasing transparency and opacity as required.
In reality, it was very difficult to duplicate, because it did not yet exist. Atkinson (Apple) ended up creating the algorithims to do overlapping windows on his own. At some point he was in a car accident, and there was alot of concern, because at that point, he was the only one in the world that had the knowledge.
That's one disappointing thing about today's GUIs, that there's no dialogue. The technology exists for the computer to, say, anticipate your next move, complete it ahead of time, and wait for you to tell it if it "done good" or not. For example, completing commands at a UNIX shell prompt is quite possible (in fact, it's been done before) and useful. One of these days (it's always "one of these days") I'm going to write a shell that does this.
Windows are a useful abstraction of display space and a useful way of dealing with user input. I wouldn't want to try to program a GUI without them. However, I'm not convinced that overlapping windows are not an unnecessary and cumbersome user interface element. I myself am an advocate of non-overlapping tiles as an efficient way for a user to manage his screen space.
Some say the web browser is the most popular GUI program. But the Web browser suffers from a whole host of problems. Just like the CD player programs that looks like the front of a CD-ROM driver, Web browsers only support plodding motion through the Web. The Forward/Back/Stop formula has got to go. A really slick Web browsing scheme that I saw at U. of Maryland, I think, provides a visual browsing history in the form of miniature views of past Web pages you've visited, with more recently visited pages still visible at about half the size of the page you're presently at, and pages visited very long ago appearing very small. I don't recall if the hyperlinks on the miniature pages could be activated, but I think that they *should* be, as that would make it really easy to move from one page to another if, say, you're at a Web directory of some sort.
I'm posting this is AC so it will likely never be seen, but I actually have no /. account (GASP!) and don't feel like creating one just for this post...
anyway, I've used ion for a month or so now and I think it is GREAT. Yes, partly because of the window arrangement issue. The normal paradigm, honestly, is retarded. But even moreso because it is designed for KEYBOARD users. I switch between windows and whatnot SO much faster now. I like GUIs, I like pictures on my monitor, etc, but I absolutely detest being forced to use a mouse. It's about time some people started realizing how inefficient a mouse is compared to a keyboard.
I'm actually thinking of developing an X toolkit designed to make it easy to develop apps that are both keyboard- and mouse- user friendly.. altho I've been reading up on xlib and it seems like a huge mess, so now I'm not so sure if I really want to do that.
Microsoft's new Visual Studio.NET implements some, if not all of this. Windows can be either free floating, docking or added to a tabbed set.
.NET supports, but it isn't how I work with C/C++.
I've not used it much yet, so I don't know what layout I'll end up using.
At the moment it is set up the same as my VC 6 layout - workspace in the top left. Output/Build windows tabbed in the bottom right and the editor window taking up the entire right hand side - I like to see lots of code at once.
The default view was way too busy - for example it showed compilation errors twice - once in the standard compiler output window, and once in a new "tasks" window that allows you to tick off the errors once you've dealt with them. Maybe this is useful for one of the other languages
It would be nice if this flexiblity with floating/docking/tabbing was in the window manager instead of the application; although, to be honest, developer studio is the only application I use with a large number of internal windows. Most applications are much simpler - tending towards a single view on a single set of data.
---
http://slashdot.org/moderation.shtml
acme is the primary text editing / programmers tool on plan9 and inferno
It doesn't use overlapping windows but uses rows and columns for text areas. One can maximise to size of the column.
there are no dialog boxes, turns out you don't actually need them. File/directory interaction is just in place (click on a filename in the current directory and ti gets opened [very useful for opening include files etc.]).
this also works for running programs. middle click on the command anywhere in any window and it's stdout gets opened in a new window.
try it and you'll see how simple and innovative such an approach can be. These plan9 guys are really on to something.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
As for ion, it appears to be a restriction on user ability, rather than an increase of user ability. I can already align my windows such that they don't overlap if I desire.
But I already have the flexibility of using my graphical interface almost entirely without my mouse. I'm running Gnome and Sawfish, and I can setup multiple desktops, indexable with alt-F#. Then if I keep the number of windows on my screen down to a reasonable number, no more than 3 or 4 (which is what ion would be limited to anyway for reasonable space consumption), then I can tab between them almost instantly with alt-tab. Then I can access them all immediately without the mouse, and without sacrificing the size of my windows, because they can all be close to full screen. As for organizing by graphical tabs, that's what the tasklist in the gnome panel is for, which is always an option when one feels the urge to reach for the mouse to find a window.
Every application I use regularly on my computer has an associated Sawfish shortcut. Mozilla, gnome-terminal, xmms, etc... Even shortcuts for common functions can be created in Sawfish, such as a shortcut locking the screen, shortcuts for raising and lowering volume, shortcuts for playing cd's (all using console-based tools, and the ability to bind a key combination in sawfish to the launch of arbitrary programs), shortcuts for closing a window, and shortcuts for bringing up frequently accessed files.
Excluding web browsing and copy/paste, I could go an entire day without having to reach for the mouse.
So, most current windowed gui's are based on the idea of a desktop, with file folders, documents you shuffle bach and forth, etc. Seems like what people are asking for here are some of the normal office desktop tools, tape, stapler, scissors, pen, etc. So, should there be a gui that has this kanda stuff, a stapler to link/stack documents, tape to bind stuff, scissors to split, pen to annotate. Any other tools that would work like this?
It also has an advantage for desktop users because these heavyweight applications have the unique possibility of using paradigms different than windows for managing documents/tools reducing the window clutter on the desktop. E.g. in a PIM several related applications are presented in one window (where if needed the different components can often be opened in a seperate window anyway); in an IDE it is common to have a form editor, code editor, class browser, debugger all in one window.
But there are other approaches that can be taken. I've read dialog windows in MacOS X stick to their owner which is nice because it reduces the amount of windows you have to manage. X window managers could probably implement this feauture pretty easy.
But more can be done, e.g. it would be nice if there was a Nautilus-like panel on the right side of the screen in which things like music players, instant messengers, calendars, RDF-boxes, etc. could be embeded (these would be Bonobo components or KParts). An idea would be to model the panel after Nautilus' sidebar, only when hiding a tab the panel should disappear completely except for the tabs at the bottom of the screen.
In conclusion, it would be nice if the desktop environments started to work more towards reducing the number of open windows rather than taking the GLADE appraoch where there's a window for the menu and tool bars, a toolbox window, a property window and a window per form. (Yes, I know of workspaces but that ruins the advantage of windows even more.)
Monkey sense
A good example: I do computer support, and sometimes I'm looking at the logs for two computers to compare and contrast events between them. I need a certain amount of the log to be present, I need enough width that line wraps don't hose the legibility of the log, and I need to switch between the two windows easily to compare them. If they overlap, a front button (handy on my Sparc workstation) lets me switch between them without mousing, and away I go.
If I had to make the two windows fit on screen at the same time, it would be an enormous pain.
It's all about giving me the freedom to work how I work best; if any window manager refuses to allow me to use the paradigm I know and love, I won't fscking use it.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
I've been thinking about this for a while, nothing frustrates me more than having windows obscured behind something else, and having to either drag the front window out of the way, or else alt-tab through everything. In a lot of ways this is what first got me hooked on linux as a desktop replacement for windows, the well developed multiple desktops system. So I can hit a key combination and cycle from one desktop to another. One has my mail and IM open on it, the other one browsers, the next nothing but terminals, and then filemanagers/xmms.
A lot of application shave taken a better look at how they're actually used. Sometimes the UI is bad bad bad (StarOffice 5.2). Other times it's really appropriate, like the tabs in galeon which are great for organizing all the browsing into different windows based on subject (for those of us that like to have 20 pages open at once. Right clicking to open in a new tab is great for s site like slashdot, K5 or Adequacy, where there might be 7 or 8 links on the main page that i want to get to, but not forget if I get sidetracked.
When I first grasped mozilla's power as a platform I had the epiphany that since 90% of the apps I ran were network based and mozilla provided an API for creating spiffy looking network applications, it wouldn't be a stretch to do everything in tabs within one maximized window, and that it could eventually function as an OS for lightwieght computers. If you type chrome://messenger/content/messenger.xul in mozilla you can get the entire mail application dropped into your browser window. Press ctrl-T on a recent build and you have a new tab to browse in, but you can switch back to your mail real fast. Add Jabberzilla to your sidebar. Throw in a few more apps from MozDev.org and you can do most of what you'd want within a single window. It's in no way complete or stable, but it's enough to shed some light on a usable way to avoid the worst of window overlap. Apparantly there is a company that's working on using mozilla as an operating environment for appliances called OEone. You can check out the screenshots of their calender application here.
We already have a modern successful non overlapping interface, and it's called PalmOS. Just as it took a limited use platform to accept "modeing", probably not a lot of desktop users will be willing to give up the poer that free windowing gives them, but for appliances, or special uses, such as subject-centered web browsing. Things like tabbing and fullscreen interfaces are a good idea, and have already been implemented.
Metamuscle.com - News in the Iro
Anyone with Oberon experience out there?? It started out as a tiled windows system only, but now they've developed an overlapping windows desktop as well. Checkout the screenshots.
Their comment on tiled display is useful: The Gadgets desktop also has a tiled display mode with two vertical tracks. In this mode a newly opened viewer automatically covers half of the largest existing viewer in the track. This is ideal for text-based work, e.g., programming or text editing. Viewers can be resized vertically and moved, but they always use the full track width. Because there are fewer degrees of freedom, it is much quicker to arrange viewers optimally. newly opened viewer automatically covers half of the largest existing viewer in the track. BTW, windows are called viewers in Oberon.
XMMS does it already.
That's not quite how I mean. As an example, take Kate, the KDE editor. It has 3 panels - a tree view to the left, and to the top right an editor and below it (bottom right) an xterm.
I would like to be able to, as a user, create this same layout using, say, konqueror, nedit and an xterm. I'd do something to tell the window manager to stick them together, and I would be able to resize the edges, and have it affect all of the windows. And save the configuration so I can start it up again easily.
OK, kate already exists so I don't need to do this, but how about if I wanted an instant messanger attatched to the side of it, an irc client underneath it, and a news ticker underneath that, and I want it all to act as a single window, where I can resize any set of the programs without overlapping?
Hey, go the whole hog and find an easy way to send messages from one of the programs to another and bingo! the user suddenly can create his very own programs out of small components - the gui equivalent of the command line philosophy perhaps?
Interesting, now all you need after that is the ability to draw pipes between the windows, say drag the output of your xterm to your IM chat window and so it will send the output of your xterm to whomever you want via your IM software. The xterm might be a bad example, but you get the idea.
I use a window manager with virtual desktops (FVWM2). On every desktop I have either lots of maximized Mozilla windows, or a couple of xterms to the left (mximized vertically) and one Emacs window to the right (also maximized vertically). I switch between desktops using the mouse, and between windows by pressing F2 (which rasies or lowers the topmost window under the mouse). This works well for switching to the right xterm or browser window. Focus is always on the topmost window under the mouse, of course.
This way I get all the advantages of a tabbed interface while still being able to use the window manager like an ordinary one when that would be useful.
My windows are borderless, but they have a titlebar. I use the titlebar or F1 for moving them around and button-3 on titlebar or F3 to resize. F5 maximizes the window.
Noone thinks of Ctrl+C when they need to copy stuff, they just put their pinky on the Control key, and press the key which is about 7 cm to the right and 2 cm above.
Sorry, but the guys who actually sit around with stopwatches (and, occasionally, EEGs and CAT scanners) to quantify this sort of thing disagree with you.
Think of muscle memory as the instruction prefetch cache on a CPU. Yes, if you "hit" the cache, you'll execute the instruction faster than if you didn't. But there's still a delay involved, and (important bit here) some caching strategies are more efficient than others.
Keyboard shortcuts are a lot more intuitive to muscle memory than mouseitems can ever get.
The research that Tog cites proves the exact opposite of this claim. Where is the you research supporting it?
News for Nerds. Stuff that Matters? Like hell.
I am short of time, but this is in my opinion the killer app (window manager app) waiting to be fleshed out.
.fvwm2rc, throw out nearly
I got on a window manager kick this week and tried ion, wm2, wmx, and about 8 more. I don't care for Gnome and KDE, call me a minimalist.
I really like w9wm, which is a version of 9wm with 4 desks. It's very clean, no icons, no title bars.
I am now using fvwm2. I took the stock system.fvwm2rc and threw out everthing that said 'icon' in it, threw out the title bars, and in short made it look like 9wm. The mouse wheel switches desks, there is a _small_ pager in the lower right corner, you can move a window from one desk to another in the pager with a mouse. I did not use pages, i.e. a larger virtual screen, because windows bleed through (overlap) from one page to another. With desks you can push a window partly off the side w/o interfering with the next desk.
Anyway, fvwm is _customizable_ and a good place to start to try out different window manager ideas.
Take the stock
everyting, and start from scratch. I love modifying this thing. If you use the style MinOverlapPlacement, you can pop up xterms tiled.
Aside: I have hated mice for years and preferred a trackball - until I got a Logitech Optical wheelmouse, the $29 one not the $19 one. Wow. Mice are more efficient for some tasks, the Happy Hacking keyboard for others.
Think of muscle memory as the instruction prefetch cache on a CPU. Yes, if you "hit" the cache, you'll execute the instruction faster than if you didn't. But there's still a delay involved, and (important bit here) some caching strategies are more efficient than others.
Okay, I agree with you here. But let's just think about this. The difference is that you can create muscle-memory for specific keys (you've probably done so for typing regular text, for instance). You are able to do this because you know where every key is on the board. Where's the "ctrl" key? You already know exactly where it is. Where's the 'v' key? You don't even *think* about it, you know know how to hit it, and you've easily pasted something.
Now let's take the other method. Where's the "paste" command? You know, automatically, that it is in the "Edit" menu. You reach over to grab the mouse. Where is it? While limited by the size of the mousepad, it can be in any number of places. But you grab it. Now, where is the Edit menu? Is your window in the normal place in the screen? Is the cursor always in the same spot? Probably not, so now you have to drag the cursor from its (normally non-optimal) location over to the Edit menu that can be anywhere on your display, and and only THEN select "Paste".
The difference is that there are so many variables in using the mouse, that it is very difficult to develop a usable muscle memory. Don't believe me? Wait until you go to someone's computer where the mouse has a different acceleration value, or a different mouse-click speed, etc. etc. Then your muscle memory disappears. I'm not saying that a keyboard is infallable (I'd be lost on a Dvorak keyboard, for instance), but the changes needed for my muscle memory to be hindered are much greater.
Long Story Short: A keyboard is simpler, with less variables, which makes for a easier time learning to do tasks quickly.
The research that Tog cites proves the exact opposite of this claim. Where is the you research supporting it?
Um, I didn't see ANY research cited in Tog's article. I just saw him claim that the research shows it. Where's the reference? Actually, I'll just claim that the research proves that Tog is wrong, and provide the same amount of references that he does, right here:
The ideal interface, in my opinion, would be to support nesting of window managers within other window managers and/or within applications. The biggest problem with MDI is that every MDI application basically acts as its own window manager. Usually this "embedded window manager" is a really crappy one, which turn people off to MDI in general, but there are exceptions; my preferred browser and text editor both use tabbed document windows to very good effect. It would be cool if we could tell applications what window manager instance (WMI) to use, so that the app can delegate window management to the WMI of the user's choice. Want SDI? Tell the app to plop its subwindows into the same WMI as the parent window. Want MDI? Tell the app to plop its subwindows into a WMI ("using *this* window manager, please") embedded within the parent window. You could use the same interface to switch between a Mac-style single menu bar and Windows-style per-window menu bars. All of this could go into a fairly simple config file, allowing users to choose whatever combinations of overlapping/tabbed, MDI/SDI, Mac/Windows styles - including hybrids and mixed modes - that they want.
Slashdot - News for Herds. Stuff that Splatters.
I recall this was the case. This was supposed to
avoid Apple patents by reverting to a Xerox look.
No one really bought Windows until version 3.1
and MS Office requiring it.
So I thought that windows should expire after some amount of disuse. They should _become_ something like bookmarks (searchable by metadata (title, keywords, URL, full text, etc.), and also organized in a timeline, and also organized in a graph of branching - which link did you follow to get there?) automatically.
On either a tiled or overlapping desktop, the constant is that being able to minimize or collapse windows to remove them from the screen is important. But on a tiled desktop it would be even more important than usual. And I think the GUI mechanism for selecting from all open windows (including minimized ones), which one to view, is very important. I've recently fallen in love with the KDE "external taskbar". I put it in the upper right, enable auto-hide, and now it's very Mac-like, and compliant with Fitts's Law - I can slam the mouse up into that corner and I get a nice list of open windows, organized by which desktop they're on, without regard to whether they are minimized or not. There is enough space to show more of the title bar than you get on a typical minimized icon in WindowMaker, or a on one of those taskbar buttons on Windows or Gnome, yet, it still doesn't take up a lot of real estate, and still has mini-icons too. I can manage many more windows effectively this way. And it's rather like a stack of books (an approach to organizing information which has been advocated elsewhere).
Anyway for many purposes I like the idea of a tiled desktop; especially for "reference materials" which I need to glance at, but not interact with quite as much. But I think the user needs a very straightforward choice when spawning a new window, whether to take up space in the tile matrix for it. Maybe something like click with middle-mouse button on a link, to open it in a new tile-space; and click with left-mouse to open it in the same space, in a new window lying on top of the old one. So each tile-space becomes a stack of windows. (And I'm imagining a GUI in which most navigation is a lot like navigating hyperlinks.) Of course, every time you must make room for a new tile-space, it's liable to cause most other windows to be resized; and controlling that is tricky. Using virtual desktops effectively can help with that. It needs to be easy to move windows from one desktop to another, _and_ place them into the desired tile-space, in one fell swoop, without a lot of mousing around, or thinking too hard.
Maybe there should be a window manager which gives you a choice for each desktop - tile or overlap. I would bet quite a lot of money that will be done by somebody in the next few years.
Two words: keyboard navigation. In the Windows world at least (yeah yeah, bite me), anyone who bothers to learn the relevant keystrokes and combos can whoop the pants off a mouser in basic, nuts-and-bolts text editing tasks like selecting ranges, cutting and pasting, applying attributes, etc. Why? It's not the amount of time it takes to reach for the mouse; that is as nothing against the amount of time it takes to orient hand/mouse to screen/pointer, navigate the pointer to the appropriate button by eye, and click. I type 100 wpm on a good day, and my fingers know exactly where to go at all times. The visual interface is fine, but (for me at least) it lacks the benefit of proprioception. When I use the mouse, I am forced to stare at the screen in order to be sure of the result of my mouse movements, whereas I always know exactly what my keystrokes are doing without having to look.
For example, in most Windows text editors, pressing Control-left-arrow moves back one word. Further, holding Shift while using any navigation key combo changes the navigation action to a select action. Therefore if, for example, I want to select the paragraph I am currently editing, all I have to do is press Control-Down (end of paragraph), Shift-Control-Up (Select to top of current paragraph), and it's done. Elapsed time, about a tenth of a second. A couple more keystrokes and I can cut or delete the paragraph, add formatting (B/U/I, justification, etc.), and so on. Compare that to the time it takes to lay your hand on the mouse, move the pointer to one end of the paragraph, click and drag to sweep out the paragraph by eye. No contest.
Heck, my typing speed wouldn't even be what it is if it weren't for keyboard shortcuts. As an instinctive touch-typist, I seldom miss a typo as I go along, and by now it's a perfect reflex when I notice I've just mistyped to press Control-Shift-Left and retype the word - elapsed time, maybe half a second; expended effort, negligible.
"The deep-fried Mars bar is a symptom of a wider crisis." -- Nutritionist Ann Ralph, on the Scottish diet
The overlapping windows is just one of those things that *just plain works* in a "desktop" paradigm. If a familiar enough environment is created, the the user can come up with uses that the programmers probably never would have thought of. Someone earlier was mentioning overlapping logs to compare very specific bits of data. This can come more and more into play when dealing with multiple applications. Too lazy to pick out a color in some html code that you liked? Want to use it in Photoshop? Put the PS window over the Web Broswer and eyeball it. This, as I understand, is seen more in the Mac environment than in Windows (I dont use the Win too often, dont flame me if I get this wrong here...) But doesnt Windows (or the programmers for that matter ;-) put like a huge grey background behind all the Photoshop windows? And also I'm pretty sure all such windows have several pixel borders on them... But of course some of this is invalid since there isnt a released version of PS for OSX, but still. Also, the ability to organize windows independently of what application they belong too (unlike OS9)...
;-)
A lot of people may not like the OSX interface for some of its fancier bits (transparencies and such, which are becoming just as prevalent with XP and such) or some of its new strange functions (the dock) but the whole point of this is: create a really, really familiar metaphor and make sure to take it all the way - include all the little details. If you're going to pretend to have a "desk-top" things typically shouldn't have big borders or controls around them (not to mention coloring, thank God Apple included graphite in OSX...), or be limited in the order of the stacking. The more inconsistencies from the supposed metaphor that can be eliminated, the better. When something is consistent, if not with the entire metaphor, at least with itself... maybe just maybe the user will come up with uses unknown to you (especially between applications.)
Ok, youre all now cleared to pick away at any holes, inconsistencies or inaccuracies in my comment.
The overlapping window paradigm makes the user's desktop a mess.
Thats perfectly fine with me, my real desktop is a mess too and I wouldn't have it any other way.
When I'm done or want to pause work on something I leave it open and just put another window on top of it slightly offset. This only wastes virtual screen space when I pan over to the center of the new window.
Too much stuff? New workspace! Wouldn't you love to have that on your real desktop?
Having 5x21" displays with a slightly larger virtual resolution than physical helps too but I started this using 1 15" display a while back.
Now days big monitors aren't as expensive as you think if you're willing to muck around enough with old fixed frequency workstation monitors.
>That depends on one huge-arse variable: where the menus are.
Absolutely. Like I hinted at, Fitts' law will tell you that going to a menu like the Macintosh ones is fast and easy. However, a memorized hot-key will still be faster depending on where the menu item is in the menu.
Studies show that the 2rd or 3rd item is usually the fastest to get to. If your menu item is nested, you also have to take into account the possibility of overshoot, etc.
There is certainly a balance somewhere in there. I like my hot-keys, but I can't deny the usefulness of menu items. In the UNIX world, however, where everything is text-driven (mostly) anyway, it's usually faster to do some memorization.
In the OSX world (where I'm happily typing this from, I might add), the GUI actually extends the interface experience. I'm much more willing to use the mouse now than I was before. In Windows, I feel crippled. I haven't put any time into memorizing the interface, so I'm constantly using the mouse to get things done, and I feel like the productivity is draining out of me when I do it....
I work at an R&D center which has been developing exactly this technology, and it can be done because it has been done, using standard PC's and off the shelf graphics accelerators. The work I do is for military applications, and has not been publically released. However, you can imagine it as a game of Quake in which there is one room and a number of applications running in picture frames on the walls.
[We found that other groups are doing similar things, and our project is a bit like one at Microsoft. See Task Gallery for some interesting visuals]
In our project, we can run both Windows applications and remote applications via VNC (virtual network computing) as active applications on the walls. We have additional applications which are 3D in nature, like a globe of the Earth and a terrain viewer which sit on tables within the virtual space. Navigation is done much like in Quake, with keyboard and/or mouse movement moving the user within the virtual space. We have figured out effective methods of dealing with application focus and other UI issues typically encountered in the design of windowing systems.
My personal opinion is that such a 3D windowing user interface has benefits and drawbacks (no kidding, eh?). It has proven useful in military applications in virtualizing locations like command centers, which are 3-dimensional in nature. Military people who are not heavily into computers tend to be particularly receptive to a UI which resembles the physical operating environments they are accustomed to. I'm not sure that you'd want to (or need to) use a text editor in a 3D environment for long. In recognition of this fact, we provide a way of switching between visualization modes, bringing applications to the front as 2-dimensional displays and returning them to the wall surface they were on.
The spatial awareness issue you mention is actually one where I think 3D can be beneficial. For instance, given a virtual space which has distinct walls on which applications are running, it might be the case that you could locate a particular text document more efficiently than by trying to remember which of the emacs icons in the task bar represents which document. We are still researching such issues, and it is not yet clear how effective 3D space is at aiding visual memory for task completion.
-=-=-
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
Okay, I just downloaded and installed Ion. While I appreciate its many keyboard shortcuts, I think the real power it possesses is the ability to all but eliminate unneccessary window-resizings.
Think about it. There are only two reasons people resize windows: (1) To focus on one particular task (window), or (2) to focus on more than one task/window, without eliminating the first focus. (The case where the user wants to switch between focuses or close the current focus in most windowing systems are handled by mechanisms like taskbars and close buttons. ). Most of the time users spend in 'focus adjustment' is simply futzing with the window borders in an attempt to maximize screen coverage while preventing overlap. Even 'timesaving' options like 'tile windows vertically' are usually wasteful, because, while they speed up the initial operation, the minute you attempt to make a small alteration to your focus (say, by making one window a little larger) you actually have to perform two or more tasks: Resizing the window under consideration and resizing its neighbours to concur with the new arrangement.
Since a framed-window system allows adjustment in a single motion, it saves time. (Although there are other window-management paradigms that acheive the same trick).
Personally, I really really like Ion -- I'm running it right now, and I have no intention of switching back to Oroborus any time soon (another very good window manager, IMO....)
- undoware.ca
If you mostly use terminal apps, try using "screen" as your primary switch-between-programs environment.
I always have the same app running at a particular screen number, so switching never takes more than a second. Editor? ^]0 and I'm there. Email? Mutt is running at ^]1. News? See slrn at ^]5.
I've been using this type of setup for a year now, and it's great! I almost never interact with my WM at all, and have disabled all window decoration.
These sounds just like the arguments for why I should give up my archaic (but very well understood by me) vi editor and use that other one (you know, Eight Megs And Constantly Swapping?).
Actually, that'd be the other way around (switching to vi, from that other... well, you know).
I see your point, and I'm not trying to get people to switch if they don't want to. I'm merely trying to clear up some of the confusion about how Ion handles frames and tabs. (I know it was a little confusing to me, untill I started to play around with it).
To each his own.