From: Till Kamppeter <till.kamppeter@gmail.com>
To: "Hal V. Engel" <hvengel@astound.net>
Cc: printing-architecture@lists.linux-foundation.org
Subject: Re: [Printing-architecture] Another Common Dialog
Date: Fri, 17 Apr 2009 22:55:43 +0200 [thread overview]
Message-ID: <49E8ECCF.8050700@gmail.com> (raw)
In-Reply-To: <200904171232.16547.hvengel@astound.net>
Hal V. Engel wrote:
> On Friday 17 April 2009 11:54:28 am peter sikking wrote:
>> Till wrote:
>>> peter sikking wrote:
>>>> for users printing, faxing, scanning, memory card reading are
>>>> totally unrelated activities.
>>> I would say so, too.
>> it is not just a good idea, it is the truth.
>>
>>> Sending faxes should be done by a print queue where the printing
>>> dialog shows an appropriate widget for the fax number.
>> even that is mind-boggling incomprehensible for users.
>> I will fight tooth and nail to avoid that solution.
>>
>
> I also agree with Peter here. A user sending a fax expects to see fax
> specific dialogs. Till however is correct that hidden below that fax specific
> UI could be a print queue but the user should NEVER be aware of how it is
> actually implemented.
So fax should look like this: On the implementation side we have print
queues for faxes, the PPD files of fax queues contain the following CUPS
extension:
*cupsFax: true
(see http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html). This
allows distinguishing print queues and fax queues. Applications are
supposed to have a "Print ..." and a "Fax ..." entry. If a queue type
(printing, faxing) is not present, the corresponding menu entry gets
grayed out. Clicking "Print ..." gives the printing dialog as Peter has
designed it, but only print queues (and no fax queues) are listed.
Clicking "Fax ..." gives a dialog (slightly) different to Peter's
printing dialog, for example with an additional "zone" with one or more
widgets to choose the fax destination (by typing in, calling address
book, ...) and only the fax queues listed. The exact design for an ideal
fax dialog can also be left to OpenPrinting. WDYT?
Till
next prev parent reply other threads:[~2009-04-17 20:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 18:21 [Printing-architecture] Another Common Dialog Petrie, Glen
[not found] ` <4B3C1712-1367-404C-B77B-E7C5E5110C28@apple.com>
2009-04-16 21:35 ` [Printing-architecture] [Printing-summit] " Petrie, Glen
2009-04-16 21:50 ` Till Kamppeter
2009-04-17 18:21 ` [Printing-architecture] " peter sikking
2009-04-17 18:38 ` Till Kamppeter
2009-04-17 18:54 ` peter sikking
2009-04-17 18:58 ` Petrie, Glen
2009-04-17 19:32 ` Hal V. Engel
2009-04-17 20:55 ` Till Kamppeter [this message]
2009-04-18 9:57 ` peter sikking
[not found] ` <200904172344.n3HNivf6025718@dsl092-065-009.bos1.dsl.speakeasy.net>
2009-04-18 9:39 ` [Printing-architecture] [Printing-summit] " peter sikking
[not found] ` <alpine.LNX.2.00.0904211009120.29424@nelson.suse.de>
2009-04-21 9:09 ` peter sikking
2009-04-21 9:14 ` peter sikking
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E8ECCF.8050700@gmail.com \
--to=till.kamppeter@gmail.com \
--cc=hvengel@astound.net \
--cc=printing-architecture@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.