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? 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). 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
