Information about platform dependant instantiation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Information about platform dependant instantiation

Yvan Barthélemy
Hello,

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.

Thanks for information,
Yvan BARTHÉLEMY

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Information about platform dependant instantiation

Jan Holesovsky
Hi Yvan,

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.

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Information about platform dependant instantiation

Yvan Barthélemy
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Information about platform dependant instantiation

Yvan Barthélemy
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Information about platform dependant instantiation

Philipp Lohmann
In reply to this post by Yvan Barthélemy
Yvan Barthélemy wrote:
> 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.

Pardon, but I think that is not a good idea. It is true that there are
some platform dependent files left in svtools for historical reasons,
however the better approach to do a native dialog is like the file
dialog already does, that is via an own UNO service. We should strive to
contain system abstraction to as few modules as possible.

Also replacing the print dialog may not be as easy as it sounds since
the PrinDialog objects are currently passed around in the application as
a kind of container for print settings.

Just my 2 cents, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
      -- Author unknown

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Information about platform dependant instantiation

Yvan Barthélemy
Do you mean to create a new project for each platform dependant dialog ?

2007/5/14, Philipp Lohmann <[hidden email]>:

>
> Pardon, but I think that is not a good idea. It is true that there are
> some platform dependent files left in svtools for historical reasons,
> however the better approach to do a native dialog is like the file
> dialog already does, that is via an own UNO service. We should strive to
> contain system abstraction to as few modules as possible.
>
> Also replacing the print dialog may not be as easy as it sounds since
> the PrinDialog objects are currently passed around in the application as
> a kind of container for print settings.
>
> Just my 2 cents, pl



Yb