[GSoC] Integrating LO with GNOME - WR#3

This week I was able to do following :

* Let the widget (lokdocview.cxx) create the LOK context for us,
rather than applications create it for themselves and directly
interacting with the LOK. The main idea was to make widget do
everything behind the scenes.

* Restructure the whole widget, and make it more introspectable[1].
This has an added advantage that we can now use this widget with any
language-bindings. Our main goal is to integrate with gnome-documents
which is written in JS, so we had to make it introspectable anyways.
By making it introspectable, I mean using the standard best practices
of writing a GObject class.

* We also ported the widget to GTK3 now; besides that, removed all
deprecated functions in GTK3, and made use of latest functions. The
gtktiledviewer (c++ application using the widget) is looking better
than ever now with new gtk3 icons and features.

*  To test if the application is introspectable, I wrote a small JS
application[2], lokdocviewer, and was successfully able to use this
widget from javascript. With this, I hope that we would be able to use
the widget from other language bindings as well. Here is the small
screencast I made using the widget from JS[3].

Few bugs/problems noticed:
* I seem to have uncovered a bug in LO core on postMouseEvent[4].
* Lately, I have noticed that doc_paintTile() has been taking
exceptionally large slots of time to render the tiles in some cases. I
have not been able to track this because this doesn't happen
everytime. Though, I was able to log this and a tile took 47 seconds
to render at one particular instance. I initially thought that it
might be a regression, but if the input to the function are still same
as they used to be before, it should not be a regression. I don't know
why I couldn't reproduce this earlier on my debug build (and now I am
on non-debug build).
* There are few small dependencies like handles in android/ directory
(handle_middle.png, handle_start.png etc.) that we might want to
remove completely from the widget. Maybe these orange handles are
superfluous; we might not want to use it on non-touch displays, and
touch displays always have their own in-built mechanism, and I hope
that they would automatically show up on their own. Eg: These handles
would show up automatically with gtk3 on a touch display.

Next steps:
* We need to expose a good API for our consumers. This would mean
adding planning and deciding minimal API, signals, and properties
abstracting most of the details so that the unstable LOK part,
whenever changes, doesn't affect the application using the widget, and
the widget takes care of everything internally. So, I would be working
on this, this week.

I am also going to attend FUDCon Pune (http://fudcon.in) later this
month, and if everything goes well, I would be presenting this in
barcamps (or lightening talks) there. Maybe this widget would find
more consumers there after its introspection :)


[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://github.com/pranavk/lokdocviewer
[3] https://pranvk.fedorapeople.org/viewer.webm
[4] https://bugs.documentfoundation.org/show_bug.cgi?id=91887

-- 
Regards,
Pranav Kant
http://pranavk.me