Gnome 3 Discussions

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

On 04/25/2011 04:03 PM, Tom Metro wrote:
> David Kramer wrote:
>> I also took great offense at some of his statements.  For instance, I
>> talked about the problem of needing several apps that do similar jobs
>> because they each have their strengths.  His answer was "We'll
>> just have to work to get one application that can do all of that".  That
>> is a ridiculous statement, since all of them are put out by different
>> people...
> 
> I took that as a statement of an ideal. I'm sure you too would rather
> have one tool that did the complete job rather than combining 3.
> 
> He didn't clarify the point, but I didn't interpret what he was saying
> as "you can't do that." It was more like, "we want to avoid this kind of
> a situation for typical users."
> 
> If what you are trying to do is a common need, and it logically makes
> sense to meet all those needs with one tool, then that's what the
> community should be striving for.

Yes, but how does making it harder to tell one app from another solve
that problem?  It doesn't.  It just makes it harder to deal with.

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.  This is just one thing
that should be configurable of many, so please take this statement as
addressing the larger "design pattern" of making things simpler by
removing functionality instead of reorganizing functionality.  The same
goes for only running one instance of any app, only one dock bar,
automaximizing windows that happen to touch the edge of the screen, ...

> This doesn't always make sense. Sometimes features are better
> implemented as a chain of separate tools (classic Unix philosophy), or
> your use case may be odd-ball enough not to warrant integrating, or some
> features may not fit the philosophy of a program.
> 
> Does any one of the programs stand out as coming the closest to meeting
> your needs? Have you filed feature requests?

Yes, Rhythmbox.  Like I said in my last post, it crashes when working
with my iPod and I filed a bug report and cooperated with them every
step and they say they're not fixing it.  The short summary of the
problem is it can't handle a collection with metadata over a certain
physical size because they got cheap on field sizes.  I have a 120GB
Classic with about 6800 songs on it, and it worked fine.  Then I started
adding album art, and before you know it I was over the limit.  They
understand and acknowledge it, but won't fix it.

>> ...how am I going to be able to tell these programs apart if I can't
>> see their names?
> 
> There seemed to be some misunderstanding over the UI elements.
> 
> If you're familiar with GNOME 2, then the bar on the left side is a
> combination of the Window List and Application Launcher applets (or in
> (pre-7) Window terms, task bar and quick launch icons). I don't know
> what GNOME 3 calls this, but dock bar seems to be the common term for
> this combined functionality. (I use one called DockbarX on GNOME 2.)
> Dock bars let you see what applications are currently running, and allow
> you to "pin" a small subset of applications that you use most frequently
> so they can be launched from the bar.

OK, that makes more sense, especially in the context of them considering
the Windows 7 interface to be Holy Doctrine Of All That Is Good.  It
doesn't actually make the problem less severe, but at least I understand
their choice better (while still disagreeing with it)

> While the application list that appeared in the main part of the screen
> is the equivalent to the Applications menu.

...which you ALSO can't adjust the look and feel of.

> 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 ;)

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).  The icon is a folder, like File Manager, but it has a
mouse pointer on it.  HOW THE F*CK is that the icon of a DVD burning
program?  The icon for ARK, archiving software, is a 3D cube.

You see my point?  Just like the huge argument years ago on this list
with He Who Must Not Be Named about his proposed encryption algorithm
that could fit gigabytes of data in a few KB, 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.  This will actually be more
harmful to the beginners they are attempting to coddle than us old
hands. (punchline: After several days of arguing he finally admitted his
algorithm was not lossless.  Minor detail).

> 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.

>> The other thing that really has me worried is when he was talking about
>> the plugin architecture, and how that might be used to get around some
>> of the problems we were all complaining about. 
> 
> The ability to reprogram the UI in a main stream language (JavaScript),
> without having to recompile the whole desktop, sounds rather promising.

Again, I agree this is technically very impressive and could be a good
solution, but I have learned the hard way not to rely too heavy on
features the author admits to hating themselves ;)

> Anyone know if this is how Ubuntu's Unity UI is implemented on top of
> GNOME 3, or did they get more invasive?
> 
> 
>> "We know how the the interface should look and work, so we don't
>> really like this feature, because people are going to muck up the
>> look and feel.  This just so totally smacks of Microsoft's stance
>> ("We know what you need").  Very arrogant, and very much not the open
>> source way and attitude.
> 
> I think desktop UI designers face some of the toughest challenges of any
> UI designers, because users inevitably resist change and want a new
> desktop that works the way the old one did. That makes it pretty hard to
> innovate.

I hear what you are saying.  I embrace change.  I live Agile and deliver
code every two weeks and at the end of those two weeks the priorities
and designs have changed.  I'm 47 and still keep up with the latest
technologies.  I am not asking for no change.  I am asking for no
removal of functionality.  Make it default to however they think it
should look, but let the power user change it if they want.  If they
don't have the time to write configuration programs, then read the
config from a file we can tweak if we dare.

> Ideally you want a "soft" introduction to the new features where you can
> try them out after an upgrade, and if you find you just can't live with
> them, you can revert the problematic ones, while keeping others.

Yes.  That.

> I'm pretty sure if the capability is there in the plugin architecture,
> we'll see plugins to revert most behaviors to be GNOME 2-like.

That used to be the way in Linux.  If there was a need, it would be
filled,  If a product was cool, it would get loved.  but there are so
many products out there now, the talent (and energy!) is spread thinner.
 I am no longer confident in Adam Smith's Invisible Hand guiding the
energy and resources to the most needed and deserving projects.

Then again I'm not known for my optimism.

> I wouldn't fault the GNOME 3 developers for not putting in hundreds of
> configuration options to support GNOME 2 behaviors. But I do think it
> would be wise to have GNOME 2 compatibility plugins available in time
> for the first non-beta Linux distribution that ships with GNOME 3.

I agree that putting in that many configuration options would be a
burden and testing nightmare.  But a few dozen to start out with would
cover a lot of territory, and be indicative of a philosophy of
supporting all levels of users.

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.

>> He danced around some other long-standing issues that were not
>> addressed, like when you automatically autostart/restore applications
>> after a reboot, they should restart into the virtual desktop they were
>> on at shutdown.
> 
> Agreed. Session persistence has been a long standing problem in GNOME.

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.