gnustep-dev
[Top][All Lists]
Advanced

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

Re: SystemPreferences


From: Dennis Leeuw
Subject: Re: SystemPreferences
Date: Sat, 25 Feb 2006 11:47:28 +0100
User-agent: Debian Thunderbird 1.0.2 (X11/20051002)

Hi Matt,

Matt Rice wrote:
Hi Dennis,
not sure if this is similar to what Chris had in mind
though i'll throw in my opinions
I would say /{System,Local}/Library/<AppName>/
though it is probably better suited to the
ApplicationSupport/<AppName> given the current file
system layout

(though IMHO Library/ is what ApplicationSupport/ and
the stuff in Library/ currently should be in
Library/GNUstep or something for local root and just
Library/ for system root possibly, this is a whole
other conversation though)

I am not so much in favour of an ApplicationSupport directory. I do not understand it from a design point of view. If you want a design where a folder is the application you should put as much as possible within that folder. Not starting to re-invent the /usr/share directory... more below :)


the problem with Library/Bundles is its a catch all which contains a bunch of completely unrelated things

Yep, but we are talking (I think) about two things. Bundles that are shared amongst applications and Bundles only related to one single App.

The ones that belong to one single app I comment on below, the ones that are shared are a different story. To make a little comparison. You do not also create a Libraries/Images dir for libs that do image handling and Libraries/Sounds for sound related libs. They are all placed within the same dir.


i've forever been in favor of removing Bundles/
altogether though probably not vocal about it

so no not /System/Library/Inspectors

/System/Library/Foo/Inspectors/
/System/Library/Bar/Inspectors/

But then why shouldn't it be just part of the Resources dir like:
Foo.app/Resources/Library/Bundles
You keep the "what is it" logic, but if the "thing" is only used by the application it is stored with(in) the application.

Which imho makes more sense.


so each app would be in charge of its own heirarchy in
the Library dir and not dependent the correct
Library/<SomeTypeOfBundle> existing
though again IMHO this should be relegated to third
party stuff, and stuff which is required/default
mostly belong in the app's resources itself to allow
for the mythical cp -r/drag and drop installation

otherwise if we have something like

/System/Library/Applications/Foo.app
/System/Library/Bundles/SomeFoo.bundle
/System/Library/Bundles/FooExample.bundle
/System/Library/Documentation/Foo/

we just have a normal unix heirarchy with a bunch of
capital letters and stuff, (things from the same
components split into many places) where we're kindof going for Foo.app
Foo.app/Resources/SomeFoo.bundle

and copy Foo.app to Library/Applications

Foo/FooExample.bundle
Foo/Documentation/ and optionally Foo/ to Library/

or something

To complete it it would imho even be better to have
Foo.app/Resources/Library/Documentation
Foo.app/Resources/Library/Bundles/
Thus keeping the Bundles dir, only on another level. The Bundles dir shows a "what kind of component is this" from a system/programmers point of view. Because the user should be kept unknowing of how a system works. She should never enter the Foo.app dir. Everything within that directory is only relevant for the developer(s), so on that level it is important to know what we are talking about, Libraries, Frameworks or Bundles.

I think that everything that is not "shared" amongst other applications and is only relevant for a single app, should belong in the App Resources dir.

I think the idea is to have a toplevel structure where you find Tools, Applications and Library. Where Library contains the "shared" resources. If something is not a shared resource it should be placed in the Foo.app/Resources dir in which the toplevel structure is shown again, like
Foo.app/Resources/Tools
Foo.app/Resources/Library
Foo.app/Resources/Applications

Although Applications is most unlikely, I can imagine that the Tools dir is there (something like the libexec directory).

Another way is to regard Resources equal to Library, but that would break the overall logic.

From a users/developers point of view (what do I expect when I have never seen the system before and how do I get quickly familiar with the system) the holy three Applications, Library, Tools should appear everywhere imho.

Greetings,

Dennis



--- Dennis Leeuw <address@hidden> wrote:


Hi Chris,

Would this also mean the we need a
/System/Library/Inspectors /System/Library/Finder /System/Library/TextConverters /System/Library/GSPrinting just no name a view others that are falling in the same category.

Or am I somehow missing the point here?


Chris Vetter wrote:

Hi,

just a thought, but wouldn't it make sense to

store SystemPreference
modules somewhere else instead of

/System/Library/Bundles/ like
/System/Library/Preferences/ or sth similar?

I know, technically, they ARE bundles, but then

again, "logically" they
are system preferences and IMHO should be set

aside from regular bundles
that are loaded during

application/backend/whatever startup. Makes sense?



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com


--
"It is not necessary to change.
 After all, survival is not mandatory."
        Dr. W. Edwards Deming




reply via email to

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