 native GTK stuff, all right, running on VGA, what it works. So what's native right now in the existing releases? We've been native GTK file dialogue and that's been native forever. The most recent releases and the GTK 3 back end are tooltips, they're now native tooltips. We just tell GTK where the tooltip is for and what the text is and GTK itself renders a tooltip. So that means that if you have the case where you have two screens side by side and the tooltip is cut off, that's a GTK issue, it's not a LibreOffice issue. And then also additionally we're now using popovers for some of the things that used to be tooltips. They're a little bit different in GTK 3 and they have a little indicator that points down to what the thing being pointed to is. They're pretty nice, we have them for formula type ahead in calc and the page indicator in the impress slide pane. The original motivation for making them native was that the under whaling is very difficult to do your own tooltip style of things. So just use the GTK ones and reuse them. What else is native? The app menu which is available in ergonome is fully native of course. Our context menus are now native. If you right click on something we actually have real GTK menus there and the menu bar is now a native GTK 3 menu bar and obviously the menus within it are native GTK 3 as well and that derives out of the unity work that was done there a couple of years ago. So all of the menu positioning stuff is all native GTK so if your menu won't fit in the height available of the screen the fallback there is a GTK native fallback. So it's the GTK positioning and the GTK behavior for what happens if something doesn't fit in so all those bugs can go to toolkit rather than to us. What's not native? All of these special effects are all just open GL on whaling to show that it's flicker free. I showed them last year and they were flickery. This year they don't flicker. So what do we actually do for everything else that makes it look like it's native? Everything else is actually not native, it's our own toolkit but we use the GTK APIs to render their widgets to our actual locations where we pretend our widgets are. So it's never quite right. You have all these APIs that are fine but you have to set up the context the style context quite right to map our state to GTK state. So obviously for a radio button you'd say that it's selected or not selected and then it'll render it into the space that you set out that you want it rendered into. But you have to get the size right as well. You have to clear your GTK. What size should a radio button be in GTK? Figure that size out and then tell GTK to render into it. So if you get the size wrong, you get little artifacts that you'll see on some of our areas where it's not quite right. You also have to use the right calls so you might get them wrong. It's quite complicated set of affairs. And the actual stuff that's available for use outside the toolkit is no longer quite the stuff that's being used inside the toolkit. So you're using maybe context, style context that aren't quite right to try and get the effect that you're hoping for. So it never really quite works, but you were pretty close but it's not quite right. So we've been getting a lot of this stuff wrong. A little bit wrong anyway. So back story then. The UI descriptions where we've come from. All of our dialogues you'd just be described in a SRC file format where every widget was a fixed size. Everything was measured in arbitrary character cell widths. And then again there was when you load the UI under German it would multiply everything by 105% to get a little bit bigger because German tends to be a bit longer. If you open up the same dialogues in the Japanese it would divide it by some amount because those takes tend to be quite small. So you have this kind of guesstimate arbitrary stuff going on here and there's no GUI editor for all this old stuff. So we've come from there to a situation where we're now using the GTK builder file format and all our UI is described in terms of GTK widgets. We're not using GTK widgets. We're using our own VCL widgets but we have described everything in the GTK file format and then we're mapping that at load time with our own .UI GTK builder file format with our own loader. We added in some resizable widgets equivalence to the GTK grade GTK box. So now we have widgets that contain other widgets and then they dynamically size and position them according to the constraints that you can describe in the grade GUI editor. So the results of all that is that you've got about a thousand UI files and apparently we have like about eight accessibility bugs in each one but they can be fixed in grade. So that's the .UI file. So everything is now described in the GTK style file format but mapped at load time for our own widgets. The translations then are, yet again, were in our own custom file format. The same SRC file format and the output here is a res binary file. Each translation is indexed by a unique ID and it's all converted to relatively standard PO to go up to the website to be translated there to be brought back down and then converted back out into our own custom file format as well. And then when we converted everything over to this .UI file for the dynamic layout and the new description we had to keep a lot of this stuff and we have a little bodge there so that we run those translations through the old translation system and back again. So that's the old translation format. What we've done at this stage for 6.0, I think, is that we have finally gotten rid of that file format and we're now using the more standard get text file format. So that means that with get text we can extract our translations directly from our .UI files and from our C++ with the standard tooling for that. So we use get text to put out the tooling. Then we have our .PO files which are now directly created from the translations. They can go up to the website, back down from the website and then we can use get text to create the standard .MO output file format. And then we're using the boost get text implementation to read them. So the old translation format is gone and the new translation format is the standard get text file format. So that's 22,000 odd translations. So 1,000 UI files and 22,000 translations taken from the old binary file formats converted into the .UI XML file format and to a binary but standardized get text MO file format. The consequence of moving all of the UI descriptions and the translations out of those file formats into standardized file formats is that the dialogues are mostly GDK compatible in the sense that you can use Glade Previewer on any of our .UI files, put the .MO files from our translations into the patch where they can find them and you can use Glade Previewer to look at a localized version of any of our .UI files which should mean that if we were to deploy that Deckard Web utility for displaying translations in a .UI file as translators, modify them that should work in the majority of cases out of the box now. So obviously we're kind of hoping to go at all this. It is possible to load those .UI files natively with GDK, with its own GDK Builder API by passing our re-implementation of that and because GDK handles the get text file format let GDK load those .MO files and then come up with a kind of a compatibility layer where we would bind to those native GDK widgets rather than using our own VCL widgets which are basically then emulating those GDK widgets at runtime and then we'd take our entire existing stack that currently works and just keep that as a fallback case for guys under windows and the other ones and for the non-GDK case for the GDK case we'd use this alternative. Now let's do a walkthrough of my development version which first shows a native GDK menu fitting on screen as best it can and I will just show in case anybody hasn't seen it a pop-over that's what I'm talking about now that's a pop-over there that's a native GDK pop-over that's just a native GDK thingy the toolbars are native of course and we will go for a simple one first, more breaks and search manual break but this is then is a native GDK this one has been loaded by the native GDK loader they can both exist at the same time so this one dialog is using the native GDK stuff and the other dialog except for one or two other ones are using our fallback VCL one so what difference does it make if you keep an eye on the gradient button on the top left fades in, rather than come straight in fades in, fades in if I change to a different style and I change the file number here when I have gone down to the minimum allowed value it has grayed out the left button and left the other one ungray in our implementation we would have left them both clickable and would be an example of where we get things wrong again if we move back here and I hit this page break one this should fade in gently rather than coming in hard and then all these things are native and fully in and it works of course it works, now the style insert table has a bit more detail again gently fades in fades out when you get to that level and it might be, there we go and so on and so forth so it all just works and it's needed now what's maybe a little more interesting as well is that they're all standard widgets now what do we do for the custom case now this is another native GTK dialog loading up the .uifile that we currently are effectively using now first look at that none to the false style all these guys are going to fade in at the same time they all fade in and the right hand side then is a custom widget so for handling the case of a custom widget that's a GTK drawing area let's go back then where we draw on to our own existing output devices and then when the GTK drawing area needs to refresh it can take from our existing output device and convert it to its own so they're all native and they all work let's go back to the thingy for the conclusions yeah walk through yeah so there's a half way house API some of the problems though is that the dialogs will not be usable directly without some modification of the .uifiles because we have our implementation and GTK has its implementation there are some divergent areas where we have to modify our uifiles for some of the quirks between our two different loading implementations one minor one is like radio buttons in our case we have radio buttons and we link them to each other in a circle to make it work under GTK you have to link the inactive ones to the active one so there are changes like that and there's a whole bunch of smaller details as well where we have to modify the uifiles hopefully in a pretty much three quarters automatically kind of a way one small one is where we have our buttons on the right-hand side we're just going to have to put them on the bottom but we want to put them on the bottom anyway so there's no final things there some gotchas and the gotchas I described there and there's some difficulties where some parts of VCL have leaked out through the UNO API so you can have an up-down handlers follow the plus-minus buttons and spin buttons for the up-and-down there there isn't an existing and equivalent one in GTK so they'll have to be able to work on interfacing the existing UNO stuff that has leaked out that should never really have leaked out and there'll have to be some amount of UNO support as well to tunnel the dialogues through and one of the things that we probably need to do is we need to move those extended tips out of help and into the .UI files I think we want to do this for ages and it's still a good idea but the translators have been through a lot of pain so I don't want to put them through any more misery but that might happen anyway with the help changes if the help goes the tooltips aren't there so something will have to happen and if we stick with the model of we need a file back then we're limited only to GTK widgets that exist as equivalents to our own VCL widgets we would have to remain within the subset of the existing implementation unless we went down the line to just try and use GTK under all platforms and get rid of our toolkit and then we could use whatever be available but for the moment I'm just limiting it to what we already support okay thank you any questions? if any questions or concerns yeah you can