Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Gnome 3 Discussions



David Kramer wrote:
> Having a configuration setting in an advanced tab somewhere to turn on
> showing the names/icons/both in app links does NOT make anything harder
> for the beginners, and enables the power user.

OK. I'm not opposed to the ability to configure things. As an end-user,
it's usually to my benefit, providing the defaults are well chosen.

So for argument sake, lets assume that this, "I think that that the
GNOME developers simply don't care about users," is not true.

Then why would they take this approach?

This is a group of developers, which by definition are power users, and
presumably are living with GNOME 3. Certainly they've anticipated a
desire to retain legacy behavior. It's not like you can upgrade to GNOME
3, but keep running the GNOME 2 shell on top. So what transition plan do
they have in mind?


> If they don't have the time to write configuration programs, then
> read the config from a file we can tweak if we dare.

My understanding is that there is a ton of stuff like that in GNOME 2
that can be manipulated through gconf.


> I think about this as being similar to adding localization to a program.
> If, as you are writing the program you retrieve user-facing messages by
> resource key in a config file, the burden is actually pretty light.  If
> you go back and try to add localization to an existing app by looking
> for said messages and extracting them, well that onerous task has lead
> to the insanity of many a worthy developer.  The key is to start working
> with configurability in mind from the start, even if it's not complete,
> and it never becomes this behemoth burden.

Localization seems like a reasonable analogy and a good point. Though
from a technical implementation standpoint, it may not hold up. There
are some fundamental differences between a C application with embedded
strings, and a UI built with JS/CSS. The latter is already "skinned" and
in a better position to be localized (or otherwise customized).

A better point of comparison would be to look at Mozilla Firefox, which
uses roughly the same UI architecture. On that project there is
definitely a developer resistance to creating a lot of config options,
especially in the UI, but also in the config files. As a result, any
power user ends up using a pile of extensions.

However we also see that in the transition from FF 3.0 to 4.0, where
substantial UI changes were introduced, they retained support for the
legacy behavior via config settings.


[re: whether plugins to accomplish the GNOME 2 behaviors will exist]
> ...there are so many products out there now, the talent (and energy!)
> is spread thinner.

Yeah, but GNOME is a pretty mainstream project, with a market share of
maybe 40% or more of all desktop Linux users, and a fairly sizable
percentage of those will be power users that want to carry forward at
least some GNOME 2 behaviors. So I think the chances are fairly good
that we'll see plugins to do that.


> Tom Metro wrote:
>> Your complaint was that you couldn't distinguish multiple applications
>> with similar looking icons when they appeared on the dock bar. Is this a
>> situation you see happening when you go to launch the application, or do
>> you anticipate having all 3 running simultaneously?
> 
> How does either option make the problem more or less severe.  If I
> launch one of three (or five) programs that have very similar icons,
> whether the applications do the same thing or not, I still kinda need to
> know which is which ;)

So you're saying that if you have Rhythmbox running somewhere on your
desktop, and your thought is you need to try gtkpod instead, you'll be
confused when you look at the dock bar and see a speaker with headphones
icon present and not know which app is already running?

I suppose. Is this a situation you'd run into a lot?

I'm not saying your point about configurability is wrong, but this
particular issue may not be the ideal way to illustrate your point.

I can say from personal experience with a no-label dock bar that it
hasn't impeded my power user tendencies. But maybe I've just been lucky
that the similarly themed applications I use have distinct enough icons.
(Though I'd welcome larger icons with more unique detail, which GNOME 3
apparently provides.)


> Look at the current icon for "CD/DVD Creator" (if you search REAL HARD
> you can find out that that's Brasero, but you wouldn't know it without a
> lot of work).

You know those icons can be changed.


> You see my point?

Yes, I agree that some apps have confusingly similar icons, or poorly
chosen icons.


> ...it's provably not possible to represent the hundreds of programs
> available in the repository with icons that are meaningful to the
> purpose of the program and instantly distinguishable from all other
> such icons.

But that's not the objective. The icons only need to be distinguishable
among the currently running applications, or the small subset of
frequently used applications that you pin to the dock.

If you're talking about distinguishing applications across an entire
repository, then even having the name with the icon might not be enough.
My "Multimedia" applications menu is pretty full, and on occasions I've
had difficulty locating the correct transcoding tool I want, even with
the names. GNOME 3 won't make this any worse, as it already displays
names in the application list, and might improve the situation with
larger icons and search.

(GNOME 3 also appeared to support grouping applications into categories,
the same as the GNOME 2 Applications sub menus. They also said GNOME 3
uses the standard .desktop files, so it should be possible to use
editing editing tools to change the categorization of applications as
you like.)


>> If you use the Applications menu, then there doesn't seem to be much
>> difference between 2 and 3. The application listing they showed in the
>> demo showed both icons and program names. The biggest down side I heard
>> was that they didn't yet provide a tool for manually reorganizing the list.
> 
> Given that an Ubuntu install, unlike most, does not involve package
> selection, that could be a rather large problem.

I don't follow. Because you can't remove the applications you don't use?


> The new design seals its fate as never being solved though, because you
> no longer even have a fixed number of virtual desktops.  They're created
> as needed.
> 
> Both at work (yes, I use virtual desktops under Windows too) and at
> home, I use four virtual desktops each for a different purpose
> (mail/web, devel, admin, etc) and have different apps always on the same
> desktop.  In the New World Order, it could take quite a lot of work to
> recreate that after startup.

That's speculation. Having a variable number of workspaces doesn't
necessarily make the problem any worse. And sort of pointless, given
there are no good ways of making workspaces persistent in any GNOME
version. (I do a bit of this with some scripting and 'devilspie'.)

I can see advantages to adding workspaces on an as needed basis. More
importantly, I think it'll increase use of workspaces by non-power
users, which may lead to more tools and features (like persistence).

At least I'll welcome the improvement of a better designed workspace
switcher. The ones available for GNOME 2 barely do the job. Unless all
workspaces are empty, it is rather difficult to distinguish the
separator between them.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org