>Till Kamppeter wrote:
>> Michael Sweet wrote:
>>>
>>> 2. Use the supplied APIs to get the available drivers and
>>>devices. Right now each distro seems to be maintaining
>>>their own (insert your buzzword) database of printer
>>>drivers rather than asking CUPS for a li
Am Dienstag, 20. Dezember 2005 20:47 schrieb Michael Sweet:
Hi Michael,
> That said, it is unlikely that the generic print dialog proposed here
> will be used by more complex printing applications that provide custom
> options and dynamic previews (i.e. drag the object you are printing
> in the p
Am Dienstag, 20. Dezember 2005 20:33 schrieb Mike Shaver:
Hi Mike,
> On 20-Dec-05, at 1:26 PM, Martin Konold wrote:
> > E.g. KDE offers a file open dialog with preview capabilities. This
> > capability
> > is build into the dialog without a call back to the application
> > calling the
> > dialog.
On 20-Dec-05, at 2:47 PM, Michael Sweet wrote:
This particular discussion is for the file dialog, not the print
dialog.
Ahem, yes. *blush* I'd blame the Subject line, but that would be petty.
That said, it is unlikely that the generic print dialog proposed here
will be used by more complex p
Mike Shaver wrote:
On 20-Dec-05, at 1:26 PM, Martin Konold wrote:
E.g. KDE offers a file open dialog with preview capabilities. This
capability
is build into the dialog without a call back to the application
calling the
dialog.
But when the user changes the paper size, or changes from portr
On 20-Dec-05, at 1:26 PM, Martin Konold wrote:
E.g. KDE offers a file open dialog with preview capabilities. This
capability
is build into the dialog without a call back to the application
calling the
dialog.
But when the user changes the paper size, or changes from portrait to
landscape
Am Montag, 19. Dezember 2005 14:08 schrieben Sie:
Hi,
> > The reason for this is that the print dialog needs bidirectional
> > communication with the application for everything except the most trivial
> > tasks. E.g. if
>
> But what if you want a preview in the file dialog? Doesn't that
> requir
