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?"
http://www.atai.org/guitool/
Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
rolling your own windows system?
I think I know what you guys were rolling before writing that bizarre headline.
The Slashdot Effect: A new for
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).
"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...
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?
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.
MFC is plain horrible. It features almost none of the OO concepts at all, and encapsulation is the one feature I miss the most. In a toolkit with a good OO design, to change the font of a label to bold you type label->Font->Style = CFont.STYLE_BOLD; or something similar. Not in MFC: you have to use the Win32 API for an operation on that simple level.
The one toolkit I like the most (in the C++ world) is Borland's VCL classes. Swing is very nice and easy to extend. My experience from Apples Cocoa and other toolkits (Qt, GTK, Motif) is near zero, so I'm not going to comment on things I don't know about.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
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.
I think you said it yourself. X is mature. As much as it would be great to incorporate alpha-blending, there are compatibility issues to be worked through. Personally I feel that the way forward is incorporation, not replacement of X - and the place for this is by working as part of the XFree86 team. You can build an alpha-blended build whenever you want.
As far as networkability, the reason this feature isn't being used all that much is because too many computer users have grown up on that - ah - other operating system and don't know that it can/does work and that they should be using it. The idea that an app and a display are inextricably linked in some way is totally stupid. And X efficiency beats the hell out of some of the alternatives (anyone used VNC on Windows?) and it also is application specific, rather than desktop specific. I'd use X a lot more if I could get an X server on windows (anyone got XFree to work?) but in a UNIX environment this feature really rocks.
With regards to toolkits I do agree - there would be benefits if these could be brought together somewhat and incorporated at a lower level - but I would say that, as a lesstif/motif person.
A HCI idea I've been excited about for a long time is a "general interface spec"... ie. a general way to link an application to any number of interfaces.
Just think :
* You'd be able to twiddle kernel compile options on your interface of choice.
* Applications suddenly become automatically accessible to the disabled.
* Translation could be switched on (just in case the application doesn't support a particular language).
* Interface development could SPEED ahead if a suite of decent programs are already developed.
* Users can make choices about the bleeding-edge interfaces they use without worrying about supported applications.
* Application developers don't have to port their wares to new interfaces.
* From a Unix philosophy standpoint it just seems "right"... abstracting away the interface gives you a smaller more general tool.
I've done lots of seaching for an implimentation of this idea, and probably the closest is in XML (can't remember the name unfortunately) but it's a bit limited both in functionality and available platforms.
For simple programs, VB will do just fine.
For bigger projects sometimes it's better to use MFC. It's is based on the Model-View-Controller pattern, which makes it easier to decompose complex systems. Plus, it has some small convenient features, like object serialization.
From the other hand, MFC is very fat and quite inefficient in some areas. As a result, not many of the successful client-side applications are written using MFC. Even Microsoft programmers usually dont use it for production code, with the notable exception of WordPad. Well, it's not a surprise, of course. They don't even use the normal Visual C++ neither and use the frozen stable "internal" version of the compiler.
i think QTopia is a great idea, if only it ran on desktops