 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 you have the general overview of 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 each of the document actually has its own LibreOffice instance that is responsible for the actual typing in the document. And also these do the rendering of the document and also of course it manages the user's interactions with the document. So it passes the user events that come from the client into the LibreOffice course so that 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. For example OpenStreetMaps is using that and the entire map is split into small images like here, this is one of the tiles, you can see it here and the document is composed from that. So basically 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 a set of images that is composed together to do something that looks like text. This low leaflet communicates with the server part using backsocket. But the document itself is not the only thing in there. You can see also the toolbar, menu bar, status bar and other things that are in JavaScript. But of course it's very impractical to implement everything or re-implement everything in JavaScript. So we had to search for some right balance between what has to be in JavaScript and what has to be done and rendered by the LibreOffice core. So in the early prototypes there were no tiles, basically nothing in JavaScript, it was just pure invalidate everything, get me back the entire screen again and basically the entire UI was in the browser. Which was not where we wanted to be just because for every action that you would like to do you would have to render it on the server which is very impractical. So then we decided that the tile 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 document 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 bitmap 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 comments and red lines. Just because people are used to that the comments 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 comment and stuff like that. 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 it plays 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 takes a long time. There are hundreds of dialogues in LibreOffice and like some of them are 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 than 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 like 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 route 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. 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 all the like tunneling and and messages about about like what has to be done in the 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 extra for the extra rendering we were using the screenshotting 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 which is the which is the VCL. It is because like all the the caring of the views and and like the collaboration between between people is actually done in SFX. And 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 were we had to had a way how to like skip these levels. And so this notifier is 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. And yeah 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 in the client part you are able to to route it to to the LibreOffice core. And then of course lots and lots of callbacks from the from the VCL back to 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 and closing the dialogue. So after all this was done we thought that we have won but not yet. There are additional challenges so one was language support. The thing is that one document can be shared by multiple users and one of them has 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 their language 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 a call on switch to to get text helped us tremendously here. Just because like the the the infrastructure was was much more prepared to to actually switching things were cashed so or are cashed so like when you switch the language it is not that all the files would be like reloaded again. It is all all like loaded once and then then just used. So luckily in most cases it was just just a matter of changing the static locale into into like getting the locale again and again like when the when the view was switched. Similarly SFX module had to be adapted very similarly because again the locale there was was cashed but not using static but like as part of the 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 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 as saying 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 OK. And and like LibreOffice had a mechanism for that which was this this start execute modal but it was in practical because it was using the links the linking mechanism that is 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 into separate separate method or or function and do 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 I think we which gets a lambda and actually change the model start execute model into using the start execute I think. So now what is normally necessary to be done to convert a dialogue from the execute to a thing execute is that you do you create a dialogue not a scope VCL pointer but just a normal VCL pointer because the start execute I think will then later take care of actually destroying the dialogue. And instead of executing you do not do the executing instead you move the 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 issue them 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 soon thank you so much yes. Just curious when you sent over the bitmap of the whole dialogue you have a good initialization but then when just a single button changes or something do you send a dip or the whole dialogue again? No, because we send invalidate we know what to render so we just render this small thing. Yes, sorry? Two users can open the same dialogue in the office. Yes. And they get painted individually. Yes. My question is you explained that you're able to toggle this like a screenshot the whole dialogue and it's rendered on the client side. But how is it handled the interaction? I mean for example if combo boxes is pushed and so the combo list has to open. Yes. It is how is it handled? It is always a mechanism of rendering let's say getting the click and sending to the demo server. Yes, yes, yes and back. It has to be done this way. Just like the VMC let's say. Yes, yes in that case. Yes. Thank you. Next please prepare here. You mentioned that you allow modal dialogues but is the other user still allowed to change the document? Yes. Well, because I know a lot of places in the office that we crash left and right we use modal dialogues because you should not be allowed to change the document while the dialogue is open. I was surprised as well how well it works.