[Printing-architecture] GSoC 09: Modifying applications to use the new printing dialog

[Svilen Kanev <mighty.frost@gmail.com>]

Hello,

My name is Svilen Kanev and I am a student at Harvard College. I am 
interested in changing applications so that they use the new common 
dialog with cpdapi. I have developed under C++/C and I think I am able 
to read and modify other people's code.

Here's what I found out for the project from this mailing list, the IRC 
channel and simply common sense:
Some commonly used applications that need to be modified are Open 
Office, Firefox, Thunderbird, Evince, the GIMP, etc... Open Office has 
highest priority, but presumably Evince is simplest to patch.

I set up development environments for some of the applications and here 
are my first impressions from skimming through their code:

- Evince has, as expected, pretty self-contained printing code. It uses 
the default GTK dialog, not modifying it in any way. From what I saw, it 
uses PS format for print preview (which should probably be changed when 
the live preview is actually implemented). This makes it suitable for an 
application that can be used to test the new dialog. The modifications 
shouldn't take long (hopefully the first week or two of SoC), but would 
help a lot with the learning curve of modifying more complex applications.

- Firefox also uses the GTK dialog, but extends it, adding customized 
options about frames, headers, etc... The positive side is that it is 
cross-platform and because of that it uses interfaces to abstract away 
the actual printing dialog (which is different on different platforms). 
So, in an ideal world, the changes would be only in the implementation 
of these interfaces which, compared to the total printing code size, 
isn't that much. Adding live preview would probably complicate things 
more, but there is a lot of code that can be reused from the "static" 
print preview.

- Open Office uses its own printing dialog that looks much like the 
Windows one. In fact, most of the printing settings are hidden under 
another dialog, called "Printing Options". Both dialogs are supposed to 
be platform-independent, i.e. there is only one implementation for all 
environments. The actual code mixes GUI and data members in one class 
per dialog. All this means it will be harder to use the new dialog 
without breaking the platform independence and would require some 
restructuring of the current code. A possible approach would be to 
abstract away the different implementations that will be created with 
interfaces and choose an implementation based on the target platform (or 
for example, based on whether cpdapi is running).

So, a pessimistic SoC schedule would probably include Evince to get 
started, Open Office and Firefox. An optimistic may include Thunderbird, 
the GIMP or other applications as well, depending on how fast everything 
goes. I guess that after the first two, changing more would be 
repetitive and much easier in general. Do you think this is the right 
way to go and that the work can be done for the summer?

Svilen