[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
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hi Pranav,

On Mon, Jun 15, 2015 at 02:43:02AM +0530, Pranav Kant <[hidden email]> wrote:
> * 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.

Hmm, one of the last two commits on your branch now break the feature
where you can click into the document in gtktiledviewer and get a
blinking cursor. Can you reproduce that?

> * 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.

Thanks a lot for this, this is great! :-) Now that gtk3 is enabled by
default on master, I could push these 4 commits without drawbacks to
master.

> * I seem to have uncovered a bug in LO core on postMouseEvent[4].

If you can still reproduce it, it would be nice to see the
SwXTextDocument::postMouseEvent() frame, there a switch-case has an
assert(false) in the "default:" case, but ideally that should never
happen. So it would be nice to know what is nType when you hit the
assert.

Maybe you accidentally run your latest gtktiledviewer against an older
master that doesn't handle LOK_MOUSEEVENT_MOUSEMOVE yet?

> 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.

One idea regarding that: I think lok_doc_view_post_key() is just a hack
as I failed to find out how to give the widget the keyboard input. If
you can find a way, so that (just like the mouse input) the keyboard
input gets to the widget out of the box, then we could drop that
function. ;-)

Thanks,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice