Google Summer of Code 2017 - Some help needed

[Caolán McNamara]

On Fri, 2017-04-28 at 12:58 -0300, Till Kamppeter wrote:
> On 04/28/2017 05:59 AM, Caolán McNamara wrote:
> > The main question for me is what format/mechanism is provided by
> > the user of the backend as the print transport

> The backends simply need the PDF to be printed and the key/value-
> pair list of the option settings, nothing more. So integration should
> be easy.

That makes things easier.

> So as the backends will simply take the job in PDF and spreadsheet 
> printing support is too complex to get into external print dialogs,
> let us go the way of making LO's original print dialog ready for the
> backends.
> 
> The dialog will have to look up the available backends and then do

So, I would expect that the actual dialog won't need to be changed at
all. We have a PrinterInfoManager for unix which I think is the best
place to start and try to integrate this. There is one class
CUPSManager that inherits from this for "cups" I suggest adding another
for whatever this is called and there the implementation to get the
list of printers and printer properties can be added following the
existing cups implementation.

> 4. If LO provides some kind of job monitoring, use the backend's
> list jobs functions (does LO do a thing like that?)

I don't think we do, its just fire and forget I think, i.e. we call
cupsPrintFile and hope for the best.

One thing that might turn into a problem is getting the list of
available printers. IIRC for cups we start a thread to collect the list
of printers fairly early in the process and it can get a little
complicated. Nothing too serious to worry about at the start, just keep
it simple and collect freshly the list of printers when requested to
get up and running, but maybe something to consider once basic
functionality is working.

> What I need from you is help in mentoring the student or even
> someone fully mentoring the student (this would be the best). Google
> says that mentoring a student will take around 5 hours/week.
> 
> I also need help where to find the relevant code to modify (ideally
> so that it can make it into Ubuntu 17.10 with Feature Freeze mid-
> August), how to most efficiently test-build (not needing to build the
> whole LO after each little change), coding policy guidelines, how to
> provide patches for upstream inclusion, ...

https://wiki.documentfoundation.org/Development/gerrit Aveek should
follow the setup there to get registered in gerrit and patches can be
submitted there. gerrit builds the patches and typically the various
clang plugins active will flag code policy gotchas. Should really only
need to get libreoffice built fully once, at that point there's
probably no need to keep up to date with head, so once the full thing
is built and modifications are made in vcl, incremental builds of make
vcl.build will be sufficient and the in-tree ./instdir/program/soffice
will "just work"

I won't commit to being a full time mentor, but I can help and be the
LibreOffice contact. So you can put me on CC on anything submitted to
gerrit and I'll help get things bootstrapped and working. I'm on
freenode irc most work days for anything that may arise.

I've outlined the relevant classes above, so I'd suggest, get
libreoffice built once, copy the CUPSManager class and add trying this
new backend before falling back to the cups one, stub out the new
implementations methods and make sure its getting called and fill out
the stubs with the new backend.