 Okay, hello. I'm Jan Holczewski, I work for Collabla and I would like to tell you about the exciting things that we are doing with LibreOffice Online and that is dialogue tunneling. But before I get to that, I will explain you just a bit about the structure of the LibreOffice Online so that like you have the general overview what's going on and why we are doing this thing. So basically the LibreOffice Online has two parts. One is the server part which contains the daemon that is responsible for the actual communication with the clients. It spawns LibreOffice instances so that like each of the document actually has its own LibreOffice instance that is responsible for the actual typing in the document and also like these do the rendering of the document and also of course it manages the user's interactions with the document. So like passes the user events that come from the client into the LibreOffice course so that like it is possible to do something with the document. Of course like when something is happening in the LibreOffice core the callbacks have to be routed back to the clients and do something about that. This stuff is all in C++. On the other hand the client part is we call it low leaflet because it's based on leaflet which was originally a software for displaying maps. So which like the maps for for example street map maps is using that and like the entire map is split into like small small images like here this is one of the tiles you can see it here and the document is composed from that. So basically like even though you are seeing a document that has the text there it is not a text that would be in the browser it is just set of images that is composed together to do something that looks like like text. The low leaflet communicates with the server part using back socket and yeah and but the document itself is not the only thing in there. You can see also also the toolbar menu bar status bar and other things that are in JavaScript but of course like it's very very impractical to implement everything or implement everything in JavaScript. So we had to search for some right balance between like what has to be in JavaScript and what has to be like done and rendered by the LibreOffice core. So like in the early prototypes like there were no tiles there were nothing in well basically nothing in JavaScript it was just like pure like invalidate everything get me back the entire screen again and like basically the entire UI was in the browser which was not like where we want to be just because like for every action that you would like to do you would have to render it on the server which is very impractical. So then like we decided that the tiled approach is good because there's a code that we can reuse. There were other implementations for example on Android like Mozilla Firefox on Android was using these tiles and like lots of other projects in the industry were using the tiles for actually like rendering the documents so we thought it's the right thing to do. But on top of that we started like painting the overlay with the cursor and with the selections and just because like it was very impractical to send the entire bitmaps with just the cursor moved. So instead like we just started sending just the coordinates of the cursor and started rendering that in a layer on top of that. Then next thing that turned out to be like practical to render in JavaScript was commands and red lines just because people are used to that the commands have some nice UI. They look pretty. They can have pictures. They flow next to the cursor like when you select the text that has the command and stuff like that. So it was good to do in JavaScript. But then what about dialogues? At first we started implementing some of the dialogues in JavaScript. For example to find that they replace special character insert table. But like very soon it turned out like this is no way to go. It's just too many dialogues out there that's like very impractical. It takes a long time. There are hundreds of dialogues in LibreOffice and like some of them are like extremely complex like the cell character cell format style and these things. So the plan was to start tunneling the dialogues actually from LibreOffice. Let's reuse the dialogues as they are and use them in the browser. Actually like the plan was good. But the thing turned out to be a bit more challenging that it initially looked like. But luckily Pranavkant did all the hard work there or most of the hard work there. And now we have beautiful dialogues inside LibreOffice online. You can see on the screenshot that it has all the tabs. It has like the various custom widgets that are available in LibreOffice. For example like seeing the line types and everything. So like because it is rendered in LibreOffice but through it to the online you can have all the stuff. But there were lots of challenges. For example like now as the resulting thing you can do it collaboratively. So you can have one like two users that collaborate on one document and both of them select the same paragraph and both of them actually issue the paragraph setting dialogue. And one of the users can like shrink the size of the paragraph and the other can set the background to green. And when both of them like press OK it just does the thing that you would expect. Like it shrinks the paragraph and does it green. Which is awesome. But I think you can imagine that like it was not straightforward. Luckily the LibreOffice core was very helpful here. So like the SFX framework surprisingly like did lots of good stuff for us instead of like you know making us problems which was great. We initially did like all the like tunneling and messages about like what has to be done in the core and in dialogue in the SFX. But then like it turned out that we have to move it down to VCL. So now most of the stuff is done directly in VCL which is responsible for drawing the dialogues or drawing the widgets and stuff like that. Which we extended so that we have added there the callbacks that notify us about the invalidations about the dialogue creation about site changes and stuff like that. Then for the actual rendering we were using the screenshoting feature that was done by our friends at SIP. Then we have added the concept of lock notifier. The lock notifier is an interface that actually allows us to do stuff in SFX2 even though like we are in the lower layer which is the VCL. It is because all the caring of the views and the collaboration between people is actually done in SFX. In SFX we also have the mechanics of actually like notifying the right view through the LibreOffice kit. But because like the stuff is happening in VCL we had to had a way how to like skip these levels and so this notifier is like just a way how to overtake this and like now we are able to do stuff in VCL but then it like the LibreOffice kit is notified in SFX. So we had to add a bit of API into LibreOffice kit which was several methods. I think they are reasonably obvious. Painting of some area in the dialogue, posting some events if they are necessary. So far only closing of the window is implemented. Nothing else was necessary to be done this way. Then posting of K events, mouse events like when the user does something in the client part you are able to route it to the LibreOffice core and then of course lots and lots of callbacks from the VCL back to the LibreOffice kit and to the online. So stuff like created title change, size change, invalidate, cursor was moved, cursor was done visible and closing the dialogue. So after all this was done and we thought that we have won but not yet. There were additional challenges so one was language support. The thing is that one document can be shared by multiple users and one of them has the UI set in English and the other has that actually in check and what to do. Well as you know LibreOffice itself when you change the language it actually tells you well you cannot change it now you have to restart LibreOffice. So we had to overtake that. Luckily like Qualans switch to get text helped us tremendously here just because like the infrastructure was much more prepared to actually switching things were cached so or are cached so like when you switch the language it is not that all the files would be like reloaded again it is all like loaded once and then just used. So luckily in most cases it was just a matter of changing the static locale into like getting the locale again and again like when the view was switched. Similarly SFX module had to be adapted very similarly because again the locale there was cached but not using static but like as part of the object. The other challenge here and big one was modal dialogues. So the thing here is that the thing here is that like when you execute a dialogue like non-modal dialogues are fine like they can hang in the in the view and they are all fine but like when you have a modal dialogue you issue an execute and like at that time like it yields so like all other things is still happening so you can like from the other view issue the dialogue again that's all fine but still like you are hanging in this execute so like there's one execute and another execute like happens on top of that and so now what happens like if this user that is in the lower execute just ends the dialogue and like once his or her changes actually be visible like it doesn't happen until like the guy that is on top of him closes the dialogue as well and the guy like who is on top of them can just disappear and like you would get never you would never have the stuff confirmed so it was necessary to actually convert this modal dialogue to modal async. This means that like when you instead of this execute you do not you do not hang in that execute instead of you just trigger showing the dialogue and create a callback like what should be done when when the when the user actually touches okay and and like LibreOffice had a mechanism for that which was this start execute modal but it was in practical because it was using the links the linking mechanism that is in in LibreOffice which meant like there would be necessary to do like bigger changes to actually do that you would have to like move the code into separate method or function and maybe you wouldn't have some of the stuff that you need there available and stuff like that. So Michael actually changed that or introduced start execute async which gets a lambda and actually changed the modal start execute modal into using the start execute async. So now what is normally necessary to be done to convert a dialogue from the execute to async execute is that you do you create a dialogue not a scope VCL pointer but just a normal VCL pointer because the start execute async will then later take care of actually destroying the dialogue and instead of executing you do not do the executing instead you move the code that happens after the execute because like there was probably that here some code that was taking care of applying the changes and you would just wrap it around this this lambda get the result according to that do the changes of course like in some cases it's more complicated than just this but this is the basic structure here and usually cave it so thanks to doing these all stuff in VCL most of the dialogues just work out of the box you just issued a you know commands you know command and the dialogue appears it doesn't appear in the situation when it gets null as the parent because like in that case it doesn't have set the look notifier and like in that case it is usually just just enough to set set the parent as the window of the view shell if the dialogue doesn't switch the languages for the user then you have to find a place like where there's some static variable anything else happy to answer you any questions so thank you for listening and thanks also to these guys who has done the work because I've done only very small bit of that thank you so much yes just curious when you sent over the bitmap of the dialogue new because we send and validate we know what to render so we just render this this small thing yes yes yes yes yes yes but my mission is you explain that you able to talk about the dislike screen shot the whole dialogue and it's real red and on the client side but how is it handle the interaction I mean for example if combo boxes pushed and so the combo list has to open yes it is how's it and it is always a mechanism of rendering let's say I'm getting the click and sending to the daemon server yes yes yes and back it has to be done this way yes yes in that case yes who is next please prepare here yes I was yes I was surprised as well how well it works