 Yeah, so I get pretty much this talk, I just go ahead and take about two months off. So this is the 14th e-graph of this 2GTK3 and the current status of that. So first, I was going to do a quick demo of an ordinary GTK3 application and then the comparison of that against the current status of 5.1. So over here, we have Glade. So I use Glade because Glade still has things like menus and things like that. So it's still an application that's quite like our one that hasn't gone down the route of innings with gear menus and things like that. So what we have is menus that highlight in blue like that, little blue line separating them there. Down over here, we have a tab down here which is a similar effect. You've got it to gray highlighted, you go over it, you click it, it goes blue. And if you go over, if you use the mouse to go to menus, you see you just have no underline. If you hold down the up button, you see that the mnemonics appear automatically, but only if you press the keyboard. If you do the same thing over here and go down to the highlight, that's not, okay, the highlight, basically. And you have the R&D checkboxes, there are two specials there and the speeders are now really, really large. And so that's your town and that's your hub and the other side is like that. Yeah, standard enough, you have bold headings there and things like that. So that's a standard 2D application. So if we read that, we should reveal a 5.1 behind here with GTK3 enabled. Now the first thing is that, yeah, I exactly have this keyboard here here. So again, here we are now. We have the same fit. Here we have the blue highlighting and blue lining between it just like that. We treat this like a tad dialogue. So we have a grayness as you highlight there. You click on it and it goes blue as you would expect. So I hold down the keyboard and out mnemonics are automatic like that. If you go to tools, what do we have? We'll do that, we have something like that. Well, over here we've got the highlight and you can see around the corner there we have the focus rectangle. It's quite different now. So we actually natively draw the focus rectangle with a native for GTK. We use GTK to draw the focus rectangle instead of using our Aroma rectangle which is our painting that we did in GTK2. So that's what it's supposed to look like for me. So that's what I see when I use GTK3 port. I know there's some complaints with people with different themes that it doesn't quite look right but this is my experience. That's why I think it's not too bad. So I know it's difficult to experience it on a dark team but we're not using a dark team. So now we go back here to this and obviously because of course that's an empty presentation we don't want that anymore about the other one. That's the demo of that and I will briefly run through the architecture of GTK3 and its difference from GTK2. Basically the whole thing kind of works so that every platform, say Mac or Windows or the different ones you have in the Linux has to implement a salad instance. A salad instance mostly consists of creating, destroying stuff or either printers, frames or virtual devices and every platform has to actually implement every one of them and say the frames in here are actually visual windows on screen. Your virtual devices are your non-visible covenants which are normally for X for talking about case maps versus your standard windows. And you have to have these two basic parts to implement the VCL stuff. Frames then and virtual devices implement it and acquire graphics, salad graphics. The salad graphics is the thing that you draw with so you draw a rectangle via your salad graphics. Draw lines like that. And some of the APIs are optional so that if you return the files with them then VCL will go off and enable it as best it can with its other printers, the non-optional ones. Some of them are ridiculous but it makes sense for printers that draw ETS. You can even give ETS to it and have your revenue put your ETS into the postprint when you are printing for postprint printer and generally that's actually nothing and not a little and on any other platforms. The native visual support stuff is part of the salad graphics as well and that's where we actually draw things that look like your native platform's widgets onto our services. So when we have the GTK buttons, we don't actually have GTK buttons, we have our own buttons and then we use GTK APIs to draw onto our buttons to make them look just like a GTK button. So these are some standard implementations in VCL plugs. So we have Windows implementation with Mac implementation and then we have our Elixir implementations and they are selectable at runtime so they are in the VCL plug pattern. The original one, the generic one, the gen one is for X11 and then we have GTK 2 and a bunch of KD ones. They inherit from the X11 one so the part of it there is that they mostly reuse the X11 code, accept it better to do it and we just support so you have the GTK stuff with a lot of GTK rendering and if it doesn't need to do anything different than the original X11 code, it just reuses the X11 code. In that case, the GTK sound frame inherits directly from X11 sound frame and you find all this all the way down the tree that most of the time you're looking at using the online X11 stuff. When things get any way tricky at all, you end up just going back to the original X11 stuff. As it says at the bottom, the entirety pre-paste and drag and drop where implement is in that X11 generic backing and not in, not especially for GTK 2 and not especially for the other ones that derived from that which would go into the draw. In some places then we go as far as to, in the GTK 2 port, we go as far as to pull out the underlying XID of the GTK window. And printing on most of these ones is a generic cost back in so in case we don't have to worry about that, we will do GTK 2 or GTK 3. Now so that's pretty much the GTK 2 one that was put together and we have problems then we go to do GTK 3. There's a lot of overlap in GTK 2 of course in the places where we're not doing anything directly to X. But we have a problem in that we've not into back the version devices that we mentioned earlier. Earlier we were saying that we were backing them with X with Xmas. But if we're going to use GTK 3, then what we're looking at is we have used GTK 3 for the future. For Wayland support, we don't have XM behind you. So it's no use to us to continue to do things behind the XM back in and no use trying to do things with Xmas. So we had to have something to back those virtual devices because those areas, the surfaces we go into that are not directly visible on screen, that they're off screen, but we can do things with them. We also can no longer draw directed windows. We can no longer, for sure, that we actually had an underlying X window there so we can go and grab XIDs and then try and do things directly with them. So when we have a replacement for those Xmas virtual devices, the Xmas Clifford virtual devices, we need a new server implementation that can draw into those graphics, that can do the draw rate and the draw line and the draw EPS and things like that. What we have already is a headless mode. So we use a headless mode right now for all of our tests that do it and things like this that we do make a headless back end to use lots of times. The original headless back end was written to be a commercial product from some, so it was separated out initially from the rest of the open up code base. So for that purpose, it was implemented originally as an ECM plug so it could be an option to load it at runtime component and then it would be a good idea to target it for server applications such as dynamic conversion codes. At a later point, it was really spectacular and it was made part of the open up code but a remated ECM plug, that was a load of it. But at this stage, the headless back end has been extended and tweaked and forms a large part of the open up code for the Android port and the batch of tired stuff and quite nice. So all of these things that have ended up needing something to render onto our platforms where they don't have support for that is ended up using the headless stuff here. And the headless stuff is the same thing that we're going to use. But we are using effectively as the back end of the GDK3 stuff. It's implemented at the side instance and it implements the virtual device button that we need to remember to and mostly complete the server graphics implementation for draw line, draw rate, alpha blend and things like that. So that's what we have now. SPP is one of the subscribers of the Starevue portal and it's actually starting from the headless thing. So the GDK2 implements the X11 and the Android stuff is back down to the headless thing as well. And the GDK3 one there is some kind of a mutant where it inherits from the SPP thing and then includes at real time all sorts of stuff from the GDK2 one. I would like to give this so that we hear from the SPP and we reuse as much implementation from GDK2 at big sets. I have very little to do with any of that stuff. So that's just a description of where I found this space. So thanks to all these people who are convinced that I saw in the GDK3 directory that I could be implemented for 950 GDK2 stuff. So okay, that's what we were. But if you've seen any of the screenshots that showed up in my blog over the last year, that wasn't actually really used. So let's make that all a lot better. The thing here that Headless Baguette uses is the basic EMP big map offer. The whole pilot case that I came into that I found that we're doing lots of graphics by a form of conversion between the performance that are required to do things with Cairo and the performance that are required to do things that definitely were better already there. We need Cairo to work because GDK3 uses Cairo all over the place. It uses Cairo to do its rendering. So we need to be able to render onto our surface easily with Cairo to make it manageable. So I wouldn't do the whole pilot conversion if everyone was not supposed to weigh it down. It was Cairo to the middle man and Ed, Cairo compatible with formats and two basic EMPs. So sort of converting to front, just Cairo to the middle man and we have that in our GDX pilot format layout, which is compatible with Cairo. That means that we can use Cairo directly on our basic EMP surfaces. We can just say Cairo, Cairo create surfaces well. The big map surface that we had drawn to Cairo stuff and the problem itself. That means that we were able to say to draw a code pile of format conversion stuff and the whole kind of pilot places where we were creating 10 free butters that were compatible with Cairo can draw or draw with GDK3 APIs onto a button, then take that button and convert it back to the older basic EMP format and then put them in the right place. Need lots of work copied and then get them out by one error here or out by two error here and then just, these are right around the corner. If it doesn't then get rid of all that, you can draw Cairo straight to these EMP surfaces and then get rid of all that conversion and that then gives us an interesting that gives us an interesting problem. I'm just trying to see that. You've got that headset on the upside down. That's right, it's going to sit on the upside down. That is a terrible thing. There we go, that way around. Yes, that is a better solution then for doing the 10 problems. So at that point then what we find out is that we are now using a 32 bit surface, the RGBX is the 32 bit in size but we only use 24 bit of the data. But now let's consider it to be a 32 bit format. So we find that at that point, as soon as we turned on the headless back end to now use the RGBX, since it was pre-existing RGB file format that we had issues with 32 bit bitmap EMFs so that these bugs have existed since the EMF 32 bit support was added which seems to be back at the very dawn of time. So it's a whole pile of a 32 bit bitmap EMF issues to be fixed as well, fixed all those issues as well. Then we factor again, then we had to spit out the Cairo text that we were doing was only ever intended to be used in GTK2 in a specific area so I had to kind of genericize that so I was able to just work with any Cairo surface which allows it to be reused for GTK2, GTK3 and to be used directly in the headless mode if the back end is a Cairo compatible surface. Right, so that's getting rid of the layout issues. Next one then is that the base VMT backing surface that you're drawing onto is extended to provide tenant events when anything on it was modified. So again, there's a whole pile of stuff there that was sort of working, but not quite working so I decided to do it instead and was again just simplifying things a bit more. So anytime anything on the back end, on that backing surface, now the backing surface in this case is you're actually what you're looking at on screen or you're actually visual that we've done. So when there's any modification into that when like the word trigger is written to it or not then that creates a tenant event for that area. What we've done directly to GTK which is Q draw area which is this piece of the widget that needs to be redrawn. You get your callback then in GTK draw and draw will be given the part of the screen that you've claimed needs to be redrawn. That then because we now have a Cairo compatible base map, base BMPed surface and you're given in the draw callback the Cairo surface of the destination. Your source and destination are exactly the same file format. No more for conversion. There is no need to add anything. You just take the example time that you were given to the update. You have said that there's a rectangle to the update. It is giving you back a rectangle that needs to be copied into the destination and you're copying your destination, your source rectangle to the destination rectangle. In the simplest fashion possible. So then because the call is simple at this point you can be pretty much sure that if anything is going wrong that it's an issue in the original damage incorrect. You no longer have a complicated situation in the simple situation that you've been given. You've been given the same coordinates that you passed out. So if anything is not showing up correctly on screen you have been one to claim that the wrong area needs to be redrawn. Which means that you just have to keep debugging your damage tracking and start it out. And the whole pile of corner cases there. I think that our money in the fall into the same problem as well where for whatever reason there's a plus one required in the X and M implementation that always has been for a rectangle and the same thing needs to be done the headless one as well. So you're finding issues like that. Now that's all okay for when you had to set your case where somebody has the window on screen and they drag the window wire and things like that you need to basically trigger all those events capture all those events and trigger yourself to resize. When you passed your operating system your window managing system would be wanted to handle that but now you basically have to do it manually you have to connect to those events and force redraw yourself and not rely upon the windowing system to do that. That is a potential corner case. But I think it's out now that it might be a few corner cases but a full screening in press not in presentation mode but in ordinary mode there might still be the case where that initial resize that isn't really fully free handy yet but I haven't seen it in a while so I think that's what it is. That gives you something that I would like about and I'd be very excited about how it works you know I'd be very happy about that and everybody's still looking at it. So at that point what you have to do is get that to the native widget rendering so that you get the teaming stuff working again which is kind of important so it looks right. It's not particularly more difficult in GTK 3 to do the new widget rendering as it was in GTK 2 and again because it's chiral based and we have to chiral better and stuff it's a lot of things just become a lot easier than they were in the original one you can use all the chiral things to move things into the right place copy things around all those chiral APIs that we're able to so you can do things easier but yeah I think that's a little more on later on. So the native focus returns I think well that was a nice visual effect to show the mirror around the next things but much more like GTK 3 than GTK I think our GTK 3 implementation looks a lot more like GTK 3 than our GTK implementation looks like GTK 3 but very convenient for us because a lot of the stuff that's new in GTK 3 are very similar to the stuff you find on the Mac so a lot less of the rendering information so just go around to this and just turn on the Mac style and stuff for GTK 3 that's implemented as well. What is different with the native widget teaming in GTK 3 is that the context of things you there's a whole extended context like if you're in a menu arrow you have to be in menu arrow or in menu entry the menu entry has to be in menu arrow and the menu has to be in menu arrow the menu arrow has to be in the top level widget you have to have the hierarchy just right in all the context set just correctly to get the same effect as you do in GTK 3 and GTK 3 you know it just happens because that's the way it actually is in our one we were not actually really using the GTK 3 stuff so we have to arrange them into the same way that they are in GTK 3 to get the same visual effect which is a nuisance that you have to go right into the implementation of GTK 3 so to see how things are you know what context so an arrow they use it to render the button at the render arrow you have to go right in and look at them so you have to arrange them to a certain degree so you have to investigate for it closer to that way but that does allow us to get is support from GTK 3 for gestures such as gesture support for GTK 3 implementation and when you're using them I've added support for them but they've only made use of it in the press slideshow for now so what you do in the slideshow is you put your fingers on and trust me you can slide aside one direction you slide aside your direction from far and back you can do a long press on your presentation to get out the context and then you can draw the payment then you can long press to get the context and then you'll begin and revert so when you get a sample you spend a bit for now and the hard to do one as well that I had in mind but I haven't integrated a pinch to make such a presentation the auto-manage that I showed you earlier when you press down about the auto-move is all done by Simon Lough from Raspberry Pi so I'm looking to do it with me but it's very appreciated I forget that at the right time auto-manage has been on the proper keystroke so that's a big plus and I didn't have to do it because the GTK 3 one was derived from the X11 one we got cut in case it was free we just used the X implementation so that meant you had to do that to be able to then cut a piece of scratch which is not a lot of fun but it wasn't as bad as I feel but it was quite a bit different again accessibility you had to do it basically it was possible that we'd have to re-implement narrow path accessibility but enough GTK 3 to get the opportunity to improve things what's on a GTK 2 so once you figure out how GTK 3 operates with accessibility that's 10 times easier then the GTK 2 won't get that it then integrated so once you finally figure it out after all the week you've got like four lines of code to plug our all of our old accessibility stuff right into the new GTK 3 stuff and everything just continues as before so that's a great way that there wasn't as much effort in accessibility as there could have been yeah yeah exactly then it just comes into a new API car to do something that was very difficult in GTK 2 so that's the GTK 3 stuff that's basically why it took as long as it did and that's why it's still more difficult than it might initially appear even though we had GTK 2 working because we never really had GTK 2 working we had so much GTK 2 working that we just left it up to our excellent implementation to fit in the ranks the reason I'm doing all this is because Red Hat wants to get things working on-win all that stuff there is and this is still an hour relax server here so all that stuff is the exit mutation at that point then you've got something that's halfway working pretty much working and we flip over to Wayland and we see it doesn't work under Wayland so why didn't things work under Wayland? the first thing is that your top-level window under Wayland now is really toxic you don't want to do anything that you're top-level window the first thing we have done over top-level window is to say that it's don't want to buffer is to turn off this don't want to buffer yeah if you turn off don't want to buffer in Wayland then you get a blank screen not like a blank screen like a gray or blue but like a transparent window that you don't realize it's even there for a while so if you do if you read the documentation the documentation now says don't use this in the Wayland I don't know why it just doesn't tonight print out don't use me on the console when you're under Wayland that would save a lot of effort because I read out this documentation quite quite a book so I knew it so I didn't need to revisit it if I thought so I there was nothing about Wayland we just said don't buffer it in the past but anyway when I finally visited the documentation I'll be clear again we connect to draw on the top we connect to draw on the top-level window if you connect to draw on the top-level window you no longer get the same effect of the Wayland that you did on your X on your X it all worked out perfectly fine on the Wayland the top-level window is toxic so you get your opposite from basically what you need is the decoration decoration of Wayland is part of the top-level window so if you connect to top-level window it has to draw when it needs to be drawn the Wayland will draw it only under the top-level decoration and your applications are offsetting it and it's in the same way so the overall solution for anything is to move away from the top-level window and go to one level down and we already had some we just on the top-level that we were using to capture accessibility events that becomes a far more important widget in GTK3 that becomes the actual widget that we connect events to so we now draw on previously only for accessibility window is now extended to this in GTK3 and is the contents of the window and that's what we draw on to instead again if you connect to the mouse events at the top-level window then nothing happens you get a window that's only size when you're after kicking out some unknown event handlers for that again the solution again you have to move down the level again put an event box in between your top-level window and this widget that we're drawing to and that gives us something that is a little bit acceptably dense so that we can move resize the window and then get our mouse events in so that's where that's all the convenient stuff things I described they are all done as well so that if you do have a Wayland version a Wayland server and you start drawing for offers 5.1 and master version you've had something that you've pretty much the same as you have before the X1 that I showed you what doesn't work is placement of menu but that's because placement menu doesn't actually work all that well for GTK itself so that's the work in progress so that's not really one point investigating that for a little bit until GTK itself it's happy with the menu placement what I know as missing out in GTK3 port is drag and drop support that's on my list I get to them one of the days that G streamer support shouldn't be that difficult I haven't got around to it yet the top of the windows under Wayland and some stuff that needs to be sorted out there again, not treated the thing we've done and we said that these hard selection of tangos using Zara you'll find them in the layout I mean the layout area of the panel in the press so if you move your mouse down there on the GTK3 one and you'll see some focus from tangos appear and disappear and because of Zara that's not implemented probably never will be in those backends on the point you may want that yeah and all these 32 bit bitmats they're all on the unoptimized pads as I said before how we're covering all these bugs in the 32 bit EMF with that stuff because all this is on the unoptimized pad so there's a lot of opportunity for optimization down among these routes as well this will presumably affect the Android stuff yeah and there's lots of stuff that's not being prepared in that original SPP backend so yeah we're going to find some things like jagas here and there so what you need to do like is improve that backend for the purpose of improving all of that and this is part of the future stuff okay we are in the future we're worried about that for now all I'm saying is that I do have one I'd like to make more GTK3 about it and I have a little sound recording something that's very music later truly needed GTK3 to have a lot of time and like to get some opportunity to expand and make it okay thank you yeah all these areas get FTAs rendering in places of use and there's the amazing I did for I did some stuff like directing Cairo like the other bitmats because you know you can do blue selecting thing I did start some stuff in Cairo I don't know is Cairo available for all of the teams that need to head to this backend because I would be worried about doing stuff you can start with Cairo I think I keep the question that's the that's even a natural question yeah I mean all right so that's a bit man so I'm wondering the slides that you were showing before the problems with GTK3 and the way they they've got a box in the way they've got they've got the um the time to say well I think that's not what we're doing or okay quite I get bugs if there were bugs if there there'd be bugs in GTK3 I wonder where in that I think okay but I don't think there's stuff like all like files these files yeah they're going to be going to be there yeah yeah yeah I mean if you're an army GTK3 application you don't do many kinds of things that we do so the only other person that we need is going to be our our cylinders and fire points and the clips and they have the same kind of problems but yeah for the GTK3 application it works just fine but it sounds like it could be fixed in one and there's a lot of quite a lot of questions coming up I don't pretend no on the top middle is the right end I'm pretty sure there's the right at the top I just don't know okay that's the end bye bye