[Kde-print-devel] Open Printing Common Print Dialog

[Hal V. Engel]

On Monday 07 June 2010 09:15:53 am you wrote:
> On Thursday 03 Jun 2010 18:48:20 you wrote:
> > Hal Engel sent a message using the contact form at
> > http://www.layt.net/john/contact.
> >
> > John,
> >
> > There is a possibility that I may be working on the Qt version of the
> > Open Printing Common Print Dialog in the coming months and I have been
> > asked to locate contacts with the KDE project and Nokia to try to
> > coordinate the up coming effort.  The intention is to have working GTK
> > and Qt dialogs by the end of this year.
> >
> > I know that you have worked on printing related stuff for KDE in the
> > past. If you are not the correct person to contact could you pass this on
> > to the correct person(s).
> >
> > Thank You,
> >
> > Hal Engel
> 
> [cc: the KDE e.V. (our governing body) and kde-core-devel mailing lists as
>  an FYI, any further discussion should take place on kde-print-devel]
> 
> [For background see
> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonpr
> intingdialog]
> 
> Hi Hal,
> 
> Yes, I am still the de-facto contact for KDE print releated stuff, for my
> sins.  I've done some work on patches to improve the Qt print dialog and
>  print system, but progress is slow so any new initiatives are welcome :-)
> 
> I'd be happy to help out with coordinating the effort, but there's a lot of
> different areas of KDE I'd need to consult to be sure we get the right
> solution.  To be blunt I think it will be challenging to make our
>  end-of-year release in KDE, our feature freeze date for KDE SC 4.6 is
>  November 11, by which time we would need a complete solution that we can
>  make a API/BIC guarantee on.  A Technology Preview might be a better goal
>  for SC 4.6.

I agree with this.  Even though the work is fairly far along and there will be 
a big push through the end of the year there is still a lot that needs to be 
done.  The Open Printing plan calls for things to start appearing in distros 
in the spring of 2011.  This is sort half way between the release of 4.6 (Jan. 
2011) and 4.7 (summer 2011) which implies that it needs to be in 4.6 to meet 
this time line.  This may be ambitious but if we have a little luck it might 
be possible.  But at the very least this should be far enough along to be a 
Tech Preview by that point.

> 
> We have our annual conference (http://akademy.kde.org/) coming up in a
>  months time, which would be a great chance to grab all the necessary
>  people to discuss things, so it would be good to have some kind of idea of
>  what is needed before then.  Would someone from OpenPrinting be able to
>  attend during the hack week to discuss the plans from a technical view?

This will not work for me but someone else from Open Printing may be able to 
attend.  I have CC'ed Till Kamppeter who is the main person at Open Printing 
and it may be possible for him or someone else closer to Finland to attend.   
I think it would be a very good idea to have someone demo the CPD and also 
work out any issues.  Also as this moves forward I would be more than happy to 
have you and others working on KDE and Qt review the work so that we know we 
are headed in the right direction.

> 
> While I'm generally in favour of the concept, last time I briefly
>  investigated it there were a number of obvious points I wanted to
>  understand better, and that I expect will concern the Qt guys too.
> 
> Where will the code reside: in OpenPrinting, in Qt, in KDE, or somewhere
>  else? 

This is the $64 question.  Right now it is setup like it will be part of KDE 
(IE. cmake build and so on).  So it could be dropped into the KDE source tree 
fairly easily.   From my perspective I am not sure if this is the best 
possible place since it would be even better if this was part of Qt since that 
would make it even less desktop centric.  I suspect that getting this into the 
Qt tree would be even more difficult than getting it into the KDE tree.  But I 
think that there may need to be some hooks in Qt even if the dialog resides 
somewhere else.

>  How much is shared code and how much desktop specific?  

It appears to be divided into a shared part that handles the basic D-Bus stuff 
and a part that implements the desktop specific parts (Qt and GTK).   The 
dialogs do have lots of CUPS PPD related code since the contents of the dialog 
depend on what is in the PPD file.   I have just started looking at the code so 
I don't know for sure yet how it is actually structured.  Also I am not sure 
that the DBus stuff in the Qt dialog is actually setup to take full advantage 
of the related Qt classes.  

>  Who will be
>  responsible for the ongoing maintenance?  

This needs to be worked out but at this point I am not the person who can 
speak to this issue from the Open Printing point of view.

>  And how will differences between
>  the platforms be resolved?  

At this point I think the biggest issue here is in the area of storing user 
configuration data (IE. default printer, printer settings and stuff like that).  
Since this has not yet been implemented on the Qt dialog the details will need 
to be worked out but I would like to keep this platform agnostic if possible.  
Keep in mind that I have just started looking at the code so there may be 
other platform differences issues that need to be resolved.  

>  We have a friendly relationship with Gnome on
>  cross- desktop efforts, but our different visions sometimes makes
>  agreement difficult.
> 
> All KDE/Qt apps are coded to do push-printing, i.e. call the dialog then
>  paint the document according to the result.  Every app would need to be
>  adapted to pull-printing which could be a lot of work, but I assume
>  there's a fall-back push mode that we could use as a stepping stone?

This I am not sure about.  I will have a look at a KDE app to see how it 
prints and compare that to what the CPD expects.   I have been looking at the 
Qt classes related to printing and as you point out printing appears to be a 
lot like using a QPainter once the QPrinter is instantiated.  The CPD expects 
to get a PDF document and since the Qt print stuff can produce a PDF file as an 
option I don't think interfacing will be too difficult.  

The CPD uses poppler to render the preview for both versions of the dialog.  
Also since poppler now supports color management it might be possible to 
implement client side printer color management as part of this work flow 
without too much difficulty and color managing the preview should be fairly easy 
to add since I have done this already with the poppler Qt4 demo app.  But this 
is clearly a secondary consideration.

> 
> We need cross-platform printing, i.e. support for Windows and OSX as well
>  as CUPS/LPR.  As I doubt this will be provided by the common dialog then
>  we may need to maintain two sets of printing code in each app for push and
>  pull printing.  Any design that simplifies how we do this is more likely
>  to gain acceptance.  Any solution that is derived from the current Qt
>  print system classes would be the preferred choice.

Yes I agree totally about deriving an interface class from the existing Qt 
classes.  This would make modifying apps to use the new dialog a very simple 
process and if done correctly it may only require some mods to Qt and the 
change would be transparent to apps.  But again this class would need to be 
part of Qt for this to work for Qt apps if KDE is not installed.

Also one other possible way to view this is that the CPD could be treated as 
the "native" print dialog on *nix systems so that the *nix printing system, 
which currently does not have a native print dialog, works more like Windows 
and OS/X systems when printing from Qt apps.  But I think this implies that 
the dialog, or at least the hooks to use the dialog, are part of Qt rather 
than KDE.

> 
> That's just off the top of my head, there's a lot to be worked through both
> technical and community, but I hope we can come up with the quality
>  solution the free desktop deserves.
> 
> All further discussions should probably take place on the kde-print-devel
> mailing list, you can join at
>  https://mail.kde.org/mailman/listinfo/kde-print- devel

Done

> 
> Cheers!
> 
> John.
>