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 430773
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Improvements to Linux?
by siride on Sun 20th Jun 2010 05:17 UTC 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

RE[7]: Improvements to Linux?
by ndrw on Sun 20th Jun 2010 06:14 in reply to "RE[6]: Improvements to Linux?"
ndrw Member since:
2009-06-30

Uhh, who says the drawing has to be done in software?

That's what modern toolkits (Gtk, Qt, Cairo) do.

Do you remember what happens when a non-composited window is obscured and then exposed? The contents must be redrawn, manually, by the app.

In a legacy X application all client-side data structures are just handlers pointing to a server-side state. When the connection is lost, you loose the data.

Yes, you can reconnect to the server, open a new window, select new fonts, cursors, allocate pixmaps based only on the application state (and hope there were no big changes on the server meanwhile) but that's a lot more to do than repainting the existing window using existing resources.

Reply Parent Score: 1

RE[8]: Improvements to Linux?
by siride on Sun 20th Jun 2010 15:01 in reply to "RE[7]: Improvements to Linux?"
siride Member since:
2006-01-02

Uhh, who says the drawing has to be done in software?

That's what modern toolkits (Gtk, Qt, Cairo) do.

No, they don't. They use the server to do drawing and use either OpenGL or Xrender. Some operations are too simple to be worth accelerating anymore (like lines), so I think those really are done in software. In any case, some operations are accelerated and some are not. Which exactly, I don't know, but it's not relevant to this discussion.

Do you remember what happens when a non-composited window is obscured and then exposed? The contents must be redrawn, manually, by the app.

In a legacy X application all client-side data structures are just handlers pointing to a server-side state. When the connection is lost, you loose the data.

Yes, this is true. Whether or not those bits of data are so significant that losing them means the app effectively has to start over is another matter. I did leave the door open for apps who truly can't continue to simply reconnect and say "hey, I have to quit" and then quit. That is a much better solution than having them just crash. Perhaps even Xlib could do this if the app doesn't register itself as being able to reconnect. Xlib will reconnect and then put up a simple message box and then let the application die as usual. At least the user won't be confused.

Yes, you can reconnect to the server, open a new window, select new fonts, cursors, allocate pixmaps based only on the application state (and hope there were no big changes on the server meanwhile) but that's a lot more to do than repainting the existing window using existing resources.

My point, though, is that those things can be recreated. Certainly selecting fonts, cursors, etc. should be easily re-done by the toolkit since it has to know about all that stuff in its own internal data structures for the widget hierarchy. In that case, it really is no more complicated than walking the hierarchy to do anything else, including redraw for an exposure event. The toolkits would have to be modified, of course, but it probably wouldn't have to be much.

Reply Parent Score: 2