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

Comments

Why isn't this already out?

[AKAImBatman]

1995: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!
1998: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!
2000: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!
2005: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!

Nope, never heard these promises before...

Joking aside, I didn't see anything in the photos or videos that's revolutionary. Enlightenment looks like its usual "prrreeeeetttyyy" self, and X11 is shown with various transparency and warping effects that have been available on other platforms but have been largely unused.

The question of "Why have they gone unused?" seems to be pretty well answered by some of these videos. i.e. None of the applications seem to do much of anything different than current applications do. The only difference is that they have a "cool" interface. All I can say to that is, Kai's Power Tools had a "cool" interface as well. Didn't get them (or hundreds of other "me too!" programs) very far.

The truely interesting projects I've seen lately are:

1. Sun's Looking Glass Project. While it's not revolutionary in of itself, it is an excellent evolutionary step in user interface improvements. Sun really took the right path by keeping with existing Desktop designs, but improving on existing concepts like sticky notes and window shading (the ability to "fold up" a window). They've also left the door wide open for developers to leverage the new desktop for new UI concepts that fully utilize the 3D abilities of the system.

2. There was an "Ask Slashdot" a few days ago with a guy who was working on the mother of all touchpads. It was literally more of an interactive tactical plot that could have amazing uses in collaberative work.

Re:Why isn't this already out?

[Skraut]

Yeah wasn't there a Y windows in the works at one point.

While at times I've been firmly in the "There needs to be an X with less crap in it" camp, I've learned to really appreciate the network transparency. Though I do still wish it was a choice, something that could easilly be plugged in, or removed depending on the system install. The Linux Kernel is so flexable in how you can customize it for the hardware situation, its a shame you can't do the same thing for X.

Re:Why isn't this already out?

[AKAImBatman]

Yeah wasn't there a Y windows in the works at one point.

You mean this?
Fresco was the other big contender.

The Linux Kernel is so flexable in how you can customize it for the hardware situation, its a shame you can't do the same thing for X.

Modern X actually does let you plug-in, plug-out all kinds of useless^H useful crap. It has actually matured into a fairly decent system, network transparency or no.

Where this article falls flat is on trying to make us believe that any of what we're seeing is "new". We've seen it all before, just with fewer cheap effects (e.g. the "wobbly windows").

Re:Why isn't this already out?

[indifferent children]

You are probably referring to the perennial "Why Windows?" campaign.

Re:Why isn't this already out?

[StormReaver]

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.

Re:Why isn't this already out?

[ciroknight]

I think the real problem is, everyone knows X Windows is broken, but nobody knows what to do about it. A few reactionary people set apart to create projects like Fresco and Y-Windows, but the fact is, those are just as useless without knowing what was broken in X Windows in the first place.

As a Mac OS X user, a previous Windows user, and a current Linux Desktop user, I will not be the first to tell you that X is slooow. Windows seems more responsive than most Linux desktop distros I've used, and Mac OS X puts both to shame. Java applications on the Mac (or Windows) even seem more responsive than X Windows.

I still profess that the problem lies with the widget set/window manager not being integrated into the core, but that's just my opinion, and I'm not an expert. It just seems to me that there has to be some code that's shared between the two systems, and together, both systems generate excessive overhead that can be eliminated if we weren't so obstanant in preference of either KDE or GNOME.

To be honest, I'm surprised there hasn't been a project yet to integrate GNOME into X, which I'm surprised hasn't sparked a project to integrate KDE into X (two new forks). It'd be a nice graduate project if someone had the time, and I'd love to see what a GUI on linux could actually perform like.

Lastly, the problem comes with there being absolutely no good drivers available. Honestly, even though NVidia/ATi tries, they're not up to par with what they've got on the Windows platform, and Apple developers have had the luxury of seeing the developer's specs, so their drivers are just as impecible.

I think one of the best things that could come out of open source as of now, would be out of the ReactOS department. Find a way to use ATi's and Nvidia's drivers, then wrap them in such a way they can be used to draw X. I think that'd be an ideal solution, even if 20 people reply and tell me that this is technically unfeasable, and that licences and shit keep us from doing this legally.

Re:Why isn't this already out?

[Alan]

