On Thu, Jul 12, 2012 at 12:38:46AM +0200, Ulrich Hansen wrote: > Am 11.07.2012 um 15:36 schrieb Paul Tagliamonte: > > > On Wed, Jul 11, 2012 at 10:06:02AM +0200, Josselin Mouette wrote: > >> > >> > >> While the later part (one package per theme) is a good idea, I think > >> that splitting the plymouth, gdm, kdm etc. stuff is wrong. You’re bound > >> to end up with stupid dependencies. > > > > Whoh, right here. There's only src:theme-defaults, not binary -- there > > will be no cenetral package in my brave new world. If you need the GDM > > stuff, use the GDM metapackage, if you need the KDE stuff, use the KDE > > metapackage. > > > >> I find it much better to simply ship every theme in a single package > >> that holds a theme for all supported stuff. Especially given that some > >> pieces of the theme might be shared between several components. > > > > I think this is quite hard to decide. As I understand it, Paul suggests a > simple "artwork package" like "theme-foo-gdm" that relies on a > "theme-default-gdm" package that provides the architectural structure, > symbolic links, alternatives etc. > > Josselin on the other hand suggests single packages. That comes close to the > "desktop-theme-packages" Ronoaldo and me are currently experimenting with. > [1] > > Based on that experience, I am not really convinced that splitting and > sorting packages by the software they deal with is such a good idea. Okay, > one user installs gdm3, the other one kdm so most of them won't need both. > But who needs kdm will most certainly also need ksplash and the kde4 plasma > theme and default packages. And everyone needs grub (and no one uses > grub.themes ;-) ).We also didn't really talk about lightdm/kde4 combinations > etc. So this means building a LOT of packages that all have to play nicely > together. > > From a developers point of view this seems also a bit too complicated: As I > see it, alternatives are a great interface for theme packages to deal with, > instead of configuring stuff directly (the latter wouldn't work with multiple > theme packages anyway). So IMHO it's a good idea to use common alternatives. > In our experimental theme package, gdm3, kdm, grub-theme, plymouth and the > gnome-lockscreen use the same picture, provided by the alternative > "desktop-login". So, in the wheezy+1 vision, which package would be in charge > of that alternative? >
alternatives can be added by many packages, just btw > On the other hand I agree with Paul that artwork themes should be simple. > That WILL not be the case, if every package itself has to talk to grub, > plymouth, kdm, ksplash, kde4, gdm3, gnome stuff, etc. (even by using > alternatives). Because we have a moving target. And I don't mean by that, > that the software is developing (which also is the case, as we see with > gnome). OK, this is inherently not easy for us as developers. My plan has a lot of paperwork and a lot of effort. However, it solves this (IMHO major) problem. Here's a story: Joe-bob works for Foocorp, which uses "nihde" as their DE. "nihde" can run apps as "widgits", and the theme they wrote for their installs happens to have a theme that uses "xblerg". The theme is so brilliant they want to share it with all Debian users, so they upload it. Now, the situation: Does theme-foocorp depend on xblerg? Remember, by default Debian doesn't use nihde, so we don't need it for most cases. If we assure xblerg (which happens to be 1.4 gigs of glorious userspace) is on the system in the one big megapackage, it screws a lot of installs with a huge useless app. If we don't it causes breakage. With my solution, the answer is clear. As is, there is no good answer. > > I mean that we now have a USER that "messes" stuff up for us ;-) > > Desktop-base has been installed together with Debian. Theme packages on the > contrary are installed whenever somebody (root) wants a new theme. So here's > an example of what that means, fresh from experience: > > Example: KSplash > > desktop-base installs > usr/share/desktop-base/profiles/kde-profile/share/config/ksplashrc to set the > joy theme. [2] > > In a fresh install of Debian this works. Great. > > But once KDE has been started by the user, the KSplash setting is saved in a > file in the users home directory: > > /home/*/.kde/share/config/startupconfig > > So now if you want to install another "theme-package" after the first > package, changing > usr/share/desktop-base/profiles/kde-profile/share/config/ksplashrc alone > wouldn't have an effect any more. Even the first package wouldn't work if the > user had already once logged into KDE before the install. So you have to > change the users startupconfig too. > > But it comes worse. > > If the user decides to change the KSplash theme with the GUI (KDE System > Settings - Workspace Appearance - Splash Screen), for these settings a THIRD > configuration file is created: /home/*/.kde/share/config/ksplashrc. > > So a "theme package" that is supposed to be installed in Debian at any later > time than system install needs to be prepared to change all three files. Just > for KSplash. > > And KSplash also has a picture cache at > /home/*/.kde/cache-*system-name*/ksplashx/*. I didn't have problems with that > yet, but they may occur. At least with KDM and the KDE background, clearing > the cache is a pretty good idea if you want the user to see the effect of > your theme package. > > Changing the KDM theme is of similar complexity. [3] > > Of course it would be great if the Debian KDE team would come up with a > simpler interface for Debian packages to control and override system themes > (KDM, KDE plasma desktop, KSplash). > > But as long as they haven't, a theme package would have to deal with quite a > lot of conf files and it also would have to change user settings. Which is OK > for me because that's another BIG difference of theme packages to > desktop-base: Desktop-base is installed by default and so it has to be VERY > reluctant to change user settings. Desktop-themes are installed with the > PURPOSE of changing the system-wide artwork, they are installed completely > voluntarily, by root. So it is the job of the package to actually do the > changes. Otherwise it is broken. > > So all in all this is complicated stuff. If this is going towards single > theme packages it would be good to find an easy way to reproduce (clone) all > the changing technical infrastructure into every single theme package, so we > don't have so much work with each of them. With variables or whatever. > > Or we have indeed a "default" package that builds the infrastructure and > alternatives (for all software, I would suggest, Grub, KDM, GDM3 etc.). And > simple artwork packages that just copy the artworks and themes into > predefined places and update alternatives. I am really undecided. > > The theme-packages Ronoaldo and me are doing are somewhere in between: They > still have a lot of architectural stuff inside, but they also still depend on > desktop-base. I uploaded a new version today, and I am a bit proud to to add: > They work. > > best wishes > > Ulrich > > > [1] https://bitbucket.org/ronoaldo/desktop-theme-growing > > [2] BTW: Unfortunately this means the initial KSplash setting can't be > configured through alternatives. So IMHO it would be really great if this > could be changed one day. I would love to provide a very simple patch. > > [3] An example: If the user installs a KDM theme by GUI (KDE System Settings > - System Administration - Login Screen - Themes) the setting is saved in a > file /etc/kde4/kdm/kdmrc. Although the line in the original version of that > file clearly states "Theme=@@@ToBeReplacedByDesktopBase@@@"! So that's > another file a theme package has to change. > -- .''`. Paul Tagliamonte <[email protected]> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
