 We are waiting for them. We want to be on time Okay, yes Okay, so hello once again, and thank you once again We keep going on the GTK and GNOME topics. So the next speaker is Guillaume He's gonna talk us about the GTK RS crates that has been mentioned before so Applause is for him and let's go so hi everyone, it will be While Jordan made some kind of introduction, so I'll be able to be a bit faster at first. So let's begin It will be about last developments in the GTK RS and what we intend to do like for many next year So first who am I so I am mainly a rest reviewer and contributor part of two teams there and I'm also the current GTK RS organization owner on GitHub So yeah, now you have a pretty much good idea for what is a GTK RS, but let's go over it again so The point of GTK RS is to provide the bindings for most GNOME libraries in rest of course The point is to bring a safety and more usability over C libraries in rest directly Pretty it's for now a girl we have we're moving for right So let's start with the newest developments mostly since the last for them So if you were there at the last for them, maybe it will Be of some help. No, no So we just talked about the ETK by Jordan So we added a binding for the ETK We felt it was like a miss. So now it's fixed Just like a job and it said it's an accessibility toolkit library. I don't know we hope to be able to Make it more integrated into GTK or to be able to have it by default at some point So people don't have to provide the extra efforts to provide accessibility to everyone so another big things that what A crate to test user interfaces because we never say it enough but testing is good Not nothing, but whatever We call it the GTK test It's pretty easy to you to use It was started by Anthony at the time it was used to test a realm for those who know it so we just Improved it and modified it a bit in order to make it work for GTK RIS as well So as you can see Yeah, you see my cursor So in here we just create a button. We give it a label. So it will be called button because It's nice. So when you click on the button, we will switch the label to clicked again so much for the originality So here come the interesting part so with the GTK test to create You will be able to send a click event to your button Then because we want to be absolutely sure because we don't know what kind of server is running this test upon everything fine So we wanted to wait a second to be sure that Zola Bella has been updated And then we just to check With a nice a micro we added as well as that the button Label has been updated We also added the continuous integration for macOS because what we are supposed to suppose to Support Mac as well and since I'm mainly using Mac. It's nice to Thanks to Travis I guess So here come the interesting part So API improvements, so of course we have a lot more functions generated I will maybe maybe go back to that later on We improved the debug implementation for enums in Mac. Now we have a variant printing the correctly Which was a bit weird before but now it's working fine Someone last year asked about the support of future for asking functions in rest and JKR is well now. It's there. So if you want to test it, it would be have a fine to have a good box We also added a huge improvements of a glibs channels on the main context type and Of course, we had a lot of backfixes and everything But that's not everything we added the more into bonds So now you can have some nice calls So for those who don't know the into trait the point is to be able to Instead of having to pass none and some every time you give something you still have to give the none But for the some I should have a right to cut example You don't have to give to wrap your string into some and the same goes for the types Just like you showed in here. So the parent in here doesn't need the some if you give it It will be automatically converted inside the function directly It's my need to make a user's life a bit easier more fun to use But we also added as a disk as a display trait. So It's funny because it's mostly used for debug But yeah, so now if you create a widget in here a button again, and you print as this widget is its type It will be showed just like you believe you can see it here Yeah, of course we since we rely a lot of automatic Create and code generation thanks to gear I'll go back to that later on you can absolutely Disable this trait implementation I Think it's mostly G streamer who is doing that because they have some specific display trait implementations So I will let Sebastian talk about it later Yeah, just so it's a whole talk of Jordan was about it So more and more applications are being written with GTK rest and in here and rest more generative So just like here he talked about the fractal podcast G radio, which is still a work in progress and news flash We return from a field reader work in progress again, and it was just most Famous, let's say a norm application. I know that There are a lot more applications. It was Clyde. I think it was a name a lot more So another thing we added because code is not everything It was a frequently asked a question section. So We had some questions be asked quite frequently actually so for instance why are really this song so currently we have a Pace of around to release a year. So you will have this answer on this page I Recommend going it to there some interesting information are there Okay, so now what will come next year mostly and maybe further we'll see so of course Again a more API improvements. So functions with callback generation I had to rename this feature because my name wasn't appreciated Let's clones of strings that was you can already test it actually thanks to just ring type The whole point of this type is When for instance you return you get you we are in the example We were checking the label of the button So when you get the label of the button, you don't need to modify the string So you just get a constant a constant pointer. So instead of cloning it into Into a string in rest You we just keep a reference to it and then just provide it to the user as long as you don't try to modify it things will go fine and Of course, it's something for the long term, but object inheritance would be Will be a big thing for now. It's I think it's only very nice in a sepus plus binding Don't know for the other languages. Maybe Peter Python as well. Don't know a Thing we went into Currently was with as an inter trait. We realized that that too much into trait usage was making User life a bit difficult for user callbacks in for instance. So we'll talk well In some parts as long as the type is simple You won't have to worry and still have the inter traits But for signals and the function we focus her callbacks It's very certainly that we will remove it because it's complicated in time in case you don't want to provide a callback It will be known and you can't Well, you need to Provide to the compiler some information about the type you were supposed to give and it doesn't work very well And since I was talking about functions with callbacks, so you can see the nice C code in here Which becomes some a nice rust code in here So just like I said, there is no into very Just like I explained because you need to tell the compiler that you want to give something like this Which for now is just generic because fn is a trait, which means that it's closure or a function actually and You can't really give this information if you don't have it Simple as that so the compiler at least want to know you people with that so as you can see You don't have any more the data It's since we have a closure We don't need it because you can just give it to the closure directly and the destroy Parameter is gone as well because it's handled internally directly by GTK res now The data is destroyed directly by us safely So function with callbacks or just like I said, we don't allow user to pass destroy closure We removed the user data parameters. We are 100 lifetimes nicely. I didn't talk about that In here for instance Since this function can be called way later in the code and you're not sure that your parameter will be alive at this time You have to make it static. So anytime the function wants to be called Or will be called the object will still be alive and well, it's the mostly handled with a reference content and sales mostly So yeah, we have multiple handling of this. So for instance if you have a callbacks from there Recall on three views. There is a sort function so if the phone is a sort function Well, the sort function won't use as a closure afterwards So you don't need there's something to be static that as well is handled mainly by GTK res and the type of become FN MUT Okay So yeah, the almighty gear I mentioned it a bit earlier It became as a cornerstone of the GTK res project like We have literally every crate we have is that I generated a thanks to it With the exception of Cairo, which is because of the gear files not being very Nice up to date We can't generate using it Since the last year we had 10 contributors and well now It's a bit more than 110 commits But that's still a lot and more and more projects are depending on it For instance, if I recall correctly a little bit RSVG is using it as a library That's fine for it Maybe I will give a bit context of how we gear works. So you have a little program on a GNOME side which reads the C the C code as simple as that and generate an XML file explaining how how and what it is so Can I see? so for instance this function the page think has to be alive for a long time, so it has The parameter will have a kind of Closure will be you have three kinds. It's notified I think and Another one, which means that you can have it in an even longer time You have a this which is marked as being a part of the closure Which is important and this destroy is marked as being as a destructor of this one And just like this you can thanks to this information, which is quite complete generate literally everything. We use gear to generate a documentation as well so When we say the almighty gear it's literally thanks to this project that GTK RS is able to be alive now and It starts to get a bit or no because it has been starting in 2014 if I recall correctly So we're starting to have already a code depths Which is not so good. We come back to that So GTK RS environment because Code is nice and everything, but you have also humans behind code So a few numbers. So currently GTK RS organization has 29 crates so Yeah, and we are not counting your G steamer crates which means that It will very certainly grow up in the next year depending on how many new crates We'll be adding That's actually a question that have been asked a bit Frequently, so I go back. So currently no, we don't really have a process to accept the new crates and stuff So we just go as if people Both are of enough with one crate. We just end up Generating it and hunting But as you can see, it's a lot of crates making Every release a very long currently it takes Almost up to two days Because you have to confirm that every merger is working as expected and you have to wait for continuous integration to end up testing everything and When you have a 27 repositories, it takes hours at least And yeah, those 29 crates are Mostly shared between 27 repositories, but that's not all because we also have to handle Documentation in its own repository. So in those 27 repositories on just GTK RS crates, it's also tools and Very important elements required by the project. So for instance, I was talking about releases it's a tool on itself and we have to use it every six months is or something like that and The two test it is quite a nightmare for now We don't have a very good solution if one has one at some point. I'm very happy to hear about it and Since less for them. We had the two new releases the next one We talk about the next one later on So that Require a lot of automation and we really like to have more of it A job I had before was to write about to handle Merge cues and everything and I started the working on a new one to repeat the same thing But this time for GTK RS will be We have great views of it because for now it takes most of my time lightly even more when doing releases So for instance when you have a new gear updates We have to regenerate the most of the crates which takes a lot of time. So generally you end up reviewing 14 crates or something like that It's it takes a lot of time to for contributors for reviewers for Literally everyone so this pot would be able to help on that to run test to maybe add a bit of indigene intelligence into it and Check if something isn't going fine, but that's mostly me dreaming Yeah, help it to new contributors because if we have more tutorials and maybe how to where to start and everything I Hope that will bring the new contributors. We definitely need more help on this Thanks to access that we have already some help and I hope it will continue and of course much more so We'll see what to add in this bot For now, I think it's already seem to have we'll see when we have a start for it So continuous integration like I said is very bad currently not because of What we have a test not as much as I want to but we have test which is already something We have however a big issue when I was talking about a gear updates you have to regenerate every crates so you have to be sure that With the new update of a crater all of the other crates are working So for instance, if you update a gd, but you have to check a gtk isn't using your other API or have a surprise and When you updated gd, but generally what happens is that you break literally everything So you have to merge everything and then play very strongly that you didn't have a bug that you didn't spot and When everything works, you just check With examples and if examples are building then congrats. We are done on this updates Let's start a new nightmare. I guess so a Solution will be to make it more clever. So instead of having test running everywhere. We will have to center centralize everything into One server or something and at this point it will be At this point it will be a way more faster because you don't have to make everything again and It will update to have The last version of everything and you will just test once and for all and you will do a one review, but It's yeah for now. I don't know how to make it happen in a multi repository Context, it's not a lot of things are still up to debate if someone has solution very open to it So I think that question has been asked to me like at every talk I did so Now I will just skip question and answer it for you. So Things to be done. So before having a 1.0 release. I'd like to have a full inheritance support of course like It would just be a sum to be able to have something at the same level as the C++ bindings To have your own button doing a crazy thing like you click and you have a unique or not something Continue to work on performance before this the last release we didn't have much talked about it and I think it's a very important part of a GTK RS and if Preferences on hero users won't be here as well. So not very good We definitely needed to improve internals. So I was talking about the gear which was getting old Definitely we need to improve it at some point because it's an inner drug But we have gears separated in three parts something that passes the gear content then you Generate some AST and then from that you generate the code and that last part is The trick we went because when you add the conditions of our conditions Well, no one knows what's happening, but if it's generating something looking good you just hope it won't be a dark magic anymore, yeah, and of course, I think it's Currently the big the biggest pain point is that Documentation isn't great because we use directly the C documentation. We improve it a bit. I Don't know yet how to make maybe automatic conversion of this documentation directly for rest Where's it? I don't know for now, but yeah, definitely more tutorials because Some raster users don't know GNOME and some GNOME user don't know rest We can make the best out of the two. Yeah, we are getting close. We are not there yet, but Let's speak about that last year next year so next three is Well, since we have landed as a big I will call it user callbacks, but You know it's Sebastian Now we can have I think the next reason the next two weeks. We'll see if we have some last minute hidden bugs or a feature of someone that definitely wants The bearers VG wanted something on G We'll see so thanks for listening if you have any questions So the question was is there any documentation for the code generation Let's say maybe I don't know how you can No, it's on the gear repository. We have a description and I started to write a full tutorial on how to do you a step-by-step how to generate everything I didn't finish it yet. I don't have much time, but next access I think I will do that it will be in April So be a bit patient in a few months is it will be here I will make a big announcement in the reddit for that Another question