Re: Settings downstream would reasonably want to add [was: long thread with no resolution]



Hello Dave,

Dave Neary [2011-05-13 10:56 +0200]:
> What preferences do you think you'll want to add to GNOME CC which
> aren't currently planned, and how would you like to add them?

In previous releases we had:

 * Additional Drivers (jockey). This was exposed in control-center,
   but only due to having a "HardwareSettings" Category in its desktop
   file.

   Jockey (https://launchpad.net/jockey) has been around as an
   upstream project for ages, and also been discussed with other
   distros, but they weren't fond of it (note that trunk does not have
   any apt/Ubuntu specific things and uses PackageKit). I eventually
   just gave up trying and keep this in Ubuntu for now.

   I don't really insist on keeping this in c-c, it can just as well
   live as a standalone application. It is already integrated
   (upstream) in system-config-printer, our installer (optional) and
   will notify you after first install about missing driver, so after
   install you only need to call it if you want to e. g. switch
   between nouveau-3D and nvidia, or change openprinting.org printer
   drivers.

 * Language Selector, which allows you to configure your language and
   fallbacks ($LANGUAGE/$LC_MESSAGES), locale ($LANG), list of
   installed languages (packages which provide translations,
   dictionaries, OO.o help, etc.), and input method.This can probably
   be integrated into the now existing GNOME 3 module.

 * Software Properties: This configures package repositories,
   automatic updates, etc. I. e. highly packaging/distro specific
   stuff. It is a classic system-wide configuration and does not
   apply to any particular application.

 * system-config-printer: We decided to continue to use that instead
   of the GNOME 3 c-c one. s-c-p is a lot more complete and proven.

Those are the ones that come to my mind right now. It might change in
the future, other distros/project have different needs, etc.

> It feels like there must be a better way to handle enabling additional
> hardware drivers than an "Additional drivers" preferences panel. Is
> there a need for a "Hardware" panel?

Personally I don't think that a general "hardware tree" view makes too
much sense to have. It might be interesting for techies (but they can
just as well poke udevadm info), and for users it might create the
false impression that you could actually configure much in it?

> A "Software updates" panel which delegates preferences to downstream
> depending on whether it's apt-get, yum or zypper based? Is this
> something we could think about at the GNOME level, rather than
> having it implemented a number of different ways downstream?

PackageKit certainly went a long way towards this. Right now it still
has some conceptual designs which make it hard to use as a general
package install/upgrade tool for Debianish distros (but it's highly
useful for more special cases). But it would make a great GNOME
control center module anyway?

Although the technical details between rpm/deb based distros are
vastly different, the general concepts of having different software
channels, automatic/manual security/bug fix updates etc. are still the
same.

> Beyond Ubuntu One (which conceptually would match with the "Sharing"
> settings, and which Allan has already said should be dynamically
> addable)

You actually touch an interesting middle ground here: Instead of
arguing for an "anything goes" extendability (a lot of people are
against this for IMHO valid reasons), downstreams could instead just
argue for placeholders for individual use cases (configure package 
management, driver packages, sharing, etc.)? 

Is that what you mean? If so, then this would get GNOME what they want
(avoid arbitrary clutter) and also us what we want (e. g. package
management is not something GNOME itself deals with, but distros have
to).

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Attachment: signature.asc
Description: Digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]