“A couple of years ago I wrote a paper about what I’d do if I were asked to design a window system today. I never published it other than to hand it around to a few friends. So now, it’s here,” Java’s James Gosling writes.
James Gosling’s own DE
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The ideas he presents are really obvious, but avoided because of the fear of breaking X compatability.
We break applications constantly for other libraries and compilers, so why won’t we break apps to get the desktop caught up with todays needs and computer power? Like he says, the GFX chip can handle much more load than 10 years ago and the network hasn’t kept up. (Yes, I know X isn’t using the network on the same machine)
I know that someone will flame me for this comment, just like always, but X could be significantly improved or even depreciated into a wrapper.
“I know that someone will flame me for this comment, just like always, but X could be significantly improved or even depreciated into a wrapper.”
flames: X _is_ being significantly improved. folks complaining about X should be more specific rather than blurting out the usual “X is crap and needs to go”, “network transparency needs to go”.
As usual it isn’t just the application one would break compatiblity with.
On the one hand it would be a big problem for most application because they only build on top of some toolkits like QT/KDE or GTK/Gnome. One these are portet most things should work.
But what’s more crucial is the fact that there would be no video drivers. Such a system Gosling describes need some good drivers to work with, and to be honest that would be a big problem.
I wonder:
– wouldn’t the simple ‘stacking order’ advised by this paper create problems with transparent window?
– what about network transparency? Apparently it is made above the window system, which means that there will be probably multiple incompatible network protocol..
– how can application rendering be as efficient as server rendering?
I think that the server may use more easily hardware acceleration of modern GPU, whereas I’m not sure how the application could, or maybe the application always render to a texture and then the server merge the texture?
Seems wastefull when there is no transparency needed..
I wonder:
– wouldn’t the simple ‘stacking order’ advised by this paper create problems with transparent window?
Right, like transparent windows are the most important feature. I mean, is there a single useful application of transparent windows other than desktop wallpapers obfuscating shell windows? Seriously.
Transparent windows are needed for many many UI improvements, for example :
– video conferencing over a document (you see the guy and the document you’re talkink about.. mm.. where did i saw a news about this idea ?)
– OSD in a clean way
– Input guide (you got a wacom tablet, you want to use a jpeg as a guide in an application that does not support backgound image…)
– semi-transparent Tv/Movie player over desktop (mm.. bad idea.. lol)
– So much more!
Transparent windows are needed for many many UI improvements, for example :
– video conferencing over a document (you see the guy and the document you’re talkink about.. mm.. where did i saw a news about this idea ?)
Do you honestly believe this would actually improve the usability of a video conferencing system? A better idea might be to have two non-overlapping panes, one with the document, the other with the video image.
– OSD in a clean way
OSDs can be done without transparent window support. This feature alone hardly warrants a new window system design from scratch.
– Input guide (you got a wacom tablet, you want to use a jpeg as a guide in an application that does not support backgound image…)
Use specialized programs for specialized tasks, I say.
– semi-transparent Tv/Movie player over desktop (mm.. bad idea.. lol)
It seems to be that is the only kind of “functionality” transparent windows can provide.
– So much more!
Riiiight 😉
Deliver system messages as top windows, without taking focus and without hiding other screen objects. No need for “OK I have understood” buttons.
Have GVim ontop of Epiphany without resorting to 6-lines display.
-John
Deliver system messages as top windows, without taking focus and without hiding other screen objects. No need for “OK I have understood” buttons.
For non-critical system messages, a tooltip-like window on top of the task bar (like in MS Windows) would be less obstrusive in my opinion.
Have GVim ontop of Epiphany without resorting to 6-lines display.
Instead of having to switch between windows, you will have to read through multiple layers of text. This may be an improvement for some tasks, but for those of us having to stare at obscure code fragments for hours and hours its a usability nightmare. Also, Emacs > vi.
I’d like the whole of my desktop or shade over except my current application. That way I’ll be less distracted.
Interesting ideas for a very light wieght windowing system. Network transparancy is simply nolonger a useful feature, as Gosling points out as most desktop applications are not used in a client server situation. All he did was take the system and strip it down to the absolute minimum. Drivers would not be a problem as it would not actually interact directly with the screen, it would simply tell the window what it’s clipping polygon was and then the window would write to the screen via something like OpenGL.
>Network transparancy is simply nolonger a useful feature
I wonder if you’re trolling? Or maybe you don’t know much about working in enterprise..
Please avoid saying such thing, you don’t use it, ok, it doesn’t mean it is not a useful feature for other!
And I don’t think that Gosling is advocating removing network transparency, he just push it above the base windowing system..
I’m surprised that Gosling thinks applications should manage their own window borders. I always hate it in Windows when one of my applications freezes, and then I can’t minimize or move it until it recovers. I always considered the window manager to be one of X11’s great usability strengths.
1) Windows should be handled by the server. The appliction should only be notified by events when something about the window changes.
2) The server should do all rendering. Rendering is slow and time consuming and should thus be distributed as much as possiable. Clients should never render. To prove this, think of having 300 users connected to an application server; each user runs the shared 3D game application. If the client (appliction server) is doing the rendering, then it’ll be over tasked trying to generate the frames fast enought for each user; however if the user’s server is doing the rendering, then application server only need to be fast enough go generate the drawing requests. (Note: this is only used where you’r using a thin client type system; however, everyone writes their programs to do rendering in the client you’ll have a hard time finding applications that’ll run well in the thin client world).
3) We should trash X11 and develope X12 instead. X11 has no concept of window borders, menus, etc… We really should expand the server to support basic window concepts. Thus, the client should only be worried about what is in the layout area of a window. Menus, Border Buttons, Resizing, and Moving should be handled by the server. The concept of themes should only apply to the server and never the client.
4) The server should support a clipboard. If you select a region with-in an application and select copy, the client should determine what format the data is in and send a copy to the server’s clipboard (this includes enough information to determine what the data is. i.e. bitmap, text, …) All applications should then be able to read from the server’s clipboard.
5) Redesign the server to only handle direct calls. This will speed up the rendering on machines where the client and the server are on the same box. Create two versions of libX11; one that talks directly to the local server and one that talks to a remote interface server. The interface server would then translate the inbound requests into direct requests on the local machine. When an application is started, the system should pass it a flag stating if the user is local or remote so it’ll know which libary to load.
I love the people who come up with excuses to support the lack of transparency in a windowing system.
Lets get this straight, your windowing system has an obvious deficiency, so your only course of action is to try and propose workarounds? Look, xorg/xfree can’t do true transparency. This is a problem no matter what excuse you can come up with to provide a work around. a work around is just that, a side step to fix around a deficiency in a system. This needs to be fixed, period. Stop coming up with excuses and defending the X11 world for not fixing this stupid but obvious problem.
It looks like Gosling’s proposal is DirectFB. Too bad about the lack of translucency and security. I am also skeptical about having applications draw their own window borders, because that makes it even harder than usual to enforce some kind of consistency in your desktop.
IMO Quartz Compositor is the way to go.
@omnivector
The lack of translucency/transparency isn’t a problem in many user’s eyes, it is merely an unimplemented feature. X11 (and it’s implementations of XFree86 / X.Org) are fully capable of pulling off this “feat” — but it hasn’t been a priority for those working on it. And true translucency/transparency doesn’t necessarily mean a deficiency in the eyes of apparently many users “making excuses”.
Personally, I feel the X Windowing system is slower than the windowing system used on Mac OS 8,9,X and Windows 2000/XP. I’d rather see smooth dragging of windows (see XDamage/Xfixes) implemented correctly because it’s something that I can use. Apparently you would like the translucency/transparency first (See XComposite). And to that I say, to each his own.
But calling the missing feature a deficiency in X11, not even it’s implementations, would be a fallacy.
(P.S. someone correct me if those extensions are wrong)
I love the people who come up with excuses to support the lack of transparency in a windowing system.
Lets get this straight, your windowing system has an obvious deficiency, so your only course of action is to try and propose workarounds? Look, xorg/xfree can’t do true transparency. This is a problem no matter what excuse you can come up with to provide a work around.
But it is debatable if transparency really is such a crucial feature. Besides looking pretty I have yet to see how transparent windows can substantially improve a graphical user interface.
Stop coming up with excuses and defending the X11 world for not fixing this stupid but obvious problem.
It’s not a trivial (“stupid”) problem. It requires substantial extra hardware power and software complexity to provide that feature in X11. Is it worth the effort? I don’t think so, but then again, I don’t care for the latest super-l33t MP3 player with full transparency.
Some may not consider this of importance, and I never suggested that it should have higher priority over other features. I am however suggesting that it be included eventually, and that it is a feature of high request.
to the Anonymous person:
It is not debatable. Please take a look at the quality of the OS X interface sometime. It is only with transparency that many of the visually stunning effects in os x can be achieved. One of the great things about it, as well, is transparency in OS X is free thanks to quartz extreme’s utilization of the graphics hardware. I understand the reason some people don’t want this fancy stuff, because it requires newer hardware. However I think requiring something as minimum as a Geforce2 (I believe you can go that low on the hardware scale) for some of these useful features is worth it. You should take a look at some of the Tiger additions with CoreImage. Hardware acceleration for coreimage requries a 64mb graphics card! However, look at what you can achieve with it. the ability to do a water-ripple effect ontop of live-updating content in the desktop is pretty amazing.
I know none of this may seem worthwhile to many people, but what’s the point in having such powerful graphics hardware if we don’t push it to it’s limits? Just because you don’t see a use for these features doesn’t mean some creative, inspired developer doesn’t.
It is not debatable. Please take a look at the quality of the OS X interface sometime. It is only with transparency that many of the visually stunning effects in os x can be achieved.
I know OS X. It looks pretty. With respect to UI usability, it has gotten some things right and some things wrong. Besides looking pretty, I cannot honestly say that transparent windows make OS X easier to use than, say, Windows or KDE.
One of the great things about it, as well, is transparency in OS X is free thanks to quartz extreme’s utilization of the graphics hardware… Hardware acceleration for coreimage requries a 64mb graphics card!
So it is not quite free after all, eh?
However, look at what you can achieve with it. the ability to do a water-ripple effect ontop of live-updating content in the desktop is pretty amazing.
OS X looks spectacular, no doubt about it. Whether this improves or harms usability is another question. You see, after some time one usually gets bored with those special effects. I would rather get my work done without having water-ripple on my screen.
I know none of this may seem worthwhile to many people, but what’s the point in having such powerful graphics hardware if we don’t push it to it’s limits? Just because you don’t see a use for these features doesn’t mean some creative, inspired developer doesn’t.
Please, if you absolutely must have it, then go ahead. As long as there is a switch to turn that rubbish off :p
2) The server should do all rendering. Rendering is slow and time consuming and should thus be distributed as much as possiable. Clients should never render. To prove this, think of having 300 users connected to an application server; each user runs the shared 3D game application. If the client (appliction server) is doing the rendering, then it’ll be over tasked trying to generate the frames fast enought for each user; however if the user’s server is doing the rendering, then application server only need to be fast enough go generate the drawing requests. (Note: this is only used where you’r using a thin client type system; however, everyone writes their programs to do rendering in the client you’ll have a hard time finding applications that’ll run well in the thin client world).
Isn’t this how OpenGL over X11 works? The GLX+DGA bit atleast.
Gosling was just pissing in the wind and yall take it as a que to bag X11. If ya don’t like the way X11 does stuff contribute changes to make it better. If the architecture is truely wrong and needs to change then your contributions will be welcomed. Believe it or not, we can have a super fast local X11 with 3d aceleration and a network transparent backwards compatible X11 living side by side until one day the number of legacy applications is so few that we can shed some of that backwards compatibility.
In the distant past, I used to do a lot of graphics work and my first project at Sun was to build a PostScript-based window system called “NeWS” (the Networked, extensible, Window System). It died years ago for a variety of reasons, but lots of folks loved it. I keep getting questions about it, particularly since Apple’s window system bears some resemblance to it. Just a few minutes ago I ran into an old friend who asked the inevitable “Whatever happened to… Could you get Sun to release the source so we could resurrect it?”. I probably could get the source released, but it would be a bad idea.
Why not let us, the users, the techies, the fiddlers-around-with-G*d-knows-what, decide that?
After all, Slackware 2.* came with two windowing systems, MGR and X11, and we made up our own minds as to what we wanted.
A couple of years ago I wrote a paper about what I’d do if I were asked to design a window system today.
Try it out, just a brief implementation of the idea. Then release it under a suitable license, that allows Sun to fork it off proprietarily.
Trust us, we know what we’re doing.