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