The DesktopTeam is looking for a solution to the problems we're facing with the current gnome-system-tools.

  • we face quite a lot of bugs.
  • the languages of choice don't make debugging easier:
    • C for the frontends
    • Perl for the backends
  • It would be preferrable to re-use existing tools like adduser, pppoeconf and the like and control them via nice and easy interfaces.


The DesktopTeam feels this step is necessary, because

  • graphical system tools are very important to new users
  • the choice of infrastructure is very hard to maintain (perl for the backends, C for the frontends) and grew (a bit wildly) over the time,
  • upstream and distro maintenance is not satisfactory, we have many grave and weird bugs.

Use cases

My mother tries to change her password through the users-admin. After confirming the dialog and rebooting the box she can't login any more.

Michael wants to package a new upstream release. He spends seven hours on merging our existing patches.

Tollef is called for assistance on a weird amd64 bug. Although being an expert, it takes him six hours to find the cause in a self-written crypt() function.

Susan needs to configure some accessibility tools but is confused by they way they are spread over many locations (Apllications menu, System AT config, Keyboard settings).


The gnome-system-tools package


For edgy we will switch to the new gnome-system-tools upstream framework, pick the tools we really want to ship and make them suitable.

We will ship those tools with edgy:

  • network-admin
  • services-admin
  • time-admin
  • users-admin

Those tools need to be ported to the new framework and will be considered next cycle:

  • boot-admin
  • disks-admin

We will likely use nautilus-share instead of shares-admin

Starting to work with 'guidance' (KDE) people on common code would be nice but that's not for edgy and will probably be discussed with an another spec.


  • The new gnome-system-tools will be uploaded to edgy during the GUADEC week (with the new version of GNOME)
  • network-admin:
    • the profile code need to be ported for the new version
    • changing how profiles work to use an apply button (instead of applying changes when selecting a profile) would be nice. The current way is confusing for some people because the network settings are changed when you try to edit a profile you were not using
  • services-admin:
    • having a start,stop button would be nice (cf ServicesAdminRedesign on the wiki about possible changes for it)

    • the list of services need to be updated
  • time-admin:
    • the ntpdate patch needs to be ported for the new version
  • users-admin:
    • the profile code need to be ported for the new version
  • the "packages installation" changes we hacked during the previous cycle might require some upstream changes to be possible with the new design. If a new "package installation" infrastructure is being worked for the EasyCodecInstallation and the SuggestedPackagesForFiletypesSpec specifications we might use it for that.

We could bounty Carlos Garnacho (upstream) to do those changes, he's not working at the moment and would be happy to have a bounty to work on the changes we want to do

Outstanding issues

BoF agenda and discussion


UbuntuDemon : There is a really interesting thread in the Edgy Development section at the forums going on. It's about a Control Center. There's already an implementation.

Ubuntu Control Center http://www.ubuntuforums.org/showthread.php?t=207894

LukaRenko: I would like to point out that knetworkconf (kdeadmin source package) also has own (older) copy of gnome-system-tools perl backend and that KDE's network configuration module is also not perfect in this regard. Simple kde-guidance module in python would be much better.

CategorySpec CategoryDesktopTeam

Back to DesktopTeam.

FutureOfGst (last edited 2008-08-06 16:31:44 by localhost)