On Thu, Aug 9, 2012 at 12:10 PM, Jonathan Meek <shrouded.cl...@gmail.com> 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 -- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