Well, y-windows' last release is over a year ago, and Fresco's last frontpage news item was 2003-03. Looks like there has been some work on it, between then and early 2004, with minor changes (based on the nightly snapshot diffs), but not a huge amount. The snapshot tarball has been 4.1mb for the entire time. I have the feeling that both these projects are basically dead :(

Re:Why isn't this already out?

[vadim_t]

Plugged in how?

This is something I spent a *long* time explaining to some people on a forum about a related subject. Network transparency doesn't involve significant overhead, dammit!

There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.

Now, networking indeed can slow things down a little due to things like latency. But that's effectively inexistent if you're talking on the local host. And X already has shared memory communication as well. On Linux there are also the so called Unix Sockets, which is pretty much like TCP/IP, only with even less overhead since it's done locally, so it can be implemented in a simpler way.

However, as far as an application is concerned, an Unix socket and a TCP/IP one are exactly the same thing, so it makes no sense to get rid of network transparency - you wouldn't win anything with that anyway.

Re:Why isn't this already out?

[hankaholic]

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.

Re:Why isn't this already out?

[BlueCodeWarrior]

It doens't matter if XP has the features or not...you're forgetting that the current version of Windows is Longhorn.

The correct answer is that 'Longhorn's tight integration with hardware thanks to Microsoft's close engineering work with card makers that provides a level of performance unachievable by any other vendor.'

Because, you know, even though Longhorn is over a year away we still talk about it in the present tense.

At least if you're within Redmond's Reality Distortion Field, which is growing to be as big if not larger than Jobs'...

Re:Why isn't this already out?

[snorklewacker]

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

Re:Why isn't this already out?

[WillerZ]

You need to look in either Andrew's arch repository or mine for a more up-to-date version of Y. It's still years away from being usable wherever you get it from, so don't bother unless you want to hack on it. See my other rant: http://slashdot.org/comments.pl?sid=146748&cid=122 93465.

When Y gets to the slightly-usable stage I'll submit a story to /. myself.

Phil

Re:Why isn't this already out?

[vadim_t]

Right. But you need to do this marshalling one way or another. Remove network transparency and you'd *still* have to provide data in some particular format and follow some particular protocol.

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.

It's not like getting rid of the socket would suddenly free you from the need of communicating in some standard way with the server. How would it understand you otherwise?

Re:Why isn't this already out?

[bman08]

Yes, I have Longhorn installed on my 5tb/sqare inch pixie dust drive, and it's damned tightly integrated with my bitboys video card. I use CherryOS on it to emulate the mac at faster than native speed!

Re:Why isn't this already out?

[AKAImBatman]

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

Re:Why isn't this already out?

[teknomage1]

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.

Re:Why isn't this already out?

[Em Adespoton]

Yeah wasn't there a Y windows in the works at one point.

I've been asking myself that for years now :D

Re:Why isn't this already out?

[FrangoAssado]

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.

Re:Why isn't this already out?

[XMyth]

2.6 has MUCH better GUI performance. On par with what I've gotten with FreeBSD (go figure) in the past. I'd keep trying new 2.6 releases if I were you, it's worth the upgrade.

As for integrating GNOME or KDE into X, I don't even know what you mean on a technical level. Perhaps you could give me an example?

You don't think that explorer on Windows compiles seperately from the MFC? It simply links to it as a library (statically or dynamically, I'm not sure, doesn't really matter). This is no different in the Unix world.

I can see how it appears to be different because you have more options here where things change radically. But really, it's not all that different.

The biggest difference is how windows are drawn and messages are passed. With these latest developments, both Windows and X are moving towards the same thing (and I think OS X has been doing this) as far as drawing windows goes.

Re:Why isn't this already out?

[bushidocoder]

I realize that, but there are places where memory is allocated inproc as nonshared - see this from GnomeLive about the total cost of buffers for X.

Re:Why isn't this already out?

[Zphbeeblbrox]

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.

Re:Why isn't this already out?

[MBGMorden]

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.

Killing Explorer in Windows doesn't kill all your apps. The only thing it might kill are explorer windows you had open, and sometimes you won't see all the same tasktray icons (though the corresponding program will still be running). Other than that everything stays up. Heck you can even continue to use most programs without even starting Explorer so long as you don't minimize them.

Re:Why isn't this already out?

[Ambassador Kosh]

Memory usage reported by X is not even close to accurate. The X process also memory maps your video card in most cases and even the reports the agp buffer size sometimes. So if you have a large memory card you can sometimes see X reporting that is using many hundreds of megs of ram. I have 3 vid cards in this box and X will sometimes report up to 400M of ram used. However I have 1G of ram and the system will show almost all of it free despite what X is showing.

The problem is that accurately showing up how much real memory is used is a VERY difficult process. Linux shows it one way, Windows shows it another way and neither are close to what people probably think of as right.

Re:Why isn't this already out?

[LionKimbro]

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.

Re:Why isn't this already out?

[Ian Bicking]

There has to be some way for an application to talk to X. So, you remove the network protocol, how do you want to talk it to X then, magic? In order for two different programs to talk to each other there has to be some kind of protocol, no way around it.

Sure there's a way around it: an API. X has an API (xlib, the C library). But it also has a protocol, the means by which xlib communicates with the X server. In theory the protocol could be removed now without effecting most client programs, though I assume that would effect the implementation dramatically.

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.

Re:Why isn't this already out?

[Jherek Carnelian]

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.

That is an argument for putting the GUI in the kernel, not for getting rid of network transparency,

If we count entire paths, it would be: you-kernel-x-kernel-you, vs. you-kernel-you.

No, a "context switch" is from one process to another, a process into the kernel is not a context switch, at least not in the same way.

For example:

1) FP - process 2 process requires save & restore of floating point registers, but process to kernel does not because the kernel does not do FP

