 So that's me, and I want to talk a bit about extension to core. So how do you find the stuff in core code that is in your extension and the extension API. And Olivier just said, have you seen this horrible API or LibreOffice.org thing? Actually, I think it's not too bad, but I agree that up to now finding something there, once you're there it's okay, but finding something is the hard part. So, well actually that is true up until last weekend essentially, at least if you're running master of LibreOffice. So I don't care to do that. So first I have to say, no idea what I'm doing. When I'm talking about you and all that stuff, there are others who are much better informed about the details. But let me just give you a quick run through the concepts so that we know what we're talking about. So interfaces, service implementations, and I use some lame comparisons to introduce them. Interfaces are what you can do when you have some, you know, thing. They're usually named ComSanStar something and have a name that starts with X and then there's a description of what kind of things you can do with them. Services provide a set of interfaces, so they are essentially a collection of stuff you can do with something and they usually start with ComSanStar and have not an X at the beginning. And then you have implementations. They are what actually implements the service. One concrete example. And they are usually named whatever. So if you look at them, they have a bazillion different ways to be named which is kind of unfortunate. But they are the actual stuff that is in LibreOffice and that does something. So just to make that a bit more visible, I came up with some weird examples which are, of course, real-life use in LibreOffice, but interfaces are stuff like, okay, I have a cargo storage, I can put something in, I can take something out and it has capacity or something, and I have a transport something that goes somewhere that I can start traveling and stuff like that. And I can combine those to a lorry service where I can put stuff in and get it somewhere, but it's still abstract, it's still some lorry, it's not one concrete lorry. And the implementation then is one specific lorry, one very individual one with its own decorations and boxes. So this is to get you the idea of what an implementation was as well as what an interface is. So what can we do with unoruntime reflection? So when you have some uniting to actually find out what kind of unit thing you have there. And the first thing is X interface, which is essentially everything in the unit has an X interface, so it's a base interface of all unit interfaces, and the only thing you can do there essentially is ask if it can implement some other interface, because in itself it's not of much use by itself. The second thing that can help us there is the X type provider, and there we can actually get a sequence of types so we can get an information of which interfaces are implemented by this specific thing that I have at hand. So with this I can find out if it's, for example, if it's an X transport or if it's an X cargo service, cargo storage or whatever. So with that I can find out what I can actually do with it. And then there's X service info, and there I can ask actually which services are supported. So I can ask support service, or I can get the list of all the services that are supported by this thing. This is already pretty abstract and stacking stuff on top of concepts. When you're there like coding your little basic Python script, I assume you don't want to go all these steps. So this is why I introduced the constant star script service document as single D. That sounds even more complex, but this is something you can start once you've got a basic IDE and then you have show service docs. And whatever you have as a new thing in, for example, basic, you can just throw in there and it opens all the documents for this thing which are on api.libreoffice.org. So the hard problem that Olivier described, you go on this web page and you can't find anything. At least it's a lot easier to just take, I have this thing and I want to have documentation about what I have here. And if you're in this, double-acquiring your basic script, you can use that. And of course if you're doing that and even if you're developing stuff in C++ you can use the basic IDE to just walk through the thing that interests you and find out what it actually is. You can also... So the first thing shows the services and the second thing shows the interfaces. The interfaces are actually a lot more. If you do that for the classic writer document, so this component in basic, if you have a writer document open, the first one will open something like 10 services, which is OK-ish, and this one will open more than 40 tabs in your browser. But you get all the documentation for this stuff to work. So what do you have to do? For example, in basic to get to this, you have to get the service documenter and then you can use it to show whatever this component or whatever you know object you have actually does. In the middle I just added the old stuff that was there before and in case you didn't know it, which just pops up a message box with the methods and properties and interfaces. But you can click on them, they are not linked and there's no further help in those. I wondered if I actually should make this first line superficial by making it a global thing like Star Desktop that is always there in basic. So you would never need to write the first line and you would only use the last one and just say, OK, I don't know what this is that I have here. So this is the stuff using the UNI API from the outside, not looking into call. But actually I want you to look into call because if you have a bug that you find in the UNI interface, it's much better for the LibreOffice project if you're not only able to say it's broken but also find the way how to whether code is in fixing it or you can either look at it and see if there's further things you can do. So the other interesting thing is find out the actually implementation that does the stuff that you're working with in the call. And well, the old way to do that for example is you ask your object to get an implementation name and then you get an implementation name and then you enter this straight into openwork.debrough.org The problem with that is you get like a bazillion hits from test code and everything which is instantiating this specific search. So it works but it's not really that nice to use. The second thing I did was the first thing I did was just finding these component files in the LibreOffice Solstery and you can find them from that you can see where something is implemented but at least you can guess it if you have some experience. And the best solution probably is write a click plugin and whenever you compile LibreOffice and whenever LibreOffice is told to compile the get implementation name thing, you know okay this is some unify thing and then you find out what this method actually returns and you have the mapping from the C++ class to the implementation name. So the afoc version with the component files was some yeah it's pretty hackish but it works to get you the rough idea where code this is and you can take it from there but of course the better solution is really to do it with a click plugin. I haven't finished that yet Stefan Bergmann did write prototype of that and because I had a different Clang version and stuff it didn't work out on my machine yet but I will finish this work to get this complete auto generated mapping between the C++ implementation and the implementation name and with that when you have that I would generate a redirect page to docs.libreoffice.org which is actually documenting the core LibreOffice classes and by now you can it's just an example if you tell it that you want to have this that's my personal upload location if you go there and tell it this is the base URL you can actually use it for one class which is the text document thing and you will get the documentation on docs.libreoffice.org for the SWX text document so the plan of course is to have this all generated for all classes for all implementations and have that automatically generated for each version so that you can essentially do this show core docs for whatever types you have and then really get to the to the C++ code documentation I think that's not done yet but I plan to do that maybe in the next week and we can of course do other nifty stuff on top of that like linking to GitHub or OpenGlock once we have the C++ class name and with that make it easier for someone who is looking from the outside with a new object to actually find where the C++ code for that ok so that's the talk and I can demo that on I hope I can demo that on this machine the only thing I noticed which doesn't work at least on what that works different on this machine I will write a document I already have it I will organize my code it's basic popped up on the other window the screen this is the stuff and if I run it first get what this the old debug functions where I can see what services properties and then it opened documentation for this on the other screen I can put that over but you have to document reference there and it also works for the core object but only for this one fast when I created the HTML directly menu so that's what questions yes is it possible to just get the C++ class if you are not interested in all of these nice open things something in my browser I have my in case I have the source code in that local or early then just calling the class name it's a bit tricky because what I wanted well and currently is to create the mapping from the implementation name to the C++ class name and put these in these redirect files on the web page otherwise you would have to put the whole list and ship them with LibreOffice I don't want to do that to always and then update in LibreOffice the reflection list which maps the C++ implementation name to the C++ name to the human implementation name in some cases we already have this the C++ class name is the same as the implementation name I don't know if it would be a good idea for this one you can just probably for the implementation name there would be another idea I thought about well we should just always I assume it would cause huge pains for for the extension developers because they if you just take a random implementation name and put it into Google and you see these implementation names so whatever that did will break and that's the first thing and the other thing was all the tests I mean there would be an excuse to kill off the Java human API tests because they otherwise you would have to adjust all of them and I don't think anyone would volunteer to do that implementations of a single marker kind of service and then you traditionally always go via the implementation names to discriminate the macros of implementation so there's precedent of using these implementation names but I agree this if you look at this and you have this trying plug in telling you all the implementation names that are used I have the list now and you look at it it's completely inconsistent in a different ways what kind of strings are used there sometimes it's the C++ name sometimes it's sometimes it's something something so it's what one could at least do is have a base class or this service type of thing that we are using create a default from now and then we might at least kill off the old stuff which is not dependent on language maybe with an easy hack but we have to see what there might be some that are possibly versions that we then still have inconsistent so yeah any other questions or if you help at least a bit in finding the documentation yeah I hope so because you know this is the API is very powerful but for the average user that is used to to call VBA statements you know it's amazingly complex I mean okay then no other questions thank you