FutureOfGst

Differences between revisions 15 and 16
⇤ ← Revision 15 as of 2006-06-09 23:10:22 →
Size: 5363
Editor: granit-ext
Comment:
← Revision 16 as of 2006-06-14 10:10:13 → ⇥
Size: 5355
Editor: i577B0091
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
 * the code has grown over a long time.  * we face quite a lot of bugs.

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 weird, 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 other System Tools.

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

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

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

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

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]

CategorySpec

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