2) General registers - process 2 process requires save & restore of all general registers because each process has its own state, when you make a system call, you bring all of your general registers in with you since the "state" of the system is your currently running process. Somem will be saved off in case the kernel clobbers them, to be restored on the way back out to the user process but worst case, that's only one save & restore and if you go back to a different process (which is usually the case, even in your example) then the number of saves & restores is the same either way.

3) There's more, but I'm too sleepy to type any of the rest.

Re:Why isn't this already out?

[x2A]

Or even use the task manager to work with minimised windows!

-2A

Re:Why isn't this already out?

[Brandybuck]

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.

Re:Why isn't this already out?

[vadim_t]

Um, and how exactly would you communicate? So, you remove the protocol. And then?

An API is an interface that can be provided by instance for a library. Or it can be provided by an application and used by a library (plugins). But your application isn't *linked* to the X server, so it can't just call functions in it!

The only way to make what you say possible would require each application to be in the same address space as the X server, or for the X server to be in the kernel. Both approaches are quite horrible, IMO.

If the application is a module in the X server then a failure in the application can bring the whole server down. And there's no possible to have applications running with different permissions. Just wonderful, we can go back to MS-DOS levels of security and stability!

X in the kernel is a more viable approach, but forget about it. The kernel developers don't want it there for a good reason, and this isn't exactly removing the network protocol anyway - it's an entirely different system that wouldn't even look remotely like X.

I get the idea that you don't know much about software design. I'll say it again: You can't get rid of network transparency that easily! It has to be there because there has to be some way to talk to the server. I'll try to explain this way. Here are the most common forms of Unix IPC:

Network sockets
Unix sockets
Pipes
Shared memory
Message queues

Guess what? Except shared memory all of those are pretty much the same as network sockets. RPC (remote procedure call), which is probably what you mean by "API" works through network sockets. And shared memory is inconvenient to use for some things.

So, again: Unless the X server moves into the kernel, or the application moves into the X server there's simply nothing better than networking to make the application and server talk.

Re:Why isn't this already out?

[FooBarWidget]

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.

Re:Why isn't this already out?

[vadim_t]

There is a standard API, the X library. It's not like its interface changes every week or something. I don't know of any applications that talk the X network protocol directly.

So, we have that already. You can change the network protocol, and it IS being changed and extended (Xrandr, Render, Shape, etc). But still, you won't get rid of it.

Please take an Unix book and open it. The classic Unix server either forks or multiplexes to handle multiple clients. If it forks, how does the parent server talk to the children? Usually using shared memory, unix sockets, or pipes. How do the children talk to the clients? Shared memory, network sockets, unix sockets, or pipes.

