Chris Vetter wrote:
On 2006-02-24 11:07:47 +0100 Dennis Leeuw <[EMAIL PROTECTED]> 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?
I don't know ;-)
As I said, this was just a thought, and *I* could probably be mistaken.
The way I see it is that Bundles are part of an application, that could
possibly be used by other applications as well. For example, think of a
web browser that has a generic history manager in a bundle. An FTP
client could re-use said bundle for it's download history. (Stupid
example, but you get the idea).
Actually it explains what might be a generic Bundle and thus belongs to
the domain System/Library/Bundles...
OTOH, a preference pane of SystemPreferences is different, IMPOV. Sure,
it is implemented as a bundle, but its only purpose is to provide a
"service" in/to SystemPreferences and no other application _should_ use
it (of course they could, but I do not see a point in doing so).
Where as this does not. It should be part of
SystemPreferences/Resources/.../Bundles
(where .../ is whatever is decided on to be the path to the "internal"
Bundles dir (currently I think it is Resources/Library/Bundles... I
can't check 'cause I am installing from scratch)
So, the only reason for storing preference panes NOT in .../Bundles/ is
to distinguish between a 'real' bundle and a pref-pane. IMHO, this would
make the Library directory look a bit 'cleaner.'
I agree with you on the cleaner part. Just not sure where the panels
should end up.
Question to the OSX users -- how/where does OSX store pref panes? Maybe
we could/should just mimick their setup.
Yeah... let's hear it boys and girls. How does our big brother solved
this issue? ;)
Dennis
--
"It is not necessary to change.
After all, survival is not mandatory."
Dr. W. Edwards Deming
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
