 In this presentation, I'd like to give an update of the current status of the LibreOffice GTK 4 port. And the first thing I'd like to do is go... So, here we have our demo of the GTK 4 version. We can clearly see something on screen and it looks like LibreOffice should. If we look at the menus, you can see we have functioning menus. Here we can see that the menu is too tall to fit in the available space. We now have scrollable menus with a scroll bar on the side. The classic first dialog to look at is the word count dialog. Here we can see that the buttons have now migrated to the top of the window instead of the classic at the bottom. All of the help buttons are now replaced by this little indicator instead. The other classic dialog is insert manual break. Here again the same top level buttons. Here's an example of a combo box with a drop down menu working. And if we enable that, we have a functioning spin button there like that. Look at more ones. If you insert table, it's like the more complicated dialog. Here we have our tree view down here, functioning perfectly fine. And previews of days as we select each entry. Check buttons. Then if we look at Format Character, we have the usual notebook, multiple tabs, color selectors, all functioning under GTK 4. Over here, for drop down menus, custom widgets can be interacted with and drop downs also working. The famous double decker notebooks also functioning as well. Can fit them into the ordinary space available. The two level mode is also. If we look over in Impress and select that and check down here. We can see that we have functioning OpenGL slide transitions in preview mode at least. We don't have them working yet in full screen. But there is enough functioning to show that it will work in the end. Typing works of course. Context menus work. Context menus now. Slide. Like this. So what has changed in GTK 4 from GTK 3? The first obvious thing is how events are managed has changed. In GTK 3 to get mouse and keyboard events and so on. You can connect directly to the GTK widget and connect to the signals such as the keypress event, keyrelease event and so on. Now to do that, you have to create an event controller for the type of event you are looking for. In this case, key events. You add that controller to the widget and then connect to the keypress keyrelease events at the controller level. This has knock-on effects that are part of the API as well. So things like input methods and what not are all correspondingly changed to work with controllers instead. This makes a lot of things actually more simple from our perspective. That GTK event itself is now opaque and you can't pull out with individual members. Either some accessors have been added or many of the cases that require data that we need appears as arguments to the controller callbacks. All of this is relatively straightforward from a Libre app perspective. Cut and paste. Well, the first simple thing is that GTK clipboard has basically been renamed to GTK clipboard. The way we want to operate with the clipboard is that we just want to get the formats that are available in the clipboard. There are mind types and then we just want to get the raw data of that. Afterwards we do the conversion ourselves into our own internal formats or vice versa from our own external formats. We put them into the clipboard and we just want to have that view of things. The first change in GTK 4 is that there is now an API available to let us know that we are pasting from ourselves. GTK clipboard is local. That's convenient and can replace a horrible hack that we're using in the GTK 3 version. That's a positive. In the GTK 3 version it used to be that formats were identified by GTK Atoms. We got the mind type of that format by calling GTK Atom name to get that. Then we would call a GTK clipboard wait for contents to get the data synchronously. Convert to that and return from that to the various formats that we use internally. Fairly straightforward from our perspective. That's more complicated now with GTK 4. We can use GTK clipboard get formats and we have the ability to call GTK content formats get mind types. That's more straightforward than the previous mechanism. There's only an asynchronous mechanism to get the data now. You have to call GTK clipboard, read the sync and then a whole set of full callbacks are triggered by that. You're given a GTK input stream to read the data from. You read a chunk of data and then you return back to request to read the next chunk. And eventually it will arrive back with the final chunk and at which point you have all the data that you need from the clipboard. So it's a more roundabout mechanism from our perspective. It's basically was already doing something very similar to that. It was hidden behind the GTK clipboard wait for contents was hiding a lot of this complexity as far as so. Basically we replaced that. We have to shoehorn these new asynchronous APIs into the labor office view of the clipboard works. Spinning the main loop during cut and paste until eventually the paste completes. And we have the full amount of data that we're requesting from the clipboard. Drag and drop is strongly related to cut and paste. So when it comes to management of the data that we get from drag and drop or we reuse drag and drop we can effectively reuse the same code that we did for cut and paste. The GTK 3 event driven drag and drop has now been replaced by GTK 4s. It's a controller driven drag and drop. The changes to this versus the other controller conversion as shown in the event slide is much more extensive. But for the most part there are equivalent calls in the GTK 4 than there was in GTK 3. It's just a matter of puzzling out which one maps to which. Our changes is in launching a drag and drop. The GTK drag begin now takes a GTK content provider argument and that describes what data the drag and drop will provide and then will write that data when requested. So to make all this work in the labor office we have to implement our own GTK content provider and that then translates the labor office view of the data, the GTK's view. Drawing, the changes in drawing. The changes in drawing are the most extensive changes versus all the other ones. And GTK 3 was previously possible to connect to the draw signal and a custom GTK widget to get back a chiro context and we just plate our backing surface to that. And GTK will have clipped that destination surface to the areas that have been marked as invalid. When we know that part of our backing surface has changed we are tracking the damaged area and we just tell GTK 3 that GTK widget queue draw area. What areas are now invalid. This has all changed in GTK 4 but there still exists some routes to reuse our existing chiro based drawing mechanisms to get something working straight away under GTK 4 without having to investigate too deeply the new mechanisms of doing things. So to make all that work I decided to use a GTK drawing area for our custom drawing instead. This is how it looks in GTK 3. Just for reference at the top you have your menu bar which is a new GTK menu bar and you can see in the GTK inspector window which I've placed on top there. That you have a top level GTK window and then you have a grid and then that contains two members, the first member is that menu bar. And then we have the GTK event box and that's the event box that we listen to in GTK 3 for all of our mouse events. And other keyboard events etc. Inside that then we have this custom widget, this 00 fixed widget. That's the widget that we draw to. We draw to that by listening to the draw signal in the previous slide. We can also host native elements like the sidebar widgets. We can host them directly in that fixed widget. In GTK 4 as I said earlier we have now changed to drawing to the GTK 3 drawing area. The GTK fix still remains but now we've placed the two of them inside an overlay. So what we have is a drawing area, a GTK drawing area that fills the entire window. And then we use the overlay to float that GTK fixed up on top of it. Which means that we can still continue to put our sidebar widgets into the GTK fixed and have them up on top of the drawing area for positioning purposes. The side effects of the changes in GTK 4 is that there is no longer the queue drawing area. Only the ability to call the full GTK widget queue. So only that remains left to trigger the redraw. And on the redraw we're bleating our entire backing surface on every redraw. So on every cursor and blink the whole thing is bleated again. This all works and it feels fine in practice performance wise. But the long one we may need to rethink on that one. The other part of the drawing changes from our perspective, our drawing changes is that GTK's foreign drawing API is removed. So there is no longer a simple route to render our VCL widgets to look like the ART GTK widgets. Where we're using GTK widgets this isn't an issue. But some of the remaining VCL user interface elements like the application scroll bars in GTK 4 revert back to their built in original VCL look which you may have seen in the demo earlier. User interface descriptions. In GTK 4 the widget inheritance hierarchies changed. So previously a GTK spin button inherited from GTK entry. So GTK entry properties could be used in GTK spin buttons as well. Now on 4 it inherits directly from GTK widget. Other changes are that the generic container API has been removed in favor of specific APIs for every container. So GTK box and GTK grid have their own APIs for adding or removing children. And the generic API of GTK container add and remove doesn't exist in GTK 4 anymore. So the user interface file format for GTK 4 has correspondingly changed. And it's an error to load properties in GTK 4 that were removed. And this can happen as in the case of GTK spin button where the property used to exist and longer exist. There's a whole set of other changes as well. Seeing as we're not planning to change over to solely GTK 4. We need some sort of interim mechanism to continue to support both versions. So we managed this in two parts. First is basically after the part of the GTK 3 migration guide. Preparation in GTK 3 is to make the changes there that are recommended for GTK 3 applications. In advance it becomes GTK 4 applications. And these are applied to user address files in ingates. So these are statically done. So this script has been UI rules enforcer. If we write our user address files to remove properties and elements that have been deprecated or country indicated already in GTK 3. For the most part the properties appear to be accidental properties. Maybe somebody fat fingered something or accidentally used the scroll wheel while hovering over the panel and glade. So you get cases of where that double buffered property is set to something which is not something that we ever want to do. Or perhaps that a tracked visited links property has been toggled on in a GTK label. Mostly meaningless accidental changes. That's the static parter thing that dynamically then when we take these GTK 3 UI files as runtime. Runtime convert them to the GTK 4 equivalent properties and layout. This is conceptually similar to the GTK 4 builder tool that comes with GTK 4. Except that the builder tool will only give you a kind of template from which you have to make your final changes manually. The scope possibilities of what you get in a generic UI file are too broad really to make a perfect conversion. But in our case we can take advantage of the fact that we have a uniform nature of our UI's that they are basically following the same pattern. We can use the initial static script to find and identify and fix up any of the cases where there's some confusion as to what the version should be like and force certain rules there. So we continue to have a legal GTK 3 version that we can convert automatically to create functional GTK 4 UI versions at runtime. GTK image, GTK picture. In GTK 3 you have a single class GTK image. In GTK 4 this has been split effectively into two separate things. GTK image which is a fixed ratio which is typically used for rendering icons. And then you have a GTK picture which is less constrained. We have to basically decide at load time, at runtime what type of destination GTK 4 which is as a source GTK 3 image have to be converted to. So if we can see that it's loading an icon then it's a GTK image which is the typical case. And then if we see that it's doing something different such as the help about case then we have to convert to GTK picture. So that adds a little bit of complexity to the conversion process. A lot of changes related to that is that you can't create either of them from a chiral surface anymore. But we continue in our GTK 4 to keep our virtual devices to be backed by a chiral surface and we often want to create an image from one of those. The argument they take now instead is a GTK paintable. So I've bridged that gap with a simple limitation of one of those GTK paintables called a surface paintable. That then uses this GTK snapshot append chiral to append on the snapshot of a chiral surface to those widgets. So we can continue to use our virtual devices with the replacements in GTK 4. So that covers all the things that a worker can be made to work with a little bit more effort. There's a whole set of other things that I haven't really investigated closely yet. So for example GTK has split top levels into standalone application windows and pop-up windows. And I've made no effort to do anything with pop-up windows yet. So where GTK itself managed them directly such as the menu bar or pop-up menus then they were perfectly fine. But for something like the VCL toolbar that kind of drop-downs that they don't work at all yet. Accessibility has also changed pretty radically in GTK 4. I've made no effort to look into that deeply yet. So I just stripped it out of the user-based files when they're dynamically converted from 3 to 4. And there's no code yet to bridge our existing accessibility implementation with the GTK 4 one. GTK 3's local functions has also gone from GTK 4. So Sula Mutex is no longer automatically acquired and released by GTK. I haven't really paid much attention to that yet. It doesn't make much of a difference when you're just using it directly as a user. Some of the other toolkits have a similar problem so we can adapt the same solution used there for the GTK 4 one if necessary. They've decided things then. GTK 4 comes with built-in video support with GTK Media file which looks quite exciting but nothing is making use of that yet. But it does look like it should be possible to replace our direct use of Tree Streamer with GTK Media file instead. Which would give us maybe more flexibility and hopefully a smoother, more integrated approach with the rest of the interface. So yeah, that's where we are. GTK 4 port exists. A lot of it works. A lot of it doesn't work. But it's clear for the most part what needs to be done to get those parts working. There are a few unknowns that it looks very, very plausible that GTK 4 port will be successful. Thank you. Okay, thank you, Colin. Are there any questions? I do not see any questions in the chat room. Colin, perhaps you have something to add. Yeah, I suppose. I've just worked mentioning as well that affairs I can tell all of the dialogues are working so it's not the case that I was like skipping parts that don't work. I know that there is a few cases that aren't working 100%. But for the most part we're talking about 95% of the user interface. It seems to be functioning fine. Full screen isn't really a major issue as far as I can see. The one thing that is outstanding and most difficult is probably those pop-ups and the lack of foreign drawing. And it might be an easier in the long run to just continue the existing welding stuff to end up just using the GTK 4 scroll bars directly rather than spending any effort to emulate that now missing foreign drawing. So that's probably also the approach I'm considering for those pop-ups. So the reason I haven't investigated it is because I'm thinking about avoiding the need for it entirely if possible. Yeah, thank you. So Cisco is asking what was harder, the migration from GTK 2 to GTK 3 or from GTK 3 to GTK 4? For us the migration from 2 to 3 was more difficult because when we did our GTK 2 port we knew that GTK 2 was backed by X. So we continued to use all of our old X-based stuff whenever we ran into the sand with the GTK 2 port. So when we went from 2 to 3 we really had to do all the work we should have done when we moved to 2 in the first place. So we had accumulated a large backlog of problems there which meant that when GTK 3 could run under Wailand existed and half of that stuff just suddenly failed to work. So 2 to 3 is more difficult to get up and running to see anything on screen at all than it was from 3 to 4 to get something visible that you can motivate yourself to continue working from 3 to 4 was very easy. Although it does remain to be seen whether or not migration fully to the approved way of doing things for rendering GTK 4 that might turn out to be more effort but clearly as you can see you can see something straight away. So it was much easier 3 to 4 than 2 to 3. Okay, thanks. Yeah, as they are coming in a lot of praise for your work. Nikolas saying Kallan Naira is a beer for you for the awesome GTK 4 work. Thanks a lot. Raphael is saying GTK 4 dialogues looks great, nice work. Even Kandy is impressive of the stuff you've mentioned and Jamex. I guess for the Zola Mutech stuff you can go the same way than all other platforms just moving all the GUI stuff to a main thread. It's probably faster too. Do you know this? Yeah, I know. Well, yeah, I feel pretty much the same way that it's probably easier not to try and fight the tide and just accept that this is the way it is. And seeing as a tool case do the same thing, follow the same approach and indeed dispatch onto the main thread. If in the age case something happens and not in the main thread in the first place, which is fairly rare from the perspective of somebody just using it normally. You get cases like that in the extensions dialogue, I think is one place where it comes up where stuff is done, not in the main thread. So yeah, that's probably the right way to go. Hossein also is praising your work. And the question, do you know if the next Red Hat Enterprise Linux version 9 will be shipped with GTK 4 and it will be used for LibreOffice in it? No, LibreOffice will not be using GTK 4 by default this year at least anyway, because it just isn't going to be ready. And it's not intended to be ready.