How does the X server talk to clients? Network sockets, unix sockets or shared memory. There you have it. It works *exactly* the same way virtually every other Unix server works. Nothing at all oddball about it.

Re:Why isn't this already out?

[darkwhite]

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

Re:Why isn't this already out?

[Ian Bicking]

If there's no X process, then what handles windows? GGI, at least from what I can see on its website is simply an API that provides access to low level functions, pretty much like SDL.

GGI isn't a replacement for X, but is an example of that architecture applied to a subset of what X does. GGI has multiple backends. The GGI API is translated to the backend differently depending on the nature of the backend. For instance, some hardware implements some high-level rendering in the hardware. For other hardware some of that rendering may have to be done in software. A network backend, for instance, would turn those API calls into some form of communication and send it over the net.

Under GGI that would be, at best, a VNC style of network transparency, and you'd get a rectangle on the other end of the connection. But GGI isn't a replacement for X; if you were to implement X this way then you'd have multiple xlib implementations which forms a higher level API than GGI, with concepts of windows and whatnot.

If you want a thin layer that lets you draw stuff on the screen you can have it already: The framebuffer.

Funny you should mention it. The problem with the framebuffer is that the API is bound to the implementation. It's a framebuffer; but that implementation doesn't fully describe the hardware available. GGI has a higher level API, and so the GGI API can be translated into commands to the graphics card that take better advantage of the card's ability. Again, this isn't an X replacement, but an example of an architectural style (which I'm asserting is superior to X's client/server style).

Though you were right when you said that X is moving in the direction of an API. Something like the Render extension is the style I'm talking about (at least from my understanding of how such extensions work). It's primarily an API, not a protocol. It can be implemented in terms of the stable X protocol, but to be efficient that is usually shortcutted, using some protocol I know nothing about and probably isn't standard. (Yes, it does it with shared memory or somesuch -- but shared memory isn't a "protocol"; you need to define what you put in that shared memory, not just where it is, and AFAIK these extensions to not try to define that what in any formal way.)

Re:Why isn't this already out?

[cahiha]

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.

How the hell do you think this works on, say, Macintosh or Windows? Magic elves make the bits appear on your screen? X11 gives you the same choice as any other system: you can either let the server do a copy-conversion, or you can use direct rendering. Most sane people will choose letting the server do the copy for most applications.

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.

Huh? You have detailed control over what regions you get what events for. But what's the point anyway these days? Mouse events are not a performance bottleneck on X11.

Network transparency is a good thing. X's implementation of it stinks.

First of all, X11 isn't an "implementation", it's a protocol

Secondly, implementations of X11, like XFree86, do pretty much the same thing Macintosh or Windows do: they have a graphics server process that's separate from the application, and they use IPC to talk to it.

The only thing that "stinks" is that people like you who evidently have no idea what's going on opine about X11's design.

Re:Why isn't this already out?

[vadim_t]

Aha, I think I'm starting to understand the way you think at last. But I still don't see the point.

So fine, GGI has the API concept you like so much, and provides an uniform interface to anything. It's modular, cool and shiny. Now, how do you suggest to make a GUI environment following the same system?

The thing you seem to be missing is that X, or its replacement can't be done this way. So okay, we'll try to do it the Windows way. We'll come up with a nice API so that we call CreateWindow, and a window is made. Now, how does that actually happen?

Well, something needs to make that window. It can't be the application. In the case of GGI/SDL it's simply a problem of translating that high level command into pixels on the screen. But that won't work, you need to be able to run several applications on the same desktop. Just letting several processes call functions and draw stuff where they please is only going to create a huge mess or something useful.

So, how do we solve this? We need an arbitrator, which will assign and manage resources. It will ensure whatever is drawn is drawn in the right order. It will keep track of who owns what, and what is where. It will send messages when something of interested happens, like a paint event.

How, this can't go inside this magical library. How would you decide who is in control? That won't work. The arbitrator must be its own entity and dictate the rules to all who use the services it provides. One example of a system like this is the kernel. A program can't just take a 64K chunk of memory starting at 0x80abcdef, hell, no. The program instead calls the kernel and asks: "I want 64K of memory", and the kernel makes sure there's enough of it, that there's some location big enough, and that the program is allowed to have that much. Then, it adds it at the end of the current process, marks it as used, etc.

