 Hey guys, good evening. Welcome to the very last slot in the open document editor staff room. I'm happy to have so many of you still here. It was a great day. Wonderful program here in this room, so thanks to all the open office and the office and who else was here, a biterger guys presenting. So let's finish off this day with a session of lightning talks. We got seven talks recruited here. Perhaps one more if we have the time in the end. Here's the rules. Everyone got five minutes. I'm having some stopwatch here. 30 seconds before time's up, I will be standing and looking at you. And at the five-minute sharp, we will all kind of get up and give you some applause, so to properly cut you off in a friendly way. And then the next guy comes up. So the order is two times Marcus Morehart, then Swanter, then Samuel, I don't know, I forget. Oh yeah, Core, two times, and Jamux in the end. So without further ado, Marcus. Marcus, we talk about UI hacks. Marcus is one of the early contributors to the project. It's been active since, I think, March 2011. So how are you doing, Marcus? Thanks. So I will talk a bit about UI testing. There was a tenure from TDF about a year ago, I think, about developing a UI testing framework. We have a lot of testing frameworks already for normal stuff, but developing a UI testing framework is not that simple. There are a lot of different approaches, but most of them have some really, really ugly parts. I think they're the best ones at the moment for web stuff. But yeah, I've been thinking about that for many years. So I've designed one and implemented as part of the tenure. It's an own implementation. It has two parts. We have an introspection library in the Lib Office code that provides information about our UI elements to the outside world and allows us to send commands to these UI elements. So it's a really, really short layer above our UI elements and VCR. And then we connect to that introspection code with Python code through a UNO interface, a really, really simple UNO interface so that writing the Python code does not require any UNO knowledge. If anyone has ever done some UNO coding, you know that not requiring a UNO is actually a feature, not a bug. Element discovery. So finding a UI element and, for example, a button in a dialogue happens through the IDs that we have in UI files. The advantage of using the IDs is that they should be stable and that they are locally unique. So if you have a dialogue, it should be unique. And if you move, for example, the button to a different place in the same dialogue, you should still get the same button by going through the ID. And while our Trava API test framework that we inherited from OpenOffice.org suffers from a lot of sleeps that are random, and if a test fails and you notice, okay, let's increase the sleep time a bit and it does not fail anymore, you realize, okay, you don't want to have sleeps in your test frameworks. In UI tests where a lot of things happen unpredictably, you need a way to issue a command and wait until the event has happened. For that, we send now events for quite a few things and listen to the events on the testing framework side and resume our work as soon as the events are there. So what's good about the framework? Most of our UI elements are already covered. So most of the stuff that you find in a dialogue has part of this introspection library support. The elements are easily discoverable by the framework, so you can address them. Most of them have an ID. Some of them have none yet, especially the ones that we create and don't load from UI files. That helps also that we don't have any test failures if you just change the dialogue a bit. If our UX guys decide once again, let's redo the dialogue as long as they keep the ID, the test will still work. Because it's our own code, we can support any feature that we have in LibreOffice for users, anything as complex as we want it, we can implement it on our side. And quite importantly, we can place the code at the correct location so that it's as close to the code path taken by user events as possible, which also helps in finding bugs. So the bad, the ugly, as I mentioned, no UI testing framework is perfect. Yeah, if you want to support a new UI element, like a special type of button, you would need to add some code to the LibreOffice core to make it available on the Python side. Because you have to change LibreOffice, you can't just run the tests against any older version. The tests are quite slow. Loading LibreOffice takes quite some time, waiting until the UI is ready even more. So currently, the normal test is around five seconds. And yeah, we need to maintain our own framework, which is good to some degree, but also, again, some work for us. Yeah, that's it. Cisco is already writing tests, so with that, so apparently it works. If you want to do it, talk to me. I will help you. Wonderful. Thank you. Next question. Yeah, quickly. Very good question. On the one side, you make no courses. On the other side, you want to be close to user behavior. Users make courses. Yeah, but we don't need these sleeps that we have. So that's why we have these events, so we wait until the event is done. Okay, I see. So you just cut out the sleep phases of sleep. Yeah, the unnecessary sleep phases. Thanks. So I talked about UI testing while looking at our manual testing, which was more or less the source for all our UI tests in the beginning. Well, we did not have an automatic UI testing framework. We used manual testing for that, which looks a bit like that. You have a simple instruction. You repeat that, but yeah, it somehow doesn't scale. How do you do it in the future if you want to increase the tests? How if you want to do more tests, run it on more platforms? Do you want to do that? Just more people doing stupid instructions that were written down? Or do you want to actually use that? That scales perfectly, like taking Amazon cloud. You could do as much work as you want. So I've started working on that recently. The idea comes from the crash reporting that I wanted to test and which has some problems that we can't cover in our current test framework. So these tests run on currently on release builds. And the idea would be that we start a virtual machine to whatever we want there. We have a clean state. We can install any dependency that we want. We can test the integration with the system. For example, does the installation work? Does the connection to another service work? All the stuff that we can't do in our tests because it either requires to change the system or because it requires some dependencies that we can't assume in our tests. Part of our repository, some tests already for the crash reporting. I have some ideas how to do it a bit better with the VMs. There's some Python frameworks that you can use. And I want to do that for a number of things that we can't have in the manual test that we can't cover with the UI tests. But taking the UI tests into these tests allow us to more or less do whatever a user does, even if it requires changing the system. I think that's all. Test, test. Can you hear me? I want to talk about changes. I hope that in a few years we can use a different David Bowie song, maybe Heroes. So hopefully we can do this way. I want to talk about ODF. From one side, ODF is just the state of the user's work. It's used by LibreOffice. It was derived from Starfish, so it's very typical to LibreOffice. Maybe that's one of the reasons that LibreOffice is so dominant here in the ODF Editor death room. And it consists, like we heard before, about XML. So images are quite open, but there's a different angle. ODF is also a blueprint. It's an interface between different applications. So that's very important here. It is specified by OASIS where companies and people like me might conjoin. And it's a blueprint that others use this to use the data and give it to someone else, like once on floppy disk. And also very important, it's an ISO standard. There are many standards, but the ISO standard is very important because this has only been done by countries like Dean in Germany. And also very important, a country like Great Britain, Netherlands did, can say we have to or we demand that this file format is being used. And this is very, very important because some, you might, there's the biggest impact that ODF had was on Microsoft. Microsoft created in a very, very small amount of time the OXML standard. And it's not even, the name maybe you know it, it was confusing me a lot in the beginning. The first version of open document format was called open office XML, but then was changed because we're too specific to one application. So if we go to a standard, we want to use a more generic name so others people can join it. So it's called, this name was dropped office open, and office opening XML was born by just switching the words. I find it very interesting that they did that. And the most interesting part is, why did they do this? I mean, why did they invest so much money into creating their own ISO standard? And to be honest, I'm not sure, but it has to do with the ISO standard that governments can demand that companies have to fulfill the standard. And I believe that was heard that it's like a domain chain, but this time it started on the biggest player, the governments going to people like SAP and Oracle were large companies that supply this file format. So there's a lot, lot power in this. And I guess this is all quite often forgotten here that when I talk at the table, I want to sell my software and I care about, let's say, LibreOffice and I can't sell ODF. I don't care about ODF, yes. This is very powerful. I cannot explain how powerful and cannot estimate it, but they did it once. And I believe there's a reason that they have to do it again. And there's maybe a leverage how to break the monopoly on the business market. So first, what are the obstacles that we currently have? There are some of them. So first of all, collaboration. It's not good enough to send documents around. These times are over. Nowadays, we all have smartphones. We are all connected. And so sending these documents around is not good enough because you don't know what the others has changed. You want to merge easily. And if we do it for software, all the developers know we have source control system for the files and you can do merges there. And we have no way to say, like in Git for source code, what is the, what's the diff? And this should be defined by changes. The next time, there's no runtime API, like HTML head with the DOM. This is very important for the party software. And there's one of the biggest obstacles for selling. And last time, there's no feature testing. If I want to buy me a machine, then I took a test and what's the feature comparison. And nowadays, I see applications that they say, oh, we support ODF, but when I test a few documents, I realize they're very lousy. And there should be a better testing. And this is not possible yet. You can load, save and test. But if we would have something like a feature testing, then we would be very powerful. So how we do it, as I said, with changes. The documents are too large. And what we're doing, we're not, we're going on a higher level. And we say something like, I've changed the one millionth paragraph to red. That's what I did. And we abstract from the details, like XML, we go to what the user knows. By this, we can go across as many applications as possible. And of course, I talked about this earlier. We have to refer to a certain version that's developer snow. They use hash, but not again on XML because of verbose. We use it on this logical box. So what scenarios do we have in mind? It's, as I said, I can do like in GitHub. I cloned a document or there's read only document. I said, Oh, by the way, there's a typo. I do like to fix it. I only send this small change. Or if you say have a contract and then you return only the change, not the full contract with some kind of hidden changes, I'm not aware of, you can exchange no longer only documents, but changes. This is very powerful. And also a versioning system like give me all the changes since I was vacation and also powerful. You can sign the document. This is based only on XML, not the zip. And the signed document can be documented and changed by changing the site. And still you have the signed document. So you can do a ping pong of documents with with signing, which is currently not possible on there. A lot of other features. And I want to tell you that this should be our future. And you shouldn't get this eyes of standard opportunity out of your mind. That's it. Thanks a lot. So next one is kind of, I think I'm going to share that with Samuel. But Samuel, another one of the early LibreOffice contributors, I think June 2011. What's your first? Right. So this is about something that we just started to do. The project is called GPG for Libre. It's about integrating the new privacy guard into LibreOffice. This is all about signing and document encryption based on public cryptography using lots of cool stuff that's already out there. The project is funded by the German Federal Agency for Information Security. They do all kinds of things like audits, like security recommendations, but they also look into how to strategically change the software landscape to make everybody more secure. And this is one of that. So conceptually, it's about using the GPG, the privacy guard, and another set of auxiliary tools that are there, like key management and integration, for example, into Windows. And there's a nice API wrapper for that GPGME that goes via IPC to out-of-process tools and kind of offload all the security-relevant stuff to those tools. So LibreOffice doesn't really have to bother with keeping the passphrase secure and not just screwing up with the algorithms. So in the end, what should happen is that LibreOffice is able to sign documents and also encrypt documents with your private key and encrypt documents for recipients that you have the public key for. So you find it on the key server and you're able to encrypt the document for that recipient. The advantage to the established X5.1 certificate is that it's much better for decentralized organizations because you always have the problem if you're not a single company how to distribute the keys without trusting an external source like a CA for that. So, want to take over from here? Yeah, can do, but I don't know what I'm expecting. Screenshots? Yeah, screenshots. Yeah, the first steps we did was to make it more, how do you say, when the document, the encryption is broken, the signature, the current signature. There was a dialogue shown earlier, which not even had the warning box or something. So no icon, just a wall of text and you could easily ignore it. So the first thing we did put an info bar, a red info bar when the signature is broken and orange one when it has issues like an untrusted certificate or earlier open office versions and signed only parts of the document. Yeah, and the next steps are, yeah, we are currently integrating GPG for me into LibreOffice to build it and there is a small wrapper for C++ which makes it even easier to use. We'll be also integrating that. I think that's called GPG for me plus plus or something. Yeah, and then we're going to make your own certificates, your own keys visible in the digital signatures dialogue so you can use the existing dialogue to sign with GPG and later on also encrypt. Yeah, and there's all sort of wonderful follow-up projects there, so including PDF signing and stuff like for documents. So for PDF, there's a nice feature that you, when you sign a PDF, then there's a little area where you can put some facsimile of your actual signature there that then gets integrated to the document and something like that would be really nice to have for ODF as well. It needs a little bit of, it needs some kind of field, special purpose field then to contain that. And so for this signature stuff, I think that should be covered by the existing ODF spec. For encryption, we will probably have to propose something to the ODFTC, but that's the second step. Okay, so that's about it. It's broadly an announcement that we start working on that, so this is the first steps there. Any questions? Two questions. Yes. I think it's a good improvement that when the signature is programmed at the info bar, how does it behave when there's already an info bar showing some classification info? Yeah, they will be stacked on each other, so they all will be shown. So you can have a full screen of info bars. Ah, I love that. And second question, sorry. You mentioned PDF signing. Signing newly created PDFs, do you mean you need that? Yeah, pretty much. I mean, there's already pretty nice PDF signing, but it's again using this X541 keys, and it will be great to do that with GPG keys as well. I have no idea. It might be completely unfeasible, but it will be nice. Nice though. I haven't looked into the PDF spec there, but we're running out of time. Sorry, guys. Next one up is, I think, UCOR. Yeah, so UCOR is going to talk a little bit about it. UCOR is here since forever. UCOR is one of the founders of the Document Foundation, has been active in the Open Office project since, I don't know, 2002, 3, 4, 5, okay. So, Torsten tapped on my shoulder some hour or so ago if I was interested in lightning talk. So, I couldn't make a choice as usual. So, I got permission for two lightning talks, and I think I want to start with this one. And that's about Document Foundation. Many of you will know, and some or many maybe won't know, about all the good work that's being done behind the scenes to support the development of this great ODF tooling. It's called LibreOffice. And the Document Foundation, it's the foundation behind it. And apart from the LibreOffice project, it also hosts the Document Liberation Fronts. So, providing all the nice document filters and adding new ones to that. So, very sure. Not to be mixed up with the Front of Document Liberation. Oh, there's all kind of fronts. It's the Document Liberation project, to be honest, but it's just so, yeah. I like Liberation Fronts. Okay, TDF is the House of LibreOffice. And, yes, we started in about 2010. And there's a solid Berlin-based stiffening behind it, and statues and all the stuff. But what is it about? Basically, people that are active, working on all kinds of LibreOffice stuff can say, I want to be a member. And later, I will explain to you why it is important to be a member. And, of course, you can be accepted as a member for one year. And after a year, you are invited to apply again if you are doing good stuff. And there's a membership committee. It's mentioned below. That's looking over the process of people being a member or not. In between, there's the Board of Directors. And the Board of Directors does great stuff to make the whole thing going on. And both the membership committee and the Board of Directors obviously are chosen from the members. And then we have the Engineer and Steering Committee, where all those engineers and people that are related and interested to discuss about what's really going on. And not an official body in the sense that it has a voting rights or whatever. It's the advisory board, all kinds of organizations interested. And this is the last slide about TDF. And this is how it shows. The Board of Trustees below, it's not just members, but there's also some formal legal rules. That's why it's called Board of Trustees. And from the Board of Trustees, we choose the membership committee every two years and the other two years. So that's intermediate. The Board of Directors is chosen. And why the Board of Directors is so very important because Librov is, apart from all the great stuff that developers do, there's a lot of work behind the scenes that's enabling the work in case of infrastructure and people supporting tooling and whatever. And that is made possible by all people that make donations. And the Board of Directors knits all together and finds the projects and the tooling that needs support. So the Board of Directors looks after spending money well for Librov's development. So that's about TDF. And anyone interested in being a member, because if you are a member, you can vote or even stand for the Board of Directors, is welcome to go to documentfoundation, documentfoundation.org. So far, here's one. So that was my presentation's one. Anyone else questions? TDF? Okay. Then on top here in the, maybe I'll just start. The second thing I want to talk about is a product called Librelex. And let me just show it. Librelex is something that gives you a dialogue and to start document production. And it has some nice features and it has some old school sites as well. It started years ago. I'm running a small company in the Netherlands and we're doing some support for organizations using LibreOffice and prior to that OpenOffice.org. And this is typically old school. Within your office application, you start something and to create your documents. And even a long time ago, it was all hard coded. And this is flexible. It's based on configuration files. So here, if you choose another document, you see that this dialogue is dynamically rebuilt based on the configuration files. And if, let me take this one. As you see, there is some language information here. And you have some lists there, madam. And if you choose to make it English, you see that both the dates and the lists, all the stuff changes. It's all based on configuration files. And you have, if you prefer, you have settings. Well, also you can have choices in templates for presentations, for example. And if you have a, this is a memo document and you can start it. And this is a demo. And when you hit okay, you get both a document and you get some predefined file naming. And you can start editing the content in case it's in some protected section, whatever stuff you can edit it. And there is some stuff that you might want to print it with logo on black and white or send it as PDF or stuff like that. And emailing that it automatically is mailed as PDF with logo or as word file to someone if he needs to edit it. That's the kind of stuff that makes working in an office document often easier. There's one thing that I want to show about flexibility. So we have the memo document here. And for example, this can be made shorter, this field. And you can add extra fields. And I can show that. Here's the configuration file. And I just prepared some new lines. And I have to save it, of course. And you see now this is a short one. And additionally, there's this type of information available. Well, that's all nice and fun. And I started to open sources last year. This is now open source. It's all old school basic, old school basic. I open sourced it. It was in the planning anyway. And there was some bug in the dialogue handling with GTK3 or whatever. And that's fixed now. But if you look at the configuration stuff, that's a bit old school. And of course, the ideas are that it can be easily linked to document management services or that you create a document from a document management system. And that if it is needed, it can be picked up in LibreOffice and do stuff with auto text files and stuff like that. That's all ideas that are possible in future. But this is just how it should be to start from. Yes. Where's the code? It's just here. And when it's published somewhere, I can just share it with you. But it's not in a public repository yet. What's the license going to be? What is it? I'm not in licenses. I thought it was, yeah. There must be some. I think it's LGLP3 plus something like that. So, yes? What's the difference? Any more questions? Okay. Thank you. So, we have two more talks. James, perhaps? When you're done? Okay. This is very lightning because I just made some slides. So, next one up is Jan Marek Glorowski from City of Munich. One of the really large German deployments of LibreOffice, some 17k seats, I think, running LibreOffice, most of them on Linux. And he's been active in the project since when, 2008, 2009. So, we left two here, something like that. And I need to turn out put. Hmm. Can you do that now? Okay. Okay. So, instead, while we're solving the technical issues, this is Olivier, and you will be talking about the new help system? Yes. I would like to show you what we have achieved so far. It's basically a new URL. It's VM173.documentfoundation.org. And of course, we have some issues on the CSS. But what we have here is an imitation of what is the help system. This is the browser. This is the page rendered by the transformation. We have also collected all the bookmarks in the XHP files. And if you click on one of these, you get the page. And on the top, you have a search bar that if you type a specific keyword, it's supposed to be to collect all the mentions of Calc into this. And then you can then navigate. I have one more thing to show. What you see here is debugging the XML. You see that you can, this is pure HTML that has been transformed. Okay. So, we try to preserve, yes. What we have here is only the index.xml, which is the entry page. There is a JavaScript microserver running there. Okay. So, that takes the links and transforms inside with JavaScript. I also would like to show if you can type after the URL, slash index.html. And then a question mark. Question mark page equal. Equal. Share it. Share it, slash test.xhptest.xhp. Yeah. So, I have modified the transformation to include new multimedia. So, you can have the page with the multimedia right now on the browser, but you can't have it on the current help system. So, if you start the multimedia, it goes to YouTube and brings you the, okay. So, this is what we have achieved so far in trying to bring the help system into a more modern technology. That's it. Okay. And just one thing. We planned, I think it's a good idea to have this system bundled into an extension. Okay. So, it can, what? It may be interesting to distribute in a different way rather than installing packages. Okay. And it can run locally or in a server. Yeah. Thank you. Okay. So, let me try to, can you help me? Which, what's the name of the, of your slides? My slides. Plugfest? No. This one? Yeah. Wow. Okay. So, yeah, after those technical problems, old laptop and everything, there's just a little overview about the stuff I've been doing in Munich for the last two months, something like that, with some breaks. Basically, LibreOffice processes all stuff to do in an event loop. In LibreOffice, it's called a task loop. And the current origin where I'm coming from is, yeah, there are two different types of tasks. Some are timers, which are somewhere executed in the future. And some are idols, which are executed instantly. Basically, there is some definition of busy. So, at some point, LibreOffice says, I'm busy. So, at this point, no idle task should run. But this is very strange implemented in different backends. And some backends even do not implement it at all. So, this is kind of a crazy definition of busy. There's the main problem is that it's really kind of random how LibreOffice processes the stuff. So, even if you say, okay, protest the next event or task or whatever, sometimes it processes two. If a system event is there, sometimes it processes even two. LibreOffice events, this is not really idealistic from the point of view, if you want to know how stuff is running in LibreOffice. And then there are some really freaky stuff, like there are some comments on the Mac OS spec, and we're saying, oh, at some time, we are losing timer events. Nobody knows why it's the comments are from 2000. Really, yeah. So, they are quite very old code. And yeah. So, this is really what the fuck code at that point. And we have heard that today in the talk from Michael Meeks about parallel processing with threads that already there are a lot of problems there. And when I was started and looking into this code, I can understand why there are problems because it seems that everybody just, for every buck in that code, they implemented work around instead of rewriting the whole stuff from scratch with a normal idea. And how, in a normal way, normal tasks and event loops working today in toolkits. So, where we are currently, we're only scheduled by priority now. So, like all the normal event loops, every event or task has a priority and is scheduled like that. So, we do, you know, completely those busy stuff. That's really crazy anyway. The other thing is that LibreOffice may or more or less polling with a task which just occurred because we were missing some time a time a task sometimes. So, we started just to pause. So, in case we missed something, we found a way to continue with stuff. The single system time was work except for macOS because I don't have a macOS platform yet. I will get one. It's some time that we frost them and then I hopefully can fix the macOS back into that it has a single system timer. Then there was a strange feature that every task has to wait at least one millisecond for whatever reasons. I don't know. This was very strange too. I dropped that too and I didn't see anything while it couldn't work in the future. At least all the unit tests which were there still are working. The refactoring of all those codes made also, I made it in that way that all single tasks and patches passed all the unit tests and even I added some more unit tests to test real strange stuff like round problem when we have two tasks with the same priority. They are currently scheduled. No, they are not scheduled because then the first task is working all the time until it is finished even with its process multiple times and then the second task is just tackling and a little around rubbing at that point. Fix that too. One really stressful test which I find because sometimes I really made bugs in it and all the unit tests still passed but the desktop unit tests and LibreOffice kit unit tests are so complex that normally they instantly fail if something is wrong in the event management or in the task handling. That's the current status. That missing is basically the macOS stuff. Where we are coming to is that we run the LibreOffice event loop just from the system timer. We don't have the polling so we just restart the system timer to execute exactly when the next task is valid or even if it's zero seconds we instantly return and process that. I had the strange situation when I refactored some code and merged it that it became faster that unit tests broke because they were too fast but I fixed those unit tests now and what we are going and want to have is to have locking so currently the main loop is not multi-threading safe. We have already have those problems where some events or tasks are created in another thread and then I run in the main loop and then stuff simply breaks and we want to get that too. This is currently hard because the tasks are owned by the threads so it's really basically the only solution to that is currently to have a main global lock for the event loop and lock it and so you can release the stuff. All other event loops have. Thank you. Okay six and a half minutes. We have a few times every few minutes for questions I think. All the hours in the event loops are just not owning the task and they're normally owned by the main loop and we want to have that in LibreOffice too. It's crazy stuff. Get rid of it. Yes my main original point was that something's changed in there and MainMarch got very very something's changed in that code and MainMarch got very very slow for more than 300 documents and I said wow and every time I thought I fixed it I found something new that's crazy and it's still a little bit hard because yeah it's very low ground and plumbing in LibreOffice and if you change something there everything breaks basically it's a little bit hard. I don't remember what it was but when I deducted something in the last time I saw that it was just event handling and looping and all this stuff so it could be fixed with zero one millisecond to zero millisecond slip. That's probably our thumbs up. I mean I already learned some refactoring patches but we're really hard stuff. It's hopefully landing in the Hackfest next Monday, Tuesday. Probably that's what we're a little bit too long for. Thanks a lot everyone. You've been very kind with me, very disciplined presenters. Thanks for that. You've been a wonderful audience. Thanks for that. We have five minutes left. What I would be curious to hear some feedback from you guys. So what was the talk that you missed that was not here in the staff room that we should really have next year or any other feedback? You want to say something? I see it. I'm only a user of that and I use it maybe half a year no longer because before I came from Windows and then they changed to Windows 10 and then I changed to Linux and I'm happy with that but there is no office and I need office and so I use the Libre office. So you would have liked some more user focused topics or I mean there was the Sleep Relax that was clearly I really love it. I'd like to try that really and I'm going to code this out. It was okay for me. Okay he says it was okay. Cool. He says it's interesting what kind of problems we have with the smile in his face. Anything else? Any kind of feedback? Anything at all? Otherwise get home safely. Enjoy the rest of the fostum.