[Printing-architecture] GSOC'09: Common Printing Dialog

[Printing-architecture] GSOC'09: Common Printing Dialog

[Per Hermansson]

Hi,

My name is Per Hermansson and I'm a student from the Royal institute of 
technology in Sweden. I'm interested in developing the common printing 
dialog. Designing a printing dialog with usability in mind seems like an 
important task which if done correct would benefit a lot of people. I 
consider myself to be experienced in C/C++ developing and have developed 
with GTK. Since I've recently switched to KDE I hope to also learn a bit 
about Qt. After some investigation about the idea, I've come up with the 
following questions I hope someone here can answer:

Since designing the interface is a major component would it be possible 
to implement the dialog with both Qt and GTK for one summer? I guess 
this depends on skill level (but e.g. abstracting the dialog model would 
make it easier).

Except for the printing dialog and the cpdapi implementation I guess 
that some kind of abstraction is needed so that the underlying print 
method is decoupled from D-Bus in order to use the api for systems 
without D-Bus?

Also, if two students are chosen for the project what would be a good 
measure for success in modifying other application to use the dialog?

Finally is the cpdapi used (or experimented with) by any applications 
today that you know of?

/Per

Re: [Printing-architecture] GSOC'09: Common Printing Dialog

[Alex Wauck]

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

Per,

My name is Alex Wauck, and I started the implementation of the KDE dialog
last summer.  I intend to continue to work on the project this summer.  So,
if accepted, you would likely be working with me.  If you would like to
learn Qt, this project certainly provides an opportunity for that.  The
current code for the KDE dialog needs some refactoring, and the UI needs
some refinement.  The refactoring may be too complex for someone learning
Qt, but UI refinement should be well within reach.  Also, Lars started a GTK
dialog last summer, and since you have experience with GTK, that would be a
good project for you to work on.


Except for the printing dialog and the cpdapi implementation I guess
> that some kind of abstraction is needed so that the underlying print
> method is decoupled from D-Bus in order to use the api for systems
> without D-Bus?
>

I think the solution for Qt/KDE will subclass QPrintDialog/KPrintDialog with
some way of automatically choosing the right one so that applications don't
need to know whether they are using the Common Print Dialog or a
toolkit-native dialog.  I would imagine a similar arrangement could be made
for GTK/GNOME.

Also, if two students are chosen for the project what would be a good
> measure for success in modifying other application to use the dialog?


My current goal is to have the dialog working in at least one KDE
application (probably Okular) by the end of July.  Since you have experience
with GTK, perhaps you should pick a fairly simple application (Evince?) and
plan to modify it to use the new dialog.

Finally is the cpdapi used (or experimented with) by any applications
> today that you know of?
>

Not that I know of.  I had wanted to get my dialog in KDE 4.2, but that
proved to be way too ambitious.  We have a stupidly simple test application,
but that's it.  Getting the dialog implemented in some actual applications
is a goal for this summer.

Alex

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

Re: [Printing-architecture] GSOC'09: Common Printing Dialog

[Till Kamppeter]

Per Hermansson wrote:
> My name is Per Hermansson and I'm a student from the Royal institute of 
> technology in Sweden. I'm interested in developing the common printing 
> dialog. Designing a printing dialog with usability in mind seems like an 
> important task which if done correct would benefit a lot of people. I 
> consider myself to be experienced in C/C++ developing and have developed 
> with GTK. Since I've recently switched to KDE I hope to also learn a bit 
> about Qt. After some investigation about the idea, I've come up with the 
> following questions I hope someone here can answer:
>

Great, this is a good start for our projects on the Common Printing Dialog.

Note that you will not design the dialog but you will implement it. 
OpenUsability has designed it and in the next days (at the latest 
presented on the OpenPrinting Summit 2009 on April 8-10) a revision of 
the design will be presented. Your task will be one of the following two 
(probably you like the first more):

1. Finish the started implementation work on the GTK and Qt incarnations 
of OpenUsability's Common Printing Dialog, especially implementing the 
embedded preview and taking care of feature-completeness (CUPS page 
management options, Custom options, multi-language PPDs, ...).

2. Modifying/patching common desktop applications to use OpenUsability's 
dialog with live preview via the D-Bus CPDAPI. Priority depends on 
popularity of the apps, starting with OpenOffice.org.

> Since designing the interface is a major component would it be possible 
> to implement the dialog with both Qt and GTK for one summer? I guess 
> this depends on skill level (but e.g. abstracting the dialog model would 
> make it easier).
>

