2007/5/12, Jan Holesovsky <[EMAIL PROTECTED]>:
Hi Yvan,
As Caolan already wrote you
(http://gsl.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=1905), he did
an implementation of Gtk+ print dialog; very probably it is a better starting
point than AquaSalGraphics...
I didn't want to use that as a starting point, but as a model to replicate.
As I already wrote you ;-)
(http://gsl.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=1901), in the
long run, the agreement is that it would be best to UNOize the print dialog,
similarly to how the file dialog works. Maybe you could try to do a
proof-of-concept implementation using Caolan's work?
I don't really understand whether I should do a proof-of-concept of
Caolan's work using UNO, or a proof-of-concept of Aqua printing dialog
inspired by Caolan's work.
However, I don't understand the benefits provided using UNO rather
using the coding template used by Sal (i.e. system-dependant
subclasses)
The hardest part on this is not the layout or whatever, the hardest part is to
design the API so that it is usable by the old code, and by other
implementations (Gtk+, Aqua, KDE, ...) as well.
I totally agree that.
grep and find are your friends. Or - of course - you can run OOo in a
debugger, set a breakpoint eg. where the AquaSalFrame is created, and look at
the backtrace.
I found that a function having the same name for all platform is
responsible of instanciating platform specific XxxSalInstance.
Thanks,
Yvan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
