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?"
That windowing systems and HCI are distinct. Windowing systems is a component of HCI, but so is command line interfaces, voice interfaces, and graphical interfaces.
Windowing systems is one metaphor applied to graphical interfaces. HCI includes the concepts of learnability, consistent behavior, teachability, and useability.
I'm defining learnability as the capacity for the system to teach the user, and teachability is the capacity for the system to adapt to the user.
Windowing systems doesn't necessarily have anything to do with any of those four points unless the designer and developer choses to address those points. Themes and skins count as teachable, adaptable systems, but do not necessarily mean the system is useable, powerful, or capable.
GPL Deconstructed
BS: "Sir, the post can't be moderated any lower."
PS: "Damn the regulations! Flames on! Engage!"
holi! stale-ass moderators can't take a joke....
-shpoffo
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.
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.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
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.
int func(int a);
func((b += 3, b));
"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.