 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 bit of your 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 is up. I will be standing and looking at you. And at the five minute job, 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, and then I forget. Oh yeah, Core two times and Jimux 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 here you go, Marcus. Thanks. So I will talk a bit about UI testing. There was a tenner 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 tenner. It's an own implementation. It has two parts. We have an introspection library in the Leap 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, 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 Java 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 idea that the test will still work. Because it's our own code, we can support any feature that we have in the process for users. Anything as complex as we wanted, 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 early process core to make it available on the Python side. Because you have to change the profits, you can't just run the tests against any older version. The tests are quite slow. Loadingly profits 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. Questions? Yeah, quickly. Very good question. On the one side, you make no pauses. On the other side, you're going to be close to user behavior. Users make pauses. Yeah, but we don't need these sleeves that we have. So that's why we have these events. So we wait until the event is done. Okay, I see. So you've just cut out the sleep phases. 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? 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 currently 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. And I hope that in a few years we can use a different David Bowie song, maybe heroes. So hopefully we can do this way. So I want to talk about ODF. So what is, 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 is 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 for 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 you go to a standard, we want to use a more generic name so others people can join it. Yes. 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's what I heard, that it's like a domino chain, but this time it started from 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 on 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 a maybe a leverage, how to break the monopoly on the business market. So first, what are the upstuckers 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. Like 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 systems 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 had with the DOM. This is very important for the party software. And this is 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 like 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 better testing. And this is not possible yet. You can only 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 basically 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 their lot of other features. And I want to tell you that this should be our future. And you shouldn't get this is a standard opportunity out of your mind. That's it. Thanks a lot. So next one is some kind of, I think I'm going to share that with Samuel Samuel, another one of the early LibreOffice contributors. I think June 2011 was 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 document 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 new GPG, new privacy guard, and another set of auxiliary tools that are there, like key management and integration, for example, and to Windows. And there's a nice API wrapper for that GPG ME 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 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, so sign documents with your private key and encrypt documents for recipients that you have the public key for. So you find it on a 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 as on an 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. 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. 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 some flexibility 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 then this is the first step there. Any questions? Two questions. Yes. I think it's a good improvement that when the signature is broken, that it's all the info by, how does it behave when there's already an info by showing some classification info? They are stuck in there. Yeah, they will be stuck on each other, so they all will be shown. So you can have a full screen of info bars. Second question. Yeah, pretty much, I mean, there's already pretty nice PDF signing, but it's still using, I mean, it's again using this X521 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. I haven't looked into the PDF spec there, but we're running out of time. Sorry, guys. Next one up is, I think, U-Core. Yeah, so Core is going to talk a little bit about, I have seen it since 2010. It's here since forever. Core is one of the founders of the Document Foundation, has been active in the Open Office project since, I don't know, two thousand, two, three, four, five, okay. Not too early. Okay. Yes. Here you go. Just keep. So Torsten tapped on my shoulder some hour or so ago, if I was interested in a 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 the 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 short. What's up with the Front of Document Liberation? Not to be mixed up with the Front of Document Liberation. Oh, that's all kind of fronts. It's the Document Liberation Project, to be honest, but just so. Yeah, I like Liberation Fronts. Okay, TDF is the house at LibreOffice.org. And, yes, we started in about 2010. And there's a solid Berlin-based stifting behind it, and statues and all the stuff. But what is it about? Basically, people that are active, working on all kind 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 of not. In between, there's the Board of Directors. 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 engineering 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 kind 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 growth. That's why it's called the 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.org. So far, here's one. So that was my presentations. 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 Libre Office 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 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 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 ultimately is mailed as PDF with logo or as word file to someone if he needs to edit it. That's that kind of stuff that makes working in in an office document often easier. There's one thing that I want to show about flexibility. So we have the the memo document here. And for example, this it 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 code. It's all old school basic. Old school basic. I open sourced it. It was in the planning anyway. And there was some work 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, well, 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 just not in a public repository yet. Yeah. Yes. 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 LLGLP3 plus something like that. Yeah. So, yes. What's the difference? Any more questions? Okay. Thank you. So, we have two more talks. Jamux, perhaps? When you're done? I think we have time for one more minute. Okay. This is very lightning because I just made those slides in a few minutes. So, next one up is Jan Marek Glorowski from the 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, you've been active in the project since when? 2008, 2009. So, last two years, something like that. And I need some output. No, that's not a window maker. I'm not going to test it. Or loom. So, instead, while we're solving the technical issues, this is Olivier and you will be talking about the new hub system. Yes. I would like to show you what we have achieved so far. And 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 hub 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 things to show. What you see here is on debugging the XML. You see that you can, this is pure HTML that has been transformed. 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, yeah. Question mark page equal. Equal. Share it. Share it. Slash test.xhp. Test.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 than technology. That's it. Okay. And just one thing. We plan, 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? 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 back ends. And some back ends even do not implement it at all. So this is kind of a crazy definition of busy. 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's some really freaky stuff, like there are some comments on the Mac OS back end, 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 the parallel processing with threads that's 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 workarounds instead of rewriting the whole stuff from sketch with a normal idea and how in a normal way, normal tasks and event loops working today than toolkits. So where we are currently, we are only scheduled by priority now. So like all the normal event loops, every event or task has a priority and a schedule like that. So we do, you know, completely those busy stuff. That's really crazy anyway. The other thing is that LibreOffice was more or less polling with a task which just occurred because we were missing some time, a timer 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. Yeah, sometimes I trust 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 that couldn't work in the future. At least all the unitets 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 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. The 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. Currently the main loop is not multi-threading safe. We 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 their threads so 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 to do with that. 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 tasks 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. Thanks for looking into this. Yes I may not my main original point was that something's changed in there and main merge got very very something changed in that code and main merge 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. It's crazy and it's 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 the last time I saw that it was just event handling and looping and all this stuff it could be fixed with zero one millisecond to zero milliseconds. That's probably our sums. I mean I already learned some refactoring patches but really hard stuff is hopefully landing into the hackfast next Monday Tuesday. Probably that was a little bit too long for us. 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. 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 when the code is out. It was okay for me. Okay it was okay. He says it's interesting what kind of problems we have with the smiling face. Anything else? Any kind of feedback? Anything at all? Otherwise get home safely. Enjoy the rest of the process.