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.

[coltrane99]

Also Swing (in java) and Win32 from MSFT for what NOT to do, heh.. Actually MFC fits there too ('we determined simple inheritance was too straightforward and our implementation was inefficient so you can run these gawdawful preprocessor macros to interface with the message-passing system...)

Re:OWL, MFC, K, etc.

[DrPascal]

How many minutes (or seconds) did you actually attempt to use MFC before decrying it? Maybe you didn't get past the learning curve necessary to actually use it.

As someone who needs to use MFC on a daily basis for a medium sized project, I think MFC is quite simple and functional. Matter of fact, BeOS (R.I.P.) had an OOP architecture that reminded me a whole lot of MFC.

Are there any OO-based GUIs that you enjoy, or are you a function-based programmer? If you are the latter, than you have absolutely no stance in gauging the effectiveness of such an API / class structure.

Re:OWL, MFC, K, etc.

[Doomdark]

Minor nitpicking; neither Swing nor AWT (on which Swing is based, just AWT primitive stuff not widgets) are on X-Windows (or Win32 GUI) level. They use platforms' windowing systems for (main-level) window management, and gfx primitive for actually doing screen output.

As to whether Swing is not the way to do actual GUI level (above X-windows, upper levels of W32 GUI) is arguable. It's not completely bad, although in some places it is bit overengineered. Its beauty is in customization, and some people like its "by-the-book" design patterns + OO design. It's unfortunate that its not multi-threaded, but apparently they had some valid reasons for avoiding that route (there was a white paper about that; basically multi-threading at that level is bitch to implement reliably). As to the most popular complaint, speed... well, it just depends on what you do and how (from application). Swing has been aggressively optimized, and is not dog slow if you know how to develop and don't do braindead stuff (which, in some cases, you can get by when using faster libs in apps written in C/C++). Part of the time saved when writing apps in Java should be used for more optimizations, if/when app doesn't feel quite as responsive as native ones; it's simple as that.

Re:OWL, MFC, K, etc.

[Baba Abhui]

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.

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.

[coltrane99]

Agreed on Swing and AWT not being low-level(actually I like AWT). I would hope that someone designing a windowing system would want to provide an elegant API which is where I wanted to make the comparison.

I found Swing to have way too many pretty design patterns. In some cases, inheritance hierarchies are used where simple get/sets would have worked as well.

Performance wasn't really a problem, it was just difficult to manage the project. I had to learn everything about the classes I wanted to use and the classes THEY were using to be able to do the customizations I needed (mostly to JTables). This sounds like laziness, but it is not; in other areas under java I have found I can use what I need out of a system without further ado. I found myself reaching the 5-9 items in short-term memory barrier when I needed to understand the class, two or three parents up in the inheritance hierarchy, and then more service classes with their inheritance hierarchies, this just to manage something like changing the color of a table cell or making it editable. I cannot stress enough how important encapsulation is to object oriented systems. IMHO Swing is not properly encapsulated; they chose getting cute with the design patterns over encapsulation.

I would bet the threading lack is due to the cross-platform requirements (I recall some interesting peculiarities with threading under Solaris a while back). They maybe should have bitten the bullet and made some platform-specific extensions. They would have, if java were a platform on its own and not a weapon in the Sun-Microsoft war.. Then again, on its own java would probably be dead by now, since nobody is making money from it directly.

Re:OWL, MFC, K, etc.

[Chainsaw]

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.

Re:OWL, MFC, K, etc.

[Doomdark]

They achieve this by not accelerating ANY DRAWING CODE.

Java 2 (1.2 and up... gotta love these name games) moved some formerly native stuff to "pure Java"; this makes it easier to port to new systems (and gets rid of a few platform-dependant bugs), but usually slowed things down a bit as well. However, Swing/AWT still has to (and does) call native OS calls for certain things like blits and (I believe) line drawing. Those will be accelerated if underlying graphics subsystem has acceleration. In any case, slower speed for widgets is, like you say, mostly due to them being drawn from Java, not from native system (even if primitives for drawing are at OS/GUI level)

All the widgets are drawn onto an offscreen buffer then blitted to the main screen.

Double-buffering is on by default, but can be turned off on component-by-component basis. Designers probably thought most people prefer non-flickering widgets over flickering-but-faster ones.

As to Windows... I was under impression that Windows versions were the most optimized ones, and my experience has been that this appears true (compared to linux or solaris)?

Re:OWL, MFC, K, etc.

[Doomdark]

I agree in Swing being a complex beast... But for some reason I did like JTable; it's one of the better examples of Swing (compared to for example lists... no way to easily create simple lists). JTable is complex, but mostly since table widgets by their nature are more complicated than, say, text fields. And I was pleasantly surprised about how easy it was to embed widgets in table cells, create 'synchronized' filter fields (ie. text fields above table that scroll with table if need be); features that haven't been implemented in
JTable, but could be added due to its extensibility.

But... there is definitely a learning curve in there, and unless you plan to do lots of Swing stuff, just spending days to learn how to do basic stuff with some widgets makes no sense. It's almost as if Swing was designed for "power user"
kinds of programmers. :-)

Re:OWL, MFC, K, etc.

[gibara]

You write,

IMHO Swing is not properly encapsulated; they chose getting cute with the design patterns over encapsulation.

Can you explain what you mean by this? The purpose of design patterns is encapsulation. The proliferation of classes that you seem to have difficulty using is an indication of high levels of encapsulation.

Furthermore you say,

I would bet the threading lack is due to the cross-platform requirements.

I would say that it's a very poor bet. The purpose of single threading portions of an API which is as complex as Swing is to protect developers from incidents of deadlocks which can occur when there is a mismatch between the threading model in the API and the code using that API.

Since Swing is a windowing API, having it dictate the threading pattern of your application would certainly leave "the tail wagging the dog".

Re:OWL, MFC, K, etc.

[coltrane99]

I have found that a class with sensible default values and a lot of methods is simpler/better than a system of say 5 classes that interact with one another. There are so many potential interactions, the system can be orders of magnitude more complex to use/understand in such a case. That is what I found with some of the Swing classes. In that sense, getting too cute with the design patterns breaks encapsulation, because I need to understand how all the parts of the system interact, instead of having one interface to the system.

Thing is, so many of the java libraries strike such a good balance between usability and functionality, and are so well encapsulated (in the sense that one does not have to know about, say, Vector resizing to use a Vector, though it can be helpful to know about it). I found Swing to be deficient in that area. As if the designer was showing off and wanted everyone to savor the sophistication of the design patterns used.

Design patterns aren't bad. They're good, but only when used to a purpose and not for their own sake. The best APIs I have seen seem like the developers asked themselves each day 'fine, but what can I remove?' In other words, they employed the universal principle of good design: economy of means.

Re:OWL, MFC, K, etc.

[Jupiter9]

I've spent a good year and half at an old job using MFC. I've come to the conclusion that it's really a waste of time since you can write a VB app with the same performance in a fraction of the development time. If you're writing a windows app in C++ I'm assuming it for performance reasons, if that's so just stick with win32. If you're going to be using MFC, you might as well be using Visual Basic, you'll get the same performace ratios. (sorry I don't have any statistics proofs on me now). If VB doesn't do all you hope for, just write a .dll in C with you're high performance code, then call it from a VB app.

Re:OWL, MFC, K, etc.

[igrek]

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.

Re:OWL, MFC, K, etc.

[gibara]

I agree with just about everything above. It's just that what you are describing is less encapsulation (in the interests of useability for developers). I think that ultimately the Swing developers had little choice in the amount of encapsulation they had to use because the Swing API needed to be all things to all people. Whereas the AWT was a subset of all windowing toolkits, Swing tries to be a superset, and largely suceeds at the expense of much complexity. The complications of layering it above the AWT don't help either.

Re:OWL, MFC, K, etc.

[RoninM]

Gack. You're breaking data hiding and encapsulation in your example while lamenting its death in MFC? How about we replace label->Font->Style = CFont.STYLE_BOLD; with a function call that can check for constraints, since C++ doesn't allow for checking class invariants. For instance, label->SetFontStyle(CFont::STYLE_BOLD); would be better in C++ OO.

Re:OWL, MFC, K, etc.

[harlows_monkeys]

This book would be a useful read: Inside MFC.

MFC does indeed have some odd characteristics, but most of them are there for good reason, and that book explains them.

Re:OWL, MFC, K, etc.

[Anonymous Coward]

Now, they're not there for good reasons. The odd characterisitcs are due mainly to the fact MFC wraps Win32, and Win32 itself is ugly. I mean, pascal calling conentions? packed structs? explicit CALLLBACK declarations? F**king hungarian notation function and variable names? 16-bit and 32-bit versions of functions that do subtly different things? Documentation that doesn't correspond to reality? "Hidden" function calls that only MS and their selected friends even know about?

In this day and age? MFC REALLY SUCKS!

Re:OWL, MFC, K, etc.

[Chainsaw]

Sorry, I'm used to Borland's VCL where there properties are implemented as getFoo/setFoo and accessed with ->Foo. That, and *way* too much Java lately has made my head into a pickled mushroom when it comes to C and C++.

Re:OWL, MFC, K, etc.

[gh]

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.

Swing is not slow due to lack of accelerating drawing code. In fact, much of the blitting routines tap into native code such as the DirectX libs on the Windows platforms. In the newest JDK that is in beta, some images even can use the graphic card's memory directly for faster blitting to screen.

The problem with Swing comes mostly down to two things:

1. Class Loading
2. Object Creation

Because of the architecture of Swing many classes have to be loaded and at any given time there is a high object creation count. Both of these are EXPENSIVE operations. This leads to the problem of a slow GUI especially when first displaying the GUI.

If there's issues on X Windows, well, then there's issues on X Windows. I don't know enough to comment on it. I imagine even with X Windows specific implementation issues most of the performance problems still comes down to those two points.

For those who want to write better Swing apps, you need to design the app so it will create less objects in "bursts" and if possible preload classes or load classes in the background. Furthermore, cache some of the objects you create. Some of the methods in Swing components allow you to pass in objects and return those objects so as not to have to create new objects on the way back out - i.e. caching. In other words, don't be wasteful. There's handful of articles on the net that go into improving Swing performance. Visit some of the major Java sites (including 'zines) and do some searches.

Lastly, Swing and Java are not too OOP. The problem simply is that the OOP nature brings out some of the inefficiencies such as object creation which you as the developer have to take into account. You will find similar problems with object creation in many, if not most, other OO languages.

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.

Re:OWL, MFC, K, etc.

[Steveftoth]

What I mean when I say that they don't accelerate the drawing code is that like when you are writing a window application, you make some calls to the system to draw say a rectangle. Now if your hardware supports a rectangle drawing function, then windows just remaps your rectangle draw call to the hardware and the hardware draws it. If the hardware doesn't know what a rectangle is, then windows has to go and draw it in the memory of the video card.

Swing doesn't do that because it is very abstract in the way it draws. In a paint function you get a Graphics2D object which is great for making it easy to draw, but hard to accelerate. When you say, drawRect( 0,0,10,10); it can't just translate those cords to the screen like windows does, it has to run a transformation matrix on them see setTransform( AffineTransform) to see what I mean. This has the side effect of making drawing way better for the programmer as you draw everything in your space, and then it magically gets transformed to screen (or printer) space.

Line drawing maybe accelerated if you don't turn on features like anti-aliasing. Or if you are only using AWT widgets.

I think that windows is so fast because they use lots of directX calls. In fact, I think that's why they have so many problems with it. There was a huge problem with ATI boards for awhile. I think that IE also uses directX to speed it up as well.

Swing maintains way too many buffers in RAM when the application is active, just minimize any swing application and watch its memory usage plunge. (in windows)

Did I say 'K'?

[Anonymous Coward]

I meant Qt. Duh...

Windowing system or window manager?

[Indomitus]

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.

Re:Windowing system or window manager?

[Fnkmaster]

Again, I point out that X11 is a piece of turd. There is no reason that we should accept the X Window system as sacrosanct. Why does X insist that a font is a 1 bit bitmap? Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)? Why do the features necessary end up getting strapped on like XRender in a way that leaves us with two parallel font management systems for different types of X Windows apps? While everyone agrees that diversity and choice are good, do we really need so many different widget set and toolkits, all of which are separately themeable, resulting in the most heinous looking clash of aesthetics when Qt, Gtk, and Xaw apps are used simultaneously? Why is transparency and alpha blending on the client end totally impossible in X windows? Why is X Windows so damned chatty that it blows over the internet anyway?

While X windows is mature, and supports a lot of features, and represents (unfortunately) the repository of the vast majority of the current video support for Linux (if all the drivers for video support weren't in X land, perhaps we'd have better X Windows alternatives), that does NOT mean it is the best solution and that people shouldn't be trying to come up with something better.

Re:Windowing system or window manager?

[kaiidth]

As an HCI student I can see the interest in writing your own window manager (I'd like to do this myself... although starting from scratch might not be the best way)

If this is actually what you want to do, make sure that you can't customise an existing one before you start all over again - the chances are you could take a simple system like FVWM ie. something minimal, and just put a few custom toolbars and such on it.

Try looking at the source code to other window managers. You can find several on freshmeat that are absolutely tiny ie. a couple of hundred k. The gzipped source for aewm, for example, is apparently under 50k - incredible :P

If you're after rewriting the windowing system itself and you're doing it for HCI related reasons, I think you may be nuts. There may be a good reason to do this but it doesn't spring to mind. Whereas there are - arguably - huge numbers of usability problems with window managers in general... low consistency, little feedback, that sort of thing.

Re:Windowing system or window manager?

[psavo]

I'm sorry about the way you feel about this.
You seem really convinced that XWindows sucks ass. I personally have never suffered from any lacklust performance of XFree86. au contraire, Xfree86 has always been _fast_ for me. In all ways. I can also add that I use 'the evil option' (read: windows) on daily basis. Their performance is very comparable.

For example snes9x works for me under X at same speed as in Windows. in windows it runs with OpenGL acceleration, in XFree86 it runs without acceleration at all (using 'nv' driver). Speed is roughly the same (not max, however).
I really don't understand your comment about XW's bad performance over network. I use it for running pan over network (10bT), and performance has been very, very nice. I have also ran netscape & opera over ssh link (10bT again) and they performed very well.

Please do give some real examples where Xfree86's performance is inadeguate.

Re:Windowing system or window manager?

[LoRider]

Thank you. I have been saying this ever since I started using X. I hate that the networking bs in X is so prominent. It should be something it can do not such a big part of X.

In my opinion Linux will never be a serious threat on the desktop until X is either completly rewritten or something better comes along.

I think XWindow is good at what it does, I just don't like it. I spend too much time dealing with stuff that I don't want to deal with.

Re:Windowing system or window manager?

[Fnkmaster]

X Windows runs fine over 10bT. I said over the Internet. While the X protocol isn't very bandwidth intensive, it degrades rapidly with latency because it's fairly chatty (see for comparison Windows Terminal Server - I hate to say it, but it does a much better job at this - and I hate Windows, in general).

Most apps that just involve pixel painting (like an emu type thing) will probably run in comparable speed, since the overhead in blitting pixels to the screen is presumably not in and of itself huge. However, see something like Mozilla, for example. Try moving the window around on and off screen. Watch the redraw of the window when it moves back on screen. Awfully slow, I must say. GUI responsiveness in general is not great in X. I mean, it's not terrible - MUCH better than it used to be on older hardware.

In any case, you missed the entire point of my post, since it wasn't all about the performance of X Windows. Performance wise, X windows is adequate for what it does. Not terrible - but like I said, not great. This is subjective.

Frankly, X windows is on par speed-wise with OS X (subjectively - I'm not comparing them on identical hardware), but what matters is that OS X is aesthetically much more pleasing, renders fonts beautifully, supports transparency and anti-aliasing, and the other nice things that DPS gets you. If you can get all that nicely integrated into your windowing system rather than having them as kludgy strap-ons, and at comparable performance, why not go for it?

Re:Windowing system or window manager?

[Anonymous Coward]

: Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)?

Sigh. Morons like you gave us Microsoft Windows, where one has to pay extra for remote access to data and applications.

Re:Windowing system or window manager?

[morbid]

Hey, mod this up!

Re:Windowing system or window manager?

[lkaos]

Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)?

99% of X-Window terminals don't run on desktops. They run on Workstations, that are usually connected to very fast LANS. You may not thing transparent network operation is important at home on a 28.8k modem, but when your using it in a highly distributed production network, the fact that you can make Emacs come up on the display of a Sun from an HP since Emacs isn't installed on the Sun is one of the most useful things in the world.

While everyone agrees that diversity and choice are good, do we really need so many different widget set and toolkits, all of which are separately themeable, resulting in the most heinous looking clash of aesthetics when Qt, Gtk, and Xaw apps are used simultaneously?

So monopoly is good? People like different things. Let the desktop evolve.

Why is transparency and alpha blending on the client end totally impossible in X windows? Why is X Windows so damned chatty that it blows over the internet anyway?

LBX == Low Bandwidth X. It started as the Broadway project. When X was first designed, the chattiness wasn't a problem because there were no low bandwidth networks so this wasn't even a concern.

Why do the features necessary end up getting strapped on like XRender in a way that leaves us with two parallel font management systems for different types of X Windows apps?

The reason Linux has support for so many Window drivers is because of the XFree86 development team. They have done an incredible amount of work so that you can sit here and bitch. You don't have to like it, and you don't have to support it, but for god sakes, so atleast a little bit of respect for it.

Re:Windowing system or window manager?

[mike_sucks]

Why does it bother you so much? Especially given:

- Using XFree locally on Linux doesn't involve the network at all, it uses UNIX sockets[0] instead.
- It's all completely transparent, you don't have to do anything networky to get it running on your local machine.
- It even has a shared memory extension, for doing a few things[0] (which again eascape me).

So, why is it such a hassle for you?

Mike.

[0] - I'm too hung over to remember, but will provide references if you really want.

Re:Windowing system or window manager?

[malxau]

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.

Re:Windowing system or window manager?

[psavo]

Sorry, haven't used WTS, can't say a thing about it's performance.
About 'zilla though. Have you used it over WTS? how did it feel like? redraws?.
When you talk about mozilla redrawing after being 'out of view'.. It just means that Mozilla sucks at using using Expose event. I recently noticed this too, when galeon repainted it's windows serially, not getting all expose-events at a time. maybe i should file a bug or something ;). usually applications keep imagemap of themselves in memory, so it's redrawn very fast.
Mozilla is an complicated applications, with loads more windows than any 'Windows' application. (all thos fucking XMLeze schnutzels).

About OSX.. you get what you pay for. These guys, Apple Engineers, had something over 5-6 years on their hands, to get this thing done. They did it full-time, and paid. Compare this to XFree86.. Their [Apple] hardware is documented and don't have to fight to support _myriads_ of different cards.

Responsiviness: This is actually a Linux (when on linux ;) thing. I recently tried a preemptible kernel patch and was very surprised at snappiness (we're talking about p200 here..) of my desktop. It wasn't bad before , but oh boy was it a nice change ;)

Cheers!

Re:Windowing system or window manager?

[mike_sucks]

X11 isn't a peice of turd. It works well for what it was designed to do, which is to provide a network transparent gui interface to multi-user systems.

It does this well. Really, really well.

Whilst IANAXE[0], it clear that the current version of the protocol is not well sutied for the number of things you're griping about, but you miss the fact that it wasn't
designed for doing that stuff. It's like trying to open a can with a screwdriver; sure it may work, but not well.

X is now up to version 11. It has gone through that many major revisons because it been reworked that many times to not only get it right, but to also support new technology, when colour support was added, for example. So, maybe it's time for someone to start work on X12. Maybe, instead of bitching about it, you should start working on it.

But in the mean-time, get a can opener.

Mike.

[0] - I Am Not An X Expert.

Re:Windowing system or window manager?

[Anonymous Coward]

Morons like you gave us Microsoft Windows, where one has to pay extra for remote access to data and applications

Morons like you gave us X Windows, and all of the graphical elegance (not), snappy responsiveness (not) and wonderful usability (not) that hasn't really been improved in 15 years.

Re:Windowing system or window manager?

[Anonymous Coward]

Xfree86 actually seems to a particularly slow incarnation of an Xserver. Not to knock the Xfree people, it's an amazing work, and I am thankful daily that they put it out there for free, but try it over anything less than local connections. Even short internet hops it becomes extremely slow. Even on a big lan, it's laggy as hell. Add SSH to the mix, and it's barely useable with a home broadband. (granted that's as much SSH's fault as anyone else's). Use a commercial X Server (even for windows) in similar situations and you'll get noticeably better performance.

