Jesse Ross wrote: > I don't know that the "windows can't overlap" paradigm really makes sense > when you have a lot of windows open. Maybe you can convince me otherwise, > but I think only being able to see a tiny part of a window at once would > be very limiting -- and would lead to a lot of scroll bars on the screen > at one time.
But the entire screen is scrollable. This is how my idea differs from every other tiled-window interface (that I know of). It doesn't just try to cram everything to fit into the screen. Again, in my scheme there are three types of windows: - Manually-sized. - Automatically-sized. - Locked. How they are sized: - A manually-sized window never changes its own size: only the user can do so, manually (i.e. by dragging the sizing handles on the window). How a manually-sized window responds to manual sizing is up to the application that powers it: it may scale its contents, or provide scrollers, or whatever. If there are two manually-sized windows side-by-side, and they are wider than the screen in total, the screen has a horizontal scroller that can be used to bring them into view. - An automatically-sized window dynamically changes its size to fit available space in its container. An automatically-sized window will never have scroll bars. - A locked (closed) window also dynamically changes its size to fit available space in its container. It is only an icon, and never gets bigger than some specified size. There would never be a lot of scroll bars on the screen at one time, unless the user explicitly sized windows to be this way (as they could in any overlapping window interface). I really need to write that article soon to describe this... I'm not doing a very good job.