Same here. Now, who would arbitrate this stuff? Well, one possibility is the kernel. However, as I mentioned already, this won't happen. The kernel developers don't want it and with good reason. They say that if it can go in user space then it will have to go in user space. And since you can perfectly do all this stuff in user space that's where it will be.

Now that we decided it will be in user space, we know it will run as a process. This process manages resources used by other programs, which also are processes. All of this means both the manager and the users need to talk. And how do we do that?

Well, we can pick: Network sockets, unix sockets, shared memory, pipes, queues. I'll leave out queues because I'm not that familiar with them. Pipes are unidirectional. You can get the same effect, just better with unix sockets. Shared memory is great for sharing data but not for implementing protocols. In a complex event based system you need to be able to poke things and to be poked, and networking does this a lot better.

So, we arrive at using networking yet again! Amazing, isn't it?

Three ENGLISH articles instead of Babelfish

[Flywheels of Fire]

I got tired of reading the article on Babelfish. A bit of googling found me these three relevant articles:

1. Seth Nickell has posted a few videos showing the Luminocity window manager doing some super Open GL hardware acceleration tricks.

2. Interview: Rasterman Speaks of Enlightenment .17

3. XGL file format specs

bablefish

[jbeaupre]

I enjoyed reading the machine translation from german. Makes you think about about how language works and it's down right funny. My favorite line (from a comment): "With open SOURCE is too much abgekupfert." Don't know what it means, but I find my self agreeing...

Re:bablefish

[toxis]

abgekupfert is the perfect form of the verb abkupfern (Kupfer = copper) which comes from the old profession of engraving famous paintings in copper and other metals.

Though it takes a lot of talent those engravers (Kupferstecher) were not creative by themselves and if today a German says something is abgekupfert he/she means it is still just a copy and ignores the hard work behind it.

Y Windows

[BlacBaron]

I recall seeing this a while ago Y Windows

Re:Y Windows

[WillerZ]

Don't go there expecting anything you'll be able to use in the near future. I fully expect HURD 1.0 to be released before we're done.

Please don't join the mailing list and ask "is anyone still working on this?" or "when will feature x be included?", because I'm tired of telling people to fuck off. We're working on it, we'll work on the features _we_ want in the order we feel like doing them. If you want something done you can do it yourself or pay someone else to do it for you.

Apologies for the rant: the usual followup to that link being posted on /. is a stream of fools bitching at Mark/Andrew/me for not working hard enough on Y. I work on it in _my_ time, and people telling me what I ought to be doing usually causes me to go do something else entirely.

Phil

( phil -at- y -hyphen- windows -dot- org )

Re:Y Windows

[AKAImBatman]

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.

Re:Y Windows

[youknowmewell]

Phil, get back to work and make me some cool graphics pronto!

Re:Y Windows

[WillerZ]

I considered using this: http://en.wikipedia.org/wiki/Mark_V_Shaney and cron to do something fun with the mailing list archives, but I figured people might notice. Perhaps they wouldn't...

Phil

Re:Y Windows

[WillerZ]

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

Re:copied?

[Doctor Crumb]

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!

Why is this in the Linux section?

[Rick the Red]

X11 is not just for Linux, you know!

Re:Why is this in the Linux section?

[jellomizer]

But we dont talk about them

How about doing something actually useful ?

[Anonymous Coward]

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.

Re:copied?

[cabraverde]

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

screenshot mirror

[Anonymous Coward]

enlightenment
luminocity
xgl

UI stuff is tough to do open source.

[Viltvodlian Deoderan]

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 .

Re:UI stuff is tough to do open source.

[mattyrobinson69]

its because xfree86 was so stagnant for so long, now xorg is the popular x11 we are seeing fast development again. hopefully this will continue and we will get a great x11 again.

Re:Meanwhile Today On Earth...

[tveidt]

> come by any Apple Store and pick up a mini

This is illegal where I live. Here, we have to give money to a store in order to get something from them. Sigh.

X free of CPU and RAM usage

[Anonymous Coward]

