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?"
First you need to ask yourself if you really want to recreate the XWindows System or if you want to create a window manager like Enlightenment, fvwm, etc. If you want to recreate the years of work that has gone into X, that's your choice but I think you should look at creating a window manager, you'll probably get farther.
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.
There is not a lot of information beyond some of the linux toolkit developers or Xfree / X Group, simply because this is not a very large arena, and there just isn't enough interest in creating another interface for user applications(flamebait).
The problem is that when a user needs to write a program they have to be "aware" of your toolkit, or be unable to run on your machine.
The result of all this has become a very constrained community of developers creating tiny visual enhancements and having the community feed off their ideas. This has been going on for > 10 years, at least. Mac's are probably the most original designers of UI system, since most company's products mimmic their styles and design elements.
Bye!
No, please, not another windowing system. X11 is fine for most purposes and, if you need something is does not provide, write an extension. There are more than enough 'alternatives' that are either designed for niches, have never been finished or will never get a significant marekt share. They don't have any significant advantage, at least as a general window system, and they lack applications. And despite those people who claim that X11 is sooo bloated (usually because they see the memory usage and do not realize that most of the memory is taken by pixmaps that won't take less space in other solutions) there are proofs like TinyX and WeirdX.
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!
OWL and MFC were both written to create an OO shell around the pre-existing Windows window-management stuff. In a sense, they are hacks, not clean-sheet designs. As a result, they have some rather odd characteristics (well, at least MFC does - I haven't used OWL).
So it may be that someone interested in starting from scratch on a new, OO-based windowing system would be better served by studying something else, like Java's AWT or Swing.
Hmmm, I think I'll have to go ahead and sort of disagree with you there. DO write a window manager, but get it right. Make it comfortable, not beautiful, like all the others. Usability, not skinnablity. There are tradeoffs which have not yet been made. Waste processing power on aiding the user, not pleasing his eyes.
There are many possible cost metrics. One puts the most value in the most commonly used cases - if 99% of all users are local, focus on them and drop remote users.
Another valid metric tries to minimize the cost of the legitimate, but rare, users. Network transparency has a small cost, but it's critical for the people who need it.
Yet another valid metric tries to minimize the cost of development. It is extremely cheap to develop X Windows applications in the sense that the API I learned a decade ago is still in use today. Motif has come and gone, and there are now several additional toolkits, but it's nothing like the mishmash that Microsoft has produced in the same period.
(On a similar note, compare how little C has changed between K&R C to ANSI C9X, vs. the massive changes Visual Basic has repeatedly suffered in far less time.)
Yet another metric tries to minimize the cost of developing new drivers. The X wire protocol is well documented, and anyone who develops a driver that speaks it (as either client or server) can be confident that their code can be widely used. Non-wire protocols tend to mutate far more quickly, either decimating the potential user base or driving up development costs.
Put it all together, and the costs of network transparency are outweighed by its many benefits for all but the most demanding local users. And even they gain from it, albeit in more subtle ways.
Is X perfect? Of course not, but many of the "flaws" were actually design goals for long-gone hardware. When was the last time you used a monochrome dumb terminal? The wire protocols need to be extended to reflect the fact that commodity PC prices are now far lower than dumb terminal prices - use the power of those systems! But the key word there is extending the protocols, not replacing them. E.g., make the font system more flexible.
But at the same time, at least once a month I find I need to run an X session remotely, and I can do that from both Unix and Windows boxes. I have never been able to run Windows remotely, although I've heard that BackOrifice is pretty good for that.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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).
I've been working for about 4 years now on a graphical user interface for dos
A graphical user interface for DOS? What a novel idea!
my other penis is a vagina
I agree!
:)
You should spend your free time doing what I want you to do because I'm to lazy to do it myself, rather than what you think would be interesting and fun to do yourself.
duh
Anyway, irony excluded, the guy is speaking about a windowing system (think X) rather than a window manager (think fvvm). Don't confuse the two...
May we live long and die out