Google Summer of Code 2017 - Some help needed

[Till Kamppeter]

Hi,

as Caolán McNamara told me after presenting my problem on the 
#libreoffice-dev channel on FreeNode (see log below) I am posting it here:

I am Till Kamppeter, leader of the OpenPrinting project and I am also 
the packager of the printing stack in Ubuntu.

In the Google Summer of Code 2017 a big project of OpenPrinting will be 
work on the print dialog. What we especially want to do is:

- Common backends to all print dialogs (GTK, Qt, LibreOffice, ...):
    - Backend for local CUPS queues
    - Backend for IPP network printers
    - Backend for Google Cloud Print printers
    - In the future: Backends for new, upcoming print technologies (for
      example a cloud printing service based on PWG standards.
- Create a decent, feature-complete Qt print dialog which supports
   above-mentioned backends, for Qt upstream.
- Create patches for the current GTK print dialog to take the new
   backends, so that distros do not have to wait for these backends
   until the new GTK dialog gets released in 2 years.
- Create patches for the LibreOffice print dialog to take trhe new
   backends.

This way we want to assure that users get access to all printers and all 
print options from any desktop application, and that also if current 
print technologies (like CUPS) get changes or if new technologies will 
appear in the future. In such a case one only would need to modify or 
add a backend.

All this is meant to be contributed to the appropriate upstream projects 
so that all Linux distributions will get improved by this.

I will mentor a student who will patch the LibreOffice print dialog to 
take the backends. This will not change the appearance and GUI of the 
dialog, but only the method to obtain printer and options lists and to 
send off print jobs.

As talked about on the IRC LO allows also switching to the GTK dialog 
and there will also be a new GTK dialog which will get launched in 
around two years.

The backend idea comes already from the new GTK dialog and we want to 
get it to life as soon as possible.

It is told that it is difficult to do Spreadsheet printing with the 
usual print dialogs and therefore it could be better for LO to stay with 
its own dialog.

So what I would like to know is the following:

- Would it be a good idea to modify the inner workings (not the GUI) of 
the LibreOffice print dialog to talk to the printing 
system(s)/printer(s) through a modular backend so that easily new peint 
technologies can be added or changes for the existing ones being supplied?

- Or is it no problem for Spreadsheet printing to use the current and/or 
the future GTK print dialog so that it is a better approach to let LO 
default to the GTK dialog?

- Would someone of you help me to mentor the student who will modify the 
LO dialog and also help me and the student to get started with 
contributing to LO?

Thanks a lot already in advance.

    Till

----------



<tkamppeter> Hi, I am Till Kamppeter from OpenPrinting (also Ubuntu 
packager for printing stack).
* JohnW71 has quit (Quit: Leaving)
<tkamppeter> I am doing a project of improving the print dialogs in this 
year's Google Summer of Code.
<loircbot> LibreOffice (core) Thorsten.Behrens * sw/source/core/undo/ 
(unattr.cxx unfmco.cxx): tdf#88555: band-aid fix, using GetPos/find 
instead of Contains
<tkamppeter> The intention is to have common backends for all dialogs 
(GTK, Qt, LibreOffice), one for CUPS queues, one for IPP printers, one 
for Google Cloud Print ...
  This way one can easily apply changes in CUPS or add new print 
technologies and services.
  One student is supposed to do the needed modifications on LO's print 
dialog.
  I would need someone who helps me mentoring him and to help to get the 
result upstream into LO.
<caolan> tkamppeter: who's gsoc project is that ?
<tkamppeter> The mentoring org is the Linux Foundation where 
OpenPrinting is a part of. I am org admin for the LF.
  And the main part of OpenPrinting's GSoC activity this year is the 
work on the print dialogs, we have 6 students on that.
<caolan> tkamppeter: FWIW, if you use tools->options->advanced and 
toggle on "experimental features", then tools options->general will 
offer the option to turn off "use LibreOffice Dialog" for printing, in 
which case the gtk print dialog will stumble to life
<caolan> there was a time when I wrote some class of a "if the gtk 
dialog had this that and this" it would make life a lot easier to use, 
then there was talk of a new gtk print dialog and then it never happened
<tkamppeter> Yes, I know this tric, and probably it can turn standard 
when GTK's new dialog comes to life.
<caolan> anyhow, late here. I suggest mailing our dev list and I can try 
and dig out what I wrote the last time
<tkamppeter> GTK/GNOME is working on a new dialog currently, landing in 
more or less two years.
<mst_> erAck: oy... it's a regression from some alg commits where he 
hooked up the application undo managers in 
SdrObjEditView::SdrBeginTextEdit() ... this looks quite scary, calc has 
it implemented too apparently
<caolan> yeah, well, hmm, two year eh?
<tkamppeter> This new dialog has a backend concept which we are 
generalising now to also work in the old GTK dialog, in the LO dialog, 
and in a new Qt dialog which one of our students will write.
<mst_> can this new gtk print dialog have options for printing 
spreadsheets on it
* crossmanith (~smuxi at p5DD5BE76.dip0.t-ipconnect.de) has joined 
#libreoffice-dev
<tkamppeter> I think it has something like talking a tab with 
app-specific options.
<mst_> or what was the reason we dont use the current one, i foget
<caolan> tkamppeter: FWIW most the notes I think I wrote about the 
existing printing dialog were about stuff like spreadsheet printing and 
you can see in the gnumeric print dialog the issues
  caolan CalimeroTeknik castlelore
<caolan> this however may have been 4+ years ago :-)
<tkamppeter> caolan, if the spreadsheet printing makes it too 
complicated to use a GTK print dialog with LO it would probably be much 
easier to get the backend support into the LO dialog.
<caolan> anyhow, I suggest the mailing list and we can see what our 
collective memory about this was
<loircbot> LibreOffice (core) erack * 
i18npool/source/localedata/data/es_SV.xml: Resolves: tdf#106902 swap 
[es-SV] decimal and group separator
* nivag has quit (Remote host closed the connection)
  YuGiOhJCJ has quit (Quit: YuGiOhJCJ)
<tkamppeter> caolan, will do ...