FutureOfGst

Differences between revisions 21 and 22
Revision 21 as of 2006-06-22 17:04:10
Size: 4995
Editor: ALagny-109-1-9-136
Comment: summary of the BOF and discussions about gst for edgy
Revision 22 as of 2006-06-22 17:25:47
Size: 4203
Editor: ALagny-109-1-9-136
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from GstToUmbrella
 * '''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`, `xubuntu-system-tools`
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/automating-artwork
 * '''Created''': Thu, 08 Jun 2006 12:07:36 +0200 by DanielHolbach
 * '''Contributors''': DanielHolbach
 * '''Packages affected''': `ubuntu-artwork`
Line 9: Line 8:
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.
A set of scripts will be written and/or changed to automate the artwork process, from cutting out the icons to building a test package and showing an overview of the changes that went in.

''Please note:'' this spec can only be implemented by a Canonical employee. If you want to help out somewhere, it'd be better to pick another spec.
Line 18: Line 14:
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]
  * [http://bugzilla.gnome.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=gnome-system-tools&long_desc_type=substring&long_desc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= (upstream) bugs]
  * the existing packages are heavily patched.
  * It is mostly duplicated by the xubuntu-system-tools package. The difference is a small patch which disables the nautilus settings which use Gnome-VFS and disables gconf.
Doing `ubuntu-artwork` updates is currently highly manual work and requires time and concentration. Most parts of it could be automated.
Line 29: Line 18:
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.  * Icon designer Dave worked hard to improve a batch of icons and sends the master sheets to his Ubuntu contact. It only takes a little while until he can see all the icons in action.
Line 31: Line 20:
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).
 * Package maintainer Daniel is close to a deadline and needs to update the artwork package. He does not need to do somersaults to get all the changes in.
Line 39: Line 24:
The gnome-system-tools package The changes will involve
 * splitting of the `ubuntu-artwork` package,
 * changes in the existing scripts for processing icons.
 * some new scripts will have to be written to do additional tasks in updating the build system, for creating symlinks and visualizing changes from the old to the new artwork package.
Line 44: Line 32:
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. The first step will be to split `human-icon-theme` from `ubuntu-artwork`.
Line 46: Line 34:
We will ship those tools with edgy:
 * network-admin
 * services-admin
 * time-admin
 * users-admin
The implementation of the update functionality will run through two phases. The following table depicts which steps are to be automated and which may be done later.
Line 52: Line 36:
Those tools need to be ported to the new framework and will be considered next cycle:
 * boot-admin
 * disks-admin
''Explanation:'' MUST goals will be adressed during this spec, everything else may be automated, but it's not strictly necessary.
Line 56: Line 38:
We will likely use nautilus-share instead of shares-admin || '''Step''' || '''MUST goal''' ||
|| run gimp on .psd files, remove informational layer, save as .png file || NO ||
|| run strip-icons on iconprio.csv || YES ||
|| run strip-icons on whitelist.csv as well and automatically uuencode, uudecode where needed || NO ||
|| generate symlinks as specified in the CSV files || YES ||
|| run icon-spec-rename on them || YES ||
|| get last human-icon-theme package || YES ||
|| replace old icons with spec-renamed icons || YES ||
|| run update-Makefile.am on the icon directory || YES ||
|| some icons had to be edited manually (could be done via blacklist - but that has to be checked as well) || YES ||
|| we had chosen a wrong name (ok, needs to be fixed in the .csv files, but I noted it mostly during this stage) || NO ||
|| pbuild it || YES ||
|| check the debdiff of the two packages to see missing files etc || YES ||
|| go through iterations of the above || NO ||
Line 58: Line 53:
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.
Line 62: Line 56:
 * 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

 * tools-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 ==
 0. Split `ubuntu-artwork` into:
  * `human-icon-theme`
  * `human-wallpapers`
  * `human-splashscreens`
  * `human-theme`
  * `human-gdm-theme`
 This will make updates smaller and easier (as the individual build systems will be less complex as a whole). `ubuntu-artwork` will be merely a meta package and ship default files.
 0. Write a script which will
  * make use of the existing scripts and call them in succession,
  * pay attention to a blacklist to not overwrite icon which where specifically changed (smaller sizes, etc.),
  * run the build process of the package in pbuilder,
  * show the changes between the new and old package.
 0. Write a script, which reads the information contained in the iconprio CSV files and generate symlinks where specified.
 0. Enhance the update-Makefile.am script to be able to add new Makefiles where needed and change configure.ac and index.theme appropriately (this might justify renaming the script).
Line 87: Line 73:
== Comments ==  * Is modularization of icons also considered? I mean many icons are based on or variations of say folders or disks. So when the folder icon gets changed, do all the variations (folder-new, folder-home, ...) also have to be changed?
  * ''DanielHolbach:'' No, the spec concerns only the process of producing the `ubuntu-artwork` package from said icon master sheets.

Summary

A set of scripts will be written and/or changed to automate the artwork process, from cutting out the icons to building a test package and showing an overview of the changes that went in.

Please note: this spec can only be implemented by a Canonical employee. If you want to help out somewhere, it'd be better to pick another spec.

Rationale

Doing ubuntu-artwork updates is currently highly manual work and requires time and concentration. Most parts of it could be automated.

Use cases

  • Icon designer Dave worked hard to improve a batch of icons and sends the master sheets to his Ubuntu contact. It only takes a little while until he can see all the icons in action.
  • Package maintainer Daniel is close to a deadline and needs to update the artwork package. He does not need to do somersaults to get all the changes in.

Scope

The changes will involve

  • splitting of the ubuntu-artwork package,

  • changes in the existing scripts for processing icons.
  • some new scripts will have to be written to do additional tasks in updating the build system, for creating symlinks and visualizing changes from the old to the new artwork package.

Design

The first step will be to split human-icon-theme from ubuntu-artwork.

The implementation of the update functionality will run through two phases. The following table depicts which steps are to be automated and which may be done later.

Explanation: MUST goals will be adressed during this spec, everything else may be automated, but it's not strictly necessary.

Step

MUST goal

run gimp on .psd files, remove informational layer, save as .png file

NO

run strip-icons on iconprio.csv

YES

run strip-icons on whitelist.csv as well and automatically uuencode, uudecode where needed

NO

generate symlinks as specified in the CSV files

YES

run icon-spec-rename on them

YES

get last human-icon-theme package

YES

replace old icons with spec-renamed icons

YES

run update-Makefile.am on the icon directory

YES

some icons had to be edited manually (could be done via blacklist - but that has to be checked as well)

YES

we had chosen a wrong name (ok, needs to be fixed in the .csv files, but I noted it mostly during this stage)

NO

pbuild it

YES

check the debdiff of the two packages to see missing files etc

YES

go through iterations of the above

NO

Implementation

  1. Split ubuntu-artwork into:

    • human-icon-theme

    • human-wallpapers

    • human-splashscreens

    • human-theme

    • human-gdm-theme

    This will make updates smaller and easier (as the individual build systems will be less complex as a whole). ubuntu-artwork will be merely a meta package and ship default files.

  2. Write a script which will
    • make use of the existing scripts and call them in succession,
    • pay attention to a blacklist to not overwrite icon which where specifically changed (smaller sizes, etc.),
    • run the build process of the package in pbuilder,
    • show the changes between the new and old package.
  3. Write a script, which reads the information contained in the iconprio CSV files and generate symlinks where specified.
  4. Enhance the update-Makefile.am script to be able to add new Makefiles where needed and change configure.ac and index.theme appropriately (this might justify renaming the script).

BoF agenda and discussion

  • Is modularization of icons also considered? I mean many icons are based on or variations of say folders or disks. So when the folder icon gets changed, do all the variations (folder-new, folder-home, ...) also have to be changed?
    • DanielHolbach: No, the spec concerns only the process of producing the ubuntu-artwork package from said icon master sheets.


CategorySpec

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