Information about platform dependant instantiation

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: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org

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: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org

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: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org

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: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org

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: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org

Do you mean to create a new project for each platform
dependant dialog ?

2007/5/14, Philipp Lohmann <Philipp.Lohmannsun.com>:

>
> 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