From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEBF.CB8AC82D" Date: Thu, 16 Apr 2009 11:21:21 -0700 Message-ID: From: "Petrie, Glen" Subject: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter , peter sikking Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEBF.CB8AC82D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have you ever considered creating/defining a Common Status/Monitoring Dialog. CUPS may have something already but does it support multi-function devices sub-units like fax, scan, memory card, etc and can it provide the status/monitoring information on a sub-unit by sub-unit basis or as a roll-up for the entire MFD or both???? =20 glen ------_=_NextPart_001_01C9BEBF.CB8AC82D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have you ever considered creating/defining a Common Status/Monitoring Dialog.   CUPS may have something already = but does it support multi-function devices sub-units like fax, scan, memory card, = etc and can it provide the status/monitoring information on a sub-unit by = sub-unit basis or as a roll-up for the entire MFD or = both????

 

glen

------_=_NextPart_001_01C9BEBF.CB8AC82D-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEDA.EA672465" Date: Thu, 16 Apr 2009 14:35:29 -0700 Message-ID: References: <4B3C1712-1367-404C-B77B-E7C5E5110C28@apple.com> From: "Petrie, Glen" Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Sweet Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEDA.EA672465 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the inputs Michael. This provides some seeds for the implementation details. I am hoping Peter will provide similar comment for the look-and-feel of the interface. =20 Glen =20 =20 ________________________________ From: Michael Sweet [mailto:msweet@apple.com]=20 Sent: Thursday, April 16, 2009 2:18 PM To: Petrie, Glen Cc: Till Kamppeter; peter sikking; printing-architecture@lists.linux-foundation.org; printing-summit@lists.linux-foundation.org Subject: Re: [Printing-summit] Another Common Dialog =20 Due to numerous practical issues, most MFPs that support fax and print have to use two separate print queues; detecting this from the print dialog or monitoring application is fairly easy (compare device URIs and capability bits, merge queues that differ only by capabilities), and supporting this at the OS level is essential (and then you can really make things easy by creating both queues, "foo" and "foo_fax"...) =20 Scanning functionality is managed separately from CUPS at the OS level (usually SANE + a USB driver) but can be merged in the UI as long as the OS provides the necessary hooks. =20 Supporting memory cards (presumably exposed as USB mass storage or some sort of network share) is also possible, again as long as the OS has the necessary hooks. =20 On Apr 16, 2009, at 11:21 AM, Petrie, Glen wrote: Have you ever considered creating/defining a Common Status/Monitoring Dialog. CUPS may have something already but does it support multi-function devices sub-units like fax, scan, memory card, etc and can it provide the status/monitoring information on a sub-unit by sub-unit basis or as a roll-up for the entire MFD or both???? =20 glen _______________________________________________ Printing-summit mailing list Printing-summit@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/printing-summit =20 ________________________________________ Michael R Sweet, Senior Printing System Engineer =20 ------_=_NextPart_001_01C9BEDA.EA672465 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the inputs Michael. =  This provides some seeds for the implementation details.  I am hoping Peter will = provide similar comment for the look-and-feel of the = interface.

 

Glen

 

 

From: = Michael Sweet [mailto:msweet@apple.com]
Sent: Thursday, April 16, = 2009 2:18 PM
To: Petrie, Glen
Cc: Till Kamppeter; peter = sikking; printing-architecture@lists.linux-foundation.org; = printing-summit@lists.linux-foundation.org
Subject: Re: = [Printing-summit] Another Common Dialog

 

Due to numerous practical issues, most MFPs that support fax and = print have to use two separate print queues; detecting this from the print = dialog or monitoring application is fairly easy (compare device URIs and = capability bits, merge queues that differ only by capabilities), and supporting this at = the OS level is essential (and then you can really make things easy by creating = both queues, "foo" and = "foo_fax"...)

 

Scanning functionality is managed separately from CUPS at the OS = level (usually SANE + a USB driver) but can be merged in the UI as long as the = OS provides the necessary hooks.

 

Supporting memory cards (presumably exposed as USB mass storage = or some sort of network share) is also possible, again as long as the OS has the necessary hooks.

 

On Apr 16, 2009, at 11:21 AM, Petrie, Glen wrote:



