FutureOfGst
4526
Comment:
|
5363
|
Deletions are marked like this. | Additions are marked like this. |
Line 43: | Line 43: |
1. The ["DesktopTeam"] could gradually try to extend system tools with new pygtk based frontends and new python based backends using the glue that liboops 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. :-)) | 1. 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. :-)) |
Line 58: | Line 58: |
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] |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/gst-to-umbrella
Created: Thu, 08 Jun 2006 11:38:33 +0200 by DanielHolbach
Contributors: MichaelVogt, SebastienBacher, ManuCornet, SivanGreen, MarioDanic
Packages affected: gnome-system-tools, system-tools-backends, liboobs
Summary
The ["DesktopTeam"] is looking for a solution to the problems we're facing with the current gnome-system-tools.
- the code has grown over a long time.
- 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
- 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.
[https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bugs gnome-system-tools (Ubuntu) bugs], [https://launchpad.net/distros/ubuntu/+source/system-tools-backends/+bugs system-tools-backends (Ubuntu) bugs]
- the existing packages are heavily patched.
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
- Look into other System Tools.
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.
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].
- 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.
- 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]
FutureOfGst (last edited 2008-08-06 16:31:44 by localhost)