Toluu

Design Fu

Beating the sh*t out of bad apps

New Planet Gnome LookMay 1 2005

Its rough, its dirty, its still pretty cool. Diana and I originally put together a mockup for the RH blog aggregator, to replace the existing monstrosity:

It sounds like the RH blog aggregator will be moving to Planet soon anyway, so I thought I'd get an early start on the template/CSS munging. And since I was already doing it for Planet, I figured, why not take a whirl at the Planet I know and love?

Here's Planet Gnome with the new template/css. Obviously I'm not running the planet.py updater periodically, so its fixed where I left it last night. Lots of little cleanups left to do, like using day names instead of dates, hardcoding the little image sizes to improve render speed, making it work at narrower sizes, make titles link, etc. There's also a couple visual details off relative to the mockup (some of the spacing, the blog entry titles should be darker which looks better and is easier to read). I chose the colors 10 seconds ago, so they suck :-)

This design isn't just purty, its designed to improve reading too.

K00l Luminocity OpenGL VideosMarch 26 2005

Since he caught a glimpse of Kristian's wobbly windows, Bryan has stalked Red Hat's dark and hallowed halls, breathing fire, demanding his chance in the directorial seat. So it is that we bring you Monkey Hoot productions first, uh, production. Since a lot of people have asked, these videos show Luminocity running on two different laptops, both with fairly slow/old video cards (Intel i830 and ATI Radeon 7500 mobility) and open source drivers.

Luminocity

Theora | MPEG4

Kristian showing off his spring-modeled "wobbly windows" effect in Luminocity,Owen's crack-tastic OpenGL based window/compositing manager. This is the only effect that requires GL hardware acceleration in Luminocity (and not even much at that, Kristian's development machine uses an embedded Intel video card). Notice that menus and tooltips are also animated as they pop on and off the screen. The animation effects on window impulse

Building LuminocityMarch 26 2005

Just created a wiki page for Luminocity with improved build instructions. Should be a lot easier now, esp. thanks to all the people who have reported problems and found solutions on #fedora-desktop. Its basically "jhbuild build xserver luminocity" at this point, except that a patch has to be applied to xserver first.

How Luminocity Relates to Other StuffMarch 24 2005

Relation to Metacity

When it has proved itself, Luminocity's compositing manager will probably be moved into Metacity (along with any effects / extra features we consider good and stable). We originally considered doing the work in Metacity itself, but didn't want to destabilize it until various approaches were tested. Luminocity is, effectively, a testbed for Metacity. It provides a smaller/simpler codebase to test interesting rendering code with, and means we don't have to worry about fucking up Metacity in the process. Soeren's computer is (as of tonight, at least, that's the first I saw of it) running a version of Metacity that's apparently using the compositing manager code from Luminocity to render to a GL context.

Relation to xcompmgr

Luminocity has an internal compositing manager that performs the same function as xcompmgr. The compositing manager / window manager integration allows Luminocity to do things that an individual compositing manager or window manager couldn't. Of course, Luminocity composites using OpenGL, unlike xcompmgr. This apparently can be an upside and a downside, but I don't know anything about it so I'll shut my trap.

Relation to Xgl

This is the complicated one :-). I'm loathe to stick my toes in these waters because I'm the wrong person to do it, but I'm also afraid that we're going to end up with two rendering infrastructures down the road and no clarity for application developers as to which (if eith

Improving the User Experience for Desktop Sysadmins - SabayonFebruary 18 2005

The three immediate design stakeholders in the 'enterprise desktop' are: end users, help desk staff, and desktop system administrators. Most design work for GNOME has gone into improving the end user experience, which is really the dominant stakeholder of those three. Some improvements aimed at end-users, like promoting preferences instead of settings you can get wrong, have also made life a little easier for help desk staff (as people are that much less likely to hose things). Recently Mark's work on Vino has added a very large improvement for help desk staff: the ability to remotely view and operate user's desktops (there is nothing more frustrating than blindly stepping people through computer operations over the phone).

So what about sysadmins? Sabayon is GNOME's first major design targeted at improving the user experience for people who administer GNOME systems, and hopefully the start of an initiative toward designing for this important group of users. I'm jazzed about Sabayon as the first step toward a historic goal: GNOME as the definitive desktop management experience for sysadmins. We have a long way to go, but if there's a hundred possible improvements to make over Windows and MacOS/X toward the end-user experience, there's a thousand for admins. But big things start with small steps, right? I see promise for Sabayon as the ground floor of the revolution! <seth takes a deep breath and retu