|
From: Brian H. <br...@ab...> - 2003-06-12 14:48:15
|
> > - 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 ? Yes, that's right. Paths are UNIX style. I can update this if it's needed. It's pretty low on the priority list for now. > Would it be far fetched to find or provide these 3rd party libraries as frameworks too > ? Just a suggestion though ... I would rather not do that. That'd be quite a lot more work to maintain, and I am pretty sure it's not really required. The end-users of NGL (other developers, not end-users of NGL applications) should need only NGL.framework and the PB template to create NGL applications. That's my goal. > > 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. Ah, great! > 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. The "pimpl" C++ idiom seems apropos. http://www.gotw.ca/gotw/024.htm Thanks, Brian Hammond [http://threeminutehero.com] |