 Welcome. Good morning, good afternoon, good evening, wherever you are. Welcome to a little update on the LibreOffice WebAssembly story. We kind of, perhaps overambitiously, promised LibreOffice in the browser life and in color today. There will be some colors on the slides. There's still not a very demoable version from the WebAssembly port just to get expectations right here. We're sorry for that. It turns out to be quite a massive moonshot, but at least we will give you some updates on where we are, what we achieved, what we're planning to do, and some updated timeline. I'm here with Jan Mavek who's been doing the bulk of the work of that porting really. So in a moment I will just hand over to him to update you on what was going on. I was also doing a bit of work here and some hacking, but he really, he and Armin unfortunately can't be here today to bulk off the work. First of all, what this is all about. So LibreOffice WebAssembly is an attempt to get LibreOffice running natively in the browser, which means compile it down to WebAssembly, which is a very special binary format that runs natively in the browser, not like JavaScript, very similar from a high-level point of view. There's a number of reasons why we think that is important. We gave some, we pitched that last year for the LibreOffice conference. We gave an update at FOSSTEM this year. It's a very nice complement, we believe, to other solutions beyond the fact, obviously, we believe that the browser as a platform is very, very interesting and it's a very good way to reach vast numbers of users without having to port to any native, whatever they're running devices. So we further think that the time is ripe for that. We've seen a number of high-profile ports into WebAssembly in the last year or two. For example, AutoCAD have ported their engine natively. There's a ton of smaller projects, many of them open source, for example, for encryption or other stuff that you really would like to run as close as possible to where your user and your data is. So, and there's been quite some nice improvements. So we still do believe, although we did hit the outsized number of problems, particularly with the toolchain, we still believe that this is the right time to do that and in general, that things are there, available and ready. We're very grateful. This project is funded by an LNET. Thanks for that. Who in turn are funded by EU Horizon project. Yeah, so thanks to an LNET foundation for helping us out here. Let me now hand over to Jan Marek for a quick update on where we are, the challenges and what's coming. So, as you can see, that's basically our links from last year. There's still more or less up to date. We just pushed a few updates in the last days during the conference to that branch. You can still build LibreOffice Valsum completely and it will finish the build, but you will have runtime problems. As you can see, although in the slides you have little progress since FOSSTEM, because of the problems from the size of LibreOffice, linking and building the stuff in Valsum, we decided to go to a roundabout to do a really static Linux build, which is basically the whole stripped down of Valsum build, but the better debugging and runtime environment. And that is also working in the branch, so you can build a single S-Office binary and it will run without any other dynamic linking. There are already quite a few changes to accomplish that in master, but more stuff is pending still. There's still a lot of stuff to clean up. We hope we can push more stuff in the next time. We did quite some changes, like you've seen some configuring changes and also part of the static build stuff. The slides don't seem to be updated. I thought it was on my side, but it's your fault, seems to be like the chat is wrong. What's the current slide? Is the current Valsum status? I see that now. Yeah. Okay, great. We didn't. Okay. So let's hope it's holding up. Okay. Yeah. So, right. So, more broadly, so if you look at my commits and Jamalix commits and master, that's probably the majority of the changes since February are related to the Valsum project. There's also quite some stripping down changes from Armin there, just to get, let's say, to slim the, to slim it down and just use basic writer. Part of that is also already in master, not everything. The ongoing development as you see on the slide is indeed, so that's the latest and greatest with the last, the latest changes from yesterday, the future Valsum launch. The slides are again stuck. It seems that you have some internet connection problem. And the jitzy, there I can see only Dennis event listing and not the slides ever. Okay. Just mention it. Thank you. Okay. Okay. So I thought the theory is that if we, if we keep talking here that it would then show the slides or the screenshot, which is not the case. You see us, our moving hats in the video. Now. Yes. Now I see you perfectly clear. We need to bounce up and down a bit more. Don't stop bouncing. Sorry. Continue. Okay. Let's go. Okay. Even with stuff in the problems, just to have a reminder of what we originally had planned and what the VCR demo would be running. And we would have Qt5 at the main Valsum backend and doing some probably end-to-end encrypted communication between two LibreOffice versions. Yeah. That was a little bit over optimistic. We didn't expect that many problems already in the tool chain. So, yeah. With that, we are going to what and why the Linux static build. The first thing is the development itself is quite hard still with Valsum. We had really long link times and something like 30 minutes for linking with Valsum binary for normal setups with less than 64 gigabyte of RAM. It wouldn't link at all and would run out of memory. I think it was actually killing your box even with 64 gigabyte because actually your operating system needs a bit of space. Yeah, but that was definitely an environment you do not want. You couldn't do any native development in the browser. So, we decided, okay, why we have those general problems? How can we continue from another angel? And that's why we decided to go with C++ static build and that is actually working and you have those GDP and can really debug stuff that is broken. We patched a few stuff there based on the iOS and Android static build so that all the static build components are linked in. Currently that is something you had to manage manually but without changes you simply can build all the components and they are linked in automatically and the correct lookup maps are generated. That's even better than the Android and iOS build because they have manual list, manually maintained list of components that you need to link and the Linux static build is now self-determining what dependencies it needs. And again, the reason why we wanted that or we needed that is it's kind of simulating. It's like the GTK viewer simulating online untied rendering or the Android viewer. It's like simulating the environment that we have in Wasm like everything linked into one static binary. We were much faster, for example, for the stripping down because we didn't need to wait half an hour to an hour and needing massive amounts of RAM for the development cycle. Thorsten, please turn off the webcam. It should be more stable then. That. And then once we got to showing slides you can switch it back on and chat a bit. See you then. OK, hopefully better now. Yeah, at least the slides are really high resolution. OK. So anyway, just over the last half a year basically the development experience has quite improved. Normally the default M-scripten version used for QT is some old one-point-something version but the improvements on all sides were so enormous that we decided to ignore that and go to something newer. Actually, I'm currently using 2.29 which is the current release which means that those 30 minutes link times get down to something like a minute. It means that the massive gigabyte of RAM is not any problem anymore because now it doesn't exceed something like 3 gigabyte and even more important is, probably not more important is that now you have Dwarf information directly from C-Lang in the Wazen binaries and you can actually work and debug with those Dwarf information inside Chrome which before was just basically decompiling the Wazen into some kind of Wazen assembler and then you could try to understand that stuff and it was hard. So from that side you can see that as much as we thought okay, Wazen is now five years old, stuff should work. It still improves on a lot of times and I just recently had looked for some stuff with two or three-year-old Wazen assembly code to recompile that and the assembler gave errors so it's still a moving target but stuff massively improved in the last half a year. Maybe just one anecdote here. So it's like you know this breaking your tool chain since 1989 so I think one of our project members once did a t-shirt for that and it's really true. So with LibreOffice it was really hitting all the problems. The good news is that the M-scripten tool chain is improving and they're taking feedback and they're taking it serious and also on the browser side. But the anecdote I was about to say is like if you want to debug LibreOffice like with source-level debugging, you probably need to as of today still compile your own browser because there's a built-in limit of I think one million lines. Beyond that they will just give up and not show you any line-by-line source-level info. So I still believe it was worth doing the static native build. So the next thing is it's going to still open problems we are facing. One thing is bridges and the unumapplings to really get over bootstrapping and start the stuff. It's not 100% sure if we can really implement a bridge or it's better to work around it. There are some ideas but not really it's essentially the same problem that the iOS, first the Android port and then the iOS ports were facing that the unobriges are kind of extra-difficult code. They have that sometimes itself modifying code. Sometimes it's code that's generated on the fly. So you have code that generates a similar code and then jumps on the self-generated code and does something magic. On many platforms you can do that. If you know what you're doing you need to hack some assembler on some platforms like iOS you just can't have self-modifying binaries for security reasons. So actually my conviction is that for something that does not need any remote connections or has no built-in Java or a Python that needs to dynamically call stuff you really don't need this bridge thing. It's just that it's the number of ties it has all over the source code is quite large so still trying to work around that it's on the stack perhaps something to do later to write out the bridge for that sort of like iOS and WebAssembly and Android to write out the bridge entirely. We will see. For the while we're trying to do what the iOS port has did and just have a minimally not a working bridge but a fake bridge that does enough to survive until the first document is loading. So the second thing is something like persistent part of a file system image I mean we are already generating a file system image to get all the standard configuration files into the VASM environment. We are not yet sure what way to go to make persistent writing stuff for the user's point of view usable. I'm not sure we need to go there. Currently the LibreOffice first start-up is to start LibreOffice generate a user project profile and LibreOffice and start LibreOffice again. Obviously that's not really possible in the browser which would mean if you end LibreOffice or the VASM file the image will be gone and you start from the beginning so in this loop we will see how that's going there. I mean generally we need to re-build some G-Build stuff and we need to update it when we re-base it but most of the stuff is just working just if there are larger things we need to re-build the stuff. And of course upstream merge that into master so that the status on the branch my gut feeling is that G-Build is mostly good there just probably need some cleanup and then properly merging that into master. Right in terms of setup there we're still struggling a bit with M-scripten because it turned out that depending on when and on which time of the day phase of the moon linux version we were installing M-scripten we will get subtly different either despite the fact that you were kind of checking out a very specific version we were still getting subtly different local setups because of the NodeJS crap that this is pulling so we had docker images for building and I'm not sure whether that's the right approach because then you have all kinds of funny issues with the strut environment and then being able to or not being able to debug that because the file mapping is different but what you think is that something that has stabilized as well or No idea I'm still building without the root environment. The good thing is that the current status of the static build is that it really doesn't need any static any local libraries completely now so you can like a windows build you can build everything in and the only thing you basically need on your system is the compiler everything else is downloaded compiled and linked locally so I do not even use the strut environment for any more it works without so maybe that's the best way to go for that problem just to not depend on anything else than the compiler we will see like all the time it does seem to settle down there I'm stabilizing whether by sheer luck or by having G build now really fixed I don't know maybe we will build something with Maison next year but the stuff is there it can build right there but that's not a different problem so this is kind of the updated project plan and timelines so we still think ECL demo will run soon let's see if we are all predictions are now better than the last time I was spending the better part of the night trying to get this going and actually I got it much further but you know there's always this you only see the next door after you open this door so there's always another room so it's a bit hard to predict but when we're kind of going through the VCL in it like the bootstrap code like line by line and the ROMOS at the end so a bit of more focused work and another night shift or two the hope is that really we have that and we will let you know by social media then on Tuesday, yes? maybe then the current builds are still big even with stripped down or something like that if you have a Vazem build with debugging information you still get the one Djabyte binary don't build with debug information and optimized builds still 100 megabytes so there is still quite some part of improvements to do there basically a lot will be switching on to internal browser RPs which provide the same the same tools and calls like ICU and NSS so we do not have to compile them ourselves we did some Armin did some nice analysis there like you remember the tools we were using this blow tee from Google? I think so so we were just counting checking the binary size and then mapping to modules where the blow comes from and unfortunately quite a large bit there is something like ICU that is hard to get out if you really want to be able to load OVF documents but the good news is that browsers have the same kind of API they even bundle ICU I believe instead of shipping another ICU just use the browser API the plan but we are not there yet another thing is still that we have Qt5 at the main back end that is working but Qt5 also has its own ICU library so probably also a dedicated code there but that is generally working on also Qt5 is used in the static build to start writer and it is working there and yeah basically yours I am not that optimistic that end-to-end encryption where we are working next spring but first time is there we have some target timeline and we have again thanks to NLNET to be very understanding there that this is a kind of interesting very important but also very challenging project and they gave us some extension until early next year so we are still funded by then and we will continue fighting and hopefully succeeding so I think this end of the year to get some visible demo that is achievable we will see then what to prioritize whether we go for smaller size or whether we go for something like end-to-end encryption but so far there were massive challenges but most of those challenges half of those challenges were like the build system and Janmar kind of struggled with that and in the end won and got it going and the other bit was the M script and WebAssembly ecosystem and they also nicely without us doing much solved those issues and improved that massively so right now the way things are going is still very very positive so I'm enthusiastic and I'm also positive of that I mean we are not giving up we are still hoping everything will work out there's only onwards there's no giving up okay so a bit of time for questions I think we have like some three minutes left so we would like to thank you for your attention we would like to thank Nelnet and EU for funding this or co-funding this and we did now switch off the screen sharing and switch on the camera so you can ask us questions maybe we should let me try there we go yeah and Haiko asks how about QT6 QT6 that's a good question because Mikhail Vekhon from the city of Munich he tried to build the QT5 back end with QT6 yesterday or a few days ago and he basically wrote on ISE it just works there may be some problems and improvements needed and built with QT6 and it will start LibreOffice and there was no obsidian LibreOffice and now you tell me we should have switched to QT6 immediately I would have had a demo to that yeah we'll see like the back end like how to render in the browser that's a good question so was there rendering that kind of provides already quite a lot of strength I think that would need but QT6 is also interesting because they also have questions quite some time they have native WebAssembly support we will see whatever is easiest then I suspect the