Forgot to reply to all! On Thu, Oct 8, 2009 at 10:45 AM, Nicola Pero < nicola.p...@meta-innovation.com> wrote:
> > > It would undoubtedly be good to have some packager-specific > > documentation, but obviously the target readership is a very small > > group .... > > We *do* have packager documentation, in > > core/make/README.Packaging > > Feel free to add a short section about what was discussed here. :-) > I saw Richard committed something there. This is really the first time I've ever heard of GlobalDomain.plist, and will not forget it. > >> - How does this allow a packager to install and remove defaults as > >> part of package installation / uninstallation? Presumably you can > >> use plmerge to install them (again, is this documented anywhere?), > >> but how do you uninstall them? > > I agree with Richard's later suggestion that the package system might deal > with that > by having a directory where each package installs a .plist upon > installation, and removes > it upon deinstallation. At the end of each package > installation/deinstallation, the > package scripts could do a plmerge so that all the currently existing > .plists in the > directory are plmerged to create the global default plist, which is hence > kept up-to-date. :-) > > That said, it should probably be used with restrain ;-) > > Presumably you have a specific example in mind where it makes particular > sense (Etoile ?); but > in general, I personally don't see a reason why installing a package should > change some system defaults. > Installing a package doesn't necessarily mean enabling it. > > Eg, I could be installing 10 or 20 themes or other GNUstep GUI-changing > bundles, but that doesn't mean > every theme that is installed must be trying to force all users to switch > to it. I'd expect to have > a Preferences panel somewhere where I can change my own user defaults and > activate/deactivate the bundles > or themes I want/don't want. Different users might activate/deactivate > different bundles. > I agree with you, but the packager/distribution developers need to know what they want. For example, in Debian when I install "gnome-core" I get nothing but a plain GNOME desktop with no theming (default GTK theme), but when I install "gnome" I also get a few themes and theme engines installed but only 1 is sets Clearlook as the default theme. If the themes are installed separately (outside the "gnome" package) nothing happens, they're just installed and it's up to you to do something. Similarly, a "gnustep" package might want to install some core packages and an "etoile" package install Camaleon and it's themes and set 1 of them as default, setup horizontal menus, etc. So I think it is more important to have a very good preference application > that allow real users > to configure their environment to suit their needs, including turning > on/off bundles or extensions. :-) > > Thanks > By the way, is anyone keeping notes so that this won't all disappear after the discussion dies down? What I've gotten so far is: * Seems to be a consensus in keep GNUstep with it's default theme. GlobalDomain.plist allows packagers or distributions to global define their theme if it pleases them. * Everyone seems to want a new website. Content needs to be looked over because there is a lot of old and outdated information out there confusing newcomers. ** On the same topic, people also seem to be getting detracted by the decentralized information about GNUstep. * Packages, packages, packages. Last I heard we lost the person who did the packages for the Debian project (which is really bad). I've also been slacking on the Slackware packages (lack of time and a dedicated "play" computer). * Code beautification? Anything I missed so far? Stefan
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
