unity-design team mailing list archive

[Dylan McCall <dylanmccall@xxxxxxxxx>]

On Thu, Aug 9, 2012 at 12:10 PM, Jonathan Meek <shrouded.cloud@xxxxxxxxx> wrote:
> Nautilus is just the latest thing the eyes have fallen on. It's really
> indicative of the bigger picture... Take what I wrote here, for instance:
> http://www.omgubuntu.co.uk/2012/03/ubuntu-design-micro-vs-macro
>
> NONE of the next generation GNOME applications are going to fit in with
> Ubuntu. We can keep the discussion on Nautilus, but Empathy feels out of
> place now. So do the games. Are we going to "fix" one because it axed a few
> features that they didn't feel were being/could be maintained well and leave
> the rest to stick out like sore thumbs? They have their own design language
> just like Mozilla or elementary. This is the time to push for first-party
> default applications. At the very least to replace divergent GNOME
> applications. But that requires an HIG first, which Ubuntu doesn't have.

Thank you!

This seems to come up every cycle, and forking / replacing Nautilus is
not a sustainable solution, because Nautilus is only a tiny symptom of
the problem.

Sebastien mentions that the Nautilus changes came as a surprise due to
the schedule, and I agree with that to some extent (the schedules are
a little mixed up) but I don't think the surprising Nautilus changes
are terribly significant on their own. For the most part, the changes
seem to fit with the application design changes that have been plainly
coming down the tubes since before 3.0. For example, the move to an
Application menu with a combined window menu has been happening all
over the place. I think Nautilus is the first default app in Ubuntu
with that change (Disks was held back for other reasons), but it is
not going to be the last. That menu design is the plan, it has been
the plan for well over a year, and insisting on forking / replacing /
patching applications as they get updated is going to lead nowhere,
fast. Meanwhile it has been as obvious, for as long, that Nautilus
handling the desktop is no longer a priority upstream — because,
upstream, it doesn't handle the desktop. It's junk code and it's
something we can safely assume they want to minimize.

I think the problem is Unity does not seem to be responding very
quickly to these changes upstream: it's continuing in a direction that
is subtly incompatible with the (reasonably apparent) direction that
GNOME is going in. Continuing to twist things around at the distro
level is not sustainable. It adds to the problem, and it's only going
to get worse. I'm really afraid that you could end up doing this for
everything GNOME ships.

Here's my two cents: If an upstream only fits with amazing quantities
of ongoing maintenance at the distro level, it is the wrong upstream.
If GNOME no longer suits Unity's vision, I think it's better for
everyone to think about finding something else. It would get rid of a
lot of theatrics. On the other hand, if that upstream is really
important, there should be a serious, directed effort to at least
_think_ about fitting these two together, in a binary-compatible way,
without patching or forking. How about some high level API so an
application can support both a menu bar _and_ an Application menu +
toolbar menu button? There's similar activity going on for Android
with the jump between Gingerbread and ICS (where we lose hidden menus
and gain a common Action Bar component), so it isn't unheard of.

Oh, and I should clarify: I _like_ where Unity is going, and the HUD
and the menu bar, so I'm not saying Unity should be more like GNOME
Shell. (We already have that, after all). I'm also indifferent to what
happens for Nautilus in particular, even though I act like it's the
start of a slippery slope. I'm just saying that the "don't like it?
fork it" approach seems like a dangerous use of the very limited
resources available to Ubuntu and the free desktop community.

--
Dylan