I don't understand how you could defend X itself though. It's horrible in every way. It was designed like a hundred years ago to display an xterm and a clock over a network. Look at the APIs. It's the most kruftilent thing imaginable. Look at how copy/paste works. look at the fonts. Everything about it is horrible.

Re:Windowing system or window manager?

[carleton]

Of course... last time I checked, snes9x used the MIT Shared Memory Extension, which does allow it to greatly cut down the X overhead. Of course, it's still playable without it... I remember playing Final Fight Guy on cheesy b/w X terminals as the display and my "blazingly fast" pentium 133 as the server. No sound, no joystick, default sizing (no scaling to simulate full screen)... was playable if not perfect. This is, of course, one of X-Windows strengths in my opinion. There will always be some overhead, be it network, cpu, memory, or some other factor, to be backwardly compatible with existing X aps, but newer programs can, by picking and choosing the appropiate extensions, work fairly well in a lot of situations, as opposed to slightly better in one, and not at all in others. And while there are a lot of reasons why the local case predominates, there are some good reasons why the nonlocal case will still be necessary forever.

Re:Windowing system or window manager?

[edbarrett]

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.

Gotta love Cygwin. Some other freaks have even started porting KDE to Windows...

Re:Windowing system or window manager?

[j-pimp]

And X efficiency beats the hell out of some of the alternatives (anyone used VNC on Windows?)
Mabey your still using the AT&T vnc distrobution, but if you check out TightVNC, you might just discover a version of VNC that gives acceptable performance over a 56k modem.
Also, network transparency is fine and dandy for many purposes, but VNC serves a difference purpose. I personally run a copy of GAIM on an Xvnc session and then vnc into that to check my IMs. This way I never loos ims when I connect to different computers. I also run X apps remotly off a machine I program on through ssh. a couple copies of gvim with all the files and an xterm to run the program from. VNC and remote X serve two completly different purposes.

Re:Windowing system or window manager?

[Fnkmaster]

I open emacs windows on my desktop at work all the time. I recognize fully the value of a network enabled windowing protocol to accomplish this. However your assertion that "99% of X-Window terminals don't run on desktops" is outrageous. Though I open emacs windows at work, at least 90-95% of the windows on my desktop are generally local to my own system. I would imagine that is the case for the majority of users. Furthermore, the ENTIRE point here is all about Linux on the desktop. If you don't want Linux on the desktop, fine, you don't have to worry about this. I am NOT telling you to uninstall emacs and X Windows from the server boxes at your company. I am simply saying that I don't believe we should limit ourselves to X Windows as the be-all-and-end-all of Linux on the desktop. Hell, at work I have an X server running on Windows 2000 so I can pop up remote emacs windows. This is a perfectly fine solution for me and for lots of people that lets us use X when we need it without using it exclusively on our desktop.

Monopoly is not good. I am letting the desktop evolve. In fact I am encouraging it. However, consistency and aesthetics and usability are also good for a desktop environment. If you don't want those features, then continue using X Windows. I am hardly trying to stop you from using the tool you like - but don't insist that I have to use it too.

I have certainly heard of LBX. I think that's a great idea. I don't think it addresses the fact that I think that the approach X Windows takes is fundamentally wrong, though.

I am hardly trying to knock the immense efforts of the XFree86 team, and I am trying to do more than just "bitching". I am hoping to rally people who feel the same way I do and engage in intelligent discourse. Perhaps I'll be convinced otherwise, but it hasn't happened yet. Anybody else's effort at making a working windowing system would invariably involve borrowing a lot of ideas, code, or other stuff from the XFree86 team. I use XFree86, and I don't blame the XFree86 team for the problems endemic to the X11 protocol itself, since they didn't design it. I just think that X11 is long in the tooth. It was great at the time it came about, XFree86 made Linux a usable modern operating system. That doesn't mean we should look no further and deny the problems that have cropped up over the years and the shortcomings of the architecture of an old system.

Re:Windowing system or window manager?

[Fnkmaster]

You may be entirely correct about Mozilla and it sucking at handling certain events. I haven't tried using a preemptible kernel patch, but I imagine that might help alot with responsiveness. And I understand why OS X is good. I am just saying that there's no reason to give up on Free Software producing something equally good. But this isn't just about the implementation, this is about the system design and architecture. XFree86 is an implementation of the X Consortium standard/X11 protocol. OS X is actually designed and architected as a new desktop windowing system and operating environment. I think you are comparing apples and oranges there - that's my entire point. And I was never trying to put down the XFree86 team or a lot of the great work they have done, just saying that I think that something better than XFree86+Gtk/Qt+Gnome/KDE is possible.

Re:Windowing system or window manager?

[Fnkmaster]

Agreed. I regret some of the tone of my original comment with regards to network transparency - I think network transparency is very useful and I DO use it quite frequently. However, I don't like the local performance of XFree86. While I should have made it extremely clear in my original post that I realize that XFree86 running locally does not have any network overhead per se, architecturally the X window design is made to support very dumb terminals - part of the inheritance from the era when X was originally designed.

Anyway, I do think network transparency, in a secure fashion, should be PART of the windowing system. What I should have said was I don't think network transparency HAS to be done the way X does it, and there is perhaps a different approach to it where more work is done on the client (X server) side.

Re:Windowing system or window manager?

[Tack]

For those of you who ask "What's wrong with X?" think about those who said "What's wrong with Minix?" back in 1991.

Jason.

Re:Windowing system or window manager?

[Uller-RM]

Indeed - from a company that overcharges for its OS products and has its fingers in Office, games, etc. to back itself up.

Money makes the world go round...

Re:Windowing system or window manager?

[malxau]

I've downloaded this but can't get it to work right - specifically, it can connect and the client thinks everything's dandy but the server doesn't display anything - it does seem to be responding to requests, and allocating memory for graphic ops.

I'm probably doing something really stupid but if anyone has any ideas I'd appreciate them.

Re:Windowing system or window manager?

[CatherineCornelius]

Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)?

99% of X-Window terminals don't run on desktops. They run on Workstations, that are usually connected to very fast LANS.

Like the cheap, fast lan network that connects my laptop to the machine on which this browser is running. Thin client is a very, very old concept, and by enabling me to remotely fire up and operate Mozilla on my desktop computer, it regularly saves me from flogging this portable to death by running a browser locally.

Re:Windowing system or window manager?

[Yes]

99% of X-Window terminals don't run on desktops. They run on Workstations, that are usually connected to very fast LANS.

