[Top][All Lists]
[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