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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
