Re: Templates? (was Re: [XaraXtreme-dev] XCode - The main goal)

[Alex Bligh <alex@xxxxxxxxxxx>]

Ben,

> The first thing that my code does is to open the wx Memory Zip
> Filesystem or stream, and try to open '800 by 600 drawing.xar' which
> fails, and I think that nothing else is tried.

It is correct that nothing else is tried, because in getting the filename,
it already checked the file did not exist on disk (if you passed a "-r"
line).

However, the path should have the underscores in it, not spaces. If they
aren't there, we have found the problem.

> I accept that I may be misunderstanding something, but my first
> thought is that without the spaces/underscores, the Darwin code could
> open 'default,xar' from memory/resources perhaps owing to a bug
> somewhere which has now been fixed; but it cannot open the present
> default file.

Does MacOS do substitution of "," for "."? That could certainly cause
it. Spaces in filenames also cause problems which is why we try and
avoid them.

> > Just checked it here. See what pFileName
> > contains when you go into the function (remember it's
> > a pointer to a UNICODE null terminated string). The
> > "Templates" version is only used by the installer
> > (which you aren't using). The difference in size is that
> > the Templates version is a xar file with compression on,
> > and for various tedious reasons the binary one is not
> > a compressed .xar file (though the whole resources are
> > zipped).
>
> It is (TCHAR *)"800 by 600 drawing.xar" where each character is 4 bytes.

OK. So we need to find out where the underscores went. It should come
from IDS_DEFAULTDOCNAME, in rik-strings.xrc. Unless Luke is doing something
cleverer. On Linux, it has the underscores in, and hence works.

> I am not saying that I understand every word of that, but I have seen
> it try to open the Filename through 'memory:resources#zip' and fail. I
> have seen it look for '800 by 600 drawing.xar' when
> '800_by_600_drawing.xar' was present.

This sounds like it is the filename generation that is problematic.

Note that it isn't looking for it on your MacOS/OS-X file system,
but a virtual file system run by wx. By "path" I mean path within
the virtual filesystem - it should read (as I said) something
like "memory:resources#zip:800_by_600_drawing.xar".

AHA! A clue! I notice that in the menu the "D" of "Drawing" is
capitalized as is the "B" of "By". I can't figure where this capitalisation
came from unless something is bound in the code. Perhaps you might check
for that. Perhaps MAC Zip files are case sensitive and GTK ones aren't.

> I will do that in a second or two, it is a good idea. Note that
> Resouces whether OS X or any other kind can conveniently be placed in
> the application bundle one level up from the executable. This is the
> origin of wierd strings starting "@executable_path/../"; it is
> possible that we need no longer draw a distinction between OS X
> resources and resources in general. Placing Resources in the
> application bundle ensures that they are 'always there' and can be
> conveniently installed and uninstalled by end users. The other ideal
> place for them is the User's ~/Library/Application Support/ directory
> - I will need to check, but it is not unreasonable to assume that that
> directory is writeable, but that the application bundle is not.

Well they are definitely always there if they are bound into the
executable (which is what currently happens - it's compiled in by
being converted to a C file full of hex). I agree on MacOS using the
native way may be better but this works cross platform and I don't
see a good reason to change it right now. It looks like it's not the
(virtual wx) filesystem that's the problem (unsurprising, as it
loads everything else fine), but the generation of the filename.

Alex