[Printing-architecture] CPD development status

[Printing-architecture] CPD development status

[TORATANI Yasumasa]

Hi Till,

This is Toratani.

We will have an OpenPrinting Japan June f2f meeting on 19th, and will
have discussion of Common Printing Dialog (CPD), so, could you please
let us know about the following points?  (These points are based on
the questions/suggestions by Japanese members.)

- What the current status of the CPD development?
CPD spec has already been released as "beta" version?
CPD implementation has already started?

- Interface between CPD and applications has already been defined?
We (Japan members) think that the interface should be IPC, and CPD
and applications process should be separated to avoid the application
crash caused by CPD.

- Current CPD spec includes both "Printing Option Settings" and
"Printer Status"? We hope that the implementation group focuses on
only "Printing Option Settings" spec and implementation as a first step.
to drive the CPD implementation faster.

- Please let us know where we can see the "document" of the grouping
rule of CPD printing options to define them in PPD files.

Kind regards,
TORATANI

Re: [Printing-architecture] CPD development status

[Till Kamppeter]

Hi,

see my remarks below.

Lars, Alex, Jonathan, Peter, please add your answers and your progress 
report here, too.

TORATANI Yasumasa wrote:
> Hi Till,
> 
> This is Toratani.
> 
> We will have an OpenPrinting Japan June f2f meeting on 19th, and will
> have discussion of Common Printing Dialog (CPD), so, could you please
> let us know about the following points?  (These points are based on
> the questions/suggestions by Japanese members.)
> 
> - What the current status of the CPD development?
> CPD spec has already been released as "beta" version?
> CPD implementation has already started?
> 

Follow these links to see the progress of the development:

Requirements:
http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialogRequirements

Specs for PPD extensions and application/dialog interface:
http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialogSpecifications

Specs for the dialog's user interface:
http://wiki.openusability.org/printing/index.php/Specification

BZR repository for the dialog's user interface implementation:
http://bzr.openprinting.org/devel/common-printing-dialog

BZR repository for the application/dialog interface:
http://bzr.openprinting.org/devel/cpdapi

The specifications for the PPD extensions are practically ready. They 
will only be modified if there is any problem in the course of the 
implementation of the dialog.

The interface between application and dialog is mostly defined and 
implemented. Lars has promised to write down the specs soon. Lars, can 
you write down the specs ASAP?

The user interface of the dialog is also mostly defined. Peter, how far 
are the specs.

As much as possible of all the specs is needed for the OpenPrinting 
Japan meeting on Thursday (Japanese time, Wednesday afternoon in the US, 
Night between Wednesday and Thursday in Europe).

> - Interface between CPD and applications has already been defined?

Yes, it is mostly defined and implemented by Lars. Lars, can you please 
write down the specs ASAP? Thanks.

> We (Japan members) think that the interface should be IPC, and CPD
> and applications process should be separated to avoid the application
> crash caused by CPD.
> 

The interface is IPC, more precise to say DBUS. So the application and 
the dialog are separate processes. This improves stability and allows 
the application and the dialog to be of different incompatible licenses.

> - Current CPD spec includes both "Printing Option Settings" and
> "Printer Status"? We hope that the implementation group focuses on
> only "Printing Option Settings" spec and implementation as a first step.
> to drive the CPD implementation faster.
> 

Yes, this is the way we are working. Current work is focused on setting 
the options.

> - Please let us know where we can see the "document" of the grouping
> rule of CPD printing options to define them in PPD files.

PPD extension specs are practically ready. For the option grouping se 
the section "Option Tagging" and for the quick preset buttons the 
section "Quick Presets" on the page with the PPD extension specs.

    Till

Re: [Printing-architecture] CPD development status

[Alex Wauck]

