[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes I've been thinking of...

From: Gregory Casamento
Subject: Re: Changes I've been thinking of...
Date: Fri, 9 Oct 2009 14:23:00 -0400


This does seem to be the consensus....

Now we need help to actually make it happen.


On Thu, Oct 8, 2009 at 7:30 PM, Stef Bidi <address@hidden> wrote:
> Forgot to reply to all!
> 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
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev

Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]