Re: Having external control panels in System settings

[Alberto Ruiz <aruiz gnome org>]

2012/1/24 Bastien Nocera <hadess hadess net>

On Tue, 2012-01-24 at 14:20 +0000, Alberto Ruiz wrote:
> 2012/1/24 Bastien Nocera <hadess hadess net>
>         On Tue, 2012-01-24 at 00:07 +0000, Alberto Ruiz wrote:
>
>         > Truth be told, the fact that new panels inside the module
>         doesn't give
>         > you more control, Ubuntu is changing quite a few things in
>         both
>         > existing panels and new ones. And let me tell you the
>         current result
>         > is far from pretty (a lot of modules are still the old
>         python based
>         > ccapplets).
>
>
>         Ubuntu don't ship GNOME. They use bits of GNOME to ship Unity.
>
>         They're also the only distributor of those bits mangling the
>         panels in
>         that way, so I'd class them as the exception rather than the
>         rule.
>
>
> Is that it? Are you not going to comment on anything else of what I've
> said? I am really not at all interested in the whole Ubuntu vs. GNOME
> flame war that you seem so keen on bringing up.

You brought up the fact that Ubuntu is shipping an overly modified
version of gnome-control-center, where they do what they want, and not
what we, as upstream, would want them to ship.

I was just trying to make the point that if we keep things too tight, we lose control on how people extend the panel. And used Ubuntu's version of the control center as an example, whether they ship GNOME or not is a matter for another discussion that I'm not interested in having.

Dropbox is a proprietary app. You can't have proprietary panels as
gnome-control-center is GPL.

nVidia have been refusing to implement XRandR in a way that means that
they would use the same configuration application as everybody else. And
it's proprietary software.

nVidia's driver configuration should implement XRandR and then users
would use the Display panel. A Dropbox equivalent, like Sparkleshare,
would integrate in the Privacy and Sharing panel.

The licensing problem can be bypassed. If they were doing the right thing, they would use GSettings and could easily have the panel extension under GPL and have their daemon listening to those settings, nVidia could do similar tricks.

Having extensions on a per panel basis is certainly an interesting approach, but I think it's a lot harder to cover all possible cases. One problem that comes to mind is searchability, we may want to find a way to enable people to use the shell and the panel items if they, say, type "sparkle".

The other problem that comes to my mind is that there may be valid use cases 

 

> There are APIs to do this in Mac OS X, and I've never seen more than
> one or two extra items installed in a ac OS X host (mostly growl, the
> notification thingie), given the amount of audience that such platform
> has, I really don't buy your argument that by opening up such
> interface the gates of hell are going to open.

You mean like Google not adding their Music Manager inside the System
Preferences?
http://www.maclife.com/article/features/getting_started_music_beta_google

Google are not generally regarded for how well they integrate with the underlying system are they? In any case, my point was that even though Mac has extension points for more items, they don't seem to have too much of a problem with regards too many items showing up there and making the UI impossible to use. As I said, most of the times, users only got one or two extra items. No big deal.

 

> I find it a bit odd that we care so much about the mess that happened
> before and we are not doing an in depth analysis on why it
> happened. Why don't we try this approach and if things get messy, then
> we figure out what to do?

It happened because people thought that we weren't interested, or they
didn't want to talk to us, or couldn't talk to us. One major problem was
that there were no maintainers. At least there were no full-time ones
for nearly 2 years before Richard and I got assigned to work on it.

Point taken, we need more resources and I personally wish more commitment in the form of maintainer time was commited overall. The amount of work you've accomplished and the final result is impressive, and I really appreciate what you are trying to do, so kudos for that.

However, if ISVs need to talk to us to be able to do the right thing (whatever the right thing is), we are doing something wrong. I certainly think that the previous situation was different, they wanted items to show up in the systems submenu, and a tag in the .desktop file was the documented way to do so. That's why the whole thing went to a messy point quite easily.

However, what I we should try to avoid is a bunch of entries in the shell's application view which aren't really applications but settings, so I am trying to figure out what the right path for ISVs is in this regard. And "come talk to us and we may or may not ship it in the next GNOME release" is not really the right thing to do. ISVs need autonomy to do whatever they have to do, if they have to join an IRC channel and have a discussion with us to provide a configuration interface we've already lost as a platform I think.

I know you have discussed around this topic over and over and you are probably tired of writing mails about it but I hope you understand why many of us are still concerned about it.

-- 
Cheers,
Alberto Ruiz