[-- Attachment #1: Type: text/plain, Size: 4082 bytes --]

I've got the layout stuff more or less done.  I'm mainly waiting for the
DBUS API, an application that implements it (I was told I would eventually
be provided one), information on how to group the printer options for the
configuration matrix, and modified PPD files (if necessary) that implement
the extensions.  I'm currently working on implementing user-defined
presets.  Also, I don't know quite how I should implement the two buttons in
the lower left hand corner, as I'm not entirely convinced that a button that
pops up a menu is a good idea.

Alex

On Mon, Jun 16, 2008 at 5:38 AM, Till Kamppeter <till.kamppeter@gmail.com>
wrote:

> Hi,
>
> see my remarks below.
>
> Lars, Alex, Jonathan, Peter, please add your answers and your progress
> report here, too.
>
> TORATANI Yasumasa wrote:
> > Hi Till,
> >
> > This is Toratani.
> >
> > We will have an OpenPrinting Japan June f2f meeting on 19th, and will
> > have discussion of Common Printing Dialog (CPD), so, could you please
> > let us know about the following points?  (These points are based on
> > the questions/suggestions by Japanese members.)
> >
> > - What the current status of the CPD development?
> > CPD spec has already been released as "beta" version?
> > CPD implementation has already started?
> >
>
> Follow these links to see the progress of the development:
>
> Requirements:
>
> http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialogRequirements
>
> Specs for PPD extensions and application/dialog interface:
>
> http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialogSpecifications
>
> Specs for the dialog's user interface:
> http://wiki.openusability.org/printing/index.php/Specification
>
> BZR repository for the dialog's user interface implementation:
> http://bzr.openprinting.org/devel/common-printing-dialog
>
> BZR repository for the application/dialog interface:
> http://bzr.openprinting.org/devel/cpdapi
>
> The specifications for the PPD extensions are practically ready. They
> will only be modified if there is any problem in the course of the
> implementation of the dialog.
>
> The interface between application and dialog is mostly defined and
> implemented. Lars has promised to write down the specs soon. Lars, can
> you write down the specs ASAP?
>
> The user interface of the dialog is also mostly defined. Peter, how far
> are the specs.
>
> As much as possible of all the specs is needed for the OpenPrinting
> Japan meeting on Thursday (Japanese time, Wednesday afternoon in the US,
> Night between Wednesday and Thursday in Europe).
>
> > - Interface between CPD and applications has already been defined?
>
> Yes, it is mostly defined and implemented by Lars. Lars, can you please
> write down the specs ASAP? Thanks.
>
> > We (Japan members) think that the interface should be IPC, and CPD
> > and applications process should be separated to avoid the application
> > crash caused by CPD.
> >
>
> The interface is IPC, more precise to say DBUS. So the application and
> the dialog are separate processes. This improves stability and allows
> the application and the dialog to be of different incompatible licenses.
>
> > - Current CPD spec includes both "Printing Option Settings" and
> > "Printer Status"? We hope that the implementation group focuses on
> > only "Printing Option Settings" spec and implementation as a first step.
> > to drive the CPD implementation faster.
> >
>
> Yes, this is the way we are working. Current work is focused on setting
> the options.
>
> > - Please let us know where we can see the "document" of the grouping
> > rule of CPD printing options to define them in PPD files.
>
> PPD extension specs are practically ready. For the option grouping se
> the section "Option Tagging" and for the quick preset buttons the
> section "Quick Presets" on the page with the PPD extension specs.
>
>    Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>

[-- Attachment #2: Type: text/html, Size: 5580 bytes --]

Re: [Printing-architecture] CPD development status

[Till Kamppeter]

Alex Wauck wrote:
> I've got the layout stuff more or less done.  I'm mainly waiting for the 
> DBUS API, an application that implements it (I was told I would 
> eventually be provided one), information on how to group the printer 
> options for the configuration matrix, and modified PPD files (if 
> necessary) that implement the extensions.

All this is now in place. See the links in my posting.

> I'm currently working on 
> implementing user-defined presets.  Also, I don't know quite how I 
> should implement the two buttons in the lower left hand corner, as I'm 
> not entirely convinced that a button that pops up a menu is a good idea.

Peter, can you help Alex here?

    Till

Re: [Printing-architecture] CPD development status

[Josef Spillner]

Am Dienstag 17 Juni 2008 02:00:29 schrieb Alex Wauck:
> Also, I don't know quite how I should implement the two buttons
> in the lower left hand corner, as I'm not entirely convinced that a button
> that pops up a menu is a good idea.

FYI: There are some buttons in KDE 4 dialogues which pop up menus, e.g. the 
collaboration menu in the Get Hot New Stuff dialogue. Similar to the issue of 
hiding or greying out menus in the menu bar I'm not aware of any usability 
feedback yet and would certainly appreciate some comments.

Josef

Re: [Printing-architecture] CPD development status

[peter sikking]

Alex wrote:

> Also, I don't know quite how I should implement the two buttons in  
> the lower left hand corner, as I'm not entirely convinced that a  
> button that pops up a menu is a good idea.


it has been done for ages, no problem and a good solution under these
circumstances.

but: we found out that there is only one function that needs to go
into this menu at the moment: delete.

So as I am working on the spec today you will see the button
update to a normal pushbutton.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture