FutureOfGst

Revision 20 as of 2006-06-17 16:54:07

Clear message

Summary

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.

Rationale

The ["DesktopTeam"] feels this step is necessary, because

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

Scope

Design

Implementation

  1. Look into g-s-t, s-t-b, liboobs infrastructure

  2. Look into other System Tools.

  3. The ["DesktopTeam"] could gradually try to extend system tools with new pygtk based frontends and new python based backends using the glue that liboobs offers. The first step could involve to use SimpleGladeApp to be able to re-use the existing interfaces. ["ManuCornet"]'s ["ServicesAdminRedesign"] considerations will be taken into account. (We'd already have a Codename for the project: Umbrella (The name Umbrella was chosen by picking a random word from Finnegans wake. Apart from that it contains the Ubuntu-'u' and can be understood as an umbrella project shipping a set of system tools. Funny :))

  4. Keep in mind to make Gnome dependencies optional and easily loadable at runtime only.

Code

Data preservation and migration

We will continue on shipping gnome-system-tools and its infrastructure in edgy - this will make it easy to pedal back, if we need to.

Outstanding issues

BoF agenda and discussion

The new gnome-system-tools infrastructure will be in edgy soon. We have to make more efforts to integrate these patches again:

  • attachment:06_install_smbnfs.dpatch
  • attachment:17_ntpdate.dpatch
  • attachment:24_nautilus_share_gksudo.dpatch

Comments

  1. A common python-based configuration tool for all the accessibility tools has already been [:Accessibility/Specs/CommonATConfig:proposed]. The Orca gteam is following this approach with their config system as will [:Accessibility/Specs/SOK:SOK] and [:Accessibility/Specs/compiz-mag:compiz-mag].

  2. Where ever a tool has python bindings we should favor to use them then to use the command line tool itself. For some of the functionality it will be beneficial to explore how it can be reimplemented in python for sake of maintainability and ease of debugging.
  3. If a tool doesn have a python API, nor can be grown one, we should aim to wrap it in a way that would seperate implementation from the call level interface. This would enable us to replace implementation without affecting the dependent frontends.

  4. I might be trying to make Umbrella do something it wasn't meant to do, but I'm thinking that if we decide that we should rely on commmandline tools to do all the work and call those from our Python app, Umbrella could be used to administer remote machines too. All that would be required of the remote machine is ssh+sudo access. Alternatively, each action could have a "local" and "remote" version where the local version could depend on whatever it felt like (relevant Python modules or whatnot) while the remote version would be used for the remote systems managed via ssh+sudo. This would allow certain spiffy features only possible from within Python to be available locally to users only looking to administer their own machine while the slightly amputated version would be available for remote machines, too. -- [SorenHansen]

This process could simultaneously begin to solve other problems with g-s-t:

  • the over-long Preferences menu
  • the division between Preferences and Administration, which makes little sense to most people
  • awkward design in many tools.

A good start would be a tool combining the functions of About Me, Users & Groups, and Sessions. Another good example would be a tool combining the functions of Fonts and Theme Preferences. I'd be delighted to help design any of these. -- MatthewPaulThomas

Most of the previous example are capplets from gnome-control-center. The menus and categories issue are probably out of the scope of this spec. Note that "awkward design" is not really an useful comment, if you really want things to change better to start pointing what you would change or what do you have an issue with. Some rationnal could give you some credibility too [Sebastien Bacher]

CategorySpec