Slashdot Mirror
Resources for Rolling Your Own Windowing System?
WalterGR asks: "There are plenty of resources available for writing operating systems, e.g. Tanenbaum's Modern Operating Systems, the Dinosaur Book, and countless web sites. For those of us who aren't interested in low-level issues, and prefer focusing on human-computer interaction, what resources are available for designing windowing systems (a la X Window)? Issues like the object hierarchy, event management, modularity, redefining behavior at runtime (e.g. for skins) etc. Any suggestions?"
Of course, MS's window system is a classic example of how to break all of the established rules about GUI design.
If you rool your own, don't copy the mistakes made by MS/Apple/Xerox. GUI research has come along way since those days. Alas, we never see the results because of the entrenched WIMP paridgm - which is very out moded.
In addition, many of the things learnt through WIMP have been successively undone my MS.
For example, menus at the top of the screen (ala MacOS) worked well because a user's motor memory it trained to select items. The functions become motor program - like learning to play a piano.
Unfortunately, this is broken if the menus change (e.g. MS's idea of hiding items and them bringing them back, moving them around etc.). It also doesn't work for menus on window titles - as you need to overload your visual system to select the menu to begin with. Only context and screen top menus retain the original design a pros of menus these days.
There are many many other examples like this. I sugest you find some books on human factors and learn how visual and motor systes work etc.
/..sig file not found - permission denied.
My word processor was written by Stanford Professor Donald Knuth. Who wrote yours?
I see (at least) 3 distinct levels, and I'm not sure which one your question addresses.
1. Low level graphics manipulation. I would put X here, although X includes network transparency. What I see at this level is graphics primitives. How to draw a circle, a line, a rectangle, draw characters of text in a certian font, etc.
2. A window manager / widget toolkit. There are already five million of these for Linux. They can be fun to write and educational. But don't have any delusions of gaining significant market/mind share.
3. Human-Computer interaction. User Interface. This is more about human psychology than it is about technology. Read some good books like The Design Of Everyday Things. Apple Human Interface Guidelines. (Apple's developer web site.)
Your question makes fairly clear you aren't interested in (1). But it is ambiguous whether you are interested in (2) or (3). If you're interested in (3), then join either the GNOME or KDE projects and contribute ideas and effort that don't involve writing code.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
Why not keep X11 the way it is, but have X11R7, or X12, which has all those dangling extensions internally as a requirement.
It could keep almost 100% compatibility while making a "better" GUI system.
The problem with that though is that you are forcing the user of the GUI to be a fat system. Right now, you can run X11 on an Ipaq with problem. If you start throwing the kitchen sink in as a requirement(the only way to enforce the standard), you are also abandoning a potentially large share of your market. The beauty of X11 as it is today, is that you have the choice in what you want to use, and what you don't. XFree86 does not make the pluggable nature of X11 as clear as it should be, but none the less, I like the flexability and scalability that the current system offers.
Bye!
The Model View Controller framework abstracts the three separate components of a basic user interface. The Model is the data. This might be a double subscripted array of numbers or a tree of arbitrarily complex nodes. The Controller is probably a keyboard and mouse. There would be some driver code that would deliver mouse and keyboard events to the object currently in focus (or to what ever object registered itself as an event listener). The most important and more sophisticated of these three components is the View.
The View is an area (usually rectangular) of the display device such as a monitor or printer. The key principle behind a view is that it's potentially the child of a parent View. Thus each view may contain subviews each with their own coordinate space. Within a view graphics primiatives and subviews are drawn to create arbitarily complex grapical interfaces. Because the translation to display device coordinates is handled by the graphics context passed to all drawing functions (Graphics g in Java AWT), the implementation of a subview may draw it's widget with respect to coordinates 0,0. This makes it very easy to integrate new custom widgets (widgets stands for "Window Gadgets"). So, for example a frame is a View with a border, a label, and maybe a scrollbar. It has two buttons, some text, and another frame as children. The button is a View that contains a border decor and some text ... etc. This follows the process of Recursive Composition. There is a good description of Views in the BEOS documentation which unfortunately I cannot link to because BE has apprently disabled much of their site. I would appricitate it if someone could point me to a valid link to the description of the BView class.
Ironnically, this framework is repeated in software over and over where only one would really be necessary provided the API were general and flexible. For example, the X-Window system is an MVC framework. But Mozilla has it's own MVC framework for drawing GUI components. Then within Mozilla's rendering engine Gecko is another MVC framework for rendering html components.
In this last case of Gecko, I can understand why they would not want to use a generic windowing MVC API; the layout of components is very strict in that images, links, and the way text flows around components is required to behave in a certain way as to conform to the various associated standards such as CSS and DOM etc. It would be interesting and simplify things tremendously if one could reduce and refactor one unified implementation that parameterized all the different requirements of these MVC frameworks. Then custom components could be potentially integrated into previous unrelated applications (e.g. vi in xterm as the text area of an HTML page).