KubuntuSystemTools
|
Size: 5065
Comment: review
|
← Revision 13 as of 2008-08-06 16:32:32 ⇥
Size: 5195
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| * Created: [[Date(2005-10-07T12:45:59Z)]] by JaneWeideman * [https://launchpad.net/distros/ubuntu/+spec/kubuntu-system-tools] |
* Created: <<Date(2005-10-07T12:45:59Z)>> by JaneWeideman * [[https://launchpad.net/distros/ubuntu/+spec/kubuntu-system-tools]] |
| Line 16: | Line 16: |
| Bob wants to set a program to run at a given time, he finds he has to learn crontab format and emacs (or even worse, kcron) to be able to do so. | Bob bought a second monitor and wants to change his X display for dual head. He uses the new displayconfig tool from Guidance for this. |
| Line 20: | Line 20: |
| Alan wants to update his Apache configuration, but he doesn't want to learn all configuration settings of Apache. | == Background == KNetworkConf is a KDE frontend to the gnome-system-tools network backend. Guidance is a collection of KControl modules written in Python which currently includes a user manager, runlevel editor and fstab editor. |
| Line 26: | Line 28: |
| {{{XXX: JamesTroup: What (roughly) is 'Guidance'? What tools does it provide and/or what parts of the system does it allow you to configure? Without that information, the usefulness of this scope is lessened, IMO}}} |
Longer term Gnome System Tools may be moving to a dbus based separation using liboops which will require significant work for a KDE frontend. There is likely also to be a need for a KDE Network Manager frontend. Neither of these will be targets for dapper but at least one will probably be a target for dapper+1. |
| Line 31: | Line 30: |
| Encourage more people to develop KDE administration utilities. | Encourage more people to develop Guidance style KDE administration utilities. |
| Line 39: | Line 38: |
| Longer term Gnome System Tools may be moving to a dbus based separation using liboops which will require significant work for a KDE frontend. There is likely also to be a need for a KDE Network Manager frontend. Neither of these will be targets for dapper but at least one will probably be a target for dapper+1. {{{XXX: JamesTroup: surely this paragraph should be in Scope, rather than Implementation?}}} |
|
| Line 45: | Line 40: |
| The user interfaces for the Guidance tools are currently going through a usability review by openusability.org. We will work with the upstream Guidance developers to implement and add suggestions for usability. | The user interfaces for the Guidance tools are currently going through a usability review by openusability.org. Jan Muehlig from OpenUsability says he will have a usability report this week. We will work with the upstream Guidance developers to implement and add suggestions for usability. |
| Line 47: | Line 42: |
| The upstream Guidance developers are keen to add new tools to their suite. They are currently working on an X configuration tool. Other ideas include tools to manage crontabs, grub configuration editor, sudo configuration editor, keyboard selection and an Apache configuration tool (which could talk to a remote web server). | We will ensure .pot files are generated by Guidance for inclusion in Rosetta. Guidance is in the playground module of KDE's SVN repository which gets very little translation work, so it will be an important first use of Rosetta. |
| Line 49: | Line 44: |
| We will help the upstream developers in creating these tools and ensure they are well tested with Kubuntu. | The upstream Guidance developers are keen to add new tools to their suite. They are currently working on an X configuration tool. Other ideas include tools to manage crontabs, grub configuration editor, sudo configuration editor, keyboard selection and an Apache configuration tool (which could talk to a remote web server). None of these are immediate goals for Dapper but we will work with upstream if they start to implement them. |
| Line 51: | Line 46: |
| {{{XXX: JamesTroup: call me harsh, but "we will help" people in creating something that are simply "ideas" seems like a bit of a stretch as an "implementation plan"? Which, if any of these, are likely to happen for the Dapper timeframe? i.e. What actual implementation, if any, is going to happen?}}} To encourage more people to develop KDE administration utilities, we should focus on the simple, but powerful development language for Kubuntu which Guidance provides with its KControl PyKDE integration. {{{XXX: JamesTroup: what does 'focus' mean/involve?}}} We should also provide some sample applications and documentation to encourage others in creating configuration tools including how to start working with Python and QT/KDE Bindings. There are already some good examples on the Internet (e.g. LUMA LDAP Browser http://luma.sourceforge.net/) {{{XXX: JamesTroup: 'should' or 'will'?}}} |
We will also provide some sample applications and documentation to encourage others in creating configuration tools including how to start working with Guidance and PyKDE Bindings. |
| Line 67: | Line 50: |
| == BoF agenda and discussion == | For the existing modules: |
| Line 69: | Line 52: |
| {{{XXX: JamesTroup: Any relevant information from this section that's not duplicated above, should be added somewhere appropriate and then the section should be removed, as it's confusing. It'll be available in the history for posterity.}}} | ==== userconfig ==== |
| Line 71: | Line 54: |
| grub editor. sudo editor. Make knetworkconf better (networkmanager frontend?). | No special plans besides implementing usability improvements suggested by the forthcoming report from OpenUsability. |
| Line 73: | Line 56: |
| ldap admin/browser (LUMA already in breezy/dapper) | '''Update:''' report is now available, http://muse.19inch.net/~jr/review_guidance_malaga.pdf |
| Line 75: | Line 58: |
| improve guidance user interfaces | ==== mountconfig ==== |
| Line 77: | Line 60: |
| 21:17 < _Sime> ... a decent way of selecting a keyboard and keyboard settings. (I want to choose my keyboard from a _picture_, not guessing if I have US international or whatever) |
This means that mountconfig will need to accommodate non-root users who wish to mount via FUSE. Kubuntu will include fuse-kio bridge to support this. |
| Line 80: | Line 62: |
| 21:18 < _Sime> understandable compose key support would be good to. Right now it is not obvious how you configure it. | Investigate if it is worth switching to HAL for hardware detection. |
| Line 82: | Line 64: |
| 21:16 < _Sime> a decent cron editor thingy would be nice, something that actually showed what was going to happen when... | ==== serviceconfig ==== |
| Line 84: | Line 66: |
| KDE Apache Configuration Tool, it should provide remote uploads | Use the libapt-front bindings for Python to speed up descriptions. Further improvements are waiting on Ubuntu init scripts supporting the status command. ==== displayconfig ==== A new module for Dapper currently under development. Upstream are working to complete and debug singlehead support (mostly finished) and implement dualhead support. Debugging and testing. Upstream will be making an effort to collect and test on different graphics cards and combinations of graphics cards (AGP and PCI). We will ensure the community helps with this effort by creating a test plan for testers and keeping track of results on a wiki page. Post Dapper work should include integration with the X server and Xorg packages. displayconfig modifies /etc/X11/xorg.conf and can potentially make the GUI unusable. Problems include: - if /etc/X11/xorg.conf has been updated then the server should automatically restart after the user logs out. - After restarting the server, confirming with the user that the new config is visible and wanted (+timeout). - Automatically restoring the last known working xorg.conf if the server crashes. This needs to be further spec'ed and communicated to Xorg packagers/developers during the Dapper release cycle for Dapper+1. |
Created: 2005-10-07 by JaneWeideman
https://launchpad.net/distros/ubuntu/+spec/kubuntu-system-tools
Summary
Improve existing Kubuntu system configuration tools and help create new ones.
Rationale
Breezy includes some new and improved system configuration tools over Hoary, significantly the Guidance suite. We should improve the user interfaces of these tools, ensure they are bug free and encourage new tools by helping upstream.
Use Cases
Bob bought a second monitor and wants to change his X display for dual head. He uses the new displayconfig tool from Guidance for this.
Impi wants a way for their users to set the network interface but find the current tool insufficient.
Background
KNetworkConf is a KDE frontend to the gnome-system-tools network backend. Guidance is a collection of KControl modules written in Python which currently includes a user manager, runlevel editor and fstab editor.
Scope
Improve KNetworkConf and Guidance.
Longer term Gnome System Tools may be moving to a dbus based separation using liboops which will require significant work for a KDE frontend. There is likely also to be a need for a KDE Network Manager frontend. Neither of these will be targets for dapper but at least one will probably be a target for dapper+1.
Encourage more people to develop Guidance style KDE administration utilities.
Implementation
KNetworkConf
KNetworkConf has some significant bugs in setting the gateway and default route. We need to fix these for dapper. The user interface of KNetworkconf does not fit on a 1024 pixel wide screen, this is also important to fix. We should use the 'Gnome Network Configuration Utility' frontend as an example for ideas on improving the KNetworkConf user interface.
Guidance
The user interfaces for the Guidance tools are currently going through a usability review by openusability.org. Jan Muehlig from OpenUsability says he will have a usability report this week. We will work with the upstream Guidance developers to implement and add suggestions for usability.
We will ensure .pot files are generated by Guidance for inclusion in Rosetta. Guidance is in the playground module of KDE's SVN repository which gets very little translation work, so it will be an important first use of Rosetta.
The upstream Guidance developers are keen to add new tools to their suite. They are currently working on an X configuration tool. Other ideas include tools to manage crontabs, grub configuration editor, sudo configuration editor, keyboard selection and an Apache configuration tool (which could talk to a remote web server). None of these are immediate goals for Dapper but we will work with upstream if they start to implement them.
We will also provide some sample applications and documentation to encourage others in creating configuration tools including how to start working with Guidance and PyKDE Bindings.
As the number of modules grow we will have to be careful to not crowd 'System Settings' with too many tools. The user interface for 'System Settings' may have to be changed to handle more modules, e.g. to a vertical lineup rather than a horizontal one, as already exists in the KDE 4 branch.
For the existing modules:
userconfig
No special plans besides implementing usability improvements suggested by the forthcoming report from OpenUsability.
Update: report is now available, http://muse.19inch.net/~jr/review_guidance_malaga.pdf
mountconfig
This means that mountconfig will need to accommodate non-root users who wish to mount via FUSE. Kubuntu will include fuse-kio bridge to support this.
Investigate if it is worth switching to HAL for hardware detection.
serviceconfig
Use the libapt-front bindings for Python to speed up descriptions.
Further improvements are waiting on Ubuntu init scripts supporting the status command.
displayconfig
A new module for Dapper currently under development. Upstream are working to complete and debug singlehead support (mostly finished) and implement dualhead support.
Debugging and testing. Upstream will be making an effort to collect and test on different graphics cards and combinations of graphics cards (AGP and PCI). We will ensure the community helps with this effort by creating a test plan for testers and keeping track of results on a wiki page.
Post Dapper work should include integration with the X server and Xorg packages. displayconfig modifies /etc/X11/xorg.conf and can potentially make the GUI unusable.
Problems include:
- - if /etc/X11/xorg.conf has been updated then the server should automatically restart after the user logs out. - After restarting the server, confirming with the user that the new config is visible and wanted (+timeout). - Automatically restoring the last known working xorg.conf if the server crashes.
This needs to be further spec'ed and communicated to Xorg packagers/developers during the Dapper release cycle for Dapper+1.
KubuntuSystemTools (last edited 2008-08-06 16:32:32 by localhost)