 While everything is set up, I can make some entertainment here in the beginning to make it not so boring for those who had an app. Welcome to the GSOC panel. GSOC is one of the great pillars of open source in general and it's a great thing that Google sponsors all the development and many features that we have in LibreOffice are developed by students from all over the world which is absolutely a great thing. We are totally happy with this. Sometimes we have students who come later into the project, sometimes quite often actually, many students who do Google Summer of Code work, come later into the project and become an expert. So doing this Google Summer of Code work is not only interesting for the student or the community also for the project. So it is a great thing and it's a good tradition to have at the LibreOffice conference a panel about what has been done. But first of all, we had four admins this year. Four admins sounds like a hell of a work. It was actually not so much. Moggy did all the work in the initial preparing and later it was Torsten who did, who managed most of the process. Cisco was punishing everything and me and Heiko. So we are the four admins in the project and we had six students. Actually, is Borfiaga here a chance or is he having a talk because he was the missing admin? Yeah, he's not here. I think he is in Australia. Far away. We had six projects this year. All of the project passed both evaluations, so it was a great success. And we are happy to have hopefully many of the students here. I'm not aware who of the students is missing. I believe not everyone of the students is here. And that means the mentors will have the presentation and even if the mentor is not willing to present the topic, it will be one of us admins. That's what we plan. Do we have someone for the QR code? Do we have someone for Rasmus? Yes. Do we have someone for Sumit for the notebook bar? Do we have someone for Ahmed? Excellent. And for Kaisu? Excellent. And while we are missing slides for the chart style thing, do we have a chance of the mentor here who can then spontaneously demo that on stage? That's a shame. Okay. So that's maybe also the reason there are some slides. Right. So maybe before we start, so GSOC is actually, as Michael said, quite important for the project. So there's always a specific area, like kind of class of feature or implementation that is usually only happening during GSOC. And it's a great way to introduce students to the project and open source. It's been, it's the 14th year, so it has the 15 years anniversary next year. So found it in 2005. It's now pretty large. It's about, I think, 1,300 to 1,500 students every year that get sponsored by Google to work on open source for three months. Of course, all of that would not be possible without the mentors. So we have that in the end. But let me just give a big shout out to all the mentors spending in their time and energy. And I'm a bit sad that this year, actually, we didn't manage to get another single one of the students here for any kind of reasons, a number of reasons. Some of them were just far away or had other plans. Some of them had to cancel for personal reasons. So this year, for the first time, I think we will only have the mentors presenting. So we will see that we will do that better for the next time, because it's also would have been a great opportunity, of course, to get to know each other like you get to know the students and the students get to know you and Bond and then have fun with each other during the conference. But that's how life is this time. OK. Should we get all the mentors here on stage before we start so that there's a smooth handover? Can I ask all the mentors on stage, please? And we already have a few mentors on stage. So no. Thanks. Would you like to say something, please? Not for any minutes. So, 50 minutes. So, yeah, I think we have plenty of time. Yeah, but it gets a bit boring and it's not so much prepared. If the time exceeds 50 minutes, I would stop it. Very well. Let me hurry up. So first in the line, I was co-mentoring with Björn, the Libra Sign Project, the Libra Office on Appliances. Who knows digital signage as a concept? Right, so that's like all over the place. That's you don't have billboards these days. You just have like large displays driven by some embedded device showing some advertising or some movies or the weather. And we thought it would be great to have Libra Office running on those pieces because they can perfectly run them, like on a Raspberry Pi, for example. And then being able like an admin can then upload there some content and it would be running in an endless loop or on a conference like this or in FOSSTEM, there could be Raspberry Pi where you can just go upload your slides there and then run the slideshow from your mobile phone in a local Wi-Fi network. So that was the broad idea behind that. So as the slide just tells you again, so that was kind of we kind of tweak the plan and came up with new ideas as we were going because once we got the first thing there, we thought it would be really great if we would be able to then have this impressed remote style way to control the presentation from your second device or from your mobile phone. So the initial idea was just to have a Raspberry Pi running a server and displaying on the screen the host name or the IP address and the port. So you can just put this URL into your phone, connect with that device on that server, upload your content, like kind of choose playlists or some orders and then do some settings there and then you press the button and it will play that. But then again as we had this running, we thought it would be really great for this like, we always had this FOSSTEM set up in mind with lots of people coming in and presenting and always this problem with the connectors and the display is not really working and the aspect ratio not really right. So and then the impressed remote was kind of broken. So we thought we can do that as a JavaScript application in the browser. So it was kind of evolving. The general structure and the three parts main program is a liberal sign, Python package available from PyPy, which starts liberal office in the background and the web server. And then you can upload your ODP files there and when the liberal office will be controlled by UNO, our remote UNO loads the file, gets the virtual play button pressed and then comes the slideshow and it repeats or gets the next ODP file loaded and so on. That's JavaScript, single page application, so we can do that all in one place. And it's accessible on a local network, on a custom port. So you can of course put some reverse proxy in front of that if you want to harden that, but it's essentially Flask based, very simple REST based API with a web server that ships to some JavaScript in the browser that controls that. That's how it looks. So upload presentation, change the order, play that in conference mode or in signage mode, remove things, and then comes when you start that, you get this web based interest remote, which is another single page application, which is a separate repository, three repositories there, has slide previews and notes like the real thing, it's not quite as polished as the Android thing, but on the other hand it works, in contrast to the Android application and it gets started from the control panel and that's how it looks. So you got those thumbnails there, so you can select that, you can skip to the end, to the beginning, put it on auto play for example. Quite a bit of polishing that would still be needed, I suspect if somebody wants to productize that, but most of that is really easy hacks, like the big picture things, that's all in place and works. Clearly some optimizations, some stuff is really not perfect yet, for example, those slide thumbnails, I would slow to load for large slide decks. One of that is ready package on PyPy and works mostly out of the box. OK, what's that in time? You have 12 minutes left. How much did you say? Entertain us. How much did you say? Didn't you say five minutes? 15. Oh, 15. What a pity that you didn't set up a prototype here for these couple of presentations. I brought Raspberry Pi and then I realized I didn't bring a keyboard and then I had lots of slides to write and the student wasn't there. But I had all the best intentions. But maybe for first time we get something and then can run the death room from that. That would be really nice. So any questions to Thurston, to Rasmus? If not, let's continue. I'm sure there are questions. There must be some. Should I suggest some questions to ask? I have a question. I asked a question. Why didn't you get great UI? Yes, you did that. So maybe some show of hands. So who thinks this could be useful? And those Fostum guys, they have these little boxes with this HDMI splitter and the recording equipment there. And they're already having some embedded hardware they're running or maybe it's some atom but kind of smallish underpowered thing. And that already handles display and video signals. So it's probably just getting that into that distribution to be able to run that. And Wi-Fi is pretty good there. And with the latest Raspberry Pi versions, you've got onboard Bluetooth and Wi-Fi. So in theory, you could perhaps even get the Impress Remote original version working. We were just not up to that. OK, so if there's no questions, let's not dwell on that. Next project that I was nominally co-mentoring but it was largely Samuel that are doing the work. That's QR code generator. So there's a feature in other applications that lets you easily embed a QR code in your document and something as a special field. And Schupam grabbed that and got it to completion. And it's essentially using a third-party library that generates the QR code, shows some dialogue box where you put the necessary information, and then sticks that into the document as a shape. And it's even round-tripping that. So when you reload that and you can open it again and edit the properties, save it again, round-trip it again. QR code itself is SVG. So that's also nice when you print that. Yeah, it even works with OXML. Look at that. That's how it looks. So pretty simple, very basic, but I think quite useful these days. I see that on many letters from the bank, letters from the insurance that you've got some little QR code there. So when you fill the form and send it back, I can scan that and kind of associate that with you again without any handwriting OCR. So I suspect that's very useful to have. And it's in 6.3, more or less. What is it? At least it's in master. But I believe 6.3 has it included. What I remember is complaints to move the access from a very prominent position and edit, insert, insert QR code. So it's a route towards some place where it does not take that much space from the menu. That means people are looking at it. So not only master 6.3, 1. I'm not sure. Second? His computer is running 6.3. So switch back. But I, OK, let's, OK. Insert takes. Insert it. It has a Spanish UI. Challenged. What now? I don't see it there. OK, so let's assume it's not in 6.3, so I'm off the hook. OK, thanks. I stand corrected, so it's going to be in 6.4 then. So it's right now only in master. OK, so there was the trigger for that. This kind of oldish bug there. And the work was like kind of all over the code base. Like it was touching UI, it was touching the filters. So all in all, I think it was quite a nice project for getting into liberal office development. Had all the pieces down. And, yeah, came to a conclusion. And Shubham has also plans to continue contributing, which is also nice. Chart wizard work, some bug fixing here and there, and some open to-do items from that project. And let's see, maybe we meet him at Fostom or at one of the next SACFests. Exactly, any questions? So maybe a question to the people. The dialogue looks right now a little bit boring. It works perfectly. It is actually the same as an Inkscape. You create a QR code, and you get it. You get what you want. But it does not look like the usual feature it is of liberal office. So what can we add to the QR code to enhance this? Any ideas? I believe, since it's an SVG, you can change the color. The waving QR code. Animations. Waving QR codes. Images in the center of the QR code, for example. Which actually works. So you can have some, I don't know how that works, but I've seen that. At least you can overlay the QR code over something. What I had in mind is some 3D QR code for D, whatever, fancy stuff. If you have an idea, I believe, I forgot his name. Sorry. It's happy to continue the work. And it's one of those really nice, tiny features that are extremely useful when you need them. And when they even work with this round tripping, when they work nicely and have nice user experience, then it's a bit like, I mean, I'm reminded of the PDF export back in the day where the initial reaction of the people was, what do we need there? We just print that and then PS2 PDF convert that. And what do we need this kind of extra load, extra functionality inside liberal office? And over the time, it became a standard feature for office application. And that's kind of, I mean, it's not on the scale, but it's a very nice round extra feature. So you want to, so Tor is asking if we can reduce something or make it easier? And the question, I don't know. So the question was, why would you not have error correction or like a default error correction? Answer from Kloff is like probably it affects the size of the QR code, like more error correction, bigger, more pixel. I don't know. Yeah, but this is all about choice. This is not Apple. I'm just interested. How this is implemented? This is like treated like SVG with extra properties inside the document. Yeah, it has some custom properties. It's like a shape with an SVG image and some extra properties. I have to admit I don't know the exact, I haven't seen like the filter code. I just, I was following when there was the third party library work, integration work. But it should be easy. I mean, it's less, look for Schupam as author and you will find the change and XML of. Suggestion, the engineer in me wants to say great, but there is room to put the border units. So we can make that huge area a little bit smaller. And maybe just add the unit so that the user would know it's one pixel, one meter, one kilo, one person. I'm sure Schupam would be most thrilled to receive your bug report, your enhancement request. I need to run for the next meeting, which is conflicting with this one. Should we move to Sumit? Hello. My name is Szymon Kos and I was mentoring Sumit, who was working on improvements to the Naudung Bar. This project had two parts. First thing to do was the customization. We wanted something simple. So we decided to add only show and hide possibility because we wanted to finish this in the short summer. And later, with existing framework for modifications, we can create some easy hack to add possibility to, for example, change the unit command. Second part was extension support. And in the customization case, Sumit extended the existing dialogue. You can find it under menu in classic toolbars under tools customize. On indifferent implementations, it is placed in menu on the right side. He added new tab to this dialogue. And as you can see, you can choose here scope, which means implementation, because we can have multiple types of Naudung Bar for each application. And the second list box is the target, where you can specify if you want to modify, for example, the home tab or some of these sections inside. And there is a list of items. You can just click and show or hide this item. This was done by copying the original UI file of Naudung Bar to the user's home directory and saving the modification list to registry. Thanks to that, we can generate the same modification after LibreOffice update, when, for example, designer decides to remove or add some items. But this is only one detail to finish. We need to add this trigger after we detect updated LibreOffice, because now it's only generated on modification in the customization dialogue or on the first run. This solution with copying UI files is we decided to use that kind of solution, because we don't want to waste the time to parse the widgets on each run of LibreOffice. The second sub-project was extension support. As you can see, there is additional extension tab, where new items are added by extensions in the same way, like in classic toolbars. Extension developer needs to add special XML file into the extension code, where he specifies which commands are added. It's very similar to old XML file for toolbars, so it's not a big problem to convert existing extensions to support node toolbar. I think we can even prepare a script to convert extensions, which have some items in the toolbar. For now, it's some kind of a temporary solution that we created new modification in VCL Builder, but we are going to move the code to some separate widget for this extension code. And other thing to do is to put the extension code for all implementation, because now it's only in writer, in tapped implementation. And Summit is still contributing to the project. He actively does some changes in the code, even during the conference, so we still are improving the node toolbar. Any questions? Thanks a lot. I believe it is a project with the most communication. It was on Telegram, and I just glanced over it. Millions of messages went up and down, and Simon was continuously mentoring, and the people were talking about it. So it was amazing work. The questions? In the end, did the customization feature get implemented? And in the end, did it get implemented by saving the customized UI file into the configuration? No. We copied the original UI file into the user home directory, and we modified this UI file, depending on the configuration in registry. So in registry, we have only the list of IDs, which were modified. And we applied this to the UI file. So we add only property visible to our fonts for now. So if, for example, a lot of those UI files in the muffin or the top bar have custom widgets, so does it copy the UI file so that it still references those custom widget names? My point being that if in a later version, somebody removes one of those custom widgets, will there still be a reference to a custom widget in people's customized versions? Like are you stuck forever supporting custom widgets that you might want to get rid of, rename, modify? For now, we only modify this one property about visibility. So I don't see the problem because when we want to regenerate the customized UI file after some update and designer removed some widget, then we just don't find this item. And we ignored this setting. So I think there is no problem. You said you apply the configuration based on the IDs of the UI file. What happens if IDs are shuffled around or removed or a different element gets the same ID in the future? If another item has the same ID, I think UI file will be not rendered. So we will not create anything. I think we had sometimes during development the problem that nothing was inside the notebook and the reason was the two items were with the same ID. So probably it's somewhere in VCL. And this is not nothing. But that can't be prevented. So if anyone edits a UI dialogue or the positions and changes the IDs, if that doesn't match anymore. But these changes are added by developers and should be tested before. No, you have to do the work twice then. If you have to adapt something. Could you repeat? If you have to adapt something because you matched the IDs somehow and it's stored in the user ID, the developer can't do anything about it. Or maybe I'm misunderstood. I don't know. I'm not sure. For now, we don't modify the structure. We can only set property for each small button to visibility through or false. There is no problem with changing anything, positions, or something because we don't modify this. But you remember the properties by the IDs of the UI dialogue. So the properties are saved by the ID in the user configuration. For now, it's the dot UI. It's not loaded into any data model, but it's processed as XML file. So I'm not sure I understood that. Maybe just met a misunderstanding. Maybe I don't understand. Maybe Miklos can help here. As I understand it. And please, everyone, correct me if I'm wrong. The idea is that in case there is a version update, then they again take the original UI file, which might have some custom widgets removed, some widgets renamed, whatever. And based on the configuration, they again kind of patch the UI file, just the visibility boolean to true or false. So in case the widget IDs, for example, renamed, then you use your custom hidden state. But that's the end of it. No positions messed up, or no segmentation for just because some custom widget would be loaded, and it's no longer there or anything like that. While I imagine, given infinite time, this is not the nicest solution. I guess there is no huge compatibility concern here. At least that's how I understand it. Yes, yes. We use always the original file. So it means after update, the original file will be changed. And some not supported widgets are removed from that file. So when we read the configuration, and there is some item modification which existed before and now doesn't exist, it will be not copied to the new custom file because it is not in the new original one. Maybe Cisco can help us here with a fancy UI test. It was a hand over to the next topic in case there is no other question. Thanks a lot. Yes. So this project was carried out by Ahmed Ershayit from Egypt. I was just a commenter, and Marcus was the main mentor here. And he basically did everything. I was just back up there just in case. So if you ask me any technical question, I'm afraid I cannot answer it. But I can explain to you what it is about. So as you might know, Moggy did UI testing framework that now we use it in Jenkins with M8 check. And also, well, we use it for other purposes as well. So this UI framework or UI testing framework has a logger. So first off, I'm going to show you that logger so then you can understand what is this about. So yeah, I have to. So as you might know, if we call Libre Office with this environmental low underscore collect URL info and then the name of a file, then we can log the actions we do in the UI. For instance, if we insert this simple, but if we insert a page break, and now we close Libre Office. I don't see it. Well, OK. Going to do it again just in case. So if I insert a page break, and now I close Libre Office. OK. Now I'm going to have a file here in the UI test. And then now the name of the file. So now I can see the actions I did. So first I started right there. Then this was done in the background, I guess. And then I inserted the page break. Well, here more information. And then all the keyword actions I did when I close and I got the safe dialogue. And then finally closed the dialogue. So this is how the logger for the UI testing works. So now I can continue with the presentation. So basically the idea was that first and Ahmed did that, extend that logger. In the past it was more trivial and not that. Well, there are many actions when in lock and others when really easy to understand. So first he did that, and now many other, many new actions are locked, like the one when I saved the safe dialogue before he did his project, that action was in lock. So now, for instance, we have those action logs. And also he implemented a language, a DSL programming language to understand that log and then out of it create a UI test for the UI test framework. So that is important. So this is how it works. Well, we did first action. So now, and second one, close LibreOffice. So now we have the log. And now what we want to do and it's what Ahmed implemented is to convert this log into a test. So for that, now we have the log here. So I just go to this folder and I call the interpreter, which is Python 3, DSL, core, dot pi, and then where the path to the lock and then the output, which is this case sample. So I execute it. And now I have it here. And then I just, well, now you see it. This test was created out of the log. And now if I want to execute it, well, there is a script that you can use for executing the UI test that is basically this one. So you just set the environment variables and then you call the script. So if I execute it, then now LibreOffice is inserted. Well, it's going really fast. But yeah, if you can see LibreOffice is executed, the writer opened. And then a new base break is inserted. It says there is an error because the actions in the safe dialogue were recorded as well. And when we execute it from the UI test framework, well, this dialogue is not explained. But then we could remove that part, some player. So we could remove all this safe part. And now we have the test. And well, we did it without coding anything. So just using the UI and then using this DSL interpreter. So that's the program of this project. And that's basically it, I think. Sure. There was a question here. So why the intermediate step to convert from the log file to the Python? Why not just directly consume the log file inside the test itself? Yeah. I'm afraid I cannot answer that question. I think it's Marco's decision to do it this way. I believe, yeah, I think one of the goals of this project is that, well, if we have, let's say, a crash or a bug that needs many steps to follow, this can be interesting. So then, yeah, no, I don't know. I was going to ask the same thing, but I have another comment. So from experience, I think you're going to hit a very interesting bug that's going to frustrate all of your test almost, which is that there is no timing between the commands. So what happens when you execute something that takes a little bit longer? But your script doesn't know. So your script invokes the next command, which fails, because the first one isn't finished or it's in the wrong state. And so you get frustrated, because every time you run these scripts on different machines with different load levels, depending on the timing, half your tests are failing, because the state is not synchronized. Your script is just running at full speed, but the library office has its own pace, depending on the resources it's consuming and the system. So I would strongly suggest you include timing between the commands. So you capture not just the commands that were executed, but also the timing between them. And then what you can do is you can run them either at original speed or you can run them faster. And if you run them faster and it fails, you retry at the normal speed, you see? And this way, you have control over it. Otherwise, this is a great idea. But if you don't time it, it's just going to give you random failures. And every time you will spend time looking at it and not get anywhere. Thank you. So actually, I don't like the idea of timing. So I think things should be either triggering some state or synchronized this way, because we would like to run the tests as fast as possible. So adding some kind of timing, it just leads to when it doesn't work, let's just add 10 seconds everywhere. I don't know for sure in this particular case, but I know in the general case, the support is in there, that all these things are dispatched until there is no pending events. So it goes as fast as it can. And then it doesn't depend on any specific timing because of all those issues. And that's all built into the existing UI tests. So they all work like that anyway. So it should be all good. Any other comment? Otherwise, do we have more? So missing slides. Yeah, back to your question, Thomas. Maybe the reason why we do it now in two steps, it's because, well, initially, Marcus just did the logger. And now we have the interpreter. Maybe at some point, we decide just to remove the stepping between. So that's just the way it has been implemented. Because it could, maybe it wasn't done at once. Maybe that's the reason, but I cannot say for sure. Hello, hello. So I'm not Kaishu Shahu. I'm Kendi. But Kaishu Shahu was the awesome guy who did this liberal face Android app improvements. And why I say he was awesome? It was because he contacted the project early. He got involved into the development, sent the easy hacks early. And most of all, he sent the easy hacks in the relevant area. So from the very start, even his first easy hack that he has contributed to liberal face was actually related to the liberal face Android improvements, which is quite an achievement. Because I don't think that he has actually asked too much. So he has figured out lots of that by himself. And it showed later in the GSOC as well. Because the communication was very easy and straight to the point with him. Like, yeah, so he provided some patch. I gave some feedback or Quickie gave some feedback. He has adapted that. Boom, work done. So what he has done, yeah, and how it was with the Android. So you maybe have heard some of you that in my previous presentation. So actually, like this year, we were changing where the Android application lives and how it behaves. So his initial patches were actually into the old Android app that lives in the core.get. But the later patches and all the work that is actually listed here is for the new Android app. So all the stuff that he's committed is either still integrated because I was lagging behind and didn't integrate it yet. Or it is already there and it is being used. So for example, the print support, slideshow support, import, image into the document. This is all integrated stuff. Share document, it is still in Garrett, but I just need to test it somehow more before I integrate it. But from the patch point of view, code reading, portal view, it all looks fine as it should. Safe as document, I think it is in. Rational Dialog for Permissions, that's in, work done. Large shortcuts, that's in. This supports other formats. It is still in Garrett, dimming the document when inactive was integrated a few days ago. So lots of good stuff. But not only that, these are the new features that he has done over the summer for the new Android app. But he has also provided quite a lot of minor changes and bug fixes. So again, you can read it here. Something that I should, yeah, cut, copy and pay support, that's quite important. Yeah, otherwise, you see lots of great stuff from him. So yeah, it's a shame that he cannot be here. It would be awesome to have him here and buy him some drink of his choice, so yeah. That's Kaishu Sahu. Anything you want to know about Android, that is a question. Yes, why is this dimming when inactive needed? Doesn't the display or the device go to sleep automatically when inactive anyway? Why is this dimming needed? Dimming, yes. Doesn't the whole display go to sleep when inactive? Because I actually hate it on my phone, like when there is an app that doesn't dim itself. Or in the recent Android versions, like for example, I have an application that from some reason, when I just press the button for power so that it dims the screen, it is in some kind of mode that only just pressing it again unlocks the phone and directly you see it. So with this application, it very often happens to me that you press the power button, you expect the device is just sleeping. I put it to my pocket and at some stage, I feel the heat of the phone that it actually auto turned on and the app went into some busy loop and was just eating my power. So like what is done with this dimming is that actually like Android has some timeout after which it dims and locks the phone. And so like the online itself just has the countdown for like after which it's supposed to dim. And so like when the timeout in the online goes to zero or after half a minute or minute or I don't know how is it configured, then we turn on this auto dimming feature in Android and so it dims the screen when you then try to unlock the device, like when you touch power of the device, you have to unlock it and so it is really saving the power and you cannot get to the situation that it just unlocks itself and ease the power. So that was the motivation, my pet peevee, you know, but yeah. Any other questions? Then thank you, Kaishu. No, it was, yeah, thanks a lot. This was last every year will slide. So it has ended. Many thanks to Google. Definitely many thanks to the mentors. It was a great year. And after GSOG is before GSOG, so let's start now with finding topics for the next year, finding students that are capable that can start with easy hacks now. So looking forward for the next year, thanks a lot.