Slashdot Mirror
Next Generation X11
Rene Rebe writes "The German News site Golem is running a report (babelfish translation) about the next generation X11 projects, like the OpenGL X-Server Xgl, Luminocity as well as Enlightenment 17. The report is including many screenshots and five videos."
so? OSX has a very nice graphics architecture with lots of potential. X11 is old and crufty, and these sorts of effects require large portions of code to be rewritten. If it can suddently render a genie effect efficiently, imagine how quick it'll be to render more mundane windows!
X11 is not just for Linux, you know!
If all this should have a reason, we would be the last to know.
How about implementing dynamic X server reconfiguration to allow connecting and disconnecting external monitors to laptops on the fly? How about using different resolutions on these monitors?
Right now Linux/X11 is horribly behind both Windows and Mac OS X, being unable to detect an external monitor being connected and change resolution accordingly.
To me a lot of these effects are just copied from OS X
Are you implying that that's a bad thing? OS X has many nice GUI features. I'd like to see some of them on my Linux desktop
So in another 4-5 or more years X will have the same stuff that OS X has had for a while? This highlights the problem with Opensourcesoftwaredevelopmenten. Things go swimingly until some really un-fun interface code needs to be written. At that point, you really want to pay someone to do the grundge work. Auf Weiderscrheiben, Mike .
It has actually be shown a number of times that fancy features (such as integrating a physics engine into the desktop as so) actually leads to a more complex and harder to use system. I have to congratulate these guys on what they've achieved, but at the same time I have to wonder if this is the right direction to take, especially since Linux's only major flaw is in fact its lack of usability.
Perhaps the reason the effects have gone unused on other platforms is because they weren't part of the platform. If every application is individually responsible for managing the effects, then of course few applications are going to use them.
If the effects are provided by the desktop environment independently and transparently (no pun intended) to the application developer, then everyone is going to use them.
That is the whole point of these effects. They are going to be part of the underlying desktop to provide more appealing visuals. It's much more appealing when switching from window to window to see the old window quickly tear apart or fold itself away, and the new window to quickly and smoothly slide into place than for the windows to just suddenly change.
It makes a lot more sense for the underlying window manager to be responsible for those effects than to burden individual applications with the responsibility.
This gets dragged out every... damned... time... X gets a mention anywhere.
The argument goes like this:
A> X is bloated.
B> No it isn't.
A> But what about network transparency? That's useful.
B> You actually use that crap? Fine, network transparency is neat. But there should still be a way to shut it off.
Welcome to the next point in that argument -- the realization that any time the windowing system and its processes are running in separate processes, some form of communication will have to result ni order to allow the client to do such nifty things as detect mouse clicks or draw things to the screen.
Now that you're dealing with communication between processes, there are many ways to handle the problem. They all involve some mechanism by which communication can occur.
Let's see... two programs with a need to communicate with each other... we wouldn't have a mechanism which has been tested and refined over many years to be pretty darned good at communication, would we? Where would we... hmmm... let me think, I know that at some point there must have been the need for communication at some point in the history of computing...
Oh! A network stack! It's perfect! It not only allows high-performance, low-overhead local communication via highly optimized mechanisms which are available on damned near every operating system on which anyone in their right mind would ever want a windowing system (see contest rules for details, some exceptions apply, mileage estimates provided by EPA methods), but has a built-in mechanism for communication between machines!
Hoo, boy.
The point is, sarcasm mostly aside (maybe), that there is the need for programs to communicate. This isn't a requirement which you can simply opt out of, like, say, FAT support or unneeded sound card drivers. This is a requirement that you can't get rid of, and to use something that doesn't allow network usage is basically to limit yourself to mechanisms which are much less widespread in availability than an IP stack.
An IP stack is a good tool for the task at hand, and it just so happens to be really damned hard to remove networking from it.
I'd be interested if you could provide a counterexample -- find a widely available, generally reliable IPC (interprocess communication) mechanism which is for the most part platform-agnostic and doesn't require tons of massaging in order to get the data into the right format. Bonus points abound if it does not include the ability to communicate across a network, which you requested be unavailable.
Somebody get that guy an ambulance!
> Network transparency doesn't involve significant overhead, dammit!
Well actually, yes it does. You still have to marshal pixmaps (a wretched and primitive yet still bloated format) into a shared memory segment just so the server can pull them out of there and transfer them to the graphics driver. And X's implementation of network transparency doesn't give clients any way to tell the server to aggregate events or even tell it to "shut the hell up already" with all the mouseover events over regions where they're not listening to the events.
Network transparency is a good thing. X's implementation of it stinks.
I am no longer wasting my time with slashdot
Zooming and keyboard bindings I agree with, the rest of your proposals do not seem compelling.
Just a friendly suggestion, but you might be able to keep people off your back if you occasionally add a news item. It doesn't have to be any big news (like a release), just something to let everyone know "Hey, we're still here! Don't bug us about it!" It can be as simple as a status report or "I had this cool idea and I'm working on coding it." It could even be the line, "Yes, we're still here." (Although that won't keep anyone's interest for very long. ;-))
Just my two cents.
Javascript + Nintendo DSi = DSiCade
We have really neat X11 desktops right now.
MODS: Will you please give this guy back a point of Karma or two? Just because he's got fruitcake ideas doesn't mean that he deserves to be silenced.
Parent Poster: You're way off base on the "problems" with X, but it does strike me that you're grasping for what the core issue is. The remaining issue with X.org/XFree86 is not with the controls, but rather with the monolithic architecture. X11 demands the full attention of the video card plus all other hardware it controls, and does not like to give up that control. The result is that X11 tends to be inflexible for work outside of "normal" desktop usage.
What X.org/XFree86 really need to do is separate the graphical and interface device layers from the desktop interface layer. i.e. It should be possible for any system program to be able to ask for exclusive video card access, even when the Desktop is not running. Currently, you have to chose between running X11 or using the external SuperVGA library.
You'll note that this is how the X server functions on systems like Sun Sparcs. On my UltraSparc, the system is ALWAYS in graphics mode. Running X just makes the X-Server take over the graphical screen. Very modular, very flexible. Not to mention that it places the graphics card support back in the OS drivers where it belongs, and not in a server with a focused purpose. Remember, the Unix philosophy is to keep everything in simple, bite sized chunks. The X.org/XFree86 implementation is the anti-thesis of that (although they are attempting to compensate with their portable driver loader design).
Javascript + Nintendo DSi = DSiCade
All of these have been met. Maybe not as timely as would be nice, but met. What you don't seem to understand is that "really neat" is a moving target.
I don't care if no-one else gives a shit about it. Doesn't stop me having fun. Market share, PR, and all that crap is for companies and egotists.
Phil
I guess today is a passable day to die.
If X wasn't a process it'd have to be a kernel service, and itegrating X with the kernel would make the kernel bloated, open the kernel up to security issues from the windowing system, and generally screw up a lot of things. But every application wouldn't be drawing it's own stuff, it'd have to message the kernel. If every application tried to draw to the screen by itself you'd have unusable chaos instead of a desktop. Look at the state of things with TWO major drawing librries, now imagine if they had to actually talk directly to the screen buffer. It'd be a nightmare and leap us back to the days of DOS 6.0.
Stop intellectual property from infringing on me
While I agree with most of this, it should be pointed out that local X connections (i.e., the ones in which the server and the client run in the same machine) are usually done via UNIX sockets, not IP (witness the socket in the /tmp/.X11-unix directory while you are running an X session). The reason for it is that UNIX sockets offer less overhead than a TCP/IP stack.
Also, in modern toolkits (GTK, QT) images are usually sent via shared memory (again, only possible when the client and server are in the same machine), which is much more effecient than sending them through sockets.
Face it, monitors and input devices are two dimensional (well mice at any rate, keyboards are one dimensional), simulating a third dimension adds complexity - both in use and in implementation - and doesn't add anything to useablity or productivity. Sure, you get about 5 minutes of "Oooh, shiny!", but that's about it.
Navigating 3D space with any of the current input devices is a huge pain in the ass, trying to do useful work with a large amount of data on such a thing will get frustrating very quickly. They make it look cool in movies, but that's becuase it's scripted.
sic transit gloria mundi
This is one of my 'problems' with open source. Generally it feels like everything is a copy of windows/os x. (yes, I know there are a ton of projects underway, but nothing too mainstream) It's great we're getting transparency, fancy window effects etc, but really we're just copying os x, and a bit what longhorn will bring to the table.
We can code, no question, but what we need is a vision of what the computer is that goes one step ahead of os x/windows for people to take notice. Right now we are just sreaming 'me too' os x has nice transparency, me too! longhorn will have bland animations, me too! We need to get one step ahead, so that we can say, yeah os XI stole that from us, that's right, longhorn xp 2013 did copy that from us.
Im.
look at your average winXP installation with applications and count the processes. hrmmm... quite a few there eh? Now tell me what each of those svchost processes is actually hosting? Not easy is it. There are benefits to the way it's set up on Gnome and X. If the clock on your windows taskbar should for some hypothetical reason lock up how would you kill it? Kill Explorer? that just killed your whole window manager. Sure you can restart it with a handy little ctrl-alt-delete but you just lost all that stuff you were working on.
Me I far prefer having all those apps launching in nice easy to see processes. You don't like how much space it takes in memory? use a different one. Admittedly Gnome makes this harder than say FluxBox but the choices are there.
Explorer on my WinXP box at work takes up 20 megs in memory and has who knows how many threads. X and whatever desktop/window manager you use just make it easier to see what's doing what and change what you don't like.
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
My point is that just getting rid of the network socket won't help you any. You'll still end sending exactly the same stuff but using another mechanism, incurring in pretty much the same overhead.
Well, what the other guy was saying makes sense to me.
If you're communicating by sockets, you have to make two context switches, right? One to call the kernel, and one from the kernel to the X server. Whereas if there was a system API, then it would be just one context switch: you call the kernel, end of story.
If we count entire paths, it would be: you-kernel-x-kernel-you, vs. you-kernel-you.
So, I would imagine that your time from calling to the time of receipt would be much faster. This could be very important in games, I would think.
In a kind of parrallel situation, the GNUStep people were trying to figure out what to do with Display Postscript -- they didn't have a good or fast implementation, and DPS was supposed to be central to the NEXTSTEP design they were copying. Then someone hacked together something that implemented the Objective C bindings that generated Postscript, and made them call the xlib libraries directly, because the whole DPS thing was taking too long. It was meant as an intermediate step... but it worked. Last time I looked (which was a long time ago) they had given up on DPS as a pointless abstraction. If they want to implement accurate printing later, they can do so by creating another, entirely separate Postscript-generating layer (but without having to worry about performance or interactivity or other non-print related things).
The same possibility exists for X. Give up on the client/server and network transparency. If it matters so much, you can easily implemented it on top of a non-transparent system (as long as you have a defined API with no back doors). If it matters so much there's probably multiple ways of implementing transparency with different tradeoffs. Various hardware would have different implementations of the xlib C API -- those implementations could share code, but only if they wanted to. All the other policy, like fonts and security and whatnot, would be implemented separately, which is already happening anyway.
We have a layered system. And that's fine (and even if it wasn't it can't be changed). But X got some of the layers wrong, I think it actually did too much. That can be fixed.
This could be very important in games, I would think.
The graphics engine needed for a game is very different than the graphics engine needed for most other things. The former almost requires a kernel bypass to write directly to the video hardware. But that's overkill for drawing buttons and edit fields and window frames.
Don't blame me, I didn't vote for either of them!
Repeat after me: all modern graphics systems use IPC! If you want to get rid of the context switch overhead then you have to write directly to the hardware. There isn't a single operating system which allows you to directly write to the video hardware (with some exceptions, like DGA). Not MS Windows, not MacOS X, not BeOS, not whatever. X as it is right now is not much different from MS Windows or MacOS X as far as communication is concerned: on all platforms, the application has to send a message to an external entity which then draws stuff to screen. You have to do this, otherwise you'll get into synchronization problems with other applications.
So why don't people complain about the IPC overhead in Windows? Because the anti-network transparency hype is overrated.
plug-in, plug-out all kinds of useless^H useful crap.
Screw you. Lack of proper X support for switching between my laptop's LCD and external DVI output is my biggest problem with Linux right now. WinXP does it with zero user intervention.
Device hotplugging and autoconfiguration is the number one hardware support priority for Linux on the desktop. (The Linux kernel is not all that hot on some types of hotplugging either, and userland support for what it can do is braindead in almost all distros.)
[an error occurred while processing this directive]
All I want is 3d for arranging my windows. The windows should stay flat and look the way they do, but I want to be able to rotate myself around them. Go around the back so the window on the right is now on the left. Tilt up a bit to see my media player. Desktop switching with my mousewheel is something, but I want to be able to continuously scroll.
I am trolling
jesus christ. osx's dock effect is one the crappiest and most useless effects ever. a simple highlight/outline/arrow would suffice. instead, you have a crazy dock with icons changing size and sliding all over the place.
this is not even counting how crappy osx's dock is overall compared to say, kde or gnome's panels... functionality wise, osx's dock is horrible.
and the dropshadow effect is near useless, considering that ALL windows have dropshadows. the active window's dropshadow is slightly more pronounced than other windows, but it's only really noticeable when you have windows overlapping each other. the easiest way to tell which finder window is topped in osx is to look for the colored buttons. of course if you're colorblind, you're screwed.
interestingly enough, the use of color as 'active' indicators is a violation of apple's own gui design rules from original macos.
aqua is a step backwards in usability in many ways. apple favors eye candy now over usability. and to think apple users criticize microsoft for the same thing that osx is guilty of now...
expose is needed because osx doesn't have a pager by default. virtual desktops is much better for productivity than juggling tons of windows in a single crowded desktop. in that case, expose is better than nothing -- but only barely.
and now the legions of rabid apple kool-aid drinkers will flame me and mod me down into oblivion.