[Development] Fwd: Google Summer of Code 2017 - Common Print Dialog project

[Michael Weghorn]

[below: Till's reply and request to forward our discussion to this
mailing list]


-------- Forwarded Message --------
Subject: Re: Google Summer of Code 2017 - Common Print Dialog project
Date: Thu, 2 Feb 2017 21:56:47 -0200
From: Till Kamppeter <till.kamppeter at gmail.com>
To: Michael Weghorn <m.weghorn at posteo.de>
CC: Aveek Basu <aveek.basu at lexmark.com>, John Layt <john at layt.net>,
Bjoern Michaelsen <bjoern.michaelsen at canonical.com>, Will Cooke
<will.cooke at canonical.com>

On 02/01/2017 09:04 PM, Michael Weghorn wrote:
> Hi Till,
>
> thank you very much for your email.
>
> in general, I very much like the idea of such a Common Print Dialog
> (CPD). I think it would really improve user experience a lot. The many
> different print dialogs are confusing for the users. In my opinion, the
> CPD would be a huge improvement from a developer/maintenance point of
> view as well.
>
> Because I liked the idea of a Common Print Dialog a lot, I also asked
> about the status of the project (that had been there) in March last year
> on OpenPrinting's printing-architecture mailing list [1] where you also
> participated in the discussion.
>
> The replies there made me understand that the project had been
> paused/cancelled and as far as I understand, one of the main reasons was
> that there was no huge interest on Gtk's and Qt's side to actually
> integrate support for the CPD back then for different reasons.
>

I think the problem was the UI design in the first run, it was too
ambitious. The Ubuntu design is simpler and easier to implement.

As a minimum for this GSoC we need to get to a working model, so that we
have patches for at least one of GTK/Qt/LibreOffice to send jobs into
the D-Bus, and the dialog in at least one of GTK or Qt version, with at
least the CUPS backend, receiving jobs from the D-Bus. GTK interface and
dialog being the most important for the working model as there we have
most apps and desktops.

> While I do still very much like the idea of a CPD, I cannot estimate
> whether the situation and chances for the CPD have fundamentally changed
> since then and the new approach has better chances. Maybe you can
> estimate that better than I can.
>

As I told above, we are replacing the dialog UI design by a simpler one.

> I think it would be very important to work together with the Qt and Gtk
> projects from the start and to make sure that there is actually interest
> in supporting/integrating the CPD in both projects, as that seems to be
> crucial to me for the success of the project.
>

This would be great, if they already agree with the project and show
their support before this GSoC this would help a lot.

> Maybe it would also be good to evaluate whether it makes sense to work
> together with LibreOffice from the start as well. LibreOffice also
> works/worked on a redesign of its print dialog, s. concept at [2]. This
> is also mentioned as a potential GSOC project in LibreOffice's wiki [3].
>

LibreOffice is very important here. As it is only an app and not a
desktop for its integration we would need only its interface into the
D-Bus bridge, but it needs to be well thought out and each of the
components (Writer, Calc, Impress, ...) of LibreOffice would need to
tell the appropriate component-specific options to the dialog.

Bjoern, what would you think about a Common Print Dialog, meaning that
independent of from which application you print, the same
desktop-provided, print dialog will appear, no user confusion by
different UIs, no missing features (like Google Cloud Print for example)
for some of the apps.

The change on LibreOffice would be to add the D-Bus interface, so that a
"File" -> "Print" would call the (desktop-provided) dialog as a D-Bus
service, send the document (as PDF) to the dialog and also the list of
application/component-specific options. The dialog would show a preview,
and offer general, printer-specific, and component-specific options.
When the user changes them, the preview is updated and if needed, a new
PDF is requested from the client. The dialog does all communication with
CUPS, as polling printer lists and the capabilities of the selected printer.

>> Would you like to cooperate with us? Forward this message to Qt
upstream devs? Do mentoring on the Qt side?
>
> I would be happy to help in case I can. However, I do not think I would
> be the right person to do mentoring on the Qt side as I have not been
> involved in the project itself so far and have also just started
> contacting the project regarding the print dialog.
>

If you find appropriate people in the Qt project, please forward our
dialog to them.

> I think it might be good to address that topic on Qt's development
> mailing list. As far as I understand Andy Shaw's reply to my email
> there, the Qt project currently does not seem to be working toward a
> particular vision on the future direction of its print dialog right now
> and this might be a good situation to discuss different alternatives,
> including support for the CPD. The first message on the mentioned thread
> is [4], which was the forwarding of an email I had first written to the
> qt-interest mailing list.
>

So please do it and reach out to their mailing list, with me CCed. Thanks.

> Feel free to forward our conversation there as well in case you consider
> that useful.
>
>> P. S.: Link [4] is missing in your mail.
>
> Thank you for that note. I currently cannot think of any totally
> different resource I wanted to mention; possibly I wanted to refer to
> the thread where the discussion started in 2015, which is [5] and is
> also mentioned in the new thread.
>
> I would be grateful to hear when more details about the CPD and the next
> steps are known. I am already subscribed to OpenPrinting's
> "printing-architecture" mailing list. Are there any other resources I
> should regularly have a look at to stay informed?
>

That is OK. Discussion there will probably soon appear when we go
further into the project.

   Till