(Public service announcement: I’ve always hated themes and still wish they’d mostly just go away so we could all just concentrate on building and using the same sexy pixel-perfect GNOME look-and-feel. GNOME branding wins, performance wins, some people complain but don’t they always, yadda yadda. Now, with that out of the way…)
I was having a look at this OpenSolaris bug report yesterday. Basic problem: icons from the OpenSolaris Nimbus theme are showing up in some places larger than they ought to. Apparent cause is that the icon theme doesn’t provide those particular icons in a small enough size, and the larger versions aren’t being scaled down as required. The vinagre toolbar is the example given in the bug report, but I’ve seen it other places too (e.g. in the Glade toolbar editor).
Having a look at the index.theme file for Nimbus, I saw that all the icon folders were marked as “Type=Fixed”, and assumed that was the problem. However, I spent a couple of hours trying every combination of “Type=Scalable”, “Type=Threshold” and Threshold=[some-big-number]”, and “MinSize=[some-small-number]” that I could think of, and nothing changed. (I regenerated the icon cache after each change, and also tried without any icon cache at all.)
Just what should an index.theme file look like to ensure that (say) the 48×48 icons will always be scaled down to (say) 24×24 when required? Nimbus also has its own engine, could a bug there cause this problem? Or a bug in the gtk+ widgets/applications where we’re seeing the issue?
EDIT: Further to Matthias’ comment, Type=Scalable is working fine now. Not sure what I was doing wron yesterday…
Calum, Type=Fixed means: ‘always use as is’. Type=Scalable should scale the icon as you wish, provided the theme has the correct Size field for the directory.
Type=Threshold means ‘only scale if the desired size is more than Threshold away from the declared size’.
GtkIconTheme has a force-size flag that when specified will override all these definitions and forcible scale the found icon to the desired size, but that has to be set by individual applications.
Hmm, sounds like I need to play with Type=Scalable a bit more then, although it didn’t appear to help yesterday. Could easily have been a PEBKAC error, though 🙂
“(Public service announcement: I’ve always hated themes and still wish they’d mostly just go away so we could all just concentrate on building and using the same sexy pixel-perfect GNOME look-and-feel. GNOME branding wins, performance wins, some people complain but don’t they always, yadda yadda. Now, with that out of the way…)”
I may just save that somewhere to put at the top of every themeing related post.
There is nothing wrong with skinning to optionally customize the look and feel (with limitations), but don’t put it in at the bottom of the stack.
Well, whaddya know, Type=Scalable working fine now. Not sure what I was doing wrong yesterday…
Just posting to register my approval of the anti-theme comment. I think the next major GTK release should drop multiple theme/theme engine support and ut all it’s resources behind a single, fast, usable, perhaps *customizable* to an extent (maybe via CSS), theme or theme set.
This means that application developers could rely on certain things looking and functioning the same way, and it makes writing custom controls a lot easier.
Am I correct to guess that by “theme” you mean themes with substantial drawing differences, not including mere color themes for normal, high, and low contrast?
(Public service announcement: I’ve always hated themes and still wish they’d mostly just go away so we could all just concentrate on building and using the same sexy pixel-perfect GNOME look-and-feel. GNOME branding wins, performance wins, some people complain but don’t they always, yadda yadda. Now, with that out of the way…)
My hero.
@Greg: Yes, pretty much. Although even differently-contrasting visuals needn’t necessarily be separate “themes” as currently implemented in GNOME.
OS X, for example, just lets you change the contrast of the whole display, and/or desaturate it (remove the colour), and/or invert it. No special themes required, and it works for every app out of the box.
(Caveat: I don’t know how well this approach actually works from a visually-impaired user’s point of view, compared to GNOME’s more hand-crafted approach.)
“I’ve always hated themes and still wish they’d mostly just go away so we could all just concentrate on building and using the same sexy pixel-perfect GNOME look-and-feel. GNOME branding wins, performance wins, some people complain but don’t they always, yadda yadda. Now, with that out of the way…”
Another public service announcement: You are wasting your time by using the wrong operating system. There already is an awesome platform doing great in limiting the user: Windows.
Or with other words: Why give up Windows or OSX if Linux becomes as boring as those commercial platforms?
Oh, this one is easy.
Why give up Windows or Mac OS X?
Because they are not free software.
Duh.
@Mathias: Lack of themes doesn’t have to mean “boring”. Most people just use the theme that their GNOME desktop comes with and never change it, without getting bored. I’m sure you own fun and exciting real world objects (I know I do) whose appearance you can’t fundamentally change, but they’re still fun and exciting. Being able to turn them green or pink whenever you felt like it wouldn’t make them any more fun or exciting.
IMHO we should focus on making our desktop exciting because of what it does, and how it makes people feel about using it, not how much they can change the way it looks. But like I said, I’d fully expect to lose some people along the way if that was a direction we decided to take. And I doubt it will ever happen anyway…
@calum: by your reasoning one kind of clothes, one kind of furniture, one kind of car, one kind of whatever would be sufficient for all people.
uhm. oh. stop. this was tested in reality already.
failed horribly.
@Mathias: You’re exactly right. And by the same argument, GNOME or any other software can’t possibly be designed to suit everyone either. That’s been tried too, and that always fails horribly as well. But themeability is one of those features that generally indicates a misguided attempt to appeal to everyone anyway, rather than focusing on the best possible user experience for a few, well-understood types of user.
By the same token, most people choose clothes, furniture and cars whose design suits their taste, functional requirements and budget. Not because they want to take them home and start changing how they look. Designers have already done that part for them, so they can just enjoy the end result.
Themes make it hard to write good software, because you always have to think about how some random theme might break your user experience horribly. Look at all the complaints about the rather simple changes to the default theme for Ubuntu Lucid; that have popped up in the past week. And they’re almost all simple configuration changes, and a new theme. If we could all agree on widget behavior, and how things look, it would make it easier for everyone, and better for the users. The differences between GNOME, KDE, XFCE, etc… would all be functional and quality, and not look. It would be easier to develop applications, without worrying about whether someone’s theme breaks your application or not. It would mean KDE apps under GNOME, or vice-versa, would look and behave just like every other application you use. There’d be no clicking on “Cancel” when you meant to click on “OK”.
But of course, for some reason, people still like to think that pretty pictures make for a significant differentiation point from competitors; it doesn’t.
Daniel Borgmann nailed it in his comment – http://blogs.gnome.org/calum/2010/03/10/bothersome-themes/comment-page-1/#comment-720
there’s nothing essentially wrong with themes.
it’s just that reliable operation of a UI relies on other features first, before skinning the UI can even be considered in the first place.