Re: [NGL-devel] OS X Updates

[Vincent C. <v....@ze...>]

Brian Hammond said:
>
> - PB project for creating an OS X framework based on Carbon is done
>
>     - Using UNIX versions for Carbon implementations of a few NGL
>       interfaces (nglFile, etc)... for now.

OK, I guess it means file paths can't use Mac style 'volume:' and we can't read
ressource forks, something like that ?


> - PB project template for creating "NGL Application"s is done; this
>   embeds the framework and links application code to NGL framework code.

Very cool, we never managed to get this done for MSVC or Unix.


> - Shell scripts to install the external libs required for building the
>   NGL.framework are done (FreeType 2.1.4, libjpeg 6b, libpng 1.2.5, and
>   zlib 1.1.4).

Would it be far fetched to find or provide these 3rd party libraries as frameworks too
? Just a suggestion though ...


> The idea of the NGL.framework would be to give end-users of NGL a PKG
> that they can double click to install a developer version of the
> NGL.framework and the PB NGL Application template.  I don't want them to
> have to deal with installing the external libs (FreeType, etc),
> including the search paths in every project, etc.

Obviously a great idea, but then I stick to my previous question, would it be still
easy to use if these 3rd party libraries were distributed as frameworks ? This could
be a long term idea, as I guess becoming the Mac maintainer for a bunch of other libs
is not your top priority :)


> This is doable as long as the NGL headers do not reference
> implementation details.  I was kind of surprised that the nglFontBase.h
> includes FreeType headers (USE_FREETYPE).  I would think that for a
> public interface, it should be free of any impl details... IMHO that's
> much cleaner and also allows the OS X NGL developers to not have to
> install _any_ external libs (and their headers) to build NGL apps.  I
> have a lot of notes on this if anyone is interested.

Yes, this is ugly, we actually delayed the configuration part for a long time. It once
had a better support (18 months ago ?).

For the USE_ macros, they will all definitively move in a private and non-distributed
header, and since you need it now we'll try to do this quickly.

For the dependencies on other libs dependencies, it will require some work, mainly on
FreeType (the image codecs have a well separated internal interface). C++ can quickly
become ugly when we have to use tricks to hide internal things, and I only stuffed
this info in 'private:' for now. If you have any suggestion to make this move not too
painful, I'm interested.

I know we could go the COM way, but : we keep it simple and stupid, and we never asked
the user to do things like nglFont::Build() and nglFont::Release(). I'd really prefer
not going that way.


> - Documentation for the NGL.framework maintainer (me) with all the funky
>   steps (-seg1addr, @executable_path/../Frameworks, etc).

Rare maintainer quality, documentation ! Way to go