On 17.04.2009, at 15:25, Niko Schwarz wrote:
On Fri, Apr 17, 2009 at 8:53 AM, Rainer M Krug <r.m.k...@gmail.com>
wrote:
1) I like the lyx format as it is BECAUSE it is not compressed, so I
would definitely not change the default format.
Ok, maybe I didn't make myself clear: you can have self-contained
archives
with no compression at all on OSX. It works like this: you make a
directory
and in that directory you dump a special file that tells finder to
display
the directory as a package.
But from the command line, it is still a directory. And in finder,
you can
look into the package by choosing "Show Package Contents" from the
pop up
menu.
Now Pages files for example come as such "packages", you can copy that
directory around, send it through email (yea, email clients handle it
surprisingly well), and it still works.
Now, other operating systems see a directory and not a package.
People using
something other than OSX would have to be reminded to copy the
directory
around the .lyx file around, which would be managed by lyx.
The file would still be accessible, no performance penalty, but
complete
send-aroundability, and while it might feel a little alien on other
OS's, on
OSX it's the standard way to do such things, so OSX users will cheer.
No, they won't.
The thing is that OSX -- or at least the OSX applications that use
this concept, with Pages being a good (well, bad) example -- do *not*
treat packages as true directories, but as a "personal container".
Whenever you save a Pages document, for instance, Pages deletes
everything in the "directory" that was not created by itself. This can
be quite surprising! Pages might also decide to rename its files in
the directory. And so on.
All tools that need to manage side-by-side metadata in directories
(such as CVS and SVN) are inherently unusable with OSX apps that use
the package format. You just cannot put a Keynote presentation into an
svn repository...
Packages are one of those OSX standards that are conceptually nice,
but unfortunately seriously broken in the actual implementation.
Daniel
