Thanks for the answer Jan, In fact, what I want to do is to provide similar mechanism in svtools in order to implement a native printing dialog instead of the one provided by svtools.
My goal is to add an aqua directory where I will put Aqua Implementation specific sources. But I don't know how should I do to compile these one rather than the default one. On Friday 11 May 2007 21:33, Jan Holesovsky wrote:
On Friday 11 May 2007 21:06, Yvan Barthélemy wrote: > I have seen that some classes are platform dependant and have > different names (ex: SalGraphics has AquaSalGraphics and > WinSalGraphics). > > I wonder where (in which files), the build system can determine to use > one implementation rather than an other, and how it is able to guess > that the Mac OS X implementation of SalGraphics is called > AquaSalGraphics since there is no call for new AquaSalGraphics in the > code. It is not? I guess you use aquavcl01 [otherwise you wouldn't have AquaSalGraphics at all ;-)]; so have a look at AquaSalVirtualDevice::AquaSalVirtualDevice() in vcl/aqua/source/gdi/salvd.cxx, or at AquaSalFrame::GetGraphics() in vcl/aqua/source/window/salframe.cxx, you can see mpGraphics = new AquaSalGraphics(); there.
Interesting, but now, I want to know where AquaSalVirtualDevice is instancied, and this recursively until I reach a platform independant instanciation, since AquaSalVirtualDevice and AquaSalFrame are still platform dependant. I don't know if I am really clear... It doesn't help me to replicate the implementation choose mechanism...
For the other platforms it is very similar, or even more complicated - in the unx case where there are more plugins available [for gtk+/gnome, Qt/KDE, and plain X]. The last piece of the puzzle is that */prj/build.lst defines which subdirectories are built on which platform. Regards, Jan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
