Re: Proposal: gnome-user-share

[Havoc Pennington <hp redhat com>]

On Sun, 2004-12-05 at 12:25 +0000, Alan Cox wrote:
> 
> You are appear to be determined to break all non gnome software. If that
> is your real agenda why not just admit it. If you want a desktop that is
> credible with ISV's of existing tools (like realplayer, acrobat reader,
> oracle management tools etc) then your design doesn't work.
> 

Guess who makes all the old Motif (and Tk, and some-ISVs-crappy-custom-
toolkit-of-the-week) apps, realplayer, acrobat, etc. work with GNOME?
It's myself (since much of it involves the window manager) and my team.
Probably the team at Novell does the same. We are aware of these issues
and if there's a problem we are the ones who hear about it. We even
package and test many of these apps you mention.

There's a difference between avoiding breaking this software, and
optimizing for this software. Microsoft doesn't optimize for legacy apps
either. Does a Windows 95 app run on Longhorn? I would not be surprised.
Does it work as well in a Longhorn environment as a Longhorn app?
Absolutely not. The same was true for 3.1->95, 95->98, and 98->XP.

This is the same approach we take across the board; freedesktop.org and
GNOME both have steadily added new ways that apps can integrate with the
desktop, the UI guidelines can also be viewed that way, or any GTK+
feature really can be viewed that way.

In some cases, such as the eggcups tray icon, old apps work with and
take advantage of the new feature and we were able to do that; in some
cases the old apps continue to work as they did before, and the new apps
work differently. Motif doesn't use desktop themes, for example. Or if
you want accessibility you have to use the new stuff.

There are hundreds or thousands of examples of this. And the ISVs that
feel parity with the latest platform is important, such as Real, are
porting to the new desktop stuff; the ISVs that don't care are not
porting, but the apps still work as they always did. Fortunately in the
UNIX/Linux case, the users with Tk and Motif apps are exactly the ones
that are most comfortable with fairly strange and inconsistent UI.

You talk as if having "display names" for files is some huge break, but
guess what; OS X has it, Longhorn adds WinFS, and IBM Workplace doesn't
even touch the filesystem, they use a data store like GNOME Storage.
For that matter Workplace requires apps to be written in Java and
doesn't load each app in a separate process, among other things.

And moreover GNOME (and KDE) *already* have a file namespace that is
wildly inconsistent with the one visible in a Motif app, due to gnome-
vfs and kio, and the way the file selector and nautilus display things.
And .directory and .desktop files. So even considering GNOME alone, the
problem you are worried about already exists - and it would plainly be a
major regression to try and "fix" this problem.

So don't get me wrong, if there were no tradeoff, we should keep the old
apps consistent, as with the eggcups example. But if there is a
tradeoff, "Motif apps won't be consistent" is simply not the trump card.

Even our tech workstation customers understand this, and as long as they
can configure the desktop so the workflow (e.g. task switching, etc.)
works roughly as they are used to, and their old apps remain usable,
they are generally content. They know on some level that they have
unique requirements. They did not get upset about .directory files
either.

None of this is to say that "display names" are definitely the right
fix, but the "motif won't use it" objection is not the fatal flaw unless
we have a suggestion that is equally good while also working with motif.

> If you have a large user base then you have to deal with the fact that
> "normal" is not some tiny narrow market segment occupied solely by Red
> Hat and SuSE's business desktop target. The bigger your market the more
> shell users, the more non gnome app users. And if they can't use it they
> will go elsewhere.

And in some cases *that is just fine*. As Alan Cooper points out, there
isn't a single type of car that works for everyone, and the same is true
of software.

You can't design around everyone. You can design with one or maybe two
groups in mind, and you can then work on ways to broaden the appeal or
make things adequate for more groups. But things are only going to be
*great* for one or two targeted audiences *at most* - if you try to
design for everyone, things will be *great* for nobody. Or perhaps we
will fall into the "design for ourselves" inertia and optimize for shell
users and programmers.

I happen to believe that a great desktop for office productivity will
happen to be good enough for the tech workstation customers I've
interacted with, especially with some strategic tweaks for their benefit
- many of which I've made myself.

At the same time: absolutely, if someone came along and invested as many
resources as we put into GNOME into a desktop tuned specifically for
those tech workstation users, they could make something better than
GNOME for those users. There is no question about it.

The "as many resources" point is really the key one though, since the
tech workstation user gets a lot of advantages from being part of a
large ecosystem. If Linux hadn't appeared there would be a lot of them
switching to Windows (some of them switched to Windows anyway); even
though CDE or 4dwm may have been more what they wanted, it wasn't worth
being stuck in a niche.

All that said, I do not believe your point applies to this particular
design decision because I don't think display names really break shell
users in any significant way. No more so than .directory files when we
had those. Or .desktop files which we still have; try browsing
to /usr/share/applications in nautilus.

> Gnome and FDO should be about INCLUSIVITY. Elimination of unneeded
> choices in the UI is not the same as making the product refuse to
> interoperate with in real world situations.

It's not about who is included - we try to accommodate almost everyone,
with some exceptions - it's about who is optimized for. One way to think
of this is what are the defaults, vs. what can you set up optionally.

If we think of Linux or open source as about choice, that should mean
sedan vs. minivan vs. sports car. It should not mean mutant all-things-
to-all-people car A vs. mutant all-things-to-all-people car B.

Here's another analogy: the kernel is designed for as broad a set of
applications as possible, but at some point the tradeoffs become
fundamental. You can't be both tuned for embedded realtime and for big
iron mainframe. You do your best to accommodate both of those, but the
design and the defaults really are not *optimal* for everyone at once.
At the same time, people may find that the value of the large Linux
ecosystem is worth enough that they'd rather wedge stock Linux into
their application than use a custom-patched Linux, or at least would
rather use custom-patched Linux than a homebrew OS optimized for their
purposes.

It's exactly the same for the desktop. We broaden the appeal until it
breaks, then we say "tweak these custom config options," then we say
"patch the source code," then we say "replace parts of the system which
we've left interchangeable using specs like EWMH," and finally for the
truly niche stuff we say "use some other codebase entirely." And that's
fine and good, because tradeoffs are real.

Havoc