Okay. I think we can start. Hello. My name is Sriman Kwas and I work for Collaboral
Productivity. Today I would like to talk about the LibreOffice Kit. I named this presentation
bridge between your application and LibreOffice because LibreOffice Kit is simply an API which
provides a possibility to render the preview of the document. So if you want to build an app
which requires rendering of some documents, you can use that. So that's the API which provides not
only rendering of the documents, but also we can manipulate the documents and also it gives us
access to the UI components. We use LibreOffice Kit in Collaboral Online, but also in the LibreOffice
repository there is some sample application called the GTI TiledViewer where we can see it in action.
It renders the document from tiles and also allows us to do some simple modifications. The APIs are
in LibreOffice Kit directory and most of the crucial implementation is in desktop module. The most
important part is class LibreOffice Kit document which we can use to access all the functionality.
Also when we get some notification from the LibreOffice call, some events, because for example
selection has been changed, we got the callbacks listed in LibreOffice Kit annals. This should be
completely transparent when we talk about rendering because it should be completely
transparent when we compare to normal desktop application, but sometimes it's not possible, so
we use some conditional code for LibreOffice Kit. Behind the com helper LibreOffice Kit is active
flag. For example calling this mentioned callbacks is behind this guard. In this talk I would like
to present some improvements in LibreOffice Kit mostly in rendering the tiles. The biggest thing
is the master page mode because there was a problem. In Impress we can open slides in edit mode,
but also we can design slides how they look and this is called master page mode. There was a
problem when we had multiple users in the same presentation and some of them were watching the
master page and some of them were just editing the presentation. Sometimes we got the mixed tiles
because in our API there was no explicit way to say that we want to render tile for master page
or for the normal mode, so depending on which view we selected for rendering it was completely
not deterministic. So I introduced that parameter to our API, so now we are sure that we will not
mix tiles between different modes. Other problem I noticed was in calc. Again it was not deterministic
when we were rendering some piece of the spreadsheet because when we had two users editing content
in a similar area which was covered by one tile, when one of these cells was overflowing
because we had too much content to fit into the cell, it was rendered only when the view selected
for rendering was the actual editor, but when other users were typing we sometimes refreshed the
given fragment of the spreadsheet without that, so it was flickering and sometimes we got the
right view and sometimes we got view without overflowing content. So I fixed that and now we
are rendering always the same way, the same tile, so we got overflowing content in both cases and
like you can see here there are two views, two different views and both say have the same content.
It's very important because then client application can cache the tiles and they are the same.
Other thing I improved was rendering the slide previews because in previews we don't want to
attach any selections or draft changes in text fields, we want just plain preview of a slide.
In the old code we always used one view, the first one for rendering this but it was not
correct because when first user was typing something for example in the text box it was
visible as well in the preview for other users. So now I modified the algorithm which selects
a view for drawing and we prefer views which are not editing currently. Other functions
which get improvements was render shape selection which is responsible for rendering the shape
or image of element which is currently selected in the document. We used that for example for
showing the rotation result in the real time so when user starts to drag something or rotate
he sees the potential results. The problem here was that when we selected some image with very,
very large size it was rendering the original image so it was taking sometimes few seconds
and was sending megabytes just to render a preview. I optimized that a bit by setting
maximal resolution we used for previews because they don't have to be as big as original images.
And also from other things in the Librofist kit I added was exposing the formula bar widget
which is present in Calc. Now it sends all the events like selections or cursor movements
to the client application so it can be handled there correctly because previously in Colobor
Online we were using the tunneled pixel based formula bar which is not perfect for user
experience. And that's all from me, thank you.