Have you ever considered creating/defining a Common Status/Monitoring Dialog.   CUPS = may have something already but does it support multi-function devices sub-units = like fax, scan, memory card, etc and can it provide the status/monitoring information on a sub-unit by sub-unit basis or as a roll-up for the = entire MFD or both????

 

glen

___________________________________= ____________
Printing-summit mailing list
Printing-summi= t@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/printing-summit

 

_____________= ___________________________

Michael R = Sweet, Senior Printing System Engineer

 

------_=_NextPart_001_01C9BEDA.EA672465-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E7A822.7030703@gmail.com> Date: Thu, 16 Apr 2009 23:50:26 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <4B3C1712-1367-404C-B77B-E7C5E5110C28@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Michael Sweet Petrie, Glen wrote: > Thanks for the inputs Michael. This provides some seeds for the > implementation details. I am hoping Peter will provide similar comment > for the look-and-feel of the interface. To see which devices (scanners, card readers, printers) belong together as one MF unit, one only needs to look at the output of "lsusb -vvv" or "lshal". Till From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E8CCB8.4000201@gmail.com> Date: Fri, 17 Apr 2009 20:38:48 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> In-Reply-To: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: peter sikking Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org peter sikking wrote: > Glen, > >> Have you ever considered creating/defining a Common Status/Monitoring >> Dialog. > > for printing: sure that is the next project, together with > printer installation. > >> CUPS may have something already but does it support multi-function >> devices sub-units like fax, scan, memory card, etc and can it provide >> the status/monitoring information on a sub-unit by sub-unit basis or >> as a roll-up for the entire MFD or both???? > > for users printing, faxing, scanning, memory card reading are > totally unrelated activities. so it follows that faxing, scanning, > memory card reading is never going to be seen in a printing dialog > and also not in a status/monitoring dialog. > I would say so, too. The scanner should appear in scanning applications, memory cards should simply get auto-mounted and appear on the desktop (at least for locally connected devices, for network devices they should appear when scanning for file system shares in the network). Sending faxes should be done by a print queue where the printing dialog shows an appropriate widget for the fax number. A dialog to put these functions together is not needed. It can even get counter-intuitive if an MF device and a scan-only device is connected to the same machine. Till From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> From: peter sikking In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 20:21:27 +0200 References: Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter Glen, > Have you ever considered creating/defining a Common Status/ > Monitoring Dialog. for printing: sure that is the next project, together with printer installation. > CUPS may have something already but does it support multi-function > devices sub-units like fax, scan, memory card, etc and can it > provide the status/monitoring information on a sub-unit by sub-unit > basis or as a roll-up for the entire MFD or both???? for users printing, faxing, scanning, memory card reading are totally unrelated activities. so it follows that faxing, scanning, memory card reading is never going to be seen in a printing dialog and also not in a status/monitoring dialog. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> From: peter sikking In-Reply-To: <49E8CCB8.4000201@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 20:54:28 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> <49E8CCB8.4000201@gmail.com> Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org 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. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:58:51 -0700 Message-ID: References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> From: "Petrie, Glen" Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: peter sikking , Till Kamppeter Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Not if my function is to manage the MFD.... but memory are on the priority right now. > -----Original Message----- > From: peter sikking [mailto:peter@mmiworks.net] > Sent: Friday, April 17, 2009 11:54 AM > To: Till Kamppeter > Cc: Petrie, Glen; printing-architecture@lists.linux-foundation.org; > printing-summit@lists.linux-foundation.org > Subject: Re: Another Common Dialog >=20 > Till wrote: >=20 > > peter sikking wrote: > >> for users printing, faxing, scanning, memory card reading are > >> totally unrelated activities. > > > > I would say so, too. >=20 > it is not just a good idea, it is the truth. >=20 > > Sending faxes should be done by a print queue where the printing > > dialog shows an appropriate widget for the fax number. >=20 > even that is mind-boggling incomprehensible for users. > I will fight tooth and nail to avoid that solution. >=20 > --ps >=20 > founder + principal interaction architect > man + machine interface works >=20 > http://mmiworks.net/blog : on interaction architecture >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hal V. Engel" Date: Fri, 17 Apr 2009 12:32:16 -0700 References: <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> In-Reply-To: <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904171232.16547.hvengel@astound.net> Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: printing-architecture@lists.linux-foundation.org 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. Hal From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E8ECCF.8050700@gmail.com> Date: Fri, 17 Apr 2009 22:55:43 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> <200904171232.16547.hvengel@astound.net> In-Reply-To: <200904171232.16547.hvengel@astound.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Hal V. Engel" Cc: printing-architecture@lists.linux-foundation.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: peter sikking In-Reply-To: <200904172344.n3HNivf6025718@dsl092-065-009.bos1.dsl.speakeasy.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 11:39:24 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> <200904172344.n3HNivf6025718@dsl092-065-009.bos1.dsl.speakeasy.net> Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Krawitz Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, till.kamppeter@gmail.com Robert 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. > > Other than that with all-in-ones they're all physically in the same > box (and the manufacturers sell them that way). as long as you remember that it is unrelated user tasks packed into one physical box, then I am happy. > We get quite a few > complaints about the scanner not functioning in multi-function > devices; users appear to expect that these devices be handled as a > single coherent unit. I think the complaint is that the scanner is not working. they would love if you could make that work for them. do you really think any of them would expect a scan workflow that goes through the print dialog? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: peter sikking In-Reply-To: <49E8ECCF.8050700@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 11:57:06 +0200 References: <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> <200904171232.16547.hvengel@astound.net> <49E8ECCF.8050700@gmail.com> Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter Cc: printing-architecture@lists.linux-foundation.org Till wrote: > Hal V. Engel wrote: >> On Friday 17 April 2009 11:54:28 am peter sikking wrote: >>> Till wrote: >>>> 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. yes. this is the key to making things normal for users. > If a queue type > (printing, faxing) is not present, the corresponding menu entry gets > grayed out. both will need access installation workflow (the next project...) > Clicking "Print ..." gives the printing dialog as Peter has > designed it, but only print queues (and no fax queues) are listed. yes. excellent. > 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? just like I said for the pdf export dialog: it will be a cousin of the print dialog, not a twin brother. we can recycle a lot of good UI concepts and code for these dialogs, but sound UI practice demands that the design of each is optimised for the particular activity. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: peter sikking In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 11:09:19 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Johannes Meixner Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Johannes Meixner wrote: > On Apr 17 20:21 peter sikking wrote (shortened): >> for users printing, faxing, scanning, memory card reading are >> totally unrelated activities. so it follows that faxing, scanning, >> memory card reading is never going to be seen in a printing dialog >> and also not in a status/monitoring dialog. > > Yes and no - it depends - as always - on the details what > exactly is meant. > > In contrast to separated stand-alone devices where printing, > faxing, scanning, memory card reading works independent > of each other, all-in-one devices introduce hardware-dependent > constraints. > > For example when the all-in-one device is busy with > memory card reading, nothing else might be possible > so that the device status/monitoring in all dialogs > (i.e. also in the printing dialog) must display that > the device is busy with memory card reading. > > The crucial point here is whether or not status/monitoring > is meant regarding the actual hardware device. > > In contrast e.g. a print queue status/monitoring belongs > of course only to the printing dialog. interesting complication. can this lead to the situation that when the print dialog comes up (or users Just Print) that the printer (part) actually looks unavailable/not there to the desktop computer? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <29BE1E67-4A6A-40D7-86EC-A21E518E756A@mmiworks.net> From: peter sikking In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 11:14:36 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Johannes Meixner Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Johannes Meixner wrote: > On Apr 17 20:21 peter sikking wrote (shortened): >> for users printing, faxing, scanning, memory card reading are >> totally unrelated activities. so it follows that faxing, scanning, >> memory card reading is never going to be seen in a printing dialog >> and also not in a status/monitoring dialog. > > Yes and no - it depends - as always - on the details what > exactly is meant. > > In contrast to separated stand-alone devices where printing, > faxing, scanning, memory card reading works independent > of each other, all-in-one devices introduce hardware-dependent > constraints. > > For example when the all-in-one device is busy with > memory card reading, nothing else might be possible > so that the device status/monitoring in all dialogs > (i.e. also in the printing dialog) must display that > the device is busy with memory card reading. > > The crucial point here is whether or not status/monitoring > is meant regarding the actual hardware device. > > In contrast e.g. a print queue status/monitoring belongs > of course only to the printing dialog. interesting complication. can this lead to the situation that when the print dialog comes up (or users Just Print) that the printer (part) actually looks unavailable/not there to the desktop computer? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture