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?"

Comments

OWL, MFC, K, etc.

[Anonymous Coward]

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.

Re:OWL, MFC, K, etc.

[Steveftoth]

One of the reasons that swing is so slow is that it looks the same on ALL operating systems. They achieve this by not accelerating ANY DRAWING CODE.

All the widgets are drawn onto an offscreen buffer then blitted to the main screen. Instead of just simply being drawn to the screen ( like normally) This causes huge problems in X over the network ( especially if the application likes t call repaint a lot ).

the apple jvm accelerates some of swing, but on windows ( where most people see swing ), it is really slow.

I totatly agree that swing is a little too OO sometimes. It's a problem with java being so OO.

Re:OWL, MFC, K, etc.

[DLPierson]

No, MFC is not based on Model-View-Controller, it's
based on Document-View, which is a misguided attempt to simplify MVC by:

1. Restricting the pattern to one level. In MFC,
Documents and Views are top level application objects. There is no standard support for implementing a complex widget with it's own set of them (don't get me wrong, it is *possible* to hack MFC to do this. I've done it, it isn't pretty).

2. Merging the Controller into the Model (Document) and View. This works for simple applications but breaks down for more complex ones where the Controller logic becomes large and complex.

Having lived through Doc-View, I'll take real MVC any day.

Window System Development

[kerneljacabo]

I think the best way to learn how X, for example works would be to use the wrox book on X Window programming and then see how that works and move from there. O'reilly also recently released a book about GUIs under the Mac platform. Also, does anyone know how microsoft does there GUI stuff? Gnome is great and all but it just seems to me that the windoes GUI is much better than gnome/kde. I dont want to start a war so i'll say that I'm a linux user nonetheless, but there must be a better way than X windows.

No really, I'm serious...

[curunir]

Microsoft's Research is pretty good...

These guys spend a lot of effort answering the kind of questions you're asking.

auto GUI??

[Hooya]

i've been thinking about this for a while and i'm not sure if it fits the bill for your question about windowing systems but here it goes anyways...

after working nmap and then with nmapfe, i had the idea where you would write your tool as a native CLI base program but one which provided hooks for a gui over it. nmapfe simply, as far as i can understand, does this by using the GUI to construct the command and then when hit 'enter' running a system call. this approach could be further extended by providing some hooks into the native CLI program whereby a generic GUI tool could probe the tool to see what screens to present to the user.

for example, in the document-view setting, have the view class just generate some form of xml (glade-ish) so that this generic-runtime-gui-builder can query this command line too to build the gui for it. this is all so that each and every tool would have a commandline and a GUI in a very consistant fashion. also, most of the time, the huge GUI programs are just replicating the code for the GUI. this all could be in one generic GUI-runtime-builder.

i know this is all convoluted. i'm still trying to work it out in my head.

i did go as far as creating a 'browser' where you'd run this generic-window which then pulled the interface requested by the app into the main window using glade. just that bit is quite simple. but i'm still working on the rest of it...

SVG GUI

[schepers]

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.

Understand prior art first

[Havoc Pennington]

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.)

This might be a helpful link

[bonch]

http://www.gamedev.net/reference/programming/featu res/gui/

Why Low-level ? On linux we also have framebuffre

[mystran]

People here seem to forget one thing: There is a framebuffer support in Linux kernel. I know it's still experimental (my experience is that it's quite stable ayway) but..

If you want to do windowing system, want to support a lot of hardware with at least on basic level (VESA) and think it's OK doing it on Linux, try compiling the framebuffer support into your kernel (if it's not there already) and building your system on top of it. There some points why this would be a god idea..

• You don't have to care about the low-level stuff
• You are in less risk of having to reboot as you are running on one virtual terminal
• Now (slow) mode switches when you change virtual terminals -> easier to do debugging
• Anybody with framebuffer-support will be able to join the development as it won't be one chipset/graphics card only..

If you make it modular enough (nice wrappers for all framebuffer stuff) it will be easy to port it over to something else or build real hardware drivers later. This way you can first get something running and only then see if you/or somebody can make a better driver for it

Who knows if the project would even speed up framebuffer development if it gets popular enough :)

Re:Implement on top of OpenGL

[cow-orker]

Better yet, have a look at Berlin, not only do they already run on OpenGL, their design is also sane.

Re:Write a Server

[t_hunger]

Isen't this what http://savannah.gnu.org/projects/crust/
is all about?

Actually I think this idea is not-so-good(TM).
The biggest advantage of X is that it runs virtually everywhere. I wouldn't give that up by writting something Hurd-specific.