Many complain that CPU speed does not increase much from the user perspective but what if the new X11 tech brings us GPU based jpeg decompression?

Surf your photos and they go straight to the GPU instead of storing a CPU decompressed bitmap in RAM, the speedup would be incredible. Low CPU usage in laptops as GPU does the work.

Remote X11 display without recompression of the network stream? It would become as fast as surfing. Requested jpegs being send straight to the receivers GPU, simply upgrade the GPU in school computers to get very fast thin client Linux boxes.

Look at Apple's Core Image in Tiger: possibilities will be amazing.

Re:X free of CPU and RAM usage

[Nagus]

Dude, jpeg decompression is so efficient that it's basically free. I mean, loading the actual data from disk (or network) takes a hell of a lot more time than decompressing it.

Much more interesting is the ability to render SVG images with hardware acceleration. The xsvg renderer will give us that ability (when used with glitz as cairo backend).

Resolution-independent graphics, rendered at high speed. That is what will make for really amazing possibilities.

Re:X free of CPU and RAM usage

[Spy Hunter]

Um, JPEG is already very fast. Even if you could accelerate it on the GPU, there's really no reason to. The speedup would not be "incredible", more like "unnoticable". The RAM usage would not go down, you would just use video RAM instead of system RAM, which is *not* a good trade (video RAM is much more precious).

The bottleneck in remote X11 display is *not* decompressing and recompressing JPEGs, it is the network. Modern remote-display systems (NX, VNC) already use JPEG compression. And they already work very fast over a LAN; in many cases fast enough that you don't even notice them. You don't have to imagine "very fast thin client Linux boxes", just go set some up!

bootstrapping problems

[CowbertPrime]

We were discussing the X11 OpenGL server at the LWE X BoF session. IIRC, the current problem with full native implementation of the OGL server is that starting the ogl server requires the dri layer, which requires an X server to be running.

HCI

[paithuk]

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.

Well sure, but...

[FreeLinux]

surely you can see the immediate need and usefulness of transparent windows and wobbly windows. Not to mention that the present versions of X11 are only using from 50 to 100 megabytes of memory when modern systems have 512 to 1 gig available. I think once we get the bugs worked out of these new features, then we can look into more advanced stuff like "hot-plug monitors" and dynamic resolutions.

Movie representations of computer UI

[Winterblink]

I remember watching movies like Hackers, which is a fairly decent movie overall, and totally laughing at their representation of the user interfaces on the computers. From the seriously hacked up and personalized desktops on everyone's PCs to the "flying through the mainframe" hacking at the end of the film, I was convinced it was there as a joke.

But it seems nowadays desktop environments are getting to be SO customizable and graphically "enhanced", I start to wonder whether those old movies weren't jokes but rather premonitory.

Why not X12 instead

[Anonymous Coward]

How long will they continue on this "11" series. Isn't it about time to upgrade to X12

Re:Why not X12 instead

[node 3]

How long will they continue on this "11" series. Isn't it about time to upgrade to X12

It only goes to 11.

agree with the article...

[uodeltasig]

I would have to agree with the article on the following point:

The problem here is to implement in all drivers sufficient 2D-XRender-Hardwarebeschleunigung - those actually simply only one special case of the existing 3D-Beschleunigung represents.

I've had a hard enough time trying to figure out how to say "Hardwarebeschleunigung" let along trying to implement all the drivers for it.Despite this it is good to know however that...

Without the parallel running videoaufzeichnung the animations ran absolutely liquid.

Karama Reedemer: Below is the babelfish translation to the mirror. Mirror dot translation

Re:copied? (-1, Irrelevant)

[orasio]

