Hi Yvan,

On Sunday 22 October 2006 17:22, Yvan Barthélemy wrote:
> 2006/10/22, Mathias Bauer <[EMAIL PROTECTED]>:
> > You are right. Perhaps it's time to create one?
>
> Probably but :
> * I have no experience yet with UNO.

Don't be afraid of that.  The usage of UNO looks a bit unfamiliar at the first 
glance for a pure C++ programmer (for me personally the overloaded <<= and 
>>= operators for the type 'Any' are clearly a misuse of overloading ;-) ), 
but you can get used to that - and it's quite powerful.

There's a lot of documentation about it, eg:

http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html
http://wiki.services.openoffice.org/wiki/Uno
http://wiki.services.openoffice.org/wiki/SDKCppLanguage

> * I am not sure about what benefits UNO will bring

UNO is a component architecture, so once you define the interface (in an .idl 
file), you can do the implementation in various ways.  This is quite 
important for the print dialog - every architecture/desktop wants to do it 
its way - Win32, MacOSX, Gnome, KDE, ...; and of course you want to have a 
nice fallback if the system way is unavailable from some reason.

Matthias is the leader of the API project, I hope he could help you with the 
interface part, or allocate someone to help you.

> * I don't know where to start and I have no idea how to achive this

This task contains:
- you have to define the interface/service
- the calls to PrintDialog methods should be replaced with the calls to the 
new service
- remake PrintDialog to be an implementation of the service
- make your own MacOSX implementation

I hope it does not sound too discouraging :-) - the Caolan's implementation 
could hopefully help you, as well as having a look at how the fpicker does 
it.

Regards,
Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to