You are probably not counting a few Linux/*BSD boxes running on fast LANs (homes, offices, etc). And since when desktop != workstation?

So monopoly is good? People like different things. Let the desktop evolve.

Uhhh, the Slashdot pattern. That is, the only option is the polar opposite of everything. Structure example: "I don't like fat people. So, should we kill them?"

A question, is an open standard a monopoly? Evolving the desktop will eventually change the desktop, right? Let the standards evolve.

When X was first designed, the chattiness wasn't a problem because there were no low bandwidth networks so this wasn't even a concern.

You know, I could swear that in some other Slashdot discussions many people have emphasized that "X is sooo small and elegant by design, it was designed to work over modem lines".

They have done an incredible amount of work so that you can sit here and bitch.

What kind of answer is that? Something seems to be wrong. And the excuse for that? They have worked so hard to get there?!

Re:Windowing system or window manager?

[whereiswaldo]

You could try XManager. It's a commercial X Server for Windows. Works really well.

I agree that the separation of the app and the display is a great concept and feature. I disagree with your example, however, because VNC doesn't do UNIX any justice, either. Also, you would have to bring Terminal Services into the game, as it is _much_ faster than VNC on Windows. VNC for Windows is just a screen grabber/streamer whereas Terminal Services hooks into the Windows messages and captures the paint calls, etc...
Anyway, a remote X Server kicks the living hell out of anything else, that is for certain.

Re:Windowing system or window manager?

[Anonymous Coward]

Ah, glad to hear you say this. What the poster is looking for is "News Book : An Introduction to the Network/Extensible Window System (Sun Technical Reference Library)" by James Gosling, David S.H. Rosenthal, Michelle J. Arden.

NeWS was one of the coolest ideas I have ever seen in computer science. Basically it is a window system built on top of PostSrcipt which means your print code is almost the same as your window code, and you could leverage all the knowledge you have of postscript. The client communicated to the server by sending postscript programs, so (for example) you could download a little postscript app that would draw the rubberbanding for you when you resized a window. It is short and simple but since it runs server side performance is great and network trafic nill to you relase the mouse and the PS code sends a short message to the client saying "final dimentions X Y"

If I were doing this today I would add a mechanism to allow OpenGL bindings to a canvas and perhaps some video drawthrough.

It really is a cool idea, sad thing is we could have had this a decade ago if Sun had been smart enough to open source a reference implementation. They did it with NFS and it became a defacto standard, but not with NeWS and X beat its brains out.

Re:Windowing system or window manager?

[Anonymous Coward]

Uh, newsflash: the window system on OS X isn't DPS (it was under NeXTStep but they ripped that out and replaced it with Aqua)

Re:Windowing system or window manager?

[horse]

Yeah, I'm forced to agree. X is there for historical reasons, but it's hard for me to imagine Linux becoming a really fast graphical desktop OS using X. KDE has made Linux more appealing, but X is still a huge downside.

But I've long since realized that Linux is destined to remain a geek OS because that's what most of its developers/fanboys want it to be.

Re:Windowing system or window manager?

[Anonymous Coward]

X is not horrible in every way. It has some great ideas that have not been matched in any other mainstream system.

Network transparency is the greatest feature of X. Sure it might be better implemented today, but it is a feature we should not lose in any new interface implementations.

Re:Windowing system or window manager?

[spitzak]

Versions 0-9 were never used, and X11 came out in 1984. So there really were not very many versions.

You could make the claim that XRender is really the new X12. Of course you could also make that claim for most of the "extensions".

Re:Windowing system or window manager?

[whereiswaldo]

You know, despite my 80 posts and usually somewhat thought out replies, I have yet to get a score > 2. Most are only scored at 1 with no replies. Hrumphh... oh well. :) Maybe Slashdot is waning in users who actually read the replies.

Re:Windowing system or window manager?

[lkaos]

And since when desktop != workstation?

A desktop machine is a PC.

A workstation is a Unix box (usually RISC based).

People do real work on a workstation, and silly desktop stuff on a desktop (such as browsing the internet and making silly powerpoint presentations).

Do not forget, X != XFree86. Just because Linux and BSDs run it, doesn't mean that this is the only implementation of X.

X is much more widely used on other Unices since there are more HP & Sun workstations than Linux workstations out there.

Re:Windowing system or window manager?

[lkaos]

I am hardly trying to knock the immense efforts of the XFree86 team, and I am trying to do more than just "bitching". I am hoping to rally people who feel the same way I do and engage in intelligent discourse. Perhaps I'll be convinced otherwise, but it hasn't happened yet. Anybody else's effort at making a working windowing system would invariably involve borrowing a lot of ideas, code, or other stuff from the XFree86 team. I use XFree86, and I don't blame the XFree86 team for the problems endemic to the X11 protocol itself, since they didn't design it. I just think that X11 is long in the tooth. It was great at the time it came about, XFree86 made Linux a usable modern operating system. That doesn't mean we should look no further and deny the problems that have cropped up over the years and the shortcomings of the architecture of an old system.

People always seem to be able to criticism a system until they actually try to sit down and write one. X has evolved to be capable of so many things. Instead of just complaining about what it doesn't do, try either creating something better or fixing it.

Just complaining is a waste of bandwidth (and you wonder why there is non left for X to use).

A possibly useful page for "window designers"

[Andy Tai]

Well, not exactly a resource on how to design a windowing system, but it may lead you to other pages with information on the details of windowing system implementations (especially note the alternative windowing systems)

http://www.atai.org/guitool/

Re:A possibly useful page for "window designers"

[Anonymous Coward]

Another page about window design:
CIBSE Window Design paper

Re:A possibly useful page for "window designers"

[yadung]

hmmmm...
Score:1 Informative
I think the moderator didn't actually goto the link. How about:
Score:1 Funny
instead?

Re:A possibly useful page for "window designers"

[Anonymous Coward]

Brad Myers homepage

has several papers and links (but many old and not maintained.)

If you really want to start from the bottom up, before they became ubiquitous, windowing systems were a common topic in computer graphics , and some of the older texts cover how to do it from the bare framebuffer up.
Folley and Van Damm has been revised too often so they've probably dropped all of that for more coverage on 3D, etc. but my old copy of Sproull and Newman (sp? I don't have the text on hand to check) has all that (and even some notes on programming for Tektronix type vector displays! ).

Look at old SIGGGRAPH journals.
( 20-30 years ago, this was THE topic! )

And look at things like:
FRESCO & Berlin
Amulet
Sqeak (morphic) and Self UI papers.
OpenDoc
News
GnuStep/NextStep/Cocoa

Ignore the folks that say the world doesn't need another windowing system: the world still needs a better one, but if you don't come up with any better ideas, you might consider helping out on an existing project, rather than starting a new one from scratch. There are a lot of good ideas already out there that lack implementations and users!

X is fairly low-level

[ryants]

those of us who aren't interested in low-level issues, ... (a la X Window)?

If you aren't interested in "low-level" issues, then writing a system à la X probably won't be very interesting to you.

Anyways, the greatest documentation of all to learn form is, was, and always will be source code.

Just wanted to point out...

[2nd Post!]

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.

Re:Just wanted to point out...

[Pav]

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.

Re:Just wanted to point out...

[Anonymous Coward]

Mozilla's UI is in XUL which is XML.

Re:Just wanted to point out...

[Pav]

The XML implimentation I was thinking of is UIML.

Re:Just wanted to point out...

[benb]

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

me too. That's what my OOUI project is about.

Re:Just wanted to point out...

[benb]

Yes, but XUL is very, *very* far from what Pav described. It is completely tied to "WIMP" systems.

rolling

[Anonymous Pancake]

rolling your own windows system?

I think I know what you guys were rolling before writing that bizarre headline.

Talk to Gnome/KDE developers...

[FortKnox]

People that have successfully built Windowing System are the people to ask. Odds are, there aren't more than 1% of /. readers that have successfully made an entire windowing system.

Also, check the code of successful, open source windowing systems...

Re:Talk to Gnome/KDE developers...

[Anonymous Coward]

Dude, you tha man. Really, this is a very good post.

Re:Talk to Gnome/KDE developers...

[theKiyote]

Taking a look of the 22926 people who took place in the last poll alone, that would mean, at a one out of a hundred, that over 229 people have designed their own Windowing System and can help.

--theKiyote

Re:Talk to Gnome/KDE developers...

[Anonymous Coward]

Gnome and KDE are not windowing systems. The X window system and Berlin are.

Re:Talk to Gnome/KDE developers...

[Anonymous Coward]

You didn't factor in Microsoft trying to modify the results of that poll.
2000 actual votes is probably more accurate.

Re:Wheel.

[jungd]

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.

I'm right there.

[Ortado]

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)

Re:I'm right there.

[jdavidb]

When I first saw it, I thought it was an
acronym. In Perl, "DWIM" eq "Do What I Mean." I
thought it was "Do What I Need" or something.

Spectacular project you've got there!

Re:I'm right there.

[Entropy_ah]

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!

Re:I'm right there.

[Anonymous Coward]

No Screeshotty = No Downloady!

Here's a conference paper:

[Anonymous Coward]

CIBSE Window Design paper

There is little...

[ADRA]

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.

Re:There is little...

[HammeredHead]

Just for the record, Apple didn't design the GUI. People at Xerox innovated/designed it. Apple was the first to implement it.

how about..

[Anonymous Coward]

Creating Windowing Systems For Dummies ?

Re:Wheel.

[jungd]

Yes, I did preview my post - I'm just tired. Sorry.

There's always the source code.

[NDSalerno]

May not be the best form of documentation, but the source code to X, window managers, and KDE/GNOME will have the answers. Got to imagine all these projects have had many different ideas implemented in each one.

DONT

[tjansen]

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.

Re:DONT

[Fnkmaster]

Sorry, this is just not true. X11 sucks. There are lots of strapped on extensions that make it 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, that supports transparency and vector fonts internally, that includes a widget set/toolkit as part of the windowing system.

Just because nobody has done it yet (the only ones you point to who really tried are the Berlin folks, and they've just never had their act together, but have a lot of good concepts).

Just look at OS X for proof that your argument is entirely irrational.

Re:DONT

[JordoCrouse]

We all use X11 because its there. It has always been there. When Adam and Eve got kicked out of the garden, I'm pretty sure that he took a few X11 floppies with him. Much in the Microsoft tradition, its the most used because its the only one there.

That doesn't mean though, that it is the end all be all for windowing systems. It is at its very best in a distributed environment with many different types of machines. It is at its very worst when it is on an embedded system.

Its all a matter of having the right tool for the job.

Re:DONT

[tjansen]

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

Re:DONT

[ADRA]

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.

Re:DONT

[Fnkmaster]

I'm sorry, I don't really understand your argument. I don't really think that "network transparency" should be part of the architecture of a desktop windowing environment at all, so I don't see what this has to do with security. When you are allowing remote apps to run on other desktops, yes, a security mechanism needs to be in place. X is slower in terms of putting pixels onto screen than any other modern desktop windowing system (i.e. Windows, Mac OS X, etc.). As in I can see Mozilla redrawing when I drag a window, even with a blazing processor, and blazing graphics card.

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. :) I am not opposed to this kind of solution, and I'm not saying X doesn't have its uses, I'm just saying we CAN do better.

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?

Re:DONT

[Fnkmaster]

I am not forcing the user of the GUI to be anything. I am saying that a desktop windowing system is different from a multipurpose-network thin client windowing system, which is really what X is (err... thin X server... oh well, never mind). X assumes a dumb terminal that renders pixels as its told to. This is fine if that's what you want. What I want is a windowing system designed rationally for the 99% usage case, which is running apps locally on my desktop. Adding an X server to that is not too hard (see OroborOSX and rootless X11 support on OS X for an example).

Re:DONT

[psavo]

You don't seem to understand that while X11 IS network transparent, it DOES NOT use network at all when server&client are on the same machine. When C&S are at same machine, X11 uses unix sockets or something similar (probably something equal to sharing memory between processes).
And one cannot separate out that C&S approach, any serious windowing system to date uses it, even windows has it's message queues.
Network transparency is a NON-COST solution, given as bonus for a clean Client / Server separation.

Cheers!

Re:DONT

[Fnkmaster]

You are correct, it uses Unix domain sockets, I believe. Nevertheless, the architecture of X server, X client, and where the rendering gets done and who draws the pixels on the screen assume that the client (i.e. the X Windows app) does the rendering, and the X Server is a dumb terminal that renders them to the screen as a bunch of pixels.

This basic architecture is not ideal, in my opinion, for a desktop windowing system. I am not saying that there is network overhead when running on the same system. I am saying that X11 sucks because it was architected as a dumb-video-terminal windowing system rather than as a proper desktop windowing system.

I believe that network transparency should be achieved at a higher level, which means assuming more than a dumb video terminal. Larger functional blocks of information, less chattiness, that leaves more of the rendering to the "client" (what is called an X server in the insanity that is the X11 protocol), so that, for example, fonts could be rendered in the more sensible location.

So I don't believe that X11 achieves the _correct_ or _desireable_ form of network transparency for a _desktop windowing system_, though it's a nice backup capability to have, and I don't think X11 will or should go away anytime soon.

Re:DONT

[Ikari Gendo]

X is slower in terms of putting pixels onto screen than any other modern desktop windowing system (i.e. Windows, Mac OS X, etc.). As in I can see Mozilla redrawing when I drag a window, even with a blazing processor, and blazing graphics card.

I can't see that at all (running XFree4, windowmaker-0.80, FreeBSD, Matrox G400, Athlon 1GHz, hardly blazing). I suggest you revisit your XFree settings, as I have a hunch you're not getting 2d acceleration.

...THERE's a weakness of X. Getting it to support hardware fully is a pain. However, this can be remedied by smarter install tools. Get cracking! :)

Re:DONT

[leastsquares]

I agree with you entirely.

The QNX people got it right. They have their own windowing system, no bloat or crap. The nasty X11 stuff is then supported through an optional add-on layer so you can still run all of those important legacy apps.

One day there will be a horrible X11 compatiability layer for directFB and I will be happy.

Re:DONT

[erikdalen]

Well take a look at Berlin then.

/Erik

Re:DONT

[t_hunger]

Sorry, but Berlin _DOES_ have significant advantages over X (and most other windowing systems).

Berlin is resolution independent, device independent (has build in printer support, WYSIWYG, ...), is fully configurable without each app looking diffrently, has a sophisticated event handling, ... .

Yes, Berlin is being developed slowly. But then it is a huge project and we have very few developers.

Regards,
Tobias

Re:DONT

[t_hunger]

That's not a good idea IMHO. With 'X12' you are doing something that is not 100% compatible with X11 anyway: You can't run X12 applications on X11 servers. So you will need to upgrade every system in your network, just as you'd have to do with a completly new system or you will not be able to use the new features. So what do you gain by having X12 instead of a powerful new system? A lot of cruft and inconsistencies from pluging together lots of modules and extensions into a new protocol.

Berlin tries to do a new, consistent, powerful system. A X11 emulation can be added later. Check out
http://www.berlin-consortium.org/ :-)

Regards,
Tobias

Re:DONT

[psavo]

What do you call a proper desktop windowing system?
I believe OSX you referenced at your other comment ha exactly same components as X11 has. I really believe that X11 is as intelligent as it gets. It is extensible, and so it evolves over time..
Saying that, I don't quite understand why font rendering couldn't have been switched to xrender right away, without separate support. As far as I know, application just requests 'Draw this string Z at X, Y and begone'.
If you wan't to manipulate large cunk of your window's memory 'directly' there are ways, Xshm being one..

Could you please tell me in plain words, what do you really think would make X11 better? (less chattines is known..)

Re:DONT

[tjansen]

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.

Re:DONT

[horster]

right on - I don't know why everyone says as a knee jerk reaction that choice is better (kde/gnome;linux/bsd) but when it comes to x windows nobody wants to even think about an alternative.

it shouldn't be impossible hard to create a window system that can also run as a window inside of x or vice versa. that's one solution - mapping the x apis could be another.

i disagree with your comment that networking doesn't belong in a window system though. having used x for a while, i find it an absolute prerequisite, especially over a lan.

Re:DONT

[t_hunger]

Network transparency is great. It will be even greater in the future with all those handheld gadgets companies keep promissing!

Having said that, security in this context propably refers to clients not being able to mess with the server. So clients can rarely crash the server. Networktransparency enforces a very strict separation of client and server and so results in a 'secure' system.

Oh, yes, we can do better:-) Check out http://www.berlin-consortium.org/ and help us get it ready for primetime. We still have a lot of ground to cover, but I guess Berlin is exactly what you are looking for.

Regards,
Tobias

Re:DONT

[malxau]

You've said this in a few posts now, but I'm having trouble understanding why.

I don't think a local connection creates many performance issues. It has no significant drawbacks, with the exception that features need to be supported by both servers and clients, making changes less rapid than on Windows, OSX etc.

For the record, I'd love it if Windows or OSX networked as well as X. But they don't. We live in a networked world, and the focus now should be how to drive those networks. I don't get how saying that because Apple/M$ don't support the feature we shouldn't either. That makes no sense.

An X12/X11R7 protocol, as suggested earlier, makes sense to me (so long as I can live with X11R6 for the next few years and not junk too much hardware.) Server-side alpha blending and 32bit font support can be incorporated as extensions. With it a standard feature, apps can use it instead of building that support into toolkits everywhere. What are the drawbacks with this approach?

Re:DONT

[yomegaman]

All of those things are in Qt, and probably in Gtk as well or in the works. There's no need to dump X and all of the useful applications written for it just to get these improvements.

Re:DONT

[Anonymous Coward]

Freesco... the name grates me.

It sounds like sco unix, or some ungodly 1980s name like A-Tech or IMAX. May as well call yourself BTTF and be done with it.

Re:DONT

[Anonymous Coward]

Say I want to write a windowing system that runs on top of OpenGL or DirectX ... I just can't patch X to do this, can I?

Don't assume that the only reason to write a windowing system would be to replace X11. There are many instances where you would want to roll your own -- for an embedded system or game, for instance.

Re:DONT

[tjansen]

There already is one. It only lacks many extensions, stuff like 3D and support for at least 100 different graphics chipsets... have fun with it.

Re:DONT

[Anonymous Coward]

Qt is not resolution independent, and neither is Gtk. Berlin doesn't replace X, it can use many hardware accelerated canvases.

Re:DONT

[tjansen]

I believe that network transparency should be achieved at a higher level, which means assuming more than a dumb video terminal. Larger functional blocks of information, less chattiness, that leaves more of the rendering to the "client"

DisplayPostScript can do this for you, you just have to add DPS support to the toolkit of your choice.

bye...

Re:DONT

[Anonymous Coward]

For the record, I'd love it if Windows or OSX networked as well as X. But they don't. We live in a networked world, and the focus now should be how to drive those networks. I don't get how saying that because Apple/M$ don't support the feature we shouldn't either. That makes no sense.

Remote Desktop/ Remote Assistance/Terminal Server.

All in XP, in one flavor or another. And it works fine.

Re:DONT

[malxau]

These things are all tacked on as afterthoughts - and imho, don't work as well as my trusty DISPLAY environment variable. Do they work? Sure. Work as well as X? That's very subjective.

Also don't you think it's mildly ironic that M$ has finally implemented this stuff, but its inherent support in X is being questioned?

Re:DONT

[Anonymous Coward]

check out Gosling's NeWS. Gosling. Awesome.

Re:DONT

[horster]

so awesome that sun dropped it quite a while back - is there any good info about NeWS though? if you have some links I'd like to check it out.

Re:DONT

[RevAaron]

OS X does *not* use DPS. NeXTSTEP, OpenStep, Rhapsody, and Mac OS X Server 1.x used DPS, but Mac OS X uses Quartz, which is more-or-less Display PDF.

Re:DONT

[Anonymous Coward]

Dude, I don't think you understand, this one goes to 12.

Re:DONT

[Fnkmaster]

Ah I see what you mean about IPC. I agree fully that some sort of interprocess communication is needed. I am not suggesting that it should be. I think that there are more efficient ways to get true network transparency than what X provides, but they involve assuming that toolkits, fonts, etc. are common across the involved machines. I don't think this is such a bad thing to do. Call me strange, I know my point of view differs from many others here.

If your last point is true, then you have nothing to worry about. I'm just proposing an alternative to X windows. Why is it so damned great that we have Gtk, Xt, and so much toolkit diversity but when I propose an alternative to X Windows everyone shits their pants?

Frankly, the result would be a lot more than nothing. Go use Mac OS X. Tell me that you prefer using X Windows on Linux. If that is the case, then I encourage you to ignore me and my ranting, and I will tell you that you are blind and are not helping bring Linux to the desktop.

Re:DONT

[Pinky]

Actually, you wouldn't be forcing much of anything.,. by making a new standard called X12 or whatever and by making all the extensions mandatory, you're not forcing users to install a fat system at all. The exist of X12 doesn't mean the death of X11. Since X11 features would be a subset of X12.

So, I would vote for keeping the X11 system and proposing an X12 system to make X11 somewhat less primitive....

Re:DONT

[tjansen]

If your last point is true, then you have nothing to worry about. I'm just proposing an alternative to X windows. Why is it so damned great that we have Gtk, Xt, and so much toolkit diversity but when I propose an alternative to X Windows everyone shits their pants?

The reason for the remaining toolkit war between Gtk and Qt - almost everything else is almost dead in the free software world - are the different philosophies, especially C++ vs. C. You won't solve this by having a new window system. If you present group one an interface that is as weird as GTK/Glib they wont use it. If you give pure C programmers a C++ interface they won't use it.
However, you are free to use only software created with one toolkit and don't use any other - and you will still have more software than with a new windowing system. If you want to enforce it, patch X11 so it supports only QT apps. Tadaa, only one style in your system, finally the same style across all apps.

Frankly, the result would be a lot more than
nothing. Go use Mac OS X. Tell me that you
prefer using X Windows on Linux.

Actually I do prefer KDE over MacOS X, but even if I didnt: still nobody convinced me that there is a technical barrier that prevents anybody who invests a few hundred manyears to implement a MacOS X look-alike GUI on X11. X11 allows it. Even if it there would be something missing, add the feature to XFree. You will waste A LOT of time writing a windowing system that would be much better invested in improving KDE (or Gnome). If somebody really want to do this I cant stop him, but I can predict that unless the new system has all the old features, including 3D and driver suppport, plus improvements that are so significant that people bother to change no one will use it. You need much more than architectural improvements, you need either features that are impossible with X11 or a performance that is so much higher that people can actually see the difference.

Re:DONT

[Anonymous Coward]

These things are all tacked on as afterthoughts - and imho, don't work as well as my trusty DISPLAY environment variable. Do they work? Sure. Work as well as X? That's very subjective.

Also don't you think it's mildly ironic that M$ has finally implemented this stuff, but its inherent support in X is being questioned?

Why is it ironic? Its inherent support in X isn't being questioned; the fact that it's the cornerstone of X is the problem. It's *overhead*.

Most users *today* will never use X networked; they want a desktop computer. So tune the system for the desktop. Optimize it for that. Provide hooks for the network stuff to go in later. But don't design for networked use as the primary function.

Re:DONT

[malxau]

It's overhead, but how much overhead?

My linux box has 64Mb of RAM. It uses about 15Mb of that on boot and launches XDM (so that 15Mb includes my X Server.)

NT4's overhead is roughly similar.

I think that the drawbacks of the integrated networking model is that it makes it much more difficult to incorporate new features quickly - I haven't had any issues with X performance, at least not when compared to Qt, GTK and other related toolkits.

Is *nix really about the network stuff to go in later?

Re:DONT

[Anonymous Coward]

It's overhead, but how much overhead?

My linux box has 64Mb of RAM. It uses about 15Mb of that on boot and launches XDM (so that 15Mb includes my X Server.)

NT4's overhead is roughly similar.

I think that the drawbacks of the integrated networking model is that it makes it much more difficult to incorporate new features quickly - I haven't had any issues with X performance, at least not when compared to Qt, GTK and other related toolkits.

Is *nix really about the network stuff to go in later?


The overhead is in the cost of context switching, and passing data. Preparing the data for the socket layer. Passing the data through the socket layer. Receiving it at the other side. Decoding the data from the socket layer. Using the data. Sending results back over the socket layer.

Also, the way bitmaps are pushed through the socket layer. The way screen updates are managed. All of those things are handled in X in such a way that they're designed to optimize network traffic. They're not designed to optimize throughput in the windowing subsystem, or directly to the graphics card. It's another layer in the system -- and that costs in terms of performance.

Memory isn't the issue here; that's not the kind of overhead we're talking about. Bandwidth (CPU & bus) and CPU cycles are what counts here. Throughput to the video card.

QT and GTK run on top of X, so you're not going to see performance differences. Compare them to Windows or MacOS (or heck, RISCOS or Workbench or BeOS) and you'll see the difference -- particularly on busy screens or frequent display updates.

Is *nix about putting the networking stuff in later?

No.

But hey; that's why Linux and freeBSD are great server OSs, but lousy desktop ones.

Re:DONT

[t_hunger]

They don't. They are trying to provide for vector graphics, maybe even a SVG renderer, but they stay in the pixel-world: They don't use real-world meassurements but pixels. You can't ask them to draw a window 50mm wide. You can't have 3D objects outside of windows (the background *is* a window too in X). You can't print anything that you can display on the screen, only those things the QT/GTK guys decided to write a printerdriver for. You can't switch a theme and both QT and GTK will change their looks and feels (actually there are meta themes nowadays that combine a QT and GTK theme into one package, but even with those the 'feel' stays diffrent). How about using a mouse and a graphics tablet at the same time (in X you have to switch between these devices)? How about connecting a dataglove to your computer and using that for input? Berlin's Eventsystem can deal with such a device. How about using your shutterglasses to get a 3D impression of your desktop? Berlin can do most of this allready.

Do I understand you right: You are suggesting to remove X11 in favour for GTK/QT? Yes, X11 will stay around as some kind of compatibility layer, but it won't be used much anyway or you'd give up all these nice features you get from QT/GTK. But in fact you are proclaiming that GTK or QT is 'X12' (or 'Y' or whatever you are going to call it) and X11 is just some kind of compatibility layer for legacy applications. Actually there are things like QT-embedded, GTK on DirectFB trying to realice just that: GTK/QT without X.

Now how does this differ from having Berlin plus a thin X11-compatibility layer?

The only difference I can see is that GTK/Qt have applications while berlin has not. But all those applications should run on X-on-Berlin as well, plus you get all the niffty features of Berlin. So why do you insist on using GTK/QT on X?

There is another issue I consider to be important: How can we exspect users from coming over from the MS-plattform if we are just imitating it? We need something better, better even then the MacOS X-GUI. Berlin has that potential for that IMHO. But then I am biased;-)

Re:DONT

[Anonymous Coward]

OSX doesn't use DPS at all. NeXTStep did. OS X doesn't, it uses Aqua.

Re:DONT

[Anonymous Coward]

> What I want is a windowing system designed rationally for the 99% usage case, which is running apps locally on my desktop.

Fine by me. Except I find that when you have a computer or 2 (or 3 or 4 , or more) around the house, and have to share between several people, X quickly becomes very convenient indeed. You can have your small laptop anywhere in the house, and make your "main computer" as clunky as you like and banish it to the basement :-)

It's also useful to have when you've installed one bunch of programmes/hardware/whatever on one box, and another set on another box. You can still use all of it!

If you need to use the amplifier connected to a certain computer, or grab the modem or whatever. (And I use xmms and kppp, so sue me), well, you can just use them with no trouble whatsoever.

For me the network transparency is the best thing since sliced bread, and I couldn't live without it. :-)

Re:DONT

[Anonymous Coward]

"News Book : An Introduction to the Network/Extensible Window System (Sun Technical Reference Library)" by James Gosling, David S.H. Rosenthal, Michelle J. Arden
Springer Verlag; ISBN: 0387969152

Re:DONT

[Anonymous Coward]

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.

X12->X11 Gateway?

Re:DONT

[Anonymous Coward]

It sounds like sco unix

I agree. It sounds like a free implementation of SCO. FreeSCO, like FreeDOS, etc.

No references, just a little advice.

[Nindalf]

Mainly, don't be boring. There is no shortage of windowing systems that do what everyone else is doing, with a few mostly useless features and some buzzword compliance added to distinguish themselves from the pack. The easiest thing in the world to do is make a second-rate clone of an existing system, and that won't do anyone any good.

If you want to see interesting and innovative interfaces, look at games. They are free to experiment and be unfamiliar, people even enjoy the exotic feeling of escape from the humdrum world of standard interfaces. Of course, there is more bad than good, but it's always that way where people are trying new things.

Okay, one reference: Ask Tog. Lots of good thoughts on interface design. One of his gripes stands out for me in particular: the importance of the corners of the screen in a mouse-based interface. You can always hit the corners without looking, and with a little practice, you can also hit things near the corners by "bouncing" off the corner. Radial menus out of the corners are probably the easiest thing in the world to hit reliably and quickly. Don't neglect the corners!

Of course, this goes right out if you switch to a pen. In a lot of ways, current interfaces are much better suited to pens than to mice.

MacOS "top menu"

[Anonymous Brave Guy]

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.

Actually, it works well because it's easier and faster for the user to move a mouse to a large area (and one limited by the top of the screen) accurately, than it is to aim for a menu homed at the top of a window. "Muscle memory" has nothing to do with it, largely because it doesn't exist, although I agree that familiarity also makes it easier to use than an ever-changing menu system.

Re:MacOS "top menu"

[jungd]

The 'motor memory' component comes into play when moving your hand down to select the item, not the action of moving up to the menu.
Essentially you brain can associate movement of a particular distance with a function. Hence the function becomes automatic after a time.
('motor memory' functions are probably in the hippocampus, not the motor cortex. But no-one knowns for sure of course).

Re:MacOS "top menu"

[Anonymous Brave Guy]

The 'motor memory' component comes into play when moving your hand down to select the item, not the action of moving up to the menu.

Sorry, my bad. Yes, in that case, a top menu is definitely an advantage.

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.

Re:Window System Development

[spectecjr]

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.

Here's all the info you'll ever need.

Well, kind of. The Addison Wesley book on Win32 Programming isn't a bad resource either.

Win32 is a lot like Motif conceptually (or so I'm told; I've never programmed Motif). It's also massively extensible. And, unfortunately, once you get away from the base of the system, full of contradictions and different design philosophies. (eg. commctl32, or the new XP theming support). On the whole though, it's a very good system. The reason?

WndProcs.

Once you make everything a message, you can do amazing things. Asynchronous programming, for example, is much easier if everything's a message. You also don't get vtable bloat the way you would if it was all implemented as a C++ class hierarchy. Write some templated wrappers (or use ATL or WTL), and you're set to go with the best of both worlds.

Simon

More of an art than science.

[Circuit Breaker]

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

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.

Re:No really, I'm serious...

[wdr1]

If you're going to steal, steal from the best:

http://developer.apple.com/ue/

Say you want about Macs, but hard to deny they have a great user interface.

-Bill

Re:No really, I'm serious...

[Anonymous Coward]

Sure I can deny.
I don't like their interface.
There you go.

PS.
I really dont. It is better than , say your old typical no-interface-at-all X desktop but not even close to Windows.

Russinovich book

[shrikel]

While many argue that Microsoft is a (pardon my french) big bum-bum head, they do have a pretty snazzy windows system (with some exceptions, of course.) You've got to admit -- all security flaws and other massive problems aside, they've been doing windows There's a book that I have found IMMENSELY informative, helpful, and, in its own way, entertaining. It's called Inside Windows 2000, by David Solomon and Mark Russinovich. Mark runs sysinternals.com, a very cool site full of windows hacks and utilities that he's written. I run a Win2k network, and the sysinternals utilities have saved my life and a whole lot of work, many times. Check it out!

Re:Wheel.

[shpoffo]

BS: "Sir, the post can't be moderated any lower."

PS: "Damn the regulations! Flames on! Engage!"

For design principles

[ADRA]

I found this after a few minutes on google. Seems to have a good understanding of the Objectives that UI's produce.

http://www.sylvantech.com/~talin/projects/ui_des ig n.html

Re:for skins?

[shpoffo]

holi! stale-ass moderators can't take a joke....

-shpoffo

A Google Link?

[Anonymous Coward]

I think this is the first ever Ask Slashdot where the author actually bothered to use a search engine before asking.

Swing

[SashaM]

I have had the misfortune to have to implement a complete UI toolkit based on the limited capabilities of the JDK 1.1 AWT.

As far as the high level design is concerned, I can recommend using a model similar to Swing, simplifying where possible. Swing, although implemented horribly, has a fairly clean design and it supports practically anything you'd want from a UI toolkit. Here are some: Model View Controller pattern makes it very modular and therefore easily customizeable, pluggable look and feel which can change at runtime, the event model is clean although sometimes requires you to write a lot of classes just to support a single event.

Read the swing tutorial or the documentation

Re:Wheel.

[RedWizzard]

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.

Actually screen top (or bottom, or side) menus work well because effectively they are infinitely high (or wide) so they're easy to aim at. I think the reason Windows doesn't use them is because they didn't want to give Apple more ammunition for their look and feel lawsuit. It's also possible that Apple have a patent on screen top menus - I know Commodore-Amiga owned a patent on auto-hiding screen top menus.

What I want...

[NonSequor]

I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp. I want one language that can serve every purpose, and Lisp is the only language that I know of that is capable of that. Unix systems have all sorts of languages with very different syntaxes used for different purposes. It takes a lot of time to learn everything. Using a higher level language like Lisp would also make the system more secure by preventing buffer overflows and such.

I would also like to be able to summon some sort of Lisp console from any application. The Script-Fu console in the Gimp is pretty much what I'm thinking about. After learning the language of the system, a person could learn to automate, customize, and extend the functionality of every application.

Re:What I want...

[Spinality]

Note of course that, with the exception of your desire for LISP, you've also described Smalltalk.

Re:What I want...

[Steve Hamlin]

Well, the kernel's in C, but just run 'linux init=/bin/emacs' (although, is emacs proper written in lisp itself?)

I'm sure every common application has been written in elisp at this point - web server, browser, email app, editor, IDE - although you might have to be the one to write CC in lisp - maybe RMS can help you :) wait, lisp is self-hosting within EMACS, isn't it? - no compiler needed. And then you two could start HURD over in lisp. Another 15 years and we won't need the linux kernel anymore!

Your perfect OS is already on your hard drive! Just a config file away :)

Re:What I want...

[RevAaron]

It's called LispOS. Unfortunately, an open source LispOS is quite vaporware. In the meantime, have a look at Squeak Smalltalk , which supports all the features of a modern-day Lisp and then some, with the exception of real macros. Squeak itself is basically an operating system that is hosted by a number of other OSes, including Mac OS 9/X, Windows, Linux, and a bazillion others. In addition to that, Squeak runs bare on a x86.

Re:What I want...

[frank_adrian314159]

I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp.

Check out Symbolics. They sell the old Lisp Machine software
ported to a microcoded emulator that runs on DEC/Compaq/nobody Alpha hardware. You can also still find old Lisp Machines for sale occasionally. They're still pretty sweet.

Re:What I want...

[Anonymous Coward]

smalltalk, homes. google squeak smalltalk

Re:What I want...

[NonSequor]

I would love to have one of those just to fool around on.

I would really like to see what a Lisp machine designed today could do. TI used to have a processor designed for Lisp, but the only thing I can find on it is a fifteen year old press release about it.

Of course, it's incredibly unlikely that any company would design and market a new Lisp machine. Lisp has fallen out of favor and everyone cowers in fear of anything that breaks compatibility with what they already have. I wish everyone could agree to throw out all of our current hardware and software and make a fresh start. But only silly, impractical people like me would like that.

Re:What I want...

[Tachys]

I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp. I want one language that can serve every purpose, and Lisp is the only language that I know of that is capable of that. Unix systems have all sorts of languages with very different syntaxes used for different purposes. It takes a lot of time to learn everything. Using a higher level language like Lisp would also make the system more secure by preventing buffer overflows and such.

This is what Emacs will become in a couple of versions.

Re:What I want...

[GypC]

I'm with you, man. Unix and Windows have proven that C is not suitable for a networked system that needs security.

Squeak is pretty cool, but I like Lisp dialects better than Smalltalk.

The problem is the lack of a Lisp dialect compiler suitable for OS-level work as illustrated here.

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

Re:auto GUI??

[Anonymous Coward]

Look for Kaptain I think?

Re:auto GUI??

[Anonymous Coward]

We do something like this for the GUI for our product - we write one screen definition, which can be run as either a console app, or as a GUI window - the latter being a bit friendlier, and allowing the use of the mouse to switch between fields and operate menus.

The GUI mode, I believe, uses Tcl/Tk scripting to produce the window and contents.

Re:auto GUI??

[Hooya]

yeah something like that except that the 'grammer' script would be output by some switch eg. --kaptain (in the most rudementry form because that means that the gui has to run the program once with the switch on to generate the gui and then once to run the program.) another approach could be to link directly to a function call or some such to a standard predefined function getGuiGrammer() or some such within the executable binary. that would allow for the more important agenda that i had in mind. to illustrate, if you had something like that for aspell, wouldn't it be nice to be able to 'pipe' all your spell checking from your app to aspell but in GUI? the important agenda and my initial thought was that Unix has had it's power in pipes. but as we strive towards a GUI oriented OS, we're starting to lose that power unless we somehow transport that CLI pipe concept to GUI. this 'probe-and-generate-gui-by-generic-gui-meta-app' would allow us to be able to link to other apps GUI at runtime. thus giving the effects of GUI-piping. linux gui is nice. but we've completely lost the power in linux -- pipes. just been brainstorming on how one would metaporize pipes in GUI.

Re:Wheel.

[BitwizeGHC]

I find the window-top menus easier myself, because they let me map application functions with a particular visual workspace on the screen, and I thus have to remember less state (what application am I inside of now?). Maybe my brain is a bit more "object oriented" than most. :)

It's a ten line program

[CatherineCornelius]

#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;
}

Re:It's a ten line program

[Anonymous Coward]

> return 0;

Real programmers use

exit(EXIT_SUCCESS);

;-)

Believe it or not, C++

[CrazyJim0]

If you know classes and the virtual command, then simply make the windows as classes, and the small pieces in them as subclasses.

I made an awesome AWT in about 2 months for my MMORPG using C++. Too bad the market got swamped.

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.

So what you're saying is...

[Anonymous Coward]

That you're a moron who doesn't understand the fundamentals of OS programming.

There's a little problem of device drivers that you seem to have overlooked.

Your puny Lisp is no match for Assembler.

Re:So what you're saying is...

[NonSequor]

Actually, I've spent the last few days reading all of Intel's documents on the x86 architecture. The x86 architecture is far from ideal for the purpose of implementing a Lisp environment (or anything else for that matter), but I see no reason why device drivers couldn't be implemented in Lisp using special functions (which would have to be written in Assembler) for things such as I/O, setting interrupt handlers, etc.

Also, Lisp is much faster than you think it is. Take a look at this.

I'm sure that device drivers written in Assembler would be faster than device drivers written in Lisp. I don't really care about that. Performance is important, but it isn't the only thing. What I consider to be most important is being able to make the computer do interesting and/or useful things easily.

Re:So what you're saying is...

[Anonymous Coward]

Oh please, when someone starts spouting off about the glories of "assembler" that's an instant moron alert...

Re:So what you're saying is...

[Anonymous Coward]

Let this be a lesson to all those Assembler advocates. If you aren't writing in hex, you are severely handicapping yourself!

Cruising for Pre-Teens in my P.T. Cruiser

[Anonymous Coward]

Thanks Slashdot! I love my Slashdot PT Cruiser. It lets me pick up all the hot preteens in my neighborhood.

Re:Wheel.

[klund]

For more on some of the things wrong with Microsoft's WIMP GUI, see A Quiz Designed to Give You Fitts. Specifically, take the following quiz if you're interested in Windowing System Design:

1. Microsoft Toolbars offer the user the option of displaying a label below each tool. Name at least one reason why labeled tools can be accessed faster. (Assume, for this, that the user knows the tool and does not need the label just simply to identify the tool.)
   
   
2. You have a palette of tools in a graphics application that consists of a matrix of 16x16-pixel icons laid out as a 2x8 array that lies along the left-hand edge of the screen. Without moving the array from the left-hand side of the screen or changing the size of the icons, what steps can you take to decrease the time necessary to access the average tool?
   
   
3. A right-handed user is known to be within 10 pixels of the exact center of a large, 1600 X 1200 screen. You will place a single-pixel target on the screen that the user must point to exactly. List the five pixel locations on the screen that the user can access fastest. For extra credit, list them in order from fastest to slowest access.
   
   
4. Microsoft offers a Taskbar which can be oriented along the top, side or bottom of the screen, enabling users to get to hidden windows and applications. This Taskbar may either be hidden or constantly displayed. Describe at least two reasons why the method of triggering an auto-hidden Microsoft Taskbar is grossly inefficient.
   
   
5. Explain why a Macintosh pull-down menu can be accessed at least five times faster than a typical Windows pull-down menu. For extra credit, suggest at least two reasons why Microsoft made such an apparently stupid decision.
   
   
6. What is the bottleneck in hierarchical menus and what technique used on the Macintosh, but not on Windows, makes that bottleneck less of a problem? Can you think of other techniques that could be applied?
   
   
7. Name at least one advantage circular popup menus have over standard, linear popup menus.
   
   
8. What can you do to linear popup menus to better balance access time for all items?
   
   
9. The industrial designers let loose on the iMac not only screwed up the mouse by making it round, they screwed up the keyboard by cutting the command keys in half so the total depth of the keyboard was reduced by half a key. Why was this incredibly stupid?
   
   
10. What do the primary solutions to all these questions have in common?

Re:And before some shithead whinges on about Togsp

[swillden]

X Windowing System cannot even access a 5-pixel border all around the workspace.

False. Buttons on my KDE task bar go all the way to the edge of the screen, as do the menu items on my desktop menu bar.

I Ask Why...

[Anonymous Coward]

...this didn't make front-page news on Slashdot?

----
I Am The Why Troll

What level are you trying to address

[ReelOddeeo]

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.

Re:What level are you trying to address

[GigsVT]

What I don't understand is why the graphics drivers should be in X. That seems to be really bad style for a single layer to provide all that functionality.

All other hardware abstraction is done in the kernel, why isn't video card abstraction done there?

Re:What level are you trying to address

[Anonymous Coward]

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.

And layers (a la photoshop) - with layer transparency. This would help tremendously with anti-aliasing.

Re:What level are you trying to address

[mini me]

Layers would be a great feature when programming interfaces.

Want to move an object? Move the layer. You don't even have to worry about redrawing the image below since the windowing system will handle that. Link all your application's layers when you want to move a window. Alpha-blending would be a snap.

Photoshop is an excellent example of how the interface should work. If you've ever mocked up an interface in Photoshop you'd have seen how the layers are a great feature. Sure you can create all those routines in your program, but I think it would be better to let the WM handle it.

If layers, masks, etc, could be easily addressed programatically we would start to see some nice looking programs.
Of course, what's better looking than the CLI?

Already Done...

[DAldredge]

search for EMACS...

Re:Wheel.

[Malc]

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

You're absolutely right!

[tswinzig]

I mean, who the hell would switch to using an operating system just because the new UI kicks ass?

Smalltalk is a useful source for ideas

[Spinality]

In particular, as I recall, Smalltalk-80: The Interactive Programming Environment, Adele Goldberg has many details of how the original S80 GUI class hierarchy was architected. Smalltalk has historically been a good laboratory for designing and experimenting with user interfaces, and would be an idea source if nothing else. I'm not up to speed on current Smalltalk literature, though I'd expect it is now more from a usage standpoint than about the implementation of the environment (which the earlier books covered in detail). I thought the four Addison-Wesley volumes (including this book) were really quite good.

Re:Russinovich book --- Windows is snazzy?

[LaTeXninja]

Please define "snazzy"! The person who asked the original question appears to be interested in writing a window manager, but windows is probably one of the most primitive window managers out there. It's nearly featureless; the notepad.exe of window managers!

What can you do in it? Minimize, maximize, resize, move, close, tile, cascade, and that's about it.

Most window managers provide this basic functionality and add vertical/horizontal maximization, snapping instead of freefrom window movement, and more intelligent window placement among other things. Nothing drives me batty like windows appearing in apparantly random locations with random dimensions.

What I'm trying to say here is, MS Windows is a bare-bones window manager!

AtheOS

[leastsquares]

Although I'm always suspicious of the practise of tying a windowing system into the OS, the windowing system of AtheOS is nicely OO'd and clean.

(Unfortunately it is very young code, and therefore has an API liable to change and a few missing features).

There is no insurmountable reason why something like this couldn't be constructed for any other OS. I would drop this bloated X rubbish in a second.

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

Re:Understand prior art first

[Antti R]

And if you think X is too hairy and scary to dive into or think network transparent windowing must be possible to do in a simpler way, also check out Plan 9's /dev/draw and rio stuff.

Re:Understand prior art first

[horster]

yeah, I linked to that too - very nice and clean setup.

Plan9

[horster]

go to the plan9 site -
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.html

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.html
(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.

No more, please!!!

[suso]

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.

Re:No more, please!!!

[Anonymous Coward]

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.

Re:No more, please!!!

[Anonymous Coward]

what we need is yet another *linux variant
knockoff of BSD Unix(tm)

Re:No more, please!!!

[Kidbro]

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

Re:No more, please!!!

[Tablizer]

What is perhaps needed is analysis and cataloging of possible and potential features, organization schemes, etc. And then perhaps some sort of popularity ranking of features (or even reader comments) for different domains, target audiences, etc.

I attempted to do something like that with scripting languages at:

http://geocities.com/tablizer/langopts.htm

I won't claim that it is thorough nor perfect, but it gives one an idea of the kind of format I envision for GUI studies.

cpsc student

[Anonymous Coward]

sound like this is a computer science student that just got scared looking at her/his schedule!! OOH crap I have operating system design and theory this semester, ooh what shall I do, ok lets ask slashdot!!!

this isn't a troll, I thought of doing the same thing this christmas break, but I took the mans way, I actually put some elbow greese into searching for the information!!

Coward

Re:Wheel.

[sholden]

I find the window-top menus easier myself, because they let me map application functions with a particular visual workspace on the screen, and I thus have to remember less state (what application am I inside of now?). Maybe my brain is a bit more "object oriented" than most. :)

Or maybe your brain just likes using up more time every time you need to access a menu.

Or maybe you use the short-cut keys in which case it doesn't matter where the damn menu is put since you never mouse to it...

Try reading 'The NeWS Book' by James Gosling

[rthille]

It came out of Sun in the late 80's, early 90's and like NeXTStep used postscript and the ability to load drawing code into the windowserver to accelerate drawing operations over the network. It's got background on Andrew, SunWindows and X11

Robert

Re:Try reading 'The NeWS Book' by James Gosling

[oozer]

Display Postscript.. Even Next (or the Next engineers that got absorbed into Apple anyway) realised that was a bad idea. Its a great idea in theory I'll grant you - you get resolution independence, intelligent remote widget representation in a remote terminal environment and relatively easy programming for the app developer.

The problem with it is it's extremely resource intensive (think about it: Postscript is a fully-fledged programming language and you want to put an interpreter for it in your terminal?) plus Adobe patented it and charge a licence fee for its use.

The display engine in Mac OS X is based on the PDF standard instead. You still get the resoltion independence but because PDF is a page description language (declarative) rather than a (functional) programming language you get a less complex and less resource intensive display engine. You lose the intelligent remote widgets but then percentage-wise how many users access GUIs remotely even with a lower-grade solution such as X or (god forbid) VNC compared to those that sit infront of the machine they run all their software on? Very few. Oh, and although Adobe invented PDF, it doesn't charge a licence fee for its use.

Re:Try reading 'The NeWS Book' by James Gosling

[Anonymous Coward]

Just about everything you said is wrong:

NeWS isn't DisplayPostscript.

DisplayPost script was plenty fast. I had it on a 25Mhz 68040 and it was plenty fast, and beautyful too. On todays outrageously hardware accelerated graphics chips and fast processors it would be just fine.

Adobe didn't patent PostScript. They own a copyright on the spec and a tradmark on the term PostScript(see page 9 section 1.5 of PostScript language reference 3r ed.) But they pretty much let you use it if you don't polute the language or claim the name"

Display Postscript did have a liscensing fee associated with it (the rumored reason Apple dumped it) but as I said before NeWS != DPS so the liscensing doesn't apply.

I have no problem putting a postscript interpreter in the display server. The language isnt that bad and it is a simple stack based setup. The core interpreter should be small like a forth implementation. Plus my *small* home machine has 512Mb of memory these days since it is so cheap (hell even my laptop has half a gig of memory).

PDF maybe nice, but you lose the ability to move apropriate code into the server, and there goes a lot of power and flexability. Not just that but even on a local machine you can elminate a pair of context switches since code to react to an event might already be in the server, thus reducing load and latency even on local apps. Perhaps nobody uses remote GUI apps cause they suck. I now when I was designing integrated circuits using magic I had to do it over a 10bT network one day since the machines with magic were occupide. Man was that painful!

Re:Try reading 'The NeWS Book' by James Gosling

[spitzak]

As the anonymous responder said, NeWS is NOT Display PostScript!. It was Sun's own PostScript interpreter and did the complete job of X. It did not contain any Adobe code.

Display PostScript was an attempt by Adobe to add PostScript to X. It could only draw into a window, you needed to use Xlib to create the window. This was purchased by NeXT and the X part was thrown away and replaced with some simple PostScript calls to create windows to make the NeXT windowing system.

NeWS had an enourmousely simpler and faster method of compressing PostScript into a data stream that pretty much involved reserving some bytes to mean the most common postscript keywords and to introduce arrays of floating point numbers that were imbedded in the data stream. DPS required a compiler that produced machine-specific data structures that also appeared to be highly specific to their PostScript interpreter, I feel this was an infinitely worse design.

NeWS also used PostScript to advantage to control non-drawing things. For instance the shape of a window was controlled by a PostScript path and the position (and rotation!) by a PostScript transformation. Original DPS had none of this, requiring ugly Xlib stuff, and NeXTStep only had simple "create a rectangular window and return it's id" calls that did not integrate so well.

NeWS was enormously better than DPS and anything else out there and it was a shame Sun blew it by trying to charge for it.

I do agree that downloading widgets was NeWS's main defect. It made communication between app and server very difficult and the only programs that really worked were entirely written in PostScript to avoid this communication. But other than this mistake, the unified single interface to create windows, draw *advanced* graphics, and manage events with easy string-based interface was far ahead of anything that has been invented since.

Not what he's looking for

[srichman]

Firstly, I wouldn't call this the "Russinovich book." David Solomon is the first author for a reason: he was the sole author of the previous (4.0) edition on which Inside Windows 2000 is very largely based. (Helen Custer wrote the first edition for 3.1.)

More importantly, this book is just the Windows version of the mostly Unix-centric tomes the poster mentioned he didn't want. A look at the table of contents reveals that this book has pretty much nothing to do with developing a windowing system or a window manager.

Network transparency

[coyote-san]

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.

Re:Network transparency

[Thatman311]

Use you pick up a copy of WindowsXP Professional. It has this thing called "Remote Desktop" which will let you access your system remotely just like you are at the console. It is pretty fast and works well.

Re:Network transparency

[Anonymous Coward]

What if I just want to run a single application off of my XP computer? I don't need, or want, the entire desktop, just the app!

RDP is just a bad hack to make Windows multi-user.

MVC and Views

[KidSock]

The foundation of all windowing systems is the Model View Controller mechanism. There are surprisingly few good examples of source code or descriptions of how to actually implement such frameworks but the general idea is well know and easy to understand and appreciate.

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

Re:MVC and Views

[Anonymous Coward]

It's a very well written subject on the MVC pattern and the self similarity that form the foundation of an understanding of design patterns. In order to understand how to develop a windowing user interface package, I would suggest that you gather specs of what the user is looking for in a UI based on the desktop metaphor. The answer -- research. I think that ANSI has a committee for the CUA specs for the desktop metaphor.

Cassoway

[Baldrson]

Check out the Cassoway constraint engine's port to the Squeak system if you are serious about doing new UI/layout libraries: http://penguin.cc.gt.atl.ga.us:8080/schwa/63 For those too lazy to install Squeak and run the above constraint change set for Cassoway under it, here's a little Java 1.1 applet (better run it on Nav4.7x or above) demonstrating how the Cassoway engine maintains dynamic UI consistency within constraints (better read the instructions): http://www.cs.washington.edu/research/constraints/ cda/run.html

Yet another post

[srichman]

there are window managers out there called "Yet another window manager" or "Yet another window manager2" ... It's just got to stop.

Should people quit writing parser generators and Internet portals, too? :)

Network centrality of X

[tsprad]

In order to display graphics for multiple processes on the same display at the same time you pretty much have to have some sort of client/server architecture. Since 4.2BSD the easiest way to do the communication between clients and the server has been using sockets? Perhaps that's why X does it that way?

What alternative do you propose?

Idea for new system

[discipledaniel]

My idea has been to try to use the technologies we already have to make a new system. Let's build a system around:

Pthreads, DRI, libart and Pango

Plus Mesa and SDL for games... and VNC for network transparency... This would make a great framework to build on. I know GTK is getting a Vector API based on libart, so that's an easy port. And it shouldn't be too hard to port Qt over. What are we waiting for?

Daniel

Low Level

[Anonymous Coward]

I know this question is offtopic, but does any one know of some good web sites that have information on hardware access? I'm not talking on CPU-how but on "vendor-how". What is the I/O port for the speaker? For an USB keyboard? What is the protocol to follow when speaking to a floppy drive? How do I access the registers for an NVidia or 3dfx or ATI video card, etc. On a sound blaster?

Anyone knows? Thanks!

This might be a helpful link

[bonch]

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

Don't Forget about the Hall Of Shame

[tk422]

Dont forget about the Interface Hall of Shame. Its great reading on what *NOT* to do with a GUI and even fun for browsing while trying to avoid doing work.

The bible

[Screaming Lunatic]

It's usually referenced for graphics. Any paper on computer graphics has this book in it's bibliography. It has a couple chapters on UI and windowing that will give you the basics and point you in the right direction.

Specifically, check out chapter 9 on Dialogue Design and chapter 10 on User Interface Software.

Computer Graphics: Principles and Practice Foley, van Dam, Feiner, Hughes (c) 1996 ISBN 0-201-84840-6

Re:The bible

[Anonymous Coward]

Here I am, opening my bible and trying to find those chapters, and I see a lot of things about wailing and gnashing of teeth, the smiting of the unbelievers, the root of all evil, and I almost think of microsoft. Then I read the rest of your post and see my mistake; it's made me see the bible in a whole new light though.

Be Sensible

[gibara]

Speaking as one who has architected and implemented a remote windowing system RecipeXperience which is currently just entering beta, I feel that I have some useful advice to contribute.

Primarily I would forewarn you that such API's are inherently DIFFICULT and as they mature become BIG and careful maintanence is required.

Secondly bear in mind that a great many people have already gone through the effort (pain!) of creating stable and functional user interfaces. So you must have a very good idea of why you want to create another windowing API. In our case there are many unique aspects of the API which cannot be replicated within other toolkits.

Specifically be aware that most software exists solely to interact with other software. One good example is a webserver. Lets take the example of writing one. It is by no means a trivial task to write a good webserver. Yet the protocols it must adhere to are not particularly overwhelming and the task generally reduces to two points of low level interaction, the socket and the file system. Both of which are relatively straightforward entities to program with since their possible behaviour at any given time is constrained and typically well documented. Ultimately the 'user' of the server is a browser (or other comparable piece of software) which can interact with the server only via the fairly restrictive means of a socket connection and an well established protocol.

Now try to imagine a windowing system 'in full flow' and in its entirety (not easy unless you have worked a long time on developing one). Specifically try to think of all the actions a user could possibly try to undertake. Within a user's desktop there are literally tens of thousands of possible actions a user can undertake at any instant.

Just try counting up how many buttons you have on screen (meny buttons, form buttons, taskbar buttons), how many ways you can launch each them (clicking, shortcut keys), how many ways you can navigate to each them (keyboard navigation, programmatic selection, mouse), how many ways each button can respond (activated, toggled, selected, dropdown menu, popup menu). And that's just buttons! Think of all the different types of components which developers and users will expect in a modern windowing system.

Then look at applications as 'users' of your API, think of all the things an application could choose to do while the user (or another application) is interfering. And now we are thinking about the broader picture try to imagine not just one user action but tens of thousands and all the possible orders they could occur in, and all the possible mistakes they could contain. And think of all the possible application errors which might occur and which need to be dealt with safely (memory management is a good one to start thinking about).

Now think about implementing all of that correctly, think about how you might test it, think about debugging it, possibly across different platforms and finally think about documenting it all.

Still fancy writing a windowing API? As I said, you need a good reason to write one.

Re:Be Sensible

[Anonymous Coward]

"Still fancy writing a windowing API?"

Don't make it look so scary.
All yours thousands of buttons etc .. can be reasonably handled once one has simple Window framework as well as communication framework ( messages, callbacks etc ..)
These are hard things and you have to be very careful here.
But once you have that, if properly implemented, everything else is just a simple extension (OO is perfect for this) so your thousands of buttons can be reduced to one class Button (build on top of Window) and possibly couple of simple inherited classes like checkable button etc ...

Re:Wheel.

[Anonymous Coward]

How long have you actually used a system for that works the other way? I used to think the same thing, but, when you get used to it, the other (Mac) way is a lot faster for me. No matter what, thinking is way the hell faster than mousing, so even if it takes you 10x longer to reassociate the top of the screen to the new topmost app, that loss is swamped by the speedup of the actual mouse operation.

Re:And before some shithead whinges on about Togsp

[swillden]

Nope. I'm looking at the screen right now. It's a laptop LCD monitor with exactly 1400x1050, and the image goes all the way to the edge of the display. On a discrete-pixel display like this one, there would be no way to obscure a band of unusable pixels. Further, the X server reports that it's running at a resolution of 1400x1050.

Cut the FUD. I'll grant that there probably was an X server once, somewhere that had to deal with that issue and wasn't able to make an exception for that particular display, but XFree86 4.1 doesn't have that limitation, and it seems very unlikely that any implementation of XFree86 ever did. It never ran on Wyse X terminals.

Re:Wheel.

[philovivero]

Sure. I'll bite. I went and read that article. Ten things you can do to make the UI faster.

I'll give you a number 11:

Allow keyboard shortcuts.

In every one of those questions, we learn how it's so fast to use a mouse to traverse menus to get to the item we want.

Whatever.

Alt-F - w - f

What does that do? It creates a new folder in Microsoft's Explorer. Takes me about 1/2 second on a bad day. 1/4 second on a good one. The best mouser I know takes at least a second to do it. (Let's ignore for a moment that Microsoft, the fscking bastards, changed the shortcut in Win2k)

How about Alt-I - i in Photoshop? Change image size. Almost instantaneous for me. Compare/contrast GIMP where I have to define some meaningless "Alt-Ctrl-Shift-O" or someething to bring up the resize dialogue. No hierarchical keyboard shortcuts at all.

Windows again, any window: Alt-space - s - right right right? I've just made my window bigger by about 100 pixels on the right edge. How long for any Mac or Windows fanatic to do that with their mouse?

Exactly.

I'm amazed that so many GUI experts, years in the field with abilities to make a mouse go 10x faster don't go the extra step to define a nice, standard way to let the user go 50x faster with the keyboard.

Plan 9 Rio indeed...

[Christopher B. Brown]

This provides an "it's all Unix devices" approach that is quite entirely different from X.

It's a fascinating approach, that I expect people don't believe could possible work acceptably well.

It's very unfortunate that building a windowing system is so much work that there hasn't been more experimentation with approaches like that with Plan 9...

Re:Plan 9 Rio indeed...

[horster]

well you couldn't do it exactly the same on unix b/c there aren't per process namespaces like plan9, so you can't multplex a fileserver like you can with plan9. you could perhaps write a filesystem, but that's different, b/c it's not in userspace like p9 allows you to do.

also plan9 allows you to mount these remote fileservers (w. multiplexed data) which is central to rio - that would take quite a bit of work to bring into the unix world.

still though, why is a file or a device so different from a socket? a similiar solution to rio could be devised on unix with something sockets in user land, don't see why not.

Re:Wheel.

[Anonymous Coward]

i agree wholeheartedly. the 1st thing i do when setting up a new window manager or the like is define some of the more important keyboard shortcuts, which include bringing up a terminal
and a web browser window....

the best thing would be if the window system had a universal standard way to customize keyboard behavior...

then again, KB shortcuts apply to frequently used applications. but unfamiliar UI is a bigger problem with those apps we use infrequently....

like _exteneded_ IL for .net?

[horster]

I wonder how the ximian guys will feel about that.

Re:like _exteneded_ IL for .net?

[Numen]

The Ximian guys are quite interested in it is the reply.

I think you might understand what Extended IL is... it's a series of extensions to make function languages easier to impliment under .NET

directfb

[xshader]

use directfb.

Re:Wheel.

[gazbo]

RE Your message body:
I was given this as a quiz in my HCI course at university. I haveto say that once the answers were known it really gave us a lot to think about - it rarely occurs to you to think about the time it takes a user to think about and then actually perform a motion to a locaion on the screen (and to disagree with another poster, the time taken to think about a move is not insignificant, i can take th best part of a second)

RE Your sig:
My word processor was written by a team of developers at Microsoft. You find me a word processor written by Knuth that is as functional and I will be your bitch forever.

PS. I am pissed as a fart. Anything offensive or disagreeable should be ignored.

Re:Wheel.

[Anonymous Coward]

"As fast as possible" isn't always the most important thing. Sometimes "it doesn't look like ass" is important too, not to mention "it doesn't confuse the heck out of me."

Dutch railways blocking non-IE users

[Pussy Is Money]

This warrants the brief attention of /.; if not in a story, then in this fashion.

The Dutch railway company is blocking non-IE users. Pass it on and submit a complaint. Thanks.

Re:Dutch railways blocking non-IE users

[mister-e-dog]

The oddest part is what Netcraft.com reports:

The site www.ns.nl is running Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01 on Linux.
And wget -S gives:

2 Date: Fri, 11 Jan 2002 06:13:11 GMT
3 Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01
4 Last-Modified: Wed, 09 Jan 2002 09:24:48 GMT

I can't read Dutch but the site seems to make some mention of being 'incompabiliteit van diverse browsers'.

Any Nederlands speakers care to translate this site http://www.ns.nl/overig/pop_oversite.html ?

Re:Dutch railways blocking non-IE users

[broonzy]

Deze site werkt optimaal met Internet Explorer versie 4.0 en hoger. Indien u gebruik maakt van een lagere versie van Internet Explorer en/of Netscape Navigator, kunt u hieronder de nieuwste versie van Internet Explorer downloaden.

T:
This site works optimally with IE4 and higher. If you use an erlier version of IE and/or Netscape, you can download a newer version of IE below.

NS heeft wegens incompabiliteit van diverse browsers in de eerste release van de vernieuwde site gekozen voor toegang middels Internet Explorer. In de eerstvolgende release, welke voor januari 2002 gepland staat, wordt bezoek aan de site middels meerdere browsers mogelijk gemaakt.

T:
Because of incompatibility of various browsers, NS (Dutch railways) has chosen to make the new site accessible only to users with Internet Explorer. In the next release, planned for January 2002, the site will be accessible from other browsers as well.

Ok, and it goes on and on about specific functionality, that you need Adobe Acrobat 4 to read PDF's, and special tricks needed to make deep linking working.

But what has this got to do with rolling your own windowing system?

Re:Dutch railways blocking non-IE users

[Anonymous Coward]

Okay, going from the top, here we go:

This site works best with Internet Explorer version 4.0 and up. If you are using an earlier version of Internet Explorer and/or Netscape Navigator, U can download the latest version of Internet Explorer here.

[link to internet explorer]

NS (ed: dutch railway) has chosen, due to incompatibility problems of a diversity of browsers in the first release of the renewed site, for access using Internet Explorer. In the next release, which is planned for Januari 2002, a visit to the site should be possible using different browsers.

Also, this site is best viewed with a screen resolution of at least 800 by 600 pixels.

On several pllaces in this site, reference is made to PDF-files. To read these, your computer needs to have Adobe Acrobat 4.0 or higher. If you do not possess this, we offer you the possibility to download this by way of the Adobe Icon, which leads to the Adobe-site.

Third party sites which use a deep-link to the NS-site or for instance the Planner Plus can in most cases keep on using hte same adres. If for instance a location, departure- or arrivalstation is being passed on, then you should take into account that this link has to be adapted. Should this fail, then the NS (through the Webmaster) will always be glad to be of assistance.

Questions or suggestions that have any bearing on the functionality of this site you can ask or report to Webmaster by pushing the 'Webmaster' button. Other questions will not be answered by the Webmaster.

[button to webmaster (ed: with things like this, I imagine someone sitting in a chair, completely asleep over his keyboard, until someone presses the button, which unleashes some huge victorian steam engine device that slowly gears up until two arms are extended, one which moves to a cassette recorder to press play, and the other to repeatedly push the sleeping tormented webmaster, while in the background the cassette tape bleats "get back on the job!" in a hellish manner"]

For questions, suggestions of complaints about the NS or NS-products, you can write to:

NS klantenservice
Antwoordnummer 4470
3500 VE Utrecht

[copyright nonsense skipped]

---

hope that helps

How do YOU propose for apps to talk to the screen

[Christopher B. Brown]

X provides a protocol for applications to communicate with the screen.

Contrary to popular belief, it doesn't force huge gobs of "evil network transparency" in; that pretty much comes for free.

After all, there MUST be an IPC system involved, unless we were to transform it all into some sort of "cooperative multitasking" system with only one process (think: MS Windows, where if any bit of any application breaks, you have to reboot).

As soon as you have IPC, extending that to allow network transparency is pretty easy, and focusing on how "expensive" this is is just silly.

When you start with such huge misconceptions, that undermines the value of the whole discussion.

Namespaces

[Christopher B. Brown]

Just wait for Linux 2.5... Alex Viro had a namespace patch nearly a year ago, and other proposals have come along too...

Re:Namespaces

[horster]

yes I know about that patch - its been around for a while now.
a solution that used that for linux would be linux specific. a nice feature of x is that it runs on pretty much every unix that I know of.

have you tried the namespace patch? I haven't yet, but am thinking about giving 2.5 a run b/c it was included.

Re:Namespaces

[Christopher B. Brown]

No, I downloaded a copy about six months ago; probably ought to toss it onto my latest "TODO" list.

It's not something that will be of vast interest for applications just yet; if it enters "ordinary kernels" in 2.5.something, that's certainly a good step towards it.

The Really Cool thing to use this sort of thing for would be to have user-space filesystem drivers, and mount things under (let's say) $HOME/mnt/

• A DBM file could become a directory hierarchy, accessible only to the process that mounted it.
  
  
• You might do a "loopback encryption" that would only be accessible to processes that are children of the login shell that was used to mount (oh, say) SSH passwords or the GPG keys.
  
  
• Right now, cfs (encrypted) mounts are publicly available, albeit not being terribly visible. The namespace equivalent would not allow public access at all...
  

I should toy with it soon...

Or my favourite primitive... BLIT

[Anonymous Coward]

I can't believe it took until 1995 for microsoft to work out how to blit a bitmap in a format *you* specify to the display (WinG, then CreateDIBSection in Win32) That was the first thing I put in both my DOS based GUI systems (first one (1990) supported 16 and 4 colour cards (EGA, CGA) so it was on 8 pixel boundaries for performance. Second one (1995) was pixel based using region routines, using VESA. It's a pity VESA doesn't seem to be supported much any more now that windows has conquered everything). I wasn't using Windows because until Win95 it was not suitable for decent programs (DOS extenders allowed you to access more than 64K of RAM at once. A plague on 16 bit O/Ss still hanging around in the 1990s!). I still prefer CreateDIBsection to DirectX (it works on all cards, with print preview, font printing can be useful).

my god what a troll

[-ryan]

Do we need another windowing system? How about just getting an existing one right?

Re:Wheel.

[uebernewby]

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

NTBAMAB (not to be a microsoft apologist but ... ) There was a reason for this. Usability studies reveal that, at most, humans can remember 7 or 8 menu options, no more. So, in their infinite wisdom, MSFT decided to write an app that looks out for which 7 or 8 options a given user actually, well, uses. The other ones get hidden.

It's not a bad idea, the execution is just a bit sucky.

Have a Look at Macromedia Flash

[Anonymous Coward]

Flash is a self-contained vector graphics environment, and interactive movies can serve as controls like buttons and scrollbars. The next version of Flash will have better support for building interfaces. The advantage of Flash is its portability, and soon the ability to link the entire player into an application to serve as the GUI. Also, it enables the creation of completely non-traditional user interface elements.

YACL by M. A. Sridhar

[yeOldeSkeptic]

You can try browsing ``Building Portable C++ Applications with YACL'' by M. A. Sridhar from Addison-Wesley. It is a book on a GUI manager that can be ported across different platforms; linux and OS/2 being two of them. The source code is also available at ftp://ftp.aw.com/cseng/authors/sridhar/yacl Hope this is of help.

While you're at it....

[jasonv118]

While you're at it, would you mind telling me how to build a rocket ship? And are there any good books on developing theories about black holes to rival Stephen Hawking's?

Thanks a lot.

Why reimplement X?

[drix]

It seems to me that a lot of other people have had similar ideas, and the results have all been built on top of X. GTK/Gnome and KDE being two popular examples. I admit that my understanding of what X Windows does is fairly limited, but as far as I know it just a very fast, well written program that draws shapes on your screen and coordinates mouse and keyboard input, all rolled up into a tight, clean client-server interface. I'm not even all that sure if X Windows knows about actual windows; I believe (and this is insightful) that that's handled by the "window manager." So I think when you talk about rewriting the interface, don't you really want to think more about building your own windowing environment on top of X?

Dinosaur Book

[SpringRevolt]

I like the dinosaur book and bought it years ago. My copy is battered and dog-eared now. I have not seen it mentioned in Slashdot before however.

Incidently, in the new (6th) edition, they never mention the Hurd and the chapter on Mach has been deleted and replaced by Linux. Sign of the times, heh. Andy eat your heart out :).

Look at existing alternatives

[Anonymous Coward]

While X is pretty much the only windowing system that gets any attention, there are alternatives out there. And good ones at that. Just look at Berlin. (http://www.berlin-consortium.org/) It is based on Fresco and the design is absolutely beautiful. Also they have decided not to bloat the windowing system with all the low level graphical hardware issues and leave it up to GGI (and KGI in terms).
<P>
Anybody seriously looking into providing an alternative to X should look into Berlin. It's got a clean architecture and since most of the drawing is server based there's a huge potential for acceleration. Also, since everything is CORBA based there are bindings for pretty much every language that supports CORBA and the code is that much cleaner since all protocol issues are handled by CORBA
<p>
It might seem that Berlin and GGI are not very active, but don't let the appearances deceive you, there are big things happening in both projects!

Re:Russinovich book --- Windows is snazzy?

[Anonymous Coward]

It must be this feature-baren quality of Windows that make so many people use it...

Lets not forget that no one (very few of us anyway) reading these posts are Joe Schmoe (tm) users. X is fine for someone that can tweak settings and apply themes and knows what a "command line" is. Most users could care less about window snapping or vertical maximization. They want to turn on their computer, and see the same interface that they are comfortable with, use it, and walk away.

I am no X windows veteran, I'll be honest. I starting using Macs and have been using Windows for the past couple years as my primary OS. The one thing that you can say for both Windows and MacOS (at least pre-OSX MacOS) is that there are very few bells and whistles. That is a _good_ thing to some people. The interfaces are clean and consistent, the f-ing mouse cursor doesn't change orientation when you move over a window control, etc, etc.

I'm all for choice. I would like to see an alternative to X. That would give me a reason to switch over to Linux as my desktop environment. Throw on AbiWord and Mozilla and I can use an xterm for the rest.

The overall problem with this thread is that people are saying "Why use A when B has all these other things that are better!?" when for a lot of computer users its those "other things" that run them off to other UIs.

Posting anonymously because that way I can pretend I didn't post this.

Mouse gestures

[pclminion]

I'd have to say one of the cooler things happening more and more, and something you might want to think about playing with, is mouse gestures. The user makes a certain gesture with the mouse pointer to trigger a certain action. The Opera web browser does this, and it comes in fantastically handy. While holding the right button down, drag left and release. This is the "back" function. Dragging right instead goes forward. Right-left-right kills the current frame. Down, and you open a new frame.

I've found that these gestures decrease my command-time by a huge amount. I'm navigating all over the place without moving more than 50 pixels in any direction!

Implement on top of OpenGL

[Animats]

If you want to do a new window system, try one on top of OpenGL.

• You can run on top of Linux, Microsoft, and Apple OSs, plus some others.
• There's a well-defined API for talking to the display system.
• By the time you get it done, everything on the market will have at least NVidia NForce 3D acceleration (which is equivalent to a GEForce 2), if not better. So there won't be a performance problem.
• You can double-buffer, so that users never see partially drawn windows.
• You can scale and morph windows easily, so you can implement effects like MacOS X, if you want to.
• You can port Quake to it.

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:Implement on top of OpenGL

[Yes]

...and here are some additional ideas:

• You can implement whatever coordinate system you want. It doesn't make much sense to use pixel coordinates today. Using relative coordinates or some sort of mapping (e.g. one unit in the GUI is one inch on the screen) you could use whatever resolution and the GUI would look the same.
• You will have trouble with cheapo 3D hardware & drivers (even in the MS Windows environment, where the hardware is "supported").
• Double buffering is not OpenGL specific feature.
• If a direct OpenGL hardware access is granted to all applications (which would be nice) you will run into render state problems. That is, after each app has rendered you have to reset the device states (which is usually expensive).
• Framebuffer is no the only resource. You have to manage textures, vertex buffers etc.
• Treating the device badly probably leads to a system crash.
• ...

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

Programming a window manager

[linux_warp]

So where would one start out programming a window manager? I searched google but couldn't find any decent information.

Mindwarp

Re:Programming a window manager

[waschebaer]

If you look at many window managers home-pages, they say things like "which came from $(ANOTHER_WINDOW_MANAGER), which came from ...", so they were started off by someone hacking around with a previous window manager, until it became a seporate entity, not just a hack. I use windowmaker which (IMHO) is very elegant and easy to use. I have looked at the src a few times, and every so often change something (nothing releasable), and find that the main source is very easy to edit, and browse, so if you want to start, try reading through that. Its probably not the easiest, but its the one I use (I'm biased).

Threading in window systems

[rnyberg]

"Concurrent programming in ML" by John Reppy has got some interesting ideas about threading in window systems, and also code that implements it.

The idea is to have every widget in its own thread, which should make applications more responsive to user input and which would also negate the need to force the event based type of API down application programmer's throats.

Re:Wheel.

[Anonymous Coward]

Explain why a Macintosh pull-down menu can be accessed at least five times faster than a typical Windows pull-down menu. For extra credit, suggest at least two reasons why Microsoft made such an apparently stupid decision.

1. They didn't want to mimic Apple's look and feel.

2. It's confusing tying all applications to one menu bar. If a user wants to switch to another application, or use some menu from another application, they have to explicitly change the application, wait for the menu to change, then use the menu. On windows/sun/etc, just go to the menu that's associated with the application's window.

QTopia...?

[abdulla]

i think QTopia is a great idea, if only it ran on desktops

iMac puck mouse

[Aapje]

The mouse had only one mistake originally, it lacked a way to orient it. This was later fixed (a small indent on the button).

Once you've used it for a while, most people seem to like it:

At the risk of incurring the wrath of the group, I have to say I actually rather like the round mice.

At first I hated them, like everyone else seems to. But after a while, I stopped getting the thing the wrong way up and watching the pointer go the wrong way, and I became pretty neutral.

After a few more months, I noticed I was finding the round mice much more comfortable to work with. I'm not sure why - I think the small size gives me more room to move the mouse up and down with my fingertips, without bumping into my palm or losing touch with the buttons. Anyway, I'm not looking back now - it's round mice for me.
Post by Malcolm Cleaton

Those who argue that the round mouse is probably very uncomfortable for experienced mouse users are probably correct. I found it quite horrid for the first 2 to 4 weeks.

But now, it's *great* to use. Those who argue that it simply isn't ergonomic and is therefore completely unfit for use as a mouse are wrong. Wrong, wrong, wrong.

Having persevered, I find this the most comfortable and easy to use mouse I've ever used. It's different - but better. It provides effortless fingertip control of the pointer. I use it for hours and hours on end and love it.

Perhaps I wouldn't have come to enjoy the earlier variety - the type without the subtle but completely effective button indent (for orientation) at the top - with it, this USB puck is a delight.
Post by Bahi Para

I was a critic also once (without having used it). But I'm convinced now. Also by the fact that there has been research which shows a round mouse to be optimal.

WeirdX? Why not WiredX?

[Anonymous Coward]

It's worth checkig out its snapshot.

Write a Server

[Anonymous Coward]

for the GNU Hurd Mircokernel --
or a new Microkernel :-)

http://www.gnu.org/software/hurd/hurd.html

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.

Fitz's Law Is Wrong

[TheAJofOZ]

Well, it is technically correct in what it says, but it unfortunately leaves out a lot. The time to acquire a target is a function of distance to and size of the target as well as a range of other factors. The most significant factor that is left out is one that is used throughout the article, motor memory.

Suggestions such as:
as the user pulls further down the menu, more movement of the mouse is necessary to get a corresponding movement of the pointer
is a perfect example of when not to apply Fittz law. Technically this should be faster, but in reality it blows the users motor memory for how far the mouse should be moved away and results not just in a slower access to that menu, but if used pervasively enough, slow access to everything because the user can no longer guage how far the pointer will move. In short, since moving the pointer is so fundamental to using a GUI, it should be completely consistent to take full advantage of motor memory.

Another indication is:
What they should have done was to curve the keyboard sharply upward, so that merely lifting the finger a few degrees would access the numeric and function keys, aiding both precision and speed.
because it changes how you go about striking a key - you now use an upward action for some keys and downward for others, thus losing motor memory. More than that though, a downward stroke of the fingers is significantly more easily controlled, confident and faster than an outward or upward push. Our fingers handle hitting downward quite sharply, but the ends of our fingers are quite sensitive (or worse still, have finger nails which slip around) so using a downward action moves the point of impact further down from the tips of our fingers (though still up towards the tips so we can hit the keys cleanly) and bending the keyboard up would in fact reduce access time and accuracy.

Finally, at least one person has mentioned that keyboard shortcuts are faster, and this is true in some circumstances. If the shortcut is unintuitive it is not going to be useful. For instance, think about the keyboard shortcuts that save you the most time - I'll bet they're the shortcuts for save (meta-key + s), quit (command-q Mac only really, alt-f4 is a bit too much of a stretch for most people to use cleanly) and probably print (meta-key + p). These are fast because they are so persistant through the user interface that they become intuitive. Alt-F-right-right-down-down is neither intuitive or fast. The time taken thinking about what the key combination is has to be factored into the time required to achieve the goal. Having keyboard shortcuts for everything is not the way to create an effective GUI - have intuitive and easy to remember keyboard shortcuts for the most commonly used tasks however will markedly improve the usability of an application.

Re:Fitz's Law Is Wrong

[ForceOfWill]

Suggestions such as:
as the user pulls further down the menu, more movement of the mouse is necessary to get a corresponding movement of the pointer
is a perfect example of when not to apply Fittz law. Technically this should be faster, but in reality it blows the users motor memory for how far the mouse should be moved away and results not just in a slower access to that menu, but if used pervasively enough, slow access to everything because the user can no longer guage how far the pointer will move. In short, since moving the pointer is so fundamental to using a GUI, it should be completely consistent to take full advantage of motor memory.

I agree that consistency is important, but humans are very capable of changing their behavior in response to a different context. The canonical example is the sentence "Can you please can the can-can while I'm on the can, man?" In this case it means that we can differentiate between "menu-pulling" context and "general mouse motion" context, so having different rules for these two contexts doesn't break consistency as much as you'd think.

you now use an upward action for some keys and downward for others, thus losing motor memory

Again, this can be used with context in mind. I agree that curving the keyboard more than it already is is probably a bad idea, for the other reasons you give, but not for this one. Motor memory is context sensitive: learning to play flute doesn't affect your piano-playing skills negatively.

Alt-F-right-right-down-down is neither intuitive or fast.

Here you just ignore your previous motor-memory arguments. When you navigate the menus using Alt-menuletter-arrows, you eventually program the right sequence into your fingers, and they can perform them quite quickly. Learning Alt-q is probably still better than learning Alt-F-up-enter, but has a slightly steeper learning curve.

Re:Wheel.

[Anonymous Coward]

> I'm amazed that so many GUI experts, years in the field with abilities to make a mouse go 10x faster don't go the extra step to define a nice, standard way to let the user go 50x faster with the keyboard.

How about Dvorak?

Smalltalk!

[Anonymous Coward]

In a smalltalk system, everything is written in the same language... smalltalk. The kernel, the development tools, the gui... everything. Now, I'm not advocating s.t. as a complete and usable OS, but it can be an interesting toy to mess around with. Check out www.squeak.org for a modern implementation of smalltalk.

you have such a resource

[markj02]

It's called "X11". X11 isn't really a "window system", it's a network transparent graphics library. X11 gives you the low-level graphics, access to hardware acceleration, and network transparency. You can build whatever "window system" (in the Windows/Apple sense) on top of that: your own APIs, your own window management, your own input methods, etc.

Pike's comment on Plan 9's 8 1/2 windowing system

[billstewart]

Pike gave a talk at some Usenix a decade or so ago(I think Nashville?) on Plan 9's window system named 8 1/2, and on his "acme" user interface on it. One remark I remember was that "Ken Thompson and I spent a decade learning about things that window systems shouldn't do, and wrote one that doesn't do them." It's extremely lean and mean - I think he said the source code was about 64KB (could have been 64K lines?) and compiles in ten seconds on the Plan 9 CPU cluster (which was a then-blazingly-fast multiprocessor SGI, probably a couple hundred bogomips.) What impressed me was watching him start the window system from a shell prompt - he typed "81/2", hit return, and in about the time I'd have expected to get a $ prompt back, there was a running windowsystem on the screen - certainly under a second on a NeXt 680x0 box.

Yes, if I had real Unicode I could have written the "1/2" as a single character like Pike does

Taking a WayBack Machine ...

[gnetwerker]

Much of the early work on display managers/window systems was done in the early-to-mid 80's. The reference to Gosling's book is a good one, as is the one to Plan 9, and some of the later graphics texts contain chapters on the subject, though I know of no strong ones. I'm away from my library, or I would give you citations. I recall a detailed design document for the Apollo workstation window system, and Dave Rosenthal built an early window manager for Sun.

All of this was pushed aside by the two dominant implementations: X and Microsoft Windows. The first is clearly a case of second-system-syndrome: expansive in its features, baroque in construction, and hopelessly complex. MS-Windows is a tangled mess that no one outside of MS ever really sees or would care to.

The discussion here is on target in asking a key question: are you interested in this for your own research purposes (many students write operating systems they never expect to live out the year), or do you really want to replace the dominant paradigm? Your choice of literature will vary depending on the answer.

If you are doing the first, by all means start at the framebuffer bits! Understanding rendering (whether blit or copyrect or whatever the modern 3D equivalent is) is crucial. In particular, if you want a thesis topic, look at really good 3D font rendering ...

On the other hand, anyone who wants to work on overthrowing the windows-icons-mouse-pointers paradigm certainly has my vote. As someone who built at least two contributions to the last paradigm, I can say without fear of contradiction that it is getting quite long in the tooth!

To be taken with a grain of salt, I humbly submit one of my contributions to the literature: S. McGeady, Window Managers are Operating Systems: Software for a Distributed Graphics System, pg 23-34, USENIX ;login: vol 10, no 4 , October/November 1985.

Best of luck,
S. McGeady

Re:Wheel.

[kiwipeso]

I'm in the middle of designing KEG, the KAOS Environment GUI. KEG is based on the KAOS operating system, based on OpenBSD, blah blah blah.

The menubar is on top or bottom, depending on personal preference.
Hiding items won't happen in the K A O S main menus, but it maybe allowed in application menus.
The A O S menus can be expanded out to be the main menus (after the system K menu) if you click K A O S with a modifier key.
If you Command click the menu, it pops up as a floater like some of the unix OS's do.

Contextual menus have an option of popup or circular navigation, but are basically the same.
MenuStrip controls can be placed on the menubar, the dock, or floated. (these are like the Mac os 9 control strips)

If you can think of anything to add to the OS, please tell me and I'll give you credit and maybe a copy of KAOS when its ready.

TablOS (Re:What I want...)

[Tablizer]

(* I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp. I want one language that can serve every purpose *)

No no no! A table-based OS. Everything is in (relational) tables. The file system, the GUI, the task manager, resource manager, etc.

Then the language would not matter much. You could talk to the OS thru table API's (including, but not limited to SQL).

BTW, there already is a LISP-based OS. It is called Emacs. It started out as an editor :-)

Think like me, dammit! One brain fits all!