Resources for Rolling Your Own Windowing System? 279
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?"
OWL, MFC, K, etc. (Score:5, Informative)
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. (Score:3, Insightful)
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. (Score:2)
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. (Score:1)
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. (Score:3, Interesting)
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. (Score:2)
Re:OWL, MFC, K, etc. (Score:3, Interesting)
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. (Score:2, Informative)
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. (Score:3, Offtopic)
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. (Score:3, Informative)
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. (Score:2)
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. (Score:2)
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)
Re:OWL, MFC, K, etc. (Score:2)
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.
Windowing system or window manager? (Score:3, Insightful)
Re:Windowing system or window manager? (Score:3, Offtopic)
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? (Score:2, Insightful)
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 [snes9x.com] 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 [rebelbase.org] 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? (Score:2, Insightful)
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? (Score:2)
Money makes the world go round...
Re:Windowing system or window manager? (Score:3, Offtopic)
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? (Score:2)
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? (Score:2, Interesting)
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.
Network transparency (Score:3, Insightful)
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.
How do YOU propose for apps to talk to the screen (Score:2)
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.
Re:Windowing system or window manager? (Score:2)
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? (Score:3, Insightful)
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 [freshmeat.net] that are absolutely tiny ie. a couple of hundred k. The gzipped source for aewm [red-bean.com], for example, is apparently under 50k - incredible
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? (Score:2)
Jason.
A possibly useful page for "window designers" (Score:2, Interesting)
http://www.atai.org/guitool/ [atai.org]
Re:A possibly useful page for "window designers" (Score:2, Funny)
CIBSE Window Design paper [virtual-conference.com]
X is fairly low-level (Score:2, Redundant)
Anyways, the greatest documentation of all to learn form is, was, and always will be source code [xfree86.org].
Just wanted to point out... (Score:4, Offtopic)
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... (Score:3, Interesting)
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.
rolling (Score:2, Interesting)
I think I know what you guys were rolling before writing that bizarre headline.
Talk to Gnome/KDE developers... (Score:2)
Also, check the code of successful, open source windowing systems...
I'm right there. (Score:5, Interesting)
-Jon Gentle(atrodo@atrodo.org)
You're absolutely right! (Score:3, Funny)
Re:I'm right there. (Score:2)
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. (Score:2, Insightful)
A graphical user interface for DOS? What a novel idea [microsoft.com]!
There is little... (Score:2, Insightful)
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.
There's always the source code. (Score:1)
DONT (Score:2, Insightful)
Re:DONT (Score:2, Redundant)
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 (Score:3, Interesting)
>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 (Score:3, Interesting)
With regards to "advantage of internal support for vector fonts", the advantage is that all apps would just say "draw these letters to the screen with these fonts" and the anti-aliasing, etc. would happen internally. Now, only apps written to the XRender extension do that. This means some apps support anti-aliasing, some don't. This makes my desktop ugly as sin. Also there are two parallel font management systems. This is a nightmare.
OS X DOES support legacy X11 applications, since you can run XFree86 in rootless mode under Mac OS X. It's just that they are heinous looking compared to Aqua apps.
As for your comments about DPS and the fact that OS X uses DPS as well, I am aware of that. If you are saying we could use X11 with DPS, I suppose that is true, but that seems like yet another awful hack to me. Why not just make something new and better (DPS based or otherwise) and support X11 as an add-on, or for backwards compatibility with legacy X11 apps?
Re:DONT (Score:3, Insightful)
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 (Score:2)
Re:DONT (Score:4, Insightful)
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 (Score:2)
Re:DONT (Score:2)
DisplayPostScript can do this for you, you just have to add DPS support to the toolkit of your choice.
bye...
Re:DONT (Score:2)
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.
No references, just a little advice. (Score:2)
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 [asktog.com]. 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.
Window System Development (Score:2, Informative)
Re:Window System Development (Score:2)
Here's all the info you'll ever need [microsoft.com].
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. (Score:3, Interesting)
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 [fltk.org] (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... (Score:5, Informative)
These guys spend a lot of effort answering the kind of questions you're asking.
Russinovich book (Score:1)
Not what he's looking for (Score:2)
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 [microsoft.com] reveals that this book has pretty much nothing to do with developing a windowing system or a window manager.
For design principles (Score:1)
http://www.sylvantech.com/~talin/projects/ui_de
Swing (Score:1)
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 [sun.com] or the documentation [sun.com]
What I want... (Score:2)
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... (Score:2)
Re:What I want... (Score:2)
Check out Symbolics [symbolics.com]. 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... (Score:2)
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... (Score:2)
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... (Score:2)
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 [sonic.net].
Re:So what you're saying is... (Score:2)
Also, Lisp is much faster than you think it is. Take a look at this [nasa.gov].
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.
auto GUI?? (Score:2, Informative)
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...
It's a ten line program (Score:5, Funny)
#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;
}
Believe it or not, C++ (Score:1)
I made an awesome AWT in about 2 months for my MMORPG using C++. Too bad the market got swamped.
SVG GUI (Score:3, Informative)
Sorta off-topic, I know, but you might be interested in working with a community from the ground up.
What level are you trying to address (Score:4, Insightful)
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.
Understand prior art first (Score:4, Informative)
Here is the classic paper on how X could be improved, for example: http://www.std.org/~msm/common/WhyX.pdf [std.org].
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.)
Plan 9 Rio indeed... (Score:2)
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...
Namespaces (Score:2)
Re:Namespaces (Score:2)
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/
I should toy with it soon...
Plan9 (Score:5, Interesting)
http://www.cs.bell-labs.com/plan9dist/
(for starters see this paper on the old plan9 window system) - http://www.cs.bell-labs.com/sys/doc/8%bd/8%bd.htm
there is some information there, and the source code for the window system is actually readable because it is much few lines of code and over all simpler than x windows.
also Rob Pike (who worked on plan9) has written several interesting papers on windowing systems.
try reading them by poking around this site - http://citeseer.nj.nec.com/144447.html
http://citeseer.nj.nec.com/pike89concurrent.htm
(sorry the actual articles - linked off of the above links are only ps or pdf, no html)
These papers, the plan9 window system as well as the inferno window system prove that a simple, elegant window system can be created that is both fast and runs over a network.
Granted these use some features that don't exist in the unix world (like plan9's threading model, and the use of per process namespaces) but I believe these can be emulated somewhat using standard networking.
The size, complexity and performance of x windows are all indications that it is not the optimal solution.
Pike's comment on Plan 9's 8 1/2 windowing system (Score:2)
Yes, if I had real Unicode I could have written the "1/2" as a single character like Pike does
No more, please!!! (Score:3, Interesting)
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.
Yet another post (Score:2)
Re:No more, please!!! (Score:2, Insightful)
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...
MVC and Views (Score:4, Insightful)
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).
Cassoway (Score:2)
Why reimplement X? (Score:2)
Implement on top of OpenGL (Score:3, Interesting)
Re:Implement on top of OpenGL (Score:2, Informative)
Why Low-level ? On linux we also have framebuffre (Score:2, Informative)
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..
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 :)
QTopia...? (Score:2, Interesting)
you have such a resource (Score:2)
Re:Wheel. (Score:4, Insightful)
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.
Re:Wheel. (Score:1)
MacOS "top menu" (Score:2)
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:Wheel. (Score:3, Interesting)
Re:Wheel. (Score:2)
Re:Wheel. (Score:5, Insightful)
Fitz's Law Is Wrong (Score:2)
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:Wheel. (Score:3, Interesting)
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.
Re:Wheel. (Score:2)
NTBAMAB (not to be a microsoft apologist but
It's not a bad idea, the execution is just a bit sucky.
Re:And before some shithead whinges on about Togsp (Score:2)
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:Try reading 'The NeWS Book' by James Gosling (Score:2)
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 (Score:2)
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.
Re:Write a Server (Score:2, Informative)
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.