Living Down to a Low Standard (ComputerWorld) [LWN.net]

Living Down to a Low Standard (ComputerWorld)

Posted May 11, 2004 3:11 UTC (Tue) by elanthis (subscriber, #6227) [Link]

Do note that Fedora only very recently got the completed Nautilus with completed spatial mode. If you are basing your opinion on code that was in there months ago, you are basing your opinion on half-finished work.

I've found spatial nautilus to be a complete pleasure. Faster, simpler, cleaner, and easier. And that's coming from someone who lives in a shell prompt most of the time and develops a lot of web (navigational) software. Advanced user if ever there was one, and yet I do indeed prefer spatial. Same as the GNOME developers that implemented spatial mode.

So far as Windows/OS X, neither are good indicators of user preference of spatial vs navigational. Most OS X users I've spoken too prefer the old spatial finder over the OS X navigational finder. And Windows was _never_ spatial at all; spatial means a hell of a lot more than just "opens folder in new window," which is the only similarity spatial nautilus has to old Windows file manager.

If you don't like spatial, use browser mode. If you don't like Nautilus, use Velocity. If you don't like GNOME, quit wasting your time bitching and just use something else. I find GNOME to be the best desktop around, and so do quite a few other users. If it's not to your taste, fine. Nobody is forcing you to use it.

Living Down to a Low Standard (ComputerWorld)

Posted May 11, 2004 15:56 UTC (Tue) by Prototerm (guest, #20227) [Link]

If you don't like GNOME, quit wasting your time bitching and just use something else.

It's so nice when two people have a polite conversation, listening to what the other has to say, without resorting to name-calling and the like. After all, to do otherwise would be so...Slashdot...wouldn't it?

And while the above quote makes a good point, let's remember that distros like Red Hat are designed to work best with Gnome, and that tools like Ximian's desktop require it. The user may feel they don't have a choice in using Gnome for their particular situation. Second, they may actually love Gnome, except for that one feature that drives them crazy.

Living Down to a Low Standard (ComputerWorld)

Posted May 11, 2004 12:56 UTC (Tue) by wookey (subscriber, #5501) [Link]

> I have been running fedora rawhide for months and I can say without any reservation that spatial is virtually unusable. I tried to like it. I *really* tried to like it. But there is just nothing about it to like.

Fair, enough, but as I've pointed out before there are people who prefer the spatial browsing. All my users here complained when given the gnome 2.4 browser because 'everything keeps appearing in the same window - I can't find anything', and were very happy when I switched it to spatial browsing. For them the 2.6 default is 'correct'.

And petreley is wrong when he says no mature OS uses it - RISC OS does - that's a 20-year old OS these days and it has always worked this way and still does. It's not very popular these days, especially outside the UK and Germany, due to not being available for x86 hardware, but it's users are very happy with the UI, and always have been.

Personally I use MC for file navigation, even on the gnome desktop.

colours

Posted May 11, 2004 6:54 UTC (Tue) by jamesh (subscriber, #1159) [Link]

I'm appalled by the way Gtk2 has ruined Gtk-based apps (and the way colors can no longer be set separately from themes), and I actually like being able to configure things.

Could you ellaborate on this? GTK 2 doesn't really impose much more policy than GTK 1.2 with respect to colours. An app can still load additional rc files, or set the colours on an individual widget (which is actually easier to do now, using gtk_widget_modify_fg and gtk_widget_modify_bg).

It is true that most GTK2 apps don't provide as many preferences to customise random colours in the UI, but this isn't due to limitations in GTK. When you change the foreground or background of a widget, you will often make the text unreadable for at least one theme. Often, it will break with one of the accessibility themes (eg. high contrast inverse). Even if you set both the background and foreground, you may end up making the text unreadable for some users, since they may have special requirements (eg. some people can't read text that has high contrast with its background).

By following using the default colours and fonts, you avoid all these problems. Not only does the app fit in better with the desktop, but it is also more likely to work out of the box for people with disabilities. You will find that the W3C makes similar recommendations to website designers.

colours

Posted May 11, 2004 17:28 UTC (Tue) by rfunk (subscriber, #4054) [Link]

Could you ellaborate on this? GTK 2 doesn't really impose much more policy than GTK 1.2 with respect to colours.

Well, I first noticed this while using KDE and running Gtk apps. KDE has color themes separate from widget themes, and can extend the color theme to non-KDE apps. With traditional Xt programs, it sets X resources to do this. With Gtk 1.x programs, it uses .gtkrc to do this. With Gtk 2.x programs, it can't, because Gtk 2.x combines the colors with the themes.

That means if I pick a theme whose widgets fit with the rest of my desktop, its colors might totally clash. If I pick a theme whose colors fit, the widgets might look totally wrong.

It is true that most GTK2 apps don't provide as many preferences to customise random colours in the UI, but this isn't due to limitations in GTK. When you change the foreground or background of a widget, you will often make the text unreadable for at least one theme.

See, this is one thing that Petreley got right. WHY NOT TRUST USERS TO SET THEIR OWN COLORS?! The user can see for herself whether it's unreadable or not!

Anyway, if you set colors completely separate from themes, then you WON'T make anything "unreadable for at least one theme", because themes aren't setting colors anymore.

Not only does the app fit in better with the desktop,

Remember, at this point we're talking about Gtk2, NOT Gnome as a whole. That means the toolkit has NO IDEA what the rest of the desktop looks like. The user could be running any window manager or desktop environment -- fvwm, icewm, windowmaker, XFCE, KDE. If I want to theme my Gtk apps so their general look fits in better with MY desktop, I also want to be able to control the colors for the same reason.

If it were Gnome libraries putting on these restrictions, I wouldn't mind, but Gnome isn't the only user of Gtk.

but it is also more likely to work out of the box for people with disabilities.

I'm not talking about out of the box. I'm talking about the user being able to change what comes out of the box for their own purposes.

You will find that the W3C makes similar recommendations to website designers.

The W3C recommends that whatever web designers do, users be able to override color and font settings. Users are supposed to have the final say.

colours

Posted May 12, 2004 1:23 UTC (Wed) by jamesh (subscriber, #1159) [Link]

Well, I first noticed this while using KDE and running Gtk apps. KDE has color themes separate from widget themes, and can extend the color theme to non-KDE apps. With traditional Xt programs, it sets X resources to do this. With Gtk 1.x programs, it uses .gtkrc to do this. With Gtk 2.x programs, it can't, because Gtk 2.x combines the colors with the themes.

Have you considered that this might be a bug in KDE's colour theme control panel? Both GTK 1.2 and 2.x mix colour settings and theme settings in the gtkrc file, so there is no reason why it couldn't work.

See, this is one thing that Petreley got right. WHY NOT TRUST USERS TO SET THEIR OWN COLORS?! The user can see for herself whether it's unreadable or not!

I think I misunderstodd your previous post. I have nothing against users customising the colours of their UI (it is one of the things that still needs to be implemented for Gnome).

Back in the 1.x days, many apps used non-theme colours for various bits of their user interface. Usually they would have a section of their preferences where the user could change these colours. However, if the user had chosen a different theme (such as one of the accessibility themes), these bits of the UI might intially be invisible. The user might not even realise that they were missing out on something until they looked at the preferences. This is bad, and should be avoided.

The right way to allow the user to customise the colours is to create a new theme. Since most Gnome apps don't override the theme colours anymore, the entire desktop would take on the new colour scheme put together by the user. This is a much better situation than the old days where they would then have to play with the colour settings in many applications after changing the theme in order to get a usable desktop.

colours

Posted May 12, 2004 17:00 UTC (Wed) by rfunk (subscriber, #4054) [Link]

Have you considered that this might be a bug in KDE's colour theme control panel?

Well, first it broke when Gtk changed, not when KDE changed, and second non-KDE users are complaining about not being able to change Gnome colors. That tells me it's not a problem with KDE.

Back in the 1.x days, many apps used non-theme colours for various bits of their user interface. Usually they would have a section of their preferences where the user could change these colours.

I think we can agree that sticking color preferences inside apps is a bad thing.

The right way to allow the user to customise the colours is to create a new theme.

That's horrible! Why should someone have to go to that much effort just because they like the look of an existing theme except for its colors?

colours

Posted May 12, 2004 17:24 UTC (Wed) by sri (guest, #2077) [Link]

>That's horrible! Why should someone have to go to that much effort just >because they like the look of an existing theme except for its colors?

A new theme is automatically created as soon as you change a parameter in the theme you're using. There is no extra work. The new theme doesn't even require a name.

sri