Re: Having external control panels in System settings

[Giovanni Campagna <scampa giovanni gmail com>]

2012/2/7 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:

This is a very strong sentence - and seeing factual arguments about
decently (I wouldn't go with well) designed extensible control centers
in the competition, I'd say you need a strong proof.

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

Personally, I'd say that limitations of the shell have nothing to do
with individual components, as long as the shell is just a "launcher"
for components. Since there is no short-term plan to change that (both
in g-c-c code and public mockups), I'd mark this irrelevant.

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

Such redesign didn't happen in 3.0 timeframe, or in 3.2, and probably
won't happen before 3.4.
When such redesign is out, if the result is technically incompatible
with external panels (unlikely, since probably you want to keep each
module self-contained), distros and third-party will have time to
adapt. I'd underline "technically" - preventing extension by design
provides no real benefit to the development.

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

As stated repeatedly on this thread, this is up to the distributions
to ensure. And, btw, integrating third parties that provide system
components does make for a "consistent and coherent experience", even
if the module doesn't have the g-c-c seal of approval.

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

Not really. With due announce, you can break API as you wish, since
what you're targeting is not an appstore full of thousands of
unmaintaned microapps, it's a selected subset of 2-3 components that
cannot be upstreamed, for whatever reason.

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

I'm not sure I understand this. Looking at what Ubuntu provides in
it's patched control center, and comparing to upstream g-c-c, I see
Ubuntu One, Additional Drivers, Backup and Software Sources. Each is a
well defined component, and the user can understand why none of them
belong to any other panel. Also, each is part of the system and none
of them are upstreamable (jockey and software-properties-gtk are
apt-only stuff, deja-dup wants to stick to launchpad, Ubuntu One,
well, it's Ubuntu...).
Moreover, under Fedora, in my "Other" menu, I see many parts of the
system that would definitely benefit from g-c-c integration, like
Authentication (not upstreamable, has fedora specific PAM config),
Backup (see above), Firewall (not upstreamable, since iptables
configuration is not standard), Software Settings (this one is
actually upstreamable, I wonder why g-c-c does not include
something...). They are all distinct components, so there's really no
"integration" problem. And in any case, a separate g-c-c panel is not
worse than a separate floating capplet, buried deep into
Applications->Other.

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

I'd say Ubuntu's g-c-c scales well, despite not beign specifically
designed for that (although they probably changed the default size)

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

GNOME is not the only project to have a design team. Downstreams have
too, and they'll put your API to good use even without detailed
guidelines. Or, if it turns out any attempt to use the API results in
UI disasters, they'll let it rest, waiting for a better one in gnome
3.2*(n+1)

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

Tautology?

> 9. Once we have such guidelines we'll have to make some attempt to
> stick to them.
>
> 10. We aren't there yet.

Maybe we could be - if you had let people experiment for more than a
development release.
("You" not meaning you personally)

> So, everybody - chill.
>
> Jon

Giovanni

> 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
> _______________________________________________
> gnomecc-list mailing list
> gnomecc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomecc-list