Some are.
Some aren't.
Some were even available in demos ten years ago.
Some are obvious, and the fact that OSX implements them, means nothing.
For example, that "expose" feature that is so praised, is an obvious improvement on the window idea, and there were already papers written, and many people already implemented it in some way (heck! I even keep all my windows shaded, so when I shade the one I'm using, I can see all of them at the same time!). I didn't think OS X was copying me, or "stealing my IP", put in a more fashionable way.

also beware

[DrWhizBang]

That is not the XGL that you are looking for. This is.

Not very good googling.

What I want

[RealProgrammer]

I want an interface that lets me think in 3D.

• I want to be able to grab an edge of a window and push that edge out of the way, with the window aspect changing according to how far I push it. Grab the left border and move it right, and the contents of the window compresses (e.g., making the text look skinny).
• I want to be have a large virtual desktop which I can zoom out away from to show groups of screen objects (windows, icons, local backdrops, etc.), and zoom in on to show the objects close up. The objects should not all be in the same plane, so when I zoom in on one set of object I can still see ("far off") other tiny sets of objects. One effect of that would be to allow hiearchical groups of objects.
• I want to take a group of objects and wrap them in a box, which I can label arbitrarily. The box should have variable opacity, perhaps password security, and should respond to signals (it should be a process).
• I don't want to have to use a pointing device. If necessary, I'd rather use a subvocal microphone/sensor, keyboard mouse driver, eyeglasses, or a chin strap than a mouse, touch pad, trackball, or nipple.
• I want a video driver / X server that outputs stereovision to two displays (or two halves of a single display).

And I want it to be Free.

To answer the obvious retort: every time I get started learning X programming, my feeble little brain starts to hurt. Kudos to you wizards out there who grok X.

Re:What I want

[duerra]

http://www.hamar.sk/sphere/

Re:What I want

[glwtta]

Like all of these 3D desktop ideas, this doesn't sound all that compelling.

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.

Babelfish translation?

[c0ldfusi0n]

You mean that babelfish translates?!

Man, all this time i was thinking it was only generating random words in given language. All of it were lies. LIES!

It's a Translation!

[duerra]

Now Slashdotters have an excuse for not reading the articles!

Cairo is not a GTK fork!

[nickname_unique]

Please don't post here such nonsense! Read at least the first sentence on http://cairographics.org/introduction: Cairo is a vector graphics library designed to provide high-quality display and print output.

That's what it is. A 2D vector graphic library with multiple backends, which means you can draw something and choose if you use as drawing backend X11, a PNG file, a PDF file, glitz (OpenGL) or something else.

Gtk3(?) will _use_ Cairo and it's X11 or glitz backend to draw it's widgets!

Re:luminocity = longhorn in linux?

[DrWhizBang]

Oh brother.

There is a language being developed codenamed cairo..

No. Cairo is a 2D vector graphics library, not a language. ...to be used in Linux...

or Windows. or Mac. It is a cross platform library.

its a GTK fork...

No. It is not. The CVS head version of GTK uses cairo for drawing. ...and its special feature is ability to use opengl rendered screens in place of bitmaps for window drawing...

Among its features are multiple drawing back-ends. One is OpenGL, another is Render. Because it is a vector library, it may or may not render to bitmaps - depending on the backend.

A product is already being developed using this called luminocity.

Luminocity is a fork of the metacity window manager that has a built in composite manager that renders to OpenGL.

Now that that's been cleared up...

Un-fun code

[truthsearch]

I couldn't disagree more (you knew somebody had to, right? ;) Plenty of high quality un-fun code is written in the open source community. Think every line of the Linux kernel or GCC was fun to write? It's not as much the fun as how badly someone wants it. People have been toying around with this sort of thing for a long time. But there doesn't seem to be enough real community demand to get a big enough team to hammer it out.

I know nothing of graphics programming. But if I was very interested in having accelerated window animations I'd learn OpenGL and help out. There will always be someone who wants that itch scratched.

AGP on your 486?

[green pizza]

Unless you're still using a 486, you shouldn't have to worry about JPEG decompression using up your CPU cycles. It doesn't require that much power.

That said, I do wish libjpeg was faster and actually made significant use of SSE. Intel's optimized jpeg routines are way WAY faster.

Re:wait..

[coolGuyZak]

X11 is the standard that X clients and servers use to communicate. What you are thinking of is XFree86, which for all intents and purposes is dead/dying/bad.

Flawed argument

[AvantLegion]

The problem with your argument: a desktop that is "really neat" in 1995 is not "really neat" years later.

1995: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!
1998: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!
2000: We'll have really neat X11 desktops Real Soon Now(TM)! See, here's a demo!

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.

E17 eh?

[BuBu_]

I always planned to be playing Duke Nukem on my E17 desktop running on GNU/Hurd.

Re:wait..

[SirTalon42]

Xorg and Xfree are an implementation of the X11 standard. (your thinking of XFree86, which stagnated for years and is now dead, confirmed by netcraft)

did someone say Berlin Project?

[displague]

Or was that Fresco?

Either way, the website hasn't been touched in two years...

Okay, so how do I get some eye-candy

[moonbender]

I'm probably going to wipe off XP from my laptop RSN. I've already got Ubuntu on it, but I'll probably re-install from scratch anyway. Not sure which distro yet, pending any other convincing arguments I might just end up re-installing Ubuntu. But that's beside the point.

All those demos are nice and all, but are there any usable ways of getting cool eye-candy in a working, moderately stable Linux install today? Without all the hassle of checking out code from a VCS? Is Enlightenment a sensible choice for an install that should primarily just work? For instance, I'm going to install OpenOffice and to stuff for the university on it - is working with OOO better supported in Gnome or KDE than in E, or is there no difference? I like some eye-candy (if it doesn't get in the way, XP-style), but it's no use if the prerequisite is a system too geeky or unstable to do any work on.

