On Tue, 2008-04-01 at 19:15 +0200, Mathias Bauer wrote:
> Hi,
>
> yes, using attributes is highly recommended!
> Besides that it seems that some attributes are already part of one of
> the property value sequences ("Collate" at least, IIRC). That should
> be
> checked.
>
> But why should we call this "XPrinterPicker"? Perhaps we should devide
> this interface into two, one that contains all attributes and another
> one derived from the first one containing the dialog specific parts
> (parent and whatever else). This way we also get an interface for an
> object we can use to transport printer settings (instead of using the
> whole dialog).
http://api.openoffice.org/docs/common/ref/com/sun/star/view/PrintOptions.html
http://api.openoffice.org/docs/common/ref/com/sun/star/view/PrinterDescriptor.html
We do have at least have those pair of PrinterDescriptor and
PrintOptions muddle of properties (mentioned in the idl) and so from
that pov the num of copies, collation and pages set/get can certainly be
removed. Though there aren't existing mechanisms (or are there ?) for
the rest of the settings, e.g "All" and "Selection" etc. which are
currently passed around as part of the current "PrintDialog" and queried
and set on it.
FWIW as far as I can tell what's listed here at least serves as a
reference for what is current directly queried from the PrintDialog
itself that is shown and then passed about the place inside OOo when
printing is requested.
Though as pl points out there is a whole other pile of messy crap that
is associated with a printjob and printer sort of bolted onto the side
more of less out-of-view of the current PrintDialog that needs to be
addressed somehow. (and for myself in the long run to integrate our
gtk-unix-print work I'd like to bolt on *even more* to propagate cups
options all the way down from the dialog)
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
