Linked by David Adams on Fri 18th Jun 2010 19:17 UTC
Linux Linux Magazine has a profile of Daniel Fore and the Elementary project. Elementary is a Linux distro that's committed to a clean and simple user experience, but it's more than a distro - it's actually a multi-pronged effort to make improvements to the user experience for a whole ecosystem of components, including icons, a GTK theme, Midori improvements, Nautilus, and even Firefox. The work that elementary is doing isn't limited to their own distro, and some of their work is available in current, and perhaps future, Ubuntu releases. The results are really striking, and I think it's probably the handsomest Linux UI I've ever seen.
Thread beginning with comment 430734
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Improvements to Linux?
by siride on Sat 19th Jun 2010 21:51 UTC in reply to "RE[3]: Improvements to Linux?"
siride
Member since:
2006-01-02

They only suffer a performance hit when they have to reconnect, which is fine because the goal there is simply to get back to where you were, not to do it seamlessly fast. The fact of the matter is, clients *do* know pretty much everything they need to know to restore their state. The toolkits have an entire client-side hierarchy of objects that represents useful state. Regenerating the few bits needed on the server should be trivial. And if the app really can't handle the server crashing, then it can just exit gracefully (that is, stay alive long enough to reconnect, then give the user a useful error message, save state somewhere and exit).

Reply Parent Score: 2

RE[5]: Improvements to Linux?
by ndrw on Sun 20th Jun 2010 05:13 in reply to "RE[4]: Improvements to Linux?"
ndrw Member since:
2009-06-30

Yes, there are methods for recreating the state but they are not necessarily that simple. Clients can, for example, reconnect to the server and replay actions that lead to the lost state. This might be hard to do if there is a lot of server-side state (like in legacy X applications) or if the session was migrated to a different resolution/color depth/dpi/... screen.

So, we need to keep the information on the client side as well. And that's what, as you pointed it out, modern toolkits do. The price to pay for it is that all the drawing operations are now being done in software (in the client) and Xserver and graphics card acceleration are only used for blitting the resulting images onto pixmaps and applying some 2D/3D transformations. Yes, it works well (at least locally) but it is not the model X was designed for. In fact it works by deliberately avoiding legacy Xserver features.

The limitations are that this solution works slowly over network (or doesn't work at all if the client/toolkit uses XShm only) and is limited to applications written with new toolkits leaving e.g. $$$ Motif apps behind. That's what I meant by "performance hit" and "changing the clients".

Reply Parent Score: 1

RE[6]: Improvements to Linux?
by siride on Sun 20th Jun 2010 05:17 in reply to "RE[5]: Improvements to Linux?"
siride Member since:
2006-01-02

Uhh, who says the drawing has to be done in software? Do you remember what happens when a non-composited window is obscured and then exposed? The contents must be redrawn, manually, by the app. So what's the difference between that and having to redraw because the X server crashed? Very little, aside from a some pixmaps stored on the server and a few other bits. If the toolkits tighten up their policy about pixmaps on the server so that the pixmaps can be recreated if they get lost (which I imagine they probably already can be anyway), then your problem is moot.

Reply Parent Score: 2