Re:Okay, so how do I get some eye-candy

[veg_all]

Well, since you're distro-shopping anyway, try here.

Actually, just insert your package manager controls in place of "emerge," and it should be applicable in ubuntu or whatever.

Re:wait..

[Nasarius]

XFree86, which stagnated for years and is now dead, confirmed by netcraft

Yeah, but I don't think they know it. The funny thing is, they released 4.5.0 (4.4.0 was the one that marked the controversial license change) just a month ago, and I never even heard about it. All the Linuxes and FreeBSD (not sure about NetBSD and OpenBSD) have ditched it in favor of X.org; I don't see why they bother.

Isn't it too complicates

[wereHamster]

Is it just me or do you also have the impression that the whole X11 server architecture is way too complicated.

Xorg (the xserver), dri, drm, kernel modules, Xgl, mesa.

What amazes me, Xgl rund on top of the xserver (Xorg), because theres something with dri that Xgl can't do directly.

I've created a simple (and by simple I really mean simple) 'xserver': the basic idea was to take an existing API and build the 'xserver' on top of it, the API is OpenGL. Windows are special objects in memory that can be shared between the client and the server. The client creates an window and tells the server 'hey, there's a user and he/she wants to see this window, please put the window with ID xyz onto the first monitor so he/she can see it'. and the server loads the object and puts it into the frontbuffer. and the client can draw (write) to the window and the server reads from it. and both the server and client use the same API (OpenGL) to draw things, the server into the frontbuffer, the client into the window object. Of course there's a tiny API for handling these objects, but that's only very few functions, maybe 15, that's enough.
And it works. Now if someone writes a driver that makes use of the GPU/video ram, this could be really fast. Currently it supports the mesa software opengl library for rendering.

Re:copied?

[Imazalil]

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.

Useless Vs Useful fx (and other improvements)

[master_p]

Am I the only one that turns off GUI effects like windows zooming in and out, menus folding and unfolding etc after about 5 minutes of use? From the screenshots in the presented link, we can see zooming windows effects and transparent windows. Where is the usefulness in that? it's still down to working with xterm and the apps like the Gimp (with all the (possible ?) usability problems that it has).

The useful effects are:

a) window shadows; it really enchances the depth perception;
b) zooming from and to icons; it really gives a sense of connection to the source for each window;
c) transparent notifications (for example when new e-mails arrive)

I don't think X-Windows need more effects than the above.

But what the X desktop really needs is the following:

a) a way to programmatically specify new server-client protocols in order to minimize round trips. For example, an application's GUI could live entirely on the display server, and the application is simply reduced to using the available protocol to build widget trees. This can also be used for rich WAN applications, including the internet.

b) a widget toolkit endorsed by the X-Window committee (whatever that means), that comes as default with X, is simple and easy to use, using one of the new protocols specified above.

c) the ability to do macro-commands, either by recording them using mouse and keyboard or by entering them via an X11 script language.

The above will make a killer combination...if coupled with an information-management application like TreePad as the desktop shell, then X11 will be a true winning desktop environment.

Re:copied?

[bani]

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.