Re: Having external control panels in System settings

[William Jon McCann <william jon mccann gmail com>]

Nearly every message I've seen on this issue has it pretty much wrong.

The main reason why we only officially support in-tree settings
panels, at this time, is because the design doesn't work any other
way. There are a few issues here:

1. The System Settings "shell" we have right now was designed rather
hastily for 3.0. We were aware of a number of limitations in the
design very early on and we have learned about a few more since then.

2. We knew we would have to redesign the shell at some point to
address these issues.

3. One of the primary goals of the System Settings app is to provide a
consistent and coherent experience.

4. A large scale redesign is only possible with dynamic control of the
backing code.

5. Coherent partitioning of system settings does not map well to fixed
external code modules. There is only one system. The components of the
system are not user visible concepts.

6. Settings can be coherently displayed and partitioned for
Application settings but it was an explicit design decision that this
was out of scope for the 3.0 design and what we have does not work at
all with those kind of scaling requirements.

7. It is not enough to present a code API to third-parties. You must
also present design guidelines. You can't just slap/embed any random
thing into the app. It has to make sense. It has to be coherent. Or
else it is worse than useless - it is ugly, confusing, harmful.

8. We can't make such guidelines until we know what they are.

9. Once we have such guidelines we'll have to make some attempt to
stick to them.

10. We aren't there yet.

So, everybody - chill.

Jon

On Mon, Feb 6, 2012 at 5:56 PM, Sergey Udaltsov
<sergey udaltsov gmail com> wrote:
> Hello Allan
>
> Thanks for explaining me your opinion (as far as I can see, generally
> shared by the g-c-c maintainers). But this topic was discussed many
> times already. Obviously there is a conflict of values here - which
> makes agreement very hard to reach, if possible at all.
>
> I am still amased to see that the architecture that is "asking" for
> openness, that was open for years, from the very start - suddenly
> becomes closed just because of the lack of the detailed UI guidelines.
>
> I still fail to understand why all proprietary OSes have open
> extensible architecture around that area - while free software
> requires and effectively promotes patching which, from the overall
> attitude POV, looks like twisting of hands and intentional alienating
> of 3rd parties (in particular - hardware vendors).
>
> While g-c-c cannot prevent extension (thanks to free licenses), it
> just makes it hard and painful. Sometimes I even wonder if some people
> on that list could consider closing the source code in order to
> protect the well polished GNOME UI. Heh?;) Well, this is too much of
> trolling even for me. Let's get to some details...
>
>> situation. The best way we can promote Free Software is by making
>> products that people want to use.
> GNOME has never been end-user product. And it is not, so far. End-user
> product is a distro. GNOME is a product for distromakers. Should GNOME
> be friendly to its customers? Extension by API is orders of magnitude
> more friendly than patching - which is available anyway, so if some
> distro really wants to provide broken GNOMEish experience, wants to
> screw it, it has all possibilities (of course, I am not talking about
> Ubuntu;)
>
> If GNOME insists it is an end-user product ("GNOME OS"), it is a
> marketing move against independent (I mean - not affiliated with
> Redhat) desktop distros - they should either patch GNOME (and break
> the polished experience anyway) or just redice their activities to the
> packaging system and branded background image. Will they be happy? I
> doubt that.
>
>> Remember that distros extending the system settings in a haphazard way
>> in GNOME 2 resulted in all kinds of pain and seriously undermined the
>> user experience. We really need to do better this time around.
> I generally agree. And I completely support your point about lack of
> strict UI guidlines, perhaps more streamlined APIs etc. There are many
> ways to work on that issue. But closing the architecture is the worst
> of them.
>
>> We actually want distributors to extend GNOME 3, but we want them to
>> do it in a way that doesn't make the system worse for users.
> I guess distromakers are totally with you on this point. They are
> friends, not someone who's intention is to screw users and make them
> dislike GNOME. May be we should trust them? Cooperate? And proactively
> help them to create nice and consistently looking UIs. Not to fight
> them.
>
>> That's one reason why I'm working on a new version of the HIG.
> It is a very important work - but I hope it does not directly conflict
> with the idea of open APIs, does it?
>
>> There are also plans to have other integration points within the
>> system settings, such as with the privacy and sharing panel [1] and
>> with a notifications panel [2].
> These integration points are all good and useful. But sometimes
> something more generic is required (the examples were provided in this
> thread, and in some earlier threads).
>
> My apologies, again I could not stop myself from getting into that
> topic. I am just very happy to see this time someone as respectable as
> Federico tried to explain why extensibility is a benefit, not a curse.
> But still I do not expect anything to change in this department. I
> would be glad to be wrong, but I suspect g-c-c is going to remain as
> it is - without ability to add extra panels. That is why I am advising
> Petko to give up. Unless, of course, he wants to maintain some set of
> patches  that keeps g-c-c open.
>
> Regards,
>
> Sergey
> _______________________________________________
> gnomecc-list mailing list
> gnomecc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomecc-list