I think there will be enough time, as the design is already complete and 
most of the dialogs already implemented.

> Except for the printing dialog and the cpdapi implementation I guess 
> that some kind of abstraction is needed so that the underlying print 
> method is decoupled from D-Bus in order to use the api for systems 
> without D-Bus?
>

We mostly have the current desktop Linux distros in mind, and they all 
have a D-Bus. We have nothing against alternative coupling methods but 
they do not have the highest priority.


> Also, if two students are chosen for the project what would be a good 
> measure for success in modifying other application to use the dialog?
> 

Dialogs completed and at least OpenOffice.org, Firefox, Thunderbird, 
Evince, and the GIMP being patched (but I have no idea how long patching 
onme app takes). We also need to patch some common KDE apps (for example 
the Konqueror web browser (or however it got renamed in KDE 4).

> Finally is the cpdapi used (or experimented with) by any applications 
> today that you know of?

Not in released software, but Lars Uebernickel (CCed) is implementing 
the CPDAPI in GTK and Qt currently, so that if someone runs GNOME and 
starts a KDE app that he gets the GNOME dialog and vice versa (a first 
stage based only on patching the libs and not using the OpenUsability 
dialog yet).

    Till

Re: [Printing-architecture] GSOC'09: Common Printing Dialog

[Per Hermansson]

Till Kamppeter wrote:
> Per Hermansson wrote:
>> My name is Per Hermansson and I'm a student from the Royal institute 
>> of technology in Sweden. I'm interested in developing the common 
>> printing dialog. Designing a printing dialog with usability in mind 
>> seems like an important task which if done correct would benefit a 
>> lot of people. I consider myself to be experienced in C/C++ 
>> developing and have developed with GTK. Since I've recently switched 
>> to KDE I hope to also learn a bit about Qt. After some investigation 
>> about the idea, I've come up with the following questions I hope 
>> someone here can answer:
>>
>
> Great, this is a good start for our projects on the Common Printing 
> Dialog.
>
> Note that you will not design the dialog but you will implement it. 
> OpenUsability has designed it and in the next days (at the latest 
> presented on the OpenPrinting Summit 2009 on April 8-10) a revision of 
> the design will be presented. Your task will be one of the following 
> two (probably you like the first more):
>
> 1. Finish the started implementation work on the GTK and Qt 
> incarnations of OpenUsability's Common Printing Dialog, especially 
> implementing the embedded preview and taking care of 
> feature-completeness (CUPS page management options, Custom options, 
> multi-language PPDs, ...).
>
> 2. Modifying/patching common desktop applications to use 
> OpenUsability's dialog with live preview via the D-Bus CPDAPI. 
> Priority depends on popularity of the apps, starting with OpenOffice.org.
>
Hi Alex and Till

I have seen the interface specification that was linked from the idea 
page. So the final version will be released soon, this sounds like 
excellent news.
I like both tasks but the first one will probably be easier to implement 
since modifying patching other applications is difficult estimate how 
much time it takes. Although it would be and probably not to difficult 
to try as Alex said with an application like Evince.

>> Since designing the interface is a major component would it be 
>> possible to implement the dialog with both Qt and GTK for one summer? 
>> I guess this depends on skill level (but e.g. abstracting the dialog 
>> model would make it easier).
>>
>
> I think there will be enough time, as the design is already complete 
> and most of the dialogs already implemented.
>

I'm not sure if either GTK or Qt implementation needs the most work? If 
Alex is focusing on the KDE dialog it would seem logical to start with 
the GTK implementation. But working with Qt would be fun too, I'm a 
quick learner and will probably have some extra time until the summer 
starts to get into deep with Qt.
I've downloaded and tested the cpdapi code from the Bazar branch and it 
looked very nice but I guess both toolkit versions have to be modified 
to follow the OpenUsability design?

Also as I understand it both tasks (implementing the OpenUsablility 
design and porting desktop applications) can be done independently of 
each other?

>> Except for the printing dialog and the cpdapi implementation I guess 
>> that some kind of abstraction is needed so that the underlying print 
>> method is decoupled from D-Bus in order to use the api for systems 
>> without D-Bus?
>>
>
> We mostly have the current desktop Linux distros in mind, and they all 
> have a D-Bus. We have nothing against alternative coupling methods but 
> they do not have the highest priority.
>
>
>> Also, if two students are chosen for the project what would be a good 
>> measure for success in modifying other application to use the dialog?
>>
>
> Dialogs completed and at least OpenOffice.org, Firefox, Thunderbird, 
> Evince, and the GIMP being patched (but I have no idea how long 
> patching onme app takes). We also need to patch some common KDE apps 
> (for example the Konqueror web browser (or however it got renamed in 
> KDE 4).
>
>> Finally is the cpdapi used (or experimented with) by any applications 
>> today that you know of?
>
> Not in released software, but Lars Uebernickel (CCed) is implementing 
> the CPDAPI in GTK and Qt currently, so that if someone runs GNOME and 
> starts a KDE app that he gets the GNOME dialog and vice versa (a first 
> stage based only on patching the libs and not using the OpenUsability 
> dialog yet).
>
>    Till
>

Re: [Printing-architecture] GSOC'09: Common Printing Dialog

[Till Kamppeter]

Per Hermansson wrote:
> I have seen the interface specification that was linked from the idea 
> page. So the final version will be released soon, this sounds like 
> excellent news.

OK, if you have questions about that, ask Peter Sikking (peter at 
mmiworks dot net), leader of the development of this UI. You can also 
call into the OpenPrinting Summit 2009 at Thursday, April 9 in the 
afternoon PST and participate in the discussion about the newest state 
of the dialog (or attend personally if you are near San Francisco then).

https://www.linuxfoundation.org/en/OpenPrinting/OpenPrinting_Summit_San_Francisco_2009

> I like both tasks but the first one will probably be easier to implement 
> since modifying patching other applications is difficult estimate how 
> much time it takes. Although it would be and probably not to difficult 
> to try as Alex said with an application like Evince.
>

OK.

> I'm not sure if either GTK or Qt implementation needs the most work? If 
> Alex is focusing on the KDE dialog it would seem logical to start with 
> the GTK implementation. But working with Qt would be fun too, I'm a 
> quick learner and will probably have some extra time until the summer 
> starts to get into deep with Qt.
> I've downloaded and tested the cpdapi code from the Bazar branch and it 
> looked very nice but I guess both toolkit versions have to be modified 
> to follow the OpenUsability design?
>

Yes, they are both incomplete and your task is to complete them.

> Also as I understand it both tasks (implementing the OpenUsablility 
> design and porting desktop applications) can be done independently of 
> each other?
> 

Yes, my original idea was to have one student finishing the two dialogs 
and another patching the applications (see ideas list), but it is no 
problem for example if one student does the GTK dialog and patches the 
GTK apps and the second does the KDE dialog and patches the KDE apps. 
And if we get only applications for the dialog stuff and nothing for 
JTAPI, drivers and whatever we offered, we can even put a third student 
onto the dialog. We also can move around work tasks during the GSoC 
(this we did last year as it turned out that Lars got the CPDAPI quickly 
together, so he did also the GTK version of the dialog which the other 
student on the CPD was supposed to do, but the the Qt dialog turned out 
to be more work than expected).

    Till

Re: [Printing-architecture] GSOC'09: Common Printing Dialog

[Alex Wauck]

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

>
> Yes, my original idea was to have one student finishing the two dialogs
> and another patching the applications (see ideas list), but it is no
> problem for example if one student does the GTK dialog and patches the
> GTK apps and the second does the KDE dialog and patches the KDE apps.
> And if we get only applications for the dialog stuff and nothing for
> JTAPI, drivers and whatever we offered, we can even put a third student
> onto the dialog. We also can move around work tasks during the GSoC
> (this we did last year as it turned out that Lars got the CPDAPI quickly
> together, so he did also the GTK version of the dialog which the other
> student on the CPD was supposed to do, but the the Qt dialog turned out
> to be more work than expected).


Interesting.  I don't recall being expected to do the GTK dialog.  At any
rate, it should be easier to do other implementations now that we have an
existing implementation.  I would say the hardest part is the interface to
CUPS.  Since CUPS has a semi-object-oriented C API, producing an idiomatic
Qt interface for it is decidedly non-trivial.  Someone familiar with GLib
may find it easier to think in that way, and hence have an easier time with
it.

The next hardest part is making the custom widgets (like the option grid)
and making them look good.  I'm not much of an artist, so I tried to reuse
existing widgets as much as possible, but that didn't look the way Peter
wanted it too.  I still haven't produced a widget that looks right.  The
spec says that the widget toolkit's native grid widget should be used, but
Qt's grid widget is not designed for such use and would look really weird.

Lastly, I ran into a very strange QGraphicsView layout issue that seemed to
occur on every computer except for mine.  Hopefully, there won't be any of
that this year.

Alex

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

Re: [Printing-architecture] GSOC'09: Common Printing Dialog

[Per Hermansson]

Alex Wauck skrev:
>> Yes, my original idea was to have one student finishing the two dialogs
>> and another patching the applications (see ideas list), but it is no
>> problem for example if one student does the GTK dialog and patches the
>> GTK apps and the second does the KDE dialog and patches the KDE apps.
>> And if we get only applications for the dialog stuff and nothing for
>> JTAPI, drivers and whatever we offered, we can even put a third student
>> onto the dialog. We also can move around work tasks during the GSoC
>> (this we did last year as it turned out that Lars got the CPDAPI quickly
>> together, so he did also the GTK version of the dialog which the other
>> student on the CPD was supposed to do, but the the Qt dialog turned out
>> to be more work than expected).
>>     
>
>
> Interesting.  I don't recall being expected to do the GTK dialog.  At any
> rate, it should be easier to do other implementations now that we have an
> existing implementation.  I would say the hardest part is the interface to
> CUPS.  Since CUPS has a semi-object-oriented C API, producing an idiomatic
> Qt interface for it is decidedly non-trivial.  Someone familiar with GLib
> may find it easier to think in that way, and hence have an easier time with
> it.
>
> The next hardest part is making the custom widgets (like the option grid)
> and making them look good.  I'm not much of an artist, so I tried to reuse
> existing widgets as much as possible, but that didn't look the way Peter
> wanted it too.  I still haven't produced a widget that looks right.  The
> spec says that the widget toolkit's native grid widget should be used, but
> Qt's grid widget is not designed for such use and would look really weird.
>
> Lastly, I ran into a very strange QGraphicsView layout issue that seemed to
> occur on every computer except for mine.  Hopefully, there won't be any of
> that this year.
>
> Alex
>
>   
Thanks both of you for your valuable help.
I've done some more research (reading mailing lists archive and links 
provided on the website) and I'm starting to understand what is needed know.
Till (or anyone else), could you review my project idea and see if some 
of it makes sense and that the amount of work is within what is expected.

*Idea*

The project goal for me would be to finalize the OpenUsability design in 
at least one toolkit. My first choice would be to improve and refactor 
the current design written in Gtk. This involves being continue the 
effort to be compliance with the dialog specification and implementing 
support for missing features described in the specification like custom 
options and multi-language PPDs. With good background research and 
preparation I expect this to take at most to the midterm evaluation.

During and after the first phase has been in acceptable compliance with 
the specification I expect that the project can take two ways. Either 
help in the development of finalizing the dialog written in Qt using 
experience and pitfalls gained from the previous implementation. If it's 
at that time estimated that too little time remains to complete the 
dialog (or that the work is already done) the second choice is to begin 
porting a current desktop application to use the new common printing 
dialog API. I've made some brief code inspections and except for Evince 
that was mentioned earlier KDE text editor Kate seems to be valid choices.

*Timeline*

 - Before start of coding:
First objective will be to study the OpenUsability design, probably as a 
few design questions if anything seems unclear. Also study some advanced 
topics in Qt, GTK and CUPS that will be required to implement the 
specification. Eventually look into a few applications that could be 
easily ported to use the common printing dialog, as mentioned above.

 - May 23: (Students begin coding for their GSoC projects)
Between here and the mid-term evaluation refactoring and improvement of 
the existing design is top priority. This will probably be done using 
incremental development since I expect that the features can be broken 
done into individual tasks. Initial work will be done on the GTK dialog 
but I expect that some solutions to some ideas can be shared and also 
implemented in the Qt dialog if missing.

 - July 6: (Mid-term evaluations)
Depending on how quickly the previous phase ended, work finalizing the 
Qt dialog will be given the highest priority. If it's estimated that too 
little time is available, work to implement the dialog in a simple 
desktop application will be prioritized instead.

 - August 10:  (Suggested 'pencils down' date)
At this stage I expect that a larger part of the GTK and Qt will be in 
compliance with the specification all (most?) of the major features 
being implemented and documented. If the finalization of the dialogs 
proceeded according to the timeline above then at least one desktop 
application will be modified to use the new dialog API.

Per