On Thu, Oct 8, 2009 at 10:45 AM, Nicola Pero
<address@hidden> 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