Preview of X Windows Eye Candy
glenkim writes "Remember Seth Nickell's blog entry about next generation X Window rendering? Well, in case you were wondering what it would look like, he's updated his blog with videos of luminocity, the experimental GNOME window manager, and screenshots of programatically themed widgets." From the post: "The wobbly window effect is mildly addictive. Kristian hasn't gotten much work done since he wrote it. He (and now I) spends all day moving windows around and watching them settle."
On the other hand, the similar effect applied to drop down menus did make some sense. It made the menu appearing more obvious and anyone glancing at an unrelated part of the screen and accidentally activating the menu would be more aware of their mistake with this kind of heavily animated approach. It also looked like it wouldn't get in the way, the way it was implemented.
I also liked the translucent file selector. That's the first time I've seen translucency done in a relevant, useful, manner. Yes, I do want to see the window underneath, damn it! Combined with Apple's "attaching selectors to the window they came from" philosophy, you could have quite a massive improvement in usability.
It's nice to see some of the techniques developed largely as eye-candy actually find uses where they have functional, not just subjectively aesthetic, justification.
You are not alone. This is not normal. None of this is normal.
For those of us who don't know, is there a KDE equivalent in the pipeline?
Apple, perhaps, but not Microsoft. Longhorn will have something like this, but Longhorn is still over a year away (at least). It might very well be that this technology will become available on Linux long before Longhorn ships. In that case, Microsoft would be catching up to Linux
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
How does this compare to the upcoming Avalon engine for Longhorn?
Those are some interesting new features, quite innovative actually. However, I would be much more interested in hearing how X is being made smaller and faster. Xserver seems to be a nice continuation of Kdrive since the fork, but it is still lagging behind a full Xorg installation. Most X users are not serving up desktops to thin clients, and only need a full install for things like hardware acceleration and multihead support. I would think a small and fast X would greatly benefit desktop adoption, and if any of you have tried Kdrive on modern equipment, it more than feels snappier, it is.
Never start vast projects with half-vast ideas.
Luminosity is a testbed for technology. It's not meant to show exactly what Gnome 2.12 or X whatever is going to look like.
You say its not useful but what about something like Expose which many users think is useful? Imagine how boring the early versions of it looked which did nothing interesting or useful? Think outside the box for a minute and realize that by using the technology someone may come up with some new ways of interacting with windows that nobody has ever thought of and turns out to be really useful. Your boring and bloated accusation is way close-minded and short-sighted.
If you wanna get rich, you know that payback is a bitch
Combine it with the new Enlightenment stuff:
This one
This one
This one
This one
So who said that Linux was mainly textbased?
Don't fight for your country, if your country does not fight for you.
How about instead of just being able to store windows as bars, let us morph our windows into a sphere which rotates? or a cube? This would allow us to store more windows in less space, it would allow us to have more screen space. No one needs a big bar taking up the bottom of their screen, but spheres floating around looks better and its better for productivity. Think of terminator 2's morphing scene, that could be done to the windows.
I know it's fashionable to bash UI eye candy, but there is a reason for it. For instance, the human eye is very good at determining depth. Drop shadows on windows help distinguish one window from another. When I turned on xcompmgr on my Ubuntu box, it was actually quite surprising how much easier it was to determine what windows are where. When you have Anjuta, Firefox, Glade, and a bunch of other applications open, it can be hard to tell what window is here. Drop shadows help create another way of visually distinguishing window placements that can enhance usability.
Transparency when done right can also help usability. The transparent dialogs here help cement the relationship between a dialog and its parent window. That's why Mac OS X has such great usability - it not only has some visually interesting eye candy, but that eye candy is designed to provide you with a series of visual cues that clue you in on what actions you're performing. The "genie effect" when you minimize a window to the Dock is another example of this - by showing the window move into the Dock you're providing a visual clue that lets you know that you can find that window again in the Dock.
When done right, eye candy can really enhance usability, and thanks to things like the Damage extension, the Render extension, and the Composite extenstion, Linux usability is getting better.
And for the record, those who think that eye candy adds excessive processor bloat, my current Linux system is a Duron 600mHz with 256MB of RAM and a GeForce4 MX. Granted, the T&L engine helps a lot in making the UI responsive, but given that xcompmgr and the Composite extension is essentially beta code it's quite shocking how little processing power this sort of thing takes. Now that T&L engines on graphics cards are pretty much standard, it's time that X put that power to use to enhance usability.
It used to be that when I did a "ps aux" I knew what every process did. When I do this today with the newest KDE or Gnome I have no idea what most of the processes are for.
Try "ps faux". It shows how processes are related. I've been using KDE for years, and I haven't noticed any extra difficulty understanding what all the processes are for. You do need a wider Konsole window now than in KDE1, however, because all the KDE processes are prefixed with "kdeinit:".
But I do agree that it is slower, but I think that's just because it's doing a lot more (and I'm doing a lot more). I didn't normally have 15 browser windows/tabs open at one time 5 years ago; now it's common.