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?"
Take a look at the object windowing libraries put out by several vendors. It should give you a good footing on developing your own object hierarchy.
As for not getting into 'low-level' stuff, you're SOL if you want to build an X-like system.
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.
That windowing systems and HCI are distinct. Windowing systems is a component of HCI, but so is command line interfaces, voice interfaces, and graphical interfaces.
Windowing systems is one metaphor applied to graphical interfaces. HCI includes the concepts of learnability, consistent behavior, teachability, and useability.
I'm defining learnability as the capacity for the system to teach the user, and teachability is the capacity for the system to adapt to the user.
Windowing systems doesn't necessarily have anything to do with any of those four points unless the designer and developer choses to address those points. Themes and skins count as teachable, adaptable systems, but do not necessarily mean the system is useable, powerful, or capable.
GPL Deconstructed
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.
I've been working for about 4 years now on a graphical user interface for dos as a pet project, and have learned a great number of things. So many, in fact, that i'm in the middle (still) of rewriting it. If you're intreseted, the website is http://dwin.sf.net/ and is open sourced. When the new version comes out (or the next preview) one could use it to see how it all fits together. This would be better then trying to use XWin to learn how everything works because it is smaller, simplier and very OOP (which is great for windowing systems). And yes, most of /. will call me crazy for reinventing the GUI, but heck, i've learned so much about computers in doing it that it's been a real fun time.
-Jon Gentle(atrodo@atrodo.org)
Operating systems have so much material available because there's science involved - there are a few things that can be proved (e.g., shortest job first, lock-free / wait-free synchronziation primitives, Belady's FIFO anomaly) which should be known to everyone starting to practice. There is also a considerable accumulated body of knowledge which, though not based on solid math, has reached a "common knowledge" status.
The same cannot be said about windowing systems. The algorithms are well documented, but there isn't much connection between them and actually building a windowing system. Building a windowing system is an art more than science or engineering - a system that's a masterpiece to one is considered bad practice by another.
That said, if you want to learn from a system IMO exceptionally well balanced between doing things cleanly and making them work, take a look at FLTK (pronounced FullTick) - it revolves around the ridiculous and totally unaccepted idea that the GUI is only an aspect of your program, and that the logic of the program should not be influenced by how the GUI is implemented. How silly. (Yep, I know, SDNWOTN).
Microsoft's Research is pretty good...
These guys spend a lot of effort answering the kind of questions you're asking.
"Don't blame me, I voted for Kodos!"
#include
#include <rants/msvapple.h>
#include <rants/nextstep.h>
#include <slashdot/troll.h>
#include <stdio.h>
int main (int argc, char *argv[])
{
puts("Real programmers use curses");
return 0;
}
There is a new SourceForge project called SVgUI. The intent is to make a windowing system--Web and possibly desktop-based--using Scalable Vector Graphics (SVG). There are no released files yet, but several promising examples of GUI elements have been posted on the SVG-Developers list.
Sorta off-topic, I know, but you might be interested in working with a community from the ground up.
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!
"For example, menus at the top of the screen (ala MacOS) worked well because a user's motor memory it trained to select items. "
I think that works for small screens as in the original Macs. With big modern screens it's a pain in the arse. I also don't think it works well with the paradigm of over-lapping windows - one needs to associate the menu with active titlebar which could be on the smallest window at the bottom of the screen with a much bigger and more imposing "background" window fully visible in between. If all windows were maximised, this Mac menu paradigm might work, except then it's not much different to having the menu on the window under the titlebar. I also don't think that I'm too keen on the way the Mac menubar mixes application menu items and system items. MSFT do get one thing right with menus: they keep all of the items together at one end, anything else is bad (e.g. Netscape under X with it's Help menu in BFE!)
"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.)."
Yes, I agree with you here. MSFT's latest "innovation" of personalised menus is a real pain in the arse. I turned them off immediately - they're so loathesome! Even worse, the user interface for disabling these menus isn't consistent between MSFT apps, and really, if they're going to do it, it should be a display settings property to ensure system-wide consistency.
>suck. Writing more won't help. We need a better
>windowing system, rewritten from scratch for
>desktop use, that supports network operation >without sacrificing speed,
How do you want to improve speed? That's one of the problems. People claim that its slow, but nobody has an idea of how to make it faster without making it less secure (by letting the programs/clients access the hardware directly) or putting everything in the kernel (trading speed for stability). The only other solution I see is to reduce traffic by putting more logic on the server, and this is something already exists, it's called DisplayPostScript... of course people would have to start using it, but this is more realistic than porting appliations to a completely new system.
And even if there was a solution to improve speed, why start something new from scratch instead of using the existing XFree and adding a new communication mechanism?
> supports transparency and vector fonts
> internally
What's the advantage of saying 'this command is internally' over using an extension? There is no big difference in the X11 protocol...
> that includes a widget set/toolkit as part of
> the windowing system.
The only advantage for the user (less IPC traffic) can be achieved with DPS as well. You don't need a new windowing system for this...
> Just look at OS X for proof that your argument
> is entirely irrational.
OS X does not have any X11 legacy applications, and they use a DisplayPostScript variant as well. And OF COURSE they made sure that all existing applications still work on their new system.
bye...
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!
I mean, who the hell would switch to using an operating system just because the new UI kicks ass?
"And like that
With regards to "advantage of internal support for vector fonts", the advantage is that all apps would just say "draw these letters to the screen with these fonts" and the anti-aliasing, etc. would happen internally. Now, only apps written to the XRender extension do that. This means some apps support anti-aliasing, some don't. This makes my desktop ugly as sin. Also there are two parallel font management systems. This is a nightmare.
OS X DOES support legacy X11 applications, since you can run XFree86 in rootless mode under Mac OS X. It's just that they are heinous looking compared to Aqua apps.
As for your comments about DPS and the fact that OS X uses DPS as well, I am aware of that. If you are saying we could use X11 with DPS, I suppose that is true, but that seems like yet another awful hack to me. Why not just make something new and better (DPS based or otherwise) and support X11 as an add-on, or for backwards compatibility with legacy X11 apps?
Here is the classic paper on how X could be improved, for example: http://www.std.org/~msm/common/WhyX.pdf.
Write a window manager and fix some GUI toolkit bugs, that's a good way to understand X well. Hack on GUIs like GNOME and KDE to understand where progress is needed on the UI front, and where changing the window system could help.
(I think almost everyone who's actually hacked on this stuff a lot will tell you that replacing X isn't interesting, but if you want to make a credible claim one way or the other, getting experience is the only way.)
go to the plan9 site -l
l
http://www.cs.bell-labs.com/plan9dist/
(for starters see this paper on the old plan9 window system) - http://www.cs.bell-labs.com/sys/doc/8%bd/8%bd.htm
there is some information there, and the source code for the window system is actually readable because it is much few lines of code and over all simpler than x windows.
also Rob Pike (who worked on plan9) has written several interesting papers on windowing systems.
try reading them by poking around this site - http://citeseer.nj.nec.com/144447.html
http://citeseer.nj.nec.com/pike89concurrent.htm
(sorry the actual articles - linked off of the above links are only ps or pdf, no html)
These papers, the plan9 window system as well as the inferno window system prove that a simple, elegant window system can be created that is both fast and runs over a network.
Granted these use some features that don't exist in the unix world (like plan9's threading model, and the use of per process namespaces) but I believe these can be emulated somewhat using standard networking.
The size, complexity and performance of x windows are all indications that it is not the optimal solution.
PLEASE PLEASE PLEASE PLEASE PLEASE!!!!!
Don't write any more window managers or windowing systems. When there are window managers out there called "Yet another window manager" or "Yet another window manager2" along with all those window managers that aim to be something special. It's just got to stop. What's needed are better applications that you can be productive with. Please focus on the applications that people demand, not on the ones that you think would be cool to write.
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 don't really think that "network transparency" should be part of the architecture of a desktop windowing environment at all,
There is not a real difference between inter-process-communication and a real network. Whatever you do with IPC can be done with a network as well.
so I don't see what this has to do with security.
To access the graphics hardware you need special privileges that a user-level app should not have. So you either need a server that has these priviliges (requiring IPC, the X11 way), give the app the power to access the hardware (bad idea if the user can install applications, but ok and used in some embedded solutions) or put a significant part of the windowing system in the kernel (not really recommended, but the windows way).
With regards to "advantage of internal support for vector fonts", the advantage is that all apps would just say "draw these letters to the screen with these fonts" and the anti-aliasing, etc. would happen internally. Now, only apps written to the XRender extension do that. This means some apps support anti-aliasing, some don't.
So what? Is your argument "the app has to be rewritten to use anti-aliased fonts, so I better rewrite it completely to use a new windowing system"? (and BTW it's usually only a matter of updating the toolkit)
Why not just make something new and better (DPS based or otherwise) and support X11 as an add-on, or for backwards compatibility with legacy X11 apps?
Because no user will notice the difference. Neither will most app developers who use toolkits anyway. It is just a HUGE amount of work, consider all the drivers, video support, 3D and so on, and what will be the result: nothing.