 We are ready to start. Our next speaker is called Guillaume, so please welcome him. Hi, I'm here to present you a GTK RS. It won't be a technical speaker at all, so if you have technical questions, we can speak after the talk. So GTK RS, how to make an unsafe thing. So first, what is GTK? So it's a GNOME UI library, very used in the Linux environments. So cross-platform, it works as well on the Mac and as far as I know, it works as well on Windows. So a bit of history. At first it was started by Ben-Mary LeTang in 2015. When we were both of us still at school, we started it to learn REST. So first it was called LGTK, and we have sub-creates for each GNOME library like GAO, JLIB and stuff. It was all in the same repository at the opposite of currently. So the first implementation was very simple. It was one-to-one binding. So you had a function, an object, it was the same in REST. So not much advantages, but you could use a GTK in REST. So now the cons. So yeah, it was at the time very slow to compile. We were still in 2015. It wasn't that. We had a huge macro to generate all signals. It wasn't very, very efficient. So since it was bound by hand, a lot of typo, human errors were there, casting errors. Just like I said, it was just a wrapper around C code, just one-to-one, not much safety. And at the time the compiler was getting updated and having breaking changes like every two or three days. So changing the thousands of lines at once was quite long for a library as this big. So that's, I think it was at the start of 2016. We had a new contributor. We brought the gear support. So gear is a format which is used by the GNOME libraries to describe your API and is used by other languages to generate their own binding. And that's what we did in REST with a whole new create, gear, which generates all the code. So that's the first thing we did. We also rewrote all the glib, how to explain, the glib is the base and we had to rewrite it in order to make it work to build upon it. And so we did that. We could bring a whole new trait system. So now you can say if an object inherits from another. Very helpful. It prevents from casting from a type to another. And another thing, which I think it's still a bit of a debate, but we decided to split libraries into their own repository. So now glib isn't in GTK repository anymore. It's the same organization, but not the same repository, which has its issues for every reason. That's a debate. So the new trait system is basically based on this one, is R. So now when you have a function, for example, for the widget, you take is a widget. So every object which implements this trait can be used in this function. So now, why is it better to use GTK-RS over GTK directly? For a few things. So like it's written, let's start with compiler errors type conversions. So in C, you can totally do that. It's not a problem, not much checks. In rest, you will do it by using the upcast method. The big difference being, at this point, there isn't much. It's just in rest, we have checks done at compile time. So here, if you try to make an invalid cast, it will just take fault when you run it. So it's inconvenient to discover there is an error in your code after being compiled when distributed. And in rest, if you try the same, casting a type which isn't a children of a window. For example, a button is a children of a widget, but isn't a children of a window. If you try it, you won't compile. You will get an error. So the trait isn't implemented for a GTK button. It's quite convenient. So yeah, another advantage, of course, is the code readability. So in C, very verbose. In rest, a bit less. It's the advantage of object oriented languages. Not to say you can share. So some other gains. So there are quite a lot brought by rest directly. Automatic rafting and memory management brought by the rest compiler directly. The same can send trait bonds, which are used for signals, for example. So like that, your shell, your object won't be destroyed and called while after being destroyed. Makes sense. And we enforce when we generate the API that if you want a string or a pass, which is very convenient when you have to open a file or to specify a title, to be sure you won't try to do something strange at best. Like I said above, everything related to closure. So signals, callbacks, everything. So yeah, some other gains, of course. Now you can't have arrays which have invalid size. You can't give, we don't allow to give a size of an array when you give it to a function. It's done. An array is a five pointer. So you have it's a lens provided by the type directly. So no need to give the size anymore. Very convenient and allow to have a lot less errors. And of course the strong type system, which is one of the biggest advantages of REST. You can't make a cast however you want. Just what the function needs. Now at this point, what remains to be done? Well, I think we are around 90% of bindings automatically generated. And most of the missing functionalities, functions, objects are clearly in GIO. So I'm starting to write new things in it directly. We'll see how much time it takes, hopefully a few months, I don't know yet. We started recently at the last GNOME REST hackfest to improve the asynchronous support, which is very asked by a few people, so it's coming. And of course, from now, the documentation is generated at the same time as the API. So we directly have a C documentation, not REST one. So examples are in C, a lot of things aren't perfect. We have still a lot of work to do in there. It will be the next step, I think, once we are done with the bindings. So beyond the epic IRS. So we had a few people from the GNOME community bearing interesting interest. We started a few hackfest last year about this to write the GNOME class project, for example, where the previous talker is from GNOME and, yeah, Heidi. There is Federico, a big guy in GNOME, which is rewriting a library, live RSVG in REST directly. Yeah, I think that's because of him, we started, yeah, it was for this. And of course, yeah, we have other GNOME libraries, which start to have a binding, so just trimmer from, I don't know where he is, but yeah. We have a WebKit to GTK and SourceView and a lot more. As long as it has a gear file, basically, you can generate it automatically. I don't know how it goes for this trimmer. I think it's mostly wrote by hand. So now we have achieved a good level, I think, at this point. We don't miss much. We are on little details now, having deprecation, having more dogs, having a better interface, better roles. And at this point, how could we do to make it even better? And REM has been created for that. It's another abstraction level, so I will let its creators speak for it. So I'll give you some mic. So, as GNOME said, REM is an abstraction of our GTK RS, which provides a more idiomatic way to create desktop applications in REST, and it is based on GTK RS, and it also provides some support for asynchronous programming. So first I'll cover some pen points I had when working with GTK RS by developing a web browser. So the first problem I had is when you want to associate some data with a widget, let's say the model of your application. When you want to do that with GTK RS, because of the safety we had in REST, we need to use an RC RAF solve, so we have a RAF content value that we want to check the borough at runtime. So we need to use this borough plate code with borough mat and borough when we want to update the model in a signal, which is something we want to do somewhat frequently in GUI applications. So that's not very ergonomic. It's error prone because we only get the error at runtime instead of at compile time. So one thing I wanted to tell you is that if you can avoid using RAF solve, it's a good thing to avoid. And what I do in REST is that I use RAF solve, but I'm just not telling you. So also you can do asynchronous programming with JLIB and stuff, but it's not very ergonomic. And I wanted to integrate realm with the asynchronous IO library in REST, which is Tokyo. And also since REST does not provide inheritance, you cannot do, for instance, like in VALA, declare a new class deriving from an existing widget to be able to use this new widget like any other widgets. So that's not possible in REST. So I wanted to, with Realm, be able to declare new widgets that could be used the same way as the GTK widgets. So Realm is inspired by a language that is called M that is used for developing client-side applications. So M is an alternative to JavaScript. I found out it provides a good way to do model view controller. So that's my main inspiration for Realm. So in Realm you will declare a model, which is the data that you associate with a view, and you have an update function that would take the model in response to some event and return the new model. And you also have a view function that describes your view in a declarative way. In Realm, I use that, but I adapt it to REST. So, for instance, update and view are no matter of a widget and we use mutation when it's convenient. For instance, the update method will take some reference so that we can mutate the model instead of having to return a new model. So let's see how we can use Realm. First we need to declare a model, which is a normal type in REST, so it could be a struct. And then we use this widget attribute and an ample of widgets, which is the trait we want to implement. And for a window in this case, which will create a window. So we need, first, the model method, which declared the initial model of your widget. And then we have messages that are used to communicate, for instance, between widgets or having a message when there's a GTK event and it can also be used when there's a QNAS IO. So, for instance, you do a network request and when it's done, you receive a message. So we use the derived, well, the custom derived message and we have an enum, which has many variants that can have a value. And then we have the view. So it's still in the ample widget and we use the view macro and we now have the declarative syntax. So we can create GTK widgets and nest them and also set their properties. We can connect the click event, for instance, we will send the increment message in this case and we can also do bindings, meaning that at the last line we have the text property of the label that is bound to an attribute of the model. So that means that whenever this attribute of the model is changed, that will update the view. And then we have this update method. So it takes solved by mutable reference, which has access to the model and we can modify when we receive a message. So in this case, when we receive the decrement message we just change the counter attribute of the model and that will actually update the view even though it's not shown here. So how does all of that work? So the widget attribute will start by collecting the data binding. So it will analyze the view, check that in this case the label has a property that is called text that is bound to the counter attribute of the model. And then it will actually change the code you wrote in the update method to actually update the view. So it will see here that the counter attribute was changed and it will use this value to update the view because it noticed that there was a binding in the view. So even though I use attributes, RAM can work on stable routes because I use a hack to have the procedure on macro to work. And the future of RAM may be without features. Also I will work to improve the error messages because at the time I first started RAM it was using the old sync crate. So we didn't have access to the position of the token so that's why when you have an error message it's shown on the widget attribute which is not convenient and I will support more GDK feeders. So do you have any questions? Yes? Sorry. So the question is... I'll take this one. So the question is how does Rust check the length of arrays at compile time? It's basically an array in Rust is a slice. So in the type you have the pointer where it starts and you have its length in the same point. It's what we call a fight pointer. So when we give it to a function when we generate the code we just know the size of the slice. You can't cheat. When you create a slice you know its size. But it's constant. So when you pass it to a function obviously you know its size and we can give it to the GDK function. Other question? Yes? So the question is do I enter in JIO to use Tokyo for... I think that's it? To use futures. So I don't really know for instance with Anthony we talk a lot about how to do asynchronous stuff. And I think he will be the best one so this one actually. Yes, so in the Hackfest we had I implemented the code generator the stuff to generate the asynchronous method and for now it's just working with callbacks. So for now there's no support for futures but that may be added in the future. No pun intended. The question is for the gear generator for now. He asked if we intended to make it simpler because I didn't talk about that so I will go into details a bit. The gear generator first generates a low level API which isn't supposed to be used directly by the users and then from this it just writes the functions and all the types from the libraries and from this you can... we have another level which is used directly and it provides the API which calls the functions bound by the low level. That's clear. So at this point it's a bit complicated if you don't know how gear works even if you know it's a bit... So we interned in the few more weeks to make something better but it's more like when we have someone new starting a new library using GEAR we take what it says is missing so that's why we wrote this huge readme file and then we add new elements and maybe someday I will write a guide or something in order to avoid... to just allow more people to have their own libraries if they want.