 Okay, I'm getting visible there now Thank you Excellent Okay, so this is the we rough as a native GTK widgets I think I'm going to mean it fairly so I guess that Wait till it takes over there at his time so Back at a start we brought the six what we have at that point is We do not have a lot of native elements But we have a small number of them. So we have a native file dialogue which we've had for years at this stage We have native tooltips and we have native popovers There's a little screenshot there of a demonstration popover and calc The reason we have popovers at that point was simply because we needed to be able to display that Feature and have two tips at the same time and GTK wasn't allowing you to have multiple tooltips visible at the same time Which is what we were originally using for the popovers So split the two things up and use popovers for this Basically as a heck and you keep the other two tips as tooltips At this stage, then we have managed to get the menu bar menus to be native GTK ones as well brought over from the your winter projects work there So there's a couple of steps required to get all the way towards using the native widgets First one is how are the dialogues and the rest of user interface described in first place and the file format for that Then there's the issue about localization, the localization format And then there's the issue of having some sort of an API that you can use to actually have read GTK widgets used as VCL replacements So we'll look at these in brief So the first stage here was in a couple of years ago was to provide some sort of widget layout support to VCL itself It's in that header there And it gives you various layout containers of VCL grid VCL box all which are modeled basically on the GTK equivalence Before that we just have fixed placement of widgets each which was in a dialog is assigned a location and Size and it doesn't matter what the contents are or anything like that It all has to be specified as hard-coded numbers in SRC files Which meant that various difficulties of it Languages that have long strings would continuously emerge and the dialogue would have to be Manually every size by the designer to fix that the longest version it takes So the largest part of largest problem really was converting over all these SRC files all these hundreds and hundreds of dialogue descriptions over from this hard-coded positioned layout to this GTK builder UI definitions that UI files Where we can define that things are Relationships between widgets in a far more dynamic way. This is a kind of a human process because the the layout of all the dialogues the Relationships there or something that's just determined visually by by looking at them not any actual Structure that could be ripped it is it into a more structured XML Destination part of it as a large task large number of volunteers and the output of all this thing is that you have All of those dialogues redefined in the XML GTK builder file format We have our own dot UI loader file order at that point and you can use glade then to edit these diverse so we have is a File format to get a file format before using our own DCL widgets Then the issue is the issue of localization of something like GTK most projects use get text We use get text as well as intermediate file format at that stage But we didn't use get text as the actual file format that we stored the resultant translations in So it's good bit of work there again What we have at that point is the boost comes with a get text That immobile loader and then API you can use to to this localizations from that 22,000 there's 22,000 translation entries are converted at this point and we were able to move a lot of Existing code out then we place it all with this boost get text issue Little plus along the way here is that we get plural form support something that would be requested for a while We got that for free What's this intermediate API then this is the infamous welding thing at this stage But that's just the head of either the basic process that you use application create builder You give it your dot UI file and returns back a builder from which you can Attach yourself to the various widgets inside that so well bottom Well checkbox or whatever and depending what platform you are we read around with home back ggk widget tree Or the the classic DCM widget tree So you want to get your gtk widget tree with the gtk tree port and for everything else You're still using the the classic DCM widgets So the API then Has to be something intermediate with something that can so we can limit can use Of gtk which is just to the features of vcl supports Occasionally then you have to add stuff to the sale to bring it up to the same level of Support a gtk has in particular area. So it's a take away from one at the other so Gtk tree views can control arbitrary amount of columns and Issues and features that checkboxes columns about that the vcl ones in a limited to One or two checkbox columns and one in which column so there's a lot of them There's less flexibility in some areas in the etsy and widgets. We have to Bring ourselves down to that level Now at 61 mark do we have we just converted overall the message dialogs mass converted them all over So all this is diagnosed against native gtk ones and then either handful of very very simple dialogues just Demonstration is basically insert breakings the classic starting point for all of these Now Moving on to 6.2. We have a Quite a large amount of dialogue scale up to this point 180 generic dialogue controllers appear at this point Simple ones simple dialogues and then there's 41 tab dialogue controllers, which are the more complicated ones This is for my character for my power there from the page issues like that Because of this intro with this step-by-step process is incremental process. We have issues that tab pages Certain pages and dialogues are we use a multiple dialogues so they can appear in different dialogues It's not possible to convert over all the dialogues To the process in one step that it has to become intermediate process for tab can figure out whether it's in a native dialogue or a bca one and regenerate from the appropriate builder So it's complicated scaffolding has to be constructed to allow this to be a commentary done So here's what we have at 6.2 as an example dialogue my character dialogue here is fully native But no more emulation of the gtk team and we see a lot actually using gtk directly for that Now multi-level notebooks are notably complicated. We have many such tab dialogues and notebooks We rafters that have many many many tabs There has to be some sort of solution to deal with that and one of the built-in standard gtk solutions were considered Proper, it's on the end. We ended up backwards Mechanism to create multi-level notebooks, but they're still native gtk notebooks just Manipulated to give us something that is more like the classic way to step notebooks we had in the past So 6.2 at that again 6.3 we're moving on. We now have 266 generic dialogues 160 tab pages and then we have complicated Sfx tab dialog So it's this stage where a couple of pieces that have no longer been used directly at all Then we put them into the attic so the VCL tile dialogue is now Never directly in stency as it was in stency as it indirectly through this whole construction and the more button that's used to expand on certain dialoads is also fully wrapped What we have complicated in 6.3 are the calc green selected dialogues They're typically more than dialogues initially and then when you click on the shrink How you click on? The document behind it become more less to allow you to slip the range in the document and just tell document underneath And then we release the mouse and it's expanded back to model dialogues again. These are rather tricky Construction, but it's that walking at 6.3 Things like a full screen outside full full Simi almost application level dialogue such as the country register are fully converted over at this point as well Even more complicated things are beginning to arise. This is where we have The calc header for the dialogue has an edit engine hosted in a widget sorts of Preview widgets. They are very complicated. This begins to work in 6.3 This is fully working until 70 when it comes to Use an input engine and more complicated features like that to interact with the edit engine in bitters, but it does start to work at this point Drag and drop and that's in the pivot table where you can drag from one tree view to another to structure document This all has to be put together as well 64 64 we have now Converted all of those tab pages To the new schemes or that scaffolding I mentioned in previous versions cannot be torn down again I brought to effectively 300 plus dialogues is it me all of them at this point Then there's a whole set of UCL widgets now that are being added to that list of things that are not being used directly So we don't have any direct use of the progress bar or image controls and spin buttons also Added to that sense and then the roadmap which is being used in The assistance is is is also wrapped So here's 64 an example of that assistant we're out to using the gdk assistant directly when it comes to the wizards So there's an example of one from the mail merge also more notably in the database intro dialogue as well It's converted over now 70 what's the reason for one there's a No great change in the number of dialogues before beginning to Close in on the last uses of some of these widgets So again the whole dialogue class itself is wrapped We have completed all of the dialogues are done at this stage and all of the assistants are complete and a whole set of Less common widgets are beginning to be at it as well most notably here We have the is if you hit our tab list box in the Sv tab list box those are that the most dramatic ones to be able to see moved out of common use At this stage as well as the our dialogues we complete with the part in my store We begin to see a certain number of native elements in the tool about side as well. We've got through those here now So here a screenshot for And I said the zero release everything highlighted with that move or pink line as a native gdk element The native menu bar show but that's not a special at this point. That's a six down zero But here now we're beginning to host native gdk widgets Inside in the main window part. Oh, you see it the sidebar you can see that each block is A native gdk top level container hosted within the VCL window itself So that there are one two three three gdk pain was there and included inside through VCL windows the top then we've got the Toolbar area we've got native gdk widgets appear within the VCL toolbar and then the whole rest of it then is one single It's all VCL which itself then as one single top level gdk drawing area which is what something that's like a tree to get on there which is So in one sense, it's all gdk within gdk, but it's gdk within the VCL but in gdk you know so again is that the same area that the VCL which is constantly seen outside the gdk ones there so the style Example you can see there's a little gear menu right inside that's the VCL one and the style text and the drop-down to the after all We see it that the two of them are co-existent more examples then What's native in gdk in 7.0 is that we have custom cell renders working. So we have a true gdk Combo box on the left side as a drop-down and then we have cell renders to allow us to do all those previews as we Couldn't originally do the VCL ones as well And then there's an overlay mechanism used to produce that button So you can have a button with a silve menu and very very non-standard kind of a thing can be achieved with gdk as well And the right inside there we have a gdk tree view Again with custom cell renders so we can show previews of the styles It's just a ordinary screenshot of the base and then in 7.0 You can see the outlining again is all of the contents and base are native gdk stuff So all those outline things are converted over that actually means that all you've left at this point is just VCL status there And give you CO2 about so Yeah, so this is the incremental conversion for these kind of embedded cases So if you look at that original base example there, you take each one of those task windows where Task windows is database tasks and reports each one of them It has use an interim item window. That's a VCL window Which is allows you to put a gdk container inside but it also manages the socks of the pressing tab You can tab between the widgets of it and then when you get to the end you press tab it You can move over to the next container so that it's transparent as to whether or not you're in a VCL or a gdk widget move to the next one Once each of those window contents is converted initially here then The next layer up can be converted and you can put your The next level can be converted into an interim item window And on the levels interneuter can be made into simple classes that have no need to do anything about that anymore As you go on the incremental move everything gets up one layer one layer at a time until you end up with a single interim item window instead of having multiple So a single top-level one there again That's the process that has been done for base a base is mostly done like that and that process will have to be repeated for The sidebar here as well. So eventually we will move from having multiple item windows there telling a single item window Because it's a native gdk tree application effectively And you could run gdk try that's gtk. That's a type of a gdk debug interactive And we can use a gtk inspector to this to be a Relegant that allows you to look as to why something is the size of this So we can change the values for widths and heights. So you can change whether it spans roles For though it has Expand space or shrink or whatnot and you can explore interactively Alternative layouts case here. I've just taken the opacity and I've changed the opacity of the Tricky tree view inside in the sidebar to be less visible Right, so what's left to be done? There's the calc input bar, and I've actually done that this week. That's completely now as well particularly tricky there from some drag and drop aspects of that, but it works now as well that gives you Widgetry use in the input bar. There's a mission painting base which is rather complicated where Various widgets can be put on top of each other. So there's missing support for that That had to be added before we continue with that one You look over in writer, there's a bibliographic editor Which is a very very complicated mix of two different APIs already Direct to use in DCL widgets, and then there's the The URO AWT APIs are in use as well and fully converts one from the other So that's being left aside as a complicated find as to There's a start center which was Customy that complexly cost me teemed until recently, but again America has removed all that custom color using stuff So that's now a fine candidate to be converted over. I have a walk in progress there. That's looking quite good Um, that's the start center. Yes, and then as I said earlier You have all these panels each individual panel content has been has been done with the actual panels themselves And then now you need to be converted over and you can bring these little islands of information windows together Free window with just top level ones and completely So yeah, I think that's all I've got done