 Great. So, welcome to a talk that I'm mostly just reporting about. So, this is not my experience, but it could have been my experience. So, this is January. So, this is the trying to chart the course through not knowing much about the SDK and how to develop a LibreOffice C++ extension. So, from zero to hero if you like. And perhaps some good experience there and also some lessons learned to share here. Good. So, the background is this is a real customer project. So, we were approached to build something where we thought the best fit would be a C++ LibreOffice extension. And this is the story how that went. Yeah, some exciting new tasks comes in. And unfortunately, it involves some drivers that we need for that. And those drivers were only available for Windows and also the part of that this being a hardware project was a proprietary software. So, the decision to do that with LibreOffice was made. And the decision to do it as an extension was made because of the license challenge was there. So, we have some nicely separated piece of software then that we just link into LibreOffice. So, with the MPL, LGPL license, that would be fine. Yeah, Windows. So, the person doing that was not using Windows as a daily driver. So, that added perhaps a little bit to the challenges but not substantially. So, yeah, what was completely new but it's always great to have some guinea pig, some experiment that someone who did not do anything but it's otherwise a smart cookie and experience with the community and LibreOffice to try that out and then see how things are going and then take the feedback and iterate. Right. So, and the whole thing started with the development setup because, hey, we're doing C++ here. So, why not use LOD? Is that not the gold standard? Right. So, what you do as a decent software engineer, you start reading the documentation. Just whom am I kidding? Of course you're not. You just start hacking. So, you just open your editor, clone some Git repositories and then you want to get going and if you don't know what to do, then you ask Google or any other search engine of your choice how to get from A to B. So, well, that went not super great. So, the SDK examples simply, in particular, the C++ one simply didn't want to compile and the documentation that was there at the obvious place, which is API LibreOffice.org, the instructions there were not working either. So, neither the MinGW nor the Cygman make wouldn't do anything properly. And then some other experiments were made and some iterations and some debugging and that was exactly, that matches exactly my own experience with the, in particular, the C++ and the Java part of the SDK where you need to compile something. And then I have some magic write up somewhere on my disk and some configure file that I tend to reuse since many years. And I forgot that I had it there. And I also forgot that I wanted to document that back in the day when I was going through that process for the first time. So, I suppose many people made that experience. One of the reasons to have this talk here is to finally have it in a talk. So, now we have like four places where somebody mentioned something about it and, of course, the obvious way then is not to make five places or six places out of it, but just one later. Right. So, what was the fix then? Was the SDK, said SDK and edit the path there a little bit after figuring out how this was all playing and interacting with each other to finally get stuff going. So, then we could compile the SDK examples. Yeah. There was some interesting tweaks there with the Visual Studio command. So, let's say the shell inside Visual Studio. And, yeah, I didn't know that either. So, if I would have been asked, I would have used some Cyclone Shell or some DOS command shell for that. So, yeah, documentation is wrong. Now, great. Or are they? So, the problem actually was that there was a duplication. So, there were several places where those things were described. And the assumption was simply wrong that the API would be the go-to place there or the canonical authoritative place, which is not implausible to assume, given that it's in the name and it also has the examples listed there. And it's regenerated. So, it's not at all implausible to assume that. Turns out the go-to place would have been our development mentors, block posts, where he did exactly the same and had exactly the same experience and documented what to do there and put it in the block. Great stuff. Just absolutely cool just that there was another place that was not adapted. And so, that was for better or worse, popping up first thing on Google or for other reasons was selected. So, yeah, that engineer was then devouring those blocks, being happy ever after, bookmarked the CMake one for later, because it's interesting stuff and probably makes life generally better with that Mac system, but at least the SDK was then building. Take home message will obviously wrong documentation is worse than no documentation because you never know if it's your fault or if it's the documentation that is at fault there. If you have multiple contradictory documentations, that is even worse than wrong documentations because you don't even know which documentation is closest to the truth. So, it just massively explodes the complexity of the search space and the need to go through. And our, the liberal office projects SDK developer experience is still terrible. So, if we want to encourage people to use the SDK for anything and not be, and not lose 99 out of 100 people right there on the first date, and we really need to improve that. And the silver lining, of course, is that great strides in progress was made and thanks to mostly Hossein and Ilmari there for actually going through that and documenting their findings and improving things left and right. And fields a bit like last mile just needs a little bit of finishing touches and integration and cleanup. And then perhaps also again going through that process again, starting from zero, putting that the office search, asking the office search engine, see where you end up, go through that process again, rinse and repeat. So, yeah. So, overall, I think, and that was done in a matter of, I think, a day or two. So, it's not so bad. I had worse experience in the past when I was attempting it. And I was, of course, guilty as everybody else not turning what I experienced into positive action and fixing things up. What was the point, actually? So, as I started in the beginning, I started to say that there was an actual customer who wanted a demo in LibreOffice under Windows with their specific hardware. That company is ILS Tech and they built hardware for massive demonstrations. So, they built laser pointers and the camera device where you can essentially with, I don't know, 50 or 100 or 200 people in the room, everybody gets a laser pointer and then you can interact on a projector, on a screen, even in a planetarium, like on the ceiling. The only thing that you need is line of sight between the wall or the screen or wherever the laser pointer points to and some little camera that kind of tracks where you actually are. So, right. And I might be coming to a museum near you. So, I hear that those Miniatur Wunderland people in Hamburg were interested in having that. That's some model railway, very famous. If you're in Hamburg, go there. It's just awesome. Not because of this necessarily, but also. So, this is how it looks. Yeah, you can have a room, literally a room full of people and it really works with literally like 200 devices there. And in this case, this is, I think, some parliament and I think they're picking the color of the uniforms or something. I don't know. So, what they wanted to do, they wanted to have a demo where you have multiple pointers so that you would have something like a teacher in the classroom would be able to give their students to play with and then you can interact with the slides. You can have a poll. You can have a little game. You can do something. You can do some fun stuff or you can do educational stuff. And so, to show that that works, well, we choose a liberal office for that and impress. Right. So, this is a bit of an explanation what the hard work can do so that it's a bi-directional. So, you can also like have a back channel like you can never make it vibrate. You can have some LEDs flash down. So, right. So, that's the actual concrete request. We were following them. The challenge, beyond the fact there was some windows, it was just some shared memory. So, there was some XY coordinates and also that which button was pressed. It was just a small shared memory area where we actually needed to poke at some bytes and read some status out. Well, it's not unheard of like driver programming, hardware programming to do some bit-banging there. So, that was probably the most straightforward implementation. Sadly, we had to port that to C++. And of course, the easiest language then would have been C or C++ for having direct memory access. So, we went with Python or Java. Right. And you could use your mobile phone. It was some emulation. So, you didn't need the actual hardware. I planned to actually bring it here, but it didn't ship in time. So, trust me on that. I had it in my hand already. It works. Right. And the idea was then, there was some interaction. Have some strategy game, something exciting, something where something moves. There was, they also did some unity-based games. There are some like shoot them up or I think some star field something. Right. So, then the idea was developing. And what helped really for Impress that the engineer looking into that actually was the one who did the physics engine. So, taking this together and the fact that it should have been an Impress was kind of a natural match down. Sorry. Yes, you don't know. There will be a video in a second. So, you can, it's seeing is believing. So, yeah, then let's see what that does. What you see here is two slides. There was an extension that actually controls the shapes there. So, there's two pointers. One controls the shape with the number one and the other with the number zero. And then you can, on the first slide and you can pick, you will be attacker or defense. This is the second slide. Now you can move your little token there. Yeah. This is literally an Impress slide and those are Impress shapes. You see a few more shapes. You see a little bit more text there. After both players have placed their bets, you press shift a five. So, which means start the slide show on the current slide. It's all kind of demo. It just shows what is possible. It's not very polished, but it shows you what you can do with the SDK. So, you can do pretty much everything in liberal office, including mouse movements and interacting with the slide show. And this is the physics engine. So, those are shapes and those are shape effects. Yeah. Depending on where you put your objects there, then either both shapes end up in the bucket or just one shape. Right. And that was the demonstration. That was the lessons learned, the experience. Thanks for attention. The hope is that indeed that triggers, like from all of us, including myself, that triggers some cleanup action. And again, if you manage to go past those initial hurdles, it's just a wonderful world of possibilities. As you see, what is possible there? Just a shame that we will probably lose many interested people, both people who might have a commercial interest and then throw it away because after two days, nothing is done yet, but in particular volunteers or students or other people interested in hacking your office. Okay. That was that. Are there any questions? Okay. Dan, thanks again. And large change to the code in the office that had to do with the integer flags. And I think so that a lot of different aspects of the code had to be frozen and not touched because of external code, like maybe code that uses the CK or extension code depends on it, depends on specific definitions of flags, specific feathers, etc. And I was, so my question is, how frozen is the code digging up against the thread outside of it? Or whether it's like highly frozen or whether it's like something that's developing and changing and getting updated? Yeah. So the question, if I understood you correctly, is like, can we change the API or how easily can we change the API or should we change? So yes, it happens, but reluctantly. So when you change, so there's corners of the API that very likely nobody use it. Either it's not documented or it's been broken for many years, it couldn't have possibly been used. And then there's no harm cleaning that up or changing that. But that's obviously the other side of the coin is that there's API that is very, very, very frequently used. And if you change it, you break external people, you break external software. And since we have no control as a project about the release cycle and whether the engineers even still around to fix that basic macro or to fix that extension, that's quite a disruptive move. And as a project, I think we are well advised, we're very careful. If we do that, we should have extremely good reasons. There's no hard and fast rule. But in general, there's checks and balances in place that if some change, breaking change comes in on published API, that some alarm bell goes off and Stefan is, you have Stefan in your back. And I think that's a good thing because like, like just the same like Linux kernel or Windows API changes, if ever, then just very slowly. And at the same time, people are just extremely upset about Apple constantly changing their because it imposes a real cost. And if you're an open source project, probably the downstream cost of your change cannot be absorbed because it's volunteer time or it doesn't happen at all. So I would always advocate to be very careful. What's in? Yes. So when you say it was the extension with C++, right? Yeah. So I remember example, C++ extensions. And you know, you said that it's not that same, but now it's reversed. So now we're taking for higher extensions and you're actually using C++ extensions. So that's this way. So would you do that in Python problem? So the choice for C++ was due to the fact that it was a hardware project. So there was this chat memory driver interface that necessarily would have been some C or C++ language. So it would have just added complexity then to kind of wrap that in C and then have a Python binding for that and then use that in Python. So for that project, the quickest way was actually so we thought to go with C++. The challenge was, of course, to get it to work like the trivial things like just getting the examples to compile. But yeah. And I think it was educational in a way that this kind of re-running this or speed-running this experience and then finding your blog posts there and then realizing that it's all there. It's just a bit confusing. So that's essentially the message here that everything is there. It just needs this last mile, this last step of polishing and cleaning up and removing the misleading stuff and the duplicated stuff. So we don't use CMake, but beyond what is the proprietary bit, we can certainly share that, although I believe that there's not much. So I think the impress, let's say the how to interact with impress there, that can certainly be shared if that is of value. Or maybe we should just share it with you and then you have that as some exercise solution. So I'm interested in, let's say, some examples that some, let's say skeleton extensions in C++ and, for example, it generates the how to require it for different platforms so there are some things that are not really working. Yeah, we can absolutely share that. Let's maybe sit down, when you're done with a workshop, I don't know, can be after the conference whenever it works for you. So it's one of those, it's a demo so don't expect well-documented and clean code. There's certainly a little bit of work, but let's just sit down and go through that, see what is of value there. No problem at all. Happy to share that. Thank you. Okay, should we wrap it up? Then, thanks again. Enjoy the conference.