 Can you see me? Can you see my slide? Okay, then let's start. So again, things like will come to my office here. So, unfortunately, like we cannot meet each other in person, but hopefully like it will be possible to present at least this way. And what I want to talk about is the history of online and mobile. Yes, I've remembered that. Unfortunately, I didn't remember everything, I'm afraid. So like if you can think of some milestones that I'm not listed here, please just share it here as well, because like lots of people contributed here. Lots of companies actually co-funded this and it will be pity not to mention them. So, if I can see how to get there. To the next slide. How comes I cannot go to the next slide? What happened? So I'm afraid like we are going to be without the presentation. Are you using a LibreOffice to present it all from a PDF? I'm using the LibreOffice. But if you export the PDF and use some PDF, you have to show it to me. Or the design mode. Like I'm even touching the next button on the presentation and it's just not showing. At least I am going to export as PDF and show the PDF and then because it's fast. Like it all worked like a charm yesterday. Okay. Tendi, we can see typing your password. My password? I haven't typed my password. Are you sure? I'm sure. Much better. It was not the password, it was LibreOffice. So I think now it's kind of works. Yes. So, terribly sorry for these five minutes. And so it actually the online and mobile like trying to all, trying to get the tons of code that is in LibreOffice and previously was it's open office and star office. To something like a mobile platform and online started all with a mobile app. So originally it was some kind of like research project back in the Suze days where Thor and Michael started cross compiling to Android. And it was not only like cross compiling to Android like we were trying to cross compile to other things as well. So most notably Windows because at the time like the build times on Windows were just terrible and so like we were trying to use MinW for things to like make it faster. And part of that was like, yeah, well, when we are cross compiling, like why not to try Android as well. Like there were lots of limitations at the time. So the linker in Android like had a limited number of libraries that it could handle like it was something like 96. So it was necessary to shrink the app and actually like make it fit the limit. So lots of things had to be like statically linked all together, lots of work there. Of course, like there were some like third party libraries like font config, we were like somehow using the assets for the fonts or some hacks on top of that so that like files can be shared by Android as assets and can be somehow loaded from the assets. All this merge lip, Matush Kukain spent a lot of time like taking the components into some bits that can be like statically linked inside and run from the code first loader. Deeper game was a total nightmare. Like you had to start the app, wait, like put the sleep inside then connect your GDB somehow to the Android device or to the emulator and then hope that like it attached and then like from the command line interface like you were able to debug something. And yeah, lots of lots of things there but it resulted in the first version of LibreOffice actually on the Android. So it was not usable for real work but you could see something that like still exists. Some things very similar still exist as an app in the Android, this Android open office or how is it called? Looks like this actually, so like the full UI but like for us it was not enough like we wanted to go further. So in the following years, the approach like changed from this like entire UI visible in the app into something that was like rendering the whole pages. So for a viewer, this was a great step ahead because like now the UI could be somehow like Android but the content inside where just one page fully rendered. So like when you try to zoom inside or anything like that, it didn't work real well because like you would have to re-render the entire page in some much bigger resolution which would take a lot of resources and a lot of time. So it was not good. Of course, scrolling the entire document it was not possible either. So we were thinking like how to get it further and the answer was thought rendering. So it was not only that we would be the only ones thinking that the thought rendering is the right approach to this. So it started in 2013, just after like this collaborative productivity where it spun off by Suze and we were lucky enough that we have got a client called Cloudon who needed a mobile app on iOS because so far like they had a lot of installation of their existing app but their existing app was something very weird. So like they had a lot of virtual machines that were running Microsoft Office inside and they were kind of streaming like what was happening behind the scenes on the server down to the iPhones and iPads. So like you can think like how it could ever perform but like it actually performed because the video was like compressed quite well and when just there was some cursor blinking or something like that, the video was handling that just okay. But like they wanted to switch away from this approach to the app and instead like build a native iOS app and we were helping with them with that and they wanted to have the tile rendering because they thought that was the right thing to do. Also like it was visible that like PDF viewers at the time used the tile rendering as well and like in some of the PDF viewers at the time you could see that they were rendering tasks and like the iOS even had a convenient widget for that. So like you could have a widget over your entire screen that was asking for the tiles for different resolutions and it would even like support the transition from one layer zoomed to another layer and stuff like that. Just to remind like what is the tile rendering for those like who do not know. So it is technique that we are using in the code for like displaying the content of the document. So basically like what you are seeing on the screen is not like the font as you would imagine that. So like character by character, but you see it as small images like 256 to 256 pixels that are like one next to other. So it is actually like a picture what you are seeing that is consisting from small pictures and that is like what is being updated when you type. So in this 2013, this LibreOffice Kit was started as a thin C and C++ API to access the internals of LibreOffice Core because we thought the you know API was like not serving the purpose that we needed for. It was not performing well. So we needed something that was like much tighter into the code and like where we would be able to directly like instruct the core of LibreOffice to do the things that we needed for the tile rendering and later for the editing. So the callbacks of the events that come from the call are that can be triggered by the timers or the user's actions like basically like sent back through the LibreOffice Kit as well. And so the continuing here in 2014 and 2014 was like further for the use of the LibreOffice Kit for rendering. So it was introduced into the Android app thanks to Smooth who helps co-founding this at the time used the compositing code from Mozilla because as I said, like on iOS, there was an widget that was able to handle the tile rendering but it was nothing like that on Android. But Mozilla was using this in their Fenec project, this tile rendering as well. So we thought like, yeah, sure, let's take it so that we do not have to reinvent the wheel. So that was that. The Java part was supported from that. And then editing was made possible later thanks to Miklos Weina and it was done under the TDF tender, the initial word to start the editing in the Android app. So you might be wondering like where the online final comes to the play and it is exactly like here. So in the 2015, finally, we have found some co-founding for the developing of online. So thanks to Icewarp, we were able to create a viewer and then shared editing. So the viewer, that's obviously like what does it do? So like the user was able to open the document and see what is inside and scroll there and zoom to things that they wanted to see. But then the next thing was shared editing. So first like one editor could edit and then even like it was possible that multiple people were able to see the document, but only one of them was editing. And there was a button in the UI that allowed the user to say, well, now I want to take over the editing. So I'll be editing instead of the person that is editing just now. And from that on like they switched to the other person editing and like the person was editing from the norm. And of course it was not enough. We wanted the full collaborative editing. And that was something that we like totally feared of like how we are going to do that, how we are going to provide like multiple presers, how we are going to provide multiple selections and everything. And luckily we remembered and realized the multiple views feature in LibreOffice that I've never seen so far anybody used on the desktop. Like it is the thing you have in the window menu like next to the help that allows you to open like next view of the document. So like you can see the document like twice and even have like one selection in one of these documents and another selection like in the other view of the document, but like why one user would use that? And suddenly like this happened to be the core of everything for the collaborative editing. Luckily like this feature just works very well for a feature that I just cannot imagine anybody using on the desktop normally. And so like it provided the multiple presers, the multiple selections and it even provides the possibility to have like several dialogues open at the same time, which is awesome. Of course like whatever we have to improve in the collaborative editing will now like improve even this feature, but luckily like lots of things just worked out of the box. And then it was more about the binding that into the online itself than like having to develop it somehow extensively. So for the online, of course the server part was in C++ for the client side. Like we didn't want to write everything from scratch. So we were searching for some project that would provide some title rendering and the best at the time seemed to be leaflet which is a mapping software, so which uses styles as well. We had to hack it very extensively. So maybe looking backward, maybe it would have been very like if we invented something on our own and develop it on our own, but at the time it looked like the reusing is the right thing to do. So that's what we did. So then on the other hand in the mobile apps in the Android, like more features they're added to the toolbars and elsewhere thanks to many people. And during this time on the other hand in the online the routing of dialogues from LibreOffice was introduced because until now, like all of the things that needed some users interaction were done so that we had to re-implement the stuff in JavaScript. So the various dialogues, like search dialogue had to be re-implemented then like dialogue for inserting tables and stuff like that. So it had to be reinvented which seemed like not a good approach because it was like increasingly hard like when we wanted to introduce all of the paragraph or character properties like it would be just too much work. So we came up with the concept of routing the dialogues directly from LibreOffice. So we didn't use the dial rendering for the dialogues instead like when they are invalidated we just asked for the exact part of the dialogue that was invalidated because it seemed as an overkill for the dialogues to use the dial rendering because the dialogues are just much smaller than the document itself. So like in the worst case like you can just send the entire dialogue like when you have the entire invalidate. Lots of corner case, this is very fixed because for example, like different users can need the dialogues in different languages or even like it has to be possible that the like two users actually opened the character dialogue at the same time. Due to that and due to lifecycle of the dialogues in LibreOffice Core, like we had to change the dialogues to be asynchronous. So like it is still possible to have the dialogues because it was so that like when you were waiting for some interaction of the users it was not the main loop main event loop that was like waiting for the users actions but the dialogue when it was executed like it run a different event loop like some sub event loop. And so the outside event loop like was able still to handle things like re-rendering the document and things like that. But the problem was when two users actually opened the same dialogue because at that time like the dialogue was waiting until like when there was like one type of the dialogue for example, the character properties and two users opened that at the same time like until the user, until any of these two users was able to continue typing like both of them had to close the dialogue. So we had to do it so that actually the main event loop is used all the time and these dialogues are asynchronous and just using this main event loop. So lots of the dialogues that be exposed in the online had to be like changed to this asynchronous approach. And it's turned out in 2018 that just maintaining two, three things at the same time is just too burdensome. So having this web version, having the iOS and Android disting implementations of all these things is just unbearable anymore. So Jan Iversen at the time just started prototyping and Tor like took it over and took it to the next level that like the mobile app itself would actually consist of big web view. And we would be using the same online code for the mobile as well. And surprisingly, the performance of this solution was very reasonable. So we went ahead and continued with that approach. And so the online, so the Android app was actually like changed to this approach as well in 2019 and done the web view as well. So from that on again, like there was shared code that like when the online was improved for the mobile things, it was possible to have it in the apps as well. Lots of investment into that was thanks to thanks to Edvinis who helped go finding the iOS part of this, which was awesome. And it was still not enough like this, like having this disrouted dialogues. So we were considering what to do next and the next was actually like just providing the information about the look and behavior of the elements that are happening in the LibreOffice core and wrote them to the mobile app and their render them via JavaScript. So actually, like when you see here, like this is the mobile app. I will move myself somewhere else. So this is the mobile app and inside this, this is the sidebar. This is the sidebar that you know from the LibreOffice but it is just like provided the information like what are the elements inside the sidebar and the actions like that should be called back. And like most of them are you know commands, but of course further for some additional elements in there we needed some additional tricks. And so the additional trick was reusing the UI test API. So you may remember the Marcus Morehart's UI test framework that is like used for the testing of the UI in LibreOffice while the building in Jenkins and the CI. So basically they are using the same thing because like that way allows us to nicely hook into the dialogues and see like which elements are in there and change them in the way that is needed. And also like get the callbacks from that. Like when there's an action happening in the dialogue like see it on the online side and re-render the JavaScript accordingly which was then base for the further work on the notebook bar. So now in the online you can see a beautiful notebook bar which is actually the same notebook bar that you have in the desktop application but the information about that is rooted via JavaScript from the core and the actions are like updated according to the UI test commands that are sent back and consumed by the core. So now we are getting to the future. So for the future we would like to use this the JS dialogues for everything. So instead of the pixels that we have to use for the dialogues now use nice JavaScript rendering for that the sidebar in the desktop case should use this as well. But of course like we cannot do it as this control by one finger but something like more advanced that looks more like the sidebar in the desktop case. We would like to reuse the usage of leaflet JS and like use canvas for all the rendering instead. So now writer calc impress do that now but they still need bug fixing in master because like the zooming is not working there well and stuff like that. We would like to reduce the use of Poco just because like it makes things harder to compile and like the STD library is increasingly getting the features that we are using from the Poco. So the hope is that we will be able to kill it at some stage as well. And of course lots of papercuts fixing. So for the mobile apps we get a lot of great feedback from the Google Play reviews that helps focusing on the things that the people are actually using. And that's it from me. So big thank you everybody too who has contributed and everybody who has co-funded the work that we are doing here. So thank you so much. I'm just trying to share any questions please. Yeah, Candy, this is Gabriel from one and one. Yeah, hello. So I just wanted to ask that the direction is to remove the native dialogues that are rendered on server and replace them with the JavaScript dialogues? Well, that's the hope. Like it's still a far future but we would like to that but the dialogues like technically still live on the server. So basically like you would be still running the dialogue on the server like remotely but like you are not seeing the pixels rendered from that but instead like the... Yes, I understood the concept. I understood the concept. Okay, yeah but why? I mean, it's not more easy to just render the dialogues from server as image and some... It has various problems. So the traversal of the cursor is not like very, like you still have to go with every round trip to the server and back. Like for example, like you click a button for example, sorry, you switch checkbox or radio button and everything and like it has to go to the server and back. You cannot do any like nice animations and stuff like that. When you have that as JavaScript dialogue like you can style it with JavaScript just beautifully as you wish and it is still the same dialogue and you still have the same functionality. So that is basically the motivation. Yeah, yes. Like it is not a total priority but I just, this my personal... Yeah, but this doesn't mean some overhead on the client side for duplicating, let's say the dialogues or the user interface. Like you mean from the programming point of view or from the performance point of view? Yeah, yeah, from developing. From developing? No, because like we are taking the dialogues that are in LibreOffice and actually like traverse the content in VCL and create the JSON from that. So it is just scanning the dialogue like add this inside the structure of the widgets that are there, dumps it into JSON and then sends it to the online. Yes, yes, that I understood but still the user interface the graphical appearance of the dialogues. Should be made on the client side, right? Yes, but like that is very trivial. So like the, it's just HTML and JavaScript. So like the browsers are demise to it. Yeah, and the functionality is on server. Yeah, I understood. Okay, thank you. Yeah, thank you so much. Okay, I'm afraid I need to finish so that the next presenter can go ahead. So she won't.