Hello everyone, and welcome to another conformity two talk. I'm very excited to be presenting to you today and thanks so much for joining me as I try to tell you how how go taught me to love building applications again. But first, a little bit of background about myself. My name is Andrew Williams. I'm a software engineer author. I've been leader of various technical teams, and I've been working in open source for the last 20 years. It's possible that I bumped into you at earlier projects. I've been a core developer in the maven and enlightenment projects, including the foundation libraries, which taught me a lot about widget toolkits and how you can build applications that are efficient. I founded the fine project when I started being a Go developer early in 2018, and I'm now also the CEO at Finelabs, where we build products and services that help businesses and individuals to get more out of their applications built with the fine toolkit. When I'm not developing or hanging out in open source support channels, I do quite enjoy a bit of Sci-Fi going to some music concerts like the Zelda one you see there pictured, or riding around my garden on a train. Three very different interests. I wanted to be able to express this in one. So I thought about asking chatgpt or an OpenAI client if they could come together in some way. And then I realized it's not really necessary because Disney World is actually all of those things together, the happiest place on earth. Now that might be quite a peculiar segue for something that is about a go programming talk, but there is a connection. I promise if you've been to one of those attractions, you'll know that one of the key things about it is all of the crew in the park come together as a really great community to give you a fantastic experience. And I think that has been a huge part of my experience with the Go programming language is the people around it and the support that's available for anything that you're trying to do. It's helped shape this project and hopefully we can give a little bit back through the fine toolkit and talks like this. But before we dive into the details, let me do a small background on graphical application development. The picture that you can see there is something very early days back in the 1970s. It's a system called Star, built on the alto from Xerox ParC. Things have obviously come a long way from there, and yet at the same times, kind of they haven't. So this was a little bit before the C programming language, but only slightly. In fact, most graphical systems that you see now have a fairly substantial C heritage in them, which means you're going to have to deal with memory management and thread handling. And also these platforms were built before Webb was really popular, and so it wasn't really baked in. In fact, when you look at it, if you were to be coding in C like some of the toolkits are based, they didn't even have a good understanding of strings, never mind what Unicode and multibyte runes were going to be. So we've got a lot of things that are kind of missing because of where they came from. There are modern alternatives that we can work with. In fact, there's lots of options available in Go and Rust and JavaScript, but a lot of these are bindings over old technologies, which means that you don't have the same learning experience you don't have, I suppose the idiomatic way that this all comes together to feel completely obvious to code with. I think that's one of the main reasons that it seems to be quite complex to learn application development. Even some of the best in class platforms, like those from Apple and Google, are based on a lot of heritage. That means that you have to know things, or it makes assumptions about your experience, which is really not ideal at all. And because they bring a lot of legacy with them, they could be really, really large to get started with. I saw a hello world example with a toolkit that I won't name that required you download 10gb of data, and it took up 40gb on your disk before you could even write your first line of code. So really, there's a lot that could be done better here. And like I said, there are modern alternatives available, but they are typically platform specific. Companies putting effort into this space want you to build applications for their platform, not for everybody's platform at the same time. And so this sets the scene for an opportunity that any language or project could come along and fulfill. And I have found that go does a really good job at filling the gap there. Why? Well, to start with, as you all know, you get to write your program once and then it can compile to run on any device. Applications are going to just work. The single binary distributions that we create have no runtime dependencies and, and aren't going to require any setup for your end users. We're getting native performance on all platforms at no extra cost. The compiler is just doing that for us. So the applications are going to run as though they were hand coded for every single system we get. The joy of working with a modern programming language with all the benefits that come with that. The techniques have improved over the years, and having certain modern standards means we can spend less time worrying about how we write the code, how we pull it together, and more time spent actually building the things that we are looking to create. And all of this, I think, means that go is providing a great way to lower the barrier of entry to building graphical applications, just like it does command line applications. And so we have a new hope for app developers. And this is where the fine project stepped in. We saw that opportunity and we thought, there's got to be a way to make a toolkit that's just as simple to, to build graph collapse as that which we have for command line apps. Now, I've got a few photos in here. I think they're all of gophers. This one certainly is. As you'll know, some of the others might not be. I'm not so great on understanding the different types of nature, but hopefully they can provide a pleasant interlude through the various sections of this talk. So I've told why it might be good to have this opportunity to build again. But why would we start a new open source native app toolkit when there are so many others out there? Well, for all the reasons before, it's great to have a fresh start and build on the technologies that are now available. We wanted to have something that was easy to understand and simple to contribute to. And that's only possible if you have a completely open ecosystem, all of the libraries and the supports as well, to create platform independent native apps like Go and a couple of other languages are uniquely connected, capable of doing, and at the same time to deliver natively onto all of these platforms that are taking lightweight applications and running with really good performance and looping right back to the beginning of my introduction there to be community driven, to make the most of this fantastic group that we have around us to give back, but also to develop our platform along with the people that are using it and feeding back their experiences along the way. And that is the find toolkit. We aim to deliver the simplest way for developing beautiful and user friendly native graphical applications for desktop, mobile and beyond, such as the web and embedded devices and other things that you might see a fine app running on. The project, like I said, has been going for around six years now, which does seem like a very long time, but there's a huge amount of work here. And with this little graph of GitHub stars you can see that this is a project that has grown faster than any other like it, and continues to grow month on month. Hopefully some folk here haven't heard of it and are excited about the opportunities, so maybe you'll all go away. Give us a little star and try out your first project after finishing the video today. And a fine application is going to work on all desktop and laptop computers as you'd expect. All of the targets on of go executable I suppose. But of course we've got mobile device support baked in there as well, so your applications can compile to native iOS and Android devices, and we're delivering over the web as well. The support there is not quite 100% complete, but it's very close. The next release will take it there, which will enable your applications to run through the browser if the user doesn't have a device available to install the software onto. And like I said, embedded devices are a possibility there as well. It takes a little bit more code because it doesn't have the traditional user interactions, but it is possible. And we've seen devices running with tiny little screens in industrial settings or kiosks and things like that built off Raspberry PI devices as well. And so our first hopefully gopher in the wild there says let's build our first app, we'll get it done in just a couple of minutes. If you haven't built a go app before of any kind, you're first going to need to install a go compiler. We're working with at least version 1.17, but of course everybody should be using one more recent than that to get your security updates. Because we're working with low level graphics and building native applications, it's going to be necessary to install a c compiler as well, I'm afraid. Now, if you're a Linux user, there's a good chance it's there already. If you're on Mac and you have been doing any application development, you'll already have Xcode installed as well. Windows users will probably need to go through a little setup for msys two and Mingwoo. There's more information on our website if you're having a little bit of trouble getting set up, and if you're going to be developing with Android, you'll need the libraries downloaded. But onto any type of computer, it should be possible to run off just about anything. IOS because of Apple's licensing requires that you're running on an Apple Mac computer. But of course when it comes to coding your app, that's not necessary. That's really just when it comes to the build time so you can get the application binary prepared for iOS devices. Hopefully that all makes sense. Like I said, there's more information on the find IO website if you need to check that out in more detail. But let's go and start setting up our new project. Because we're using modules like all good go programs do, we'll create a new project directory and then initialize the module in that space, and then to install the fine code off the web, we'll just go get fine IO fine V two at latest. That's going to download the latest released version of fine, and that's of the V two major version. As you'll have noticed with some projects go quite rightly changes the import path if you have a major breaking API change, which we did a number of years ago, we're trying to keep everything now within the V two namespace, but that import path is pretty straightforward to understand. And next we're going to write some code. I'm going to possibly use Vim here. Actually, I'm just going to show you the code on screen and avoid the live code. Other text editors are available, of course, and you might well choose to use a more substantial development environment to edit your go. But here is our first fine application. It's pretty straightforward. We have our main package because it's an executable. We're going to import two sub packages of the Find project app and the widget packages, and do make sure it has v two in the import path there. It's possible that some systems can auto import the wrong version. We'll open our main function and call app new. This is what initializes the application in memory. It configures everything for the computer that it's going to be running on and gets all of the internal state prepared to run a full application. We'll create a window for that app using new window and the string that we pass it there. Hello is going to be used in the title bar if our system has title bars, typical, I suppose, on a desktop computer, but less so on mobile. The content of our application is just basically there inside the setcontent call, as you might not get any prizes for guessing. That's going to set the content of our window and we're passing in a new label widget. All widgets in fine are created with a simple constructor from the widget package. And so here we'll be creating a label and we're passing the string hello fine to display in the content area. Lastly, we call, show and run on the window, which is a shortcut for showing the window and running the application. You can have multiple windows, you could show them and hide them separately. We just need to make sure that our application has a call to run at some point, usually at the end of the main method, because that's going to keep running until your application quits. Okay, so we have written our code. What do we do next? Well, we want to run it, but we have just made some new imports. So for good practice we'll call go mod Tidy in case there's any downloads necessary. And then we're just going to go run and that is going to load the window that you see on screen. If it was bigger, you would see hello written in the title bar, but you can certainly make out hello fine in the content area. So there you go. That's the first application written, but we should probably do something a little bit more substantial because hello fine isn't really going to excite you enough, I suppose, to feel that this talk was worth looking at. Instead, let's look at a markdown editor, something that we could actually use in our day to day activities. So I'm going to arrange this as you see on screen, with an adaptive grid that has an entry for the input and a rich text widget for the rendering. Now, adaptive grid might be a new term to you. We use the word adaptive to mean that it will orient according to the output display. So in this case a normal window will position left and right the items inside it. And if you were running in a landscape screen on a device, it would do the same. But a user rotating, perhaps their phone or tablet, would arrange the content appropriately. And to make the application work I'm going to put together a connection from the entries unchanged event to the pars markdown function called in the rich text, so that each time there's a textual change we then update the output to render it. Hopefully that makes sense. Let's just look at a little bit of code again. It's not a massive application. We start out the same with an extra import here for the container package, which is where these containers that I mentioned are all stored. We will start our main function in the same way by opening an app and then creating a window. And this time it's the content of the application that is a little more complex. We'll create a new widget called Edit, and that is a multi line entry. It has nothing stored in it right now and it is set to be multi line so that we can write lots of lines of content. Our second widget there, which is called preview, is our new rich text widget. Here I'm using a demonstration that markdown can be passed into the constructor. So new rich text from Markdown. You could have any markdown document passed in there, but we have an empty one to match the content of our entry widget. And then the next line is the thing that makes the connection every time the entry is changed. We want the preview to parse the new markdown. And this works because unchanged is a function that takes a single string parameter passing the new content, and parsmarkdown receives a single string parameter which is expected to be the markdown content which you're to parse. Then we set the content of our window to be that new container that I mentioned. It's an adaptive grid, and we say that it should have two rows or columns depending on the way around that it is, and they are the edit and the preview widgets. So then just again we show and run that content. Hopefully this time it will look a little bit more impressive. There we go. So as you can see, we have our entry where we're entering markdown on the left, and on the right hand side we have our rendered markdown. It includes various types of typeface, some a divider link, and an image as well, which are all just part of the rich text widget and the markdown parser built into. Fine, I could leave that there. It's a pretty cool application and something that you might choose to use or build on yourself. But before we move on, let me show you that the same code, exactly the same code, can be used to build a mobile application instead. And this is in fact that same application running in the iPhone simulator, it's gone into light mode because that's the default for iOS. Whereas before I was on my desktop where I prefer a dark mode setup, and here we have very similar content on the left, and it's been rendered on the right hand side, as you would expect. But as I promised before, we can rotate the device and have that adaptive grid change the orientation. So if we were actually utilizing a portrait mode, we would still be able to interact with the application rather than having it squeezed up with a central divider. Excellent. So that is our application running, but there's a lot more of course to building an application than simply writing some code and running it. So let's move on there to testing and distribution. The first thing I wanted to touch on is unit testing, which has typically been quite difficult with a graphical application. But this is going to be really a lot easier. I mean go has unit test support baked right in. You can see here the steps we're going to run. We'll edit some code and then we'll just run the test runner and see the output. So let's have a quick look at the unit test here. The imports are slightly different and we're happy to be running in a test package. Seems like best practice there as well. I'm using the assert package which I find to be very helpful with my test assertions. And I'm also importing a test package from fine. So let's see why this is useful. We open a new test function and for this I'm going to test the selected text of an entry. So I'm creating a new entry widget and then I'm going to simulate the user typing some content into this entry using our test package. So we call type and say that the hello string should be typed into the entry. And then we check that the text content is in fact hello. This test is going to pass. Then we could use another function of the test package called double tap. And that as you might guess is going to simulate the user having tap twice in the content quickly, which should select the word underneath where the tap event happened. And here it is, the general area. We don't specify the coordinates specifically because that is the full content that the selected text is equal to. Hello. And also we can check that the cursor column has moved to the end so we can run that like a regular unit test. And it's not going to pop up windows on screen, it's not going to grab our keyboard focus. The test runner is able to completely execute a fine application in memory without requiring those input and output devices. So they run really fast as well. But let's move on to packaging your application. There's a really helpful command line tool also called fine. You can get it by calling Go install, you pass it this URL fine IO fine v two CMD fine at latest. It's always a good idea to have this tool at the same version of the library that you're installing and that is going to help us with our local packaging of a graphical app. I mentioned that we build single binaries like Anygo, but graphical apps on some platforms expect more metadata or bundling to be present. So instead of just go build we can now call find package and that is going to create just the right type of artifact for our platform. So if I was running that on my Mac, it would create a app bundle which I could then drag into the applications folder. If it was windows it would be a exe as you'd expect, but with the icon and other metadata embedded. Now as a developer, often what I want to do is compile the app that I've been building on and just use it locally. So we have a tool for that as well. It's just fine install. If you do that and then go to your application launcher like I've done here, you can search for your application and it will be registered and installed. But like normal on the Mac, it's simply in the applications directory. For your Windows computer. It would be in the start menu and somewhere in the program files. That's great. I've got it on my local computer, but I want to do more. I want to get this out to other people. So we also have as go would have you expect, the ability to cross compile to other systems. So here I could build my Windows executable from whatever platform I'm currently running on. Or as I showed earlier, we could have a mobile app built in the same way with the OS specified as Android or iOS. There's a little bit more data needing to be passed in here because the sandboxes on mobile platforms require to have some unique identifiers called the app id. So we pass one of those in and you can see a screenshot here how your iOS group could look like if you installed a few fine applications using those tools. Now I mentioned earlier, you do need some c compiler installation for this to work. And the cross compiling is no different. It can be a little bit complicated to manage. And if you would prefer not to, or if you're having any trouble, then you should check out the find cross tool that's going to manage all of this for you. In containers that are going to bundle the developer tools, it will launch the container, do the compile, close the instance down and provide you with output files. And so here you can see the different files that you might have available. For our project, we created main go already. We had the go mod file and I dropped an icon Png in there to be used for the application metadata. And on the second row of icons there you can see I have my Android app, the APK, the macOS app, and the Windows app, which is a Exe, and I could share those with anybody I wanted to across the network, uploading to the Internet, or just downloading it onto their phones when they come around for dinner. So we've packaged our applications, but how do we get them further afield? Well, the find app is also going to be able to help you with that. We have a release sub command which is aiming to help you get your applications up to the stores and marketplaces. So here a quick example. I'm releasing my app with a specific app id. I think this command would typically be used on Linux where there's not a standard store. So it's going to bundle up the artifacts ready to be distributed in whichever manner for iOS there is of course a standard store. In fact, most geographies, it's the only store. And you would upload that by having an Apple account and getting a profile and a certificate distributed to you signed by them. You'll download that locally and then using this release command, you can build the app bundle with the appropriate signing and it will actually create a slightly different type of, of file output. And you will then install that to the, upload that to the store by dragging it into Apple's transporter app. It's similar. Again, we want to release for the Android OS. We're going to tell it the key store that's available, which is a Java key store which you can either set up yourself or download from Google's Play Store, I think. And once you've signed that, then you'll be able to just upload your new aPk by dragging it into the browser window when you're configuring the app to be distributed through their website. Now, there's a lot of parameters here that I have discussed. It can get confusing. So we added a new file called Findapp Toml, which is a simple text markup. And as you can see here, we have got various standard parameters that allow you to write them once save it into your source control so you don't have to remember what all of those parameters are. And we'll also auto increment some of those numbers when the release process is executing. Whoa. Okay. So hopefully that has helped to show how you can get the tools installed, write some code, and create an application all the way out to the store. But of course we didn't see too much of the app toolkit itself. So let's explore that a little bit further. So there is a find demo application that you can run and that shows the various things available. And we'll start here with graphical capabilities. You can draw, as you would expect, lines, rectangles and rounded rectangles, circles. We also have text, of course, different types of gradients and also images. We have both vector images and raster images. And all of those graphical elements are what are pulled together to make everything that you see on screen, and also they are optimized to make the most of your graphics card. So we use OpenGL and various hardware acceleration capabilities to make sure it's always super fast. Also, if you tap down to the theme icons, you'll see that we have them bundled into the applications so you can have standard icon capabilities in your app that people will recognize, so you don't have to worry about that. And also we have the light and dark theme that you've seen both of already, the toolkit. So your application is going to blend in with the desktop or the mobile that it is running on. So also of course, as you might expect from a widget toolkit, there's lots of widgets available. I've grouped this into basic widgets like the label which you have seen. We have buttons that can have an icon as well as text progress bars. There's a card for grouping items together, and also the rich text that you have seen which supports markdown as well. And there are a few other things like a toolbar, text grid and accordion item separators. All sorts of things there that help to display information to your user or arrange or group items on your screen. Then we have input the types of things that you might want for building forms or getting data from your users. A password entry where you can hide and show the content, sliders for inputting a range of values, a checkbox, radio item. They both come in group forms as well, and a select like a dropdown. There's also an editable select. We can have an entire form as well. And that means it's possible to get all sorts of different kinds of data input into your application, again using just standard widgets. And these could pack into a form as well in whatever combination you're looking for. Those are all quite straightforward. You know, one line shows you one item on screen pretty much, but then you add a little desire to show lots of data, something where you need to scroll very fast through lots of things like your tweets or your email inbox. So we added the type of widget called collection. Now, there's actually a few of them, but here I'm illustrating with list. We're using a few callbacks that mean that we as the toolkit can take minimal data and display only what is necessary on screen at any point in time. So it's very quick and you can scroll through hundreds of thousands of items with no slowdown in your application. For the list with these three items, the first function is asking how many items are there so we know how long to make the scroll bar. The second callback which is here creating a new label is creating the template object and this is what's going to be reused each time a new item needs to be displayed on screen. The last callback is called the update callback and that says for a certain item id and a reusable object, make sure that the right data is displayed and so we will call the last one quite a lot. As you scroll through creation, the template object creation doesn't get called much because that's a lot slower. So with this way we can support really fast user interface with lots of data. And like I said, there's a few of them. So you could see we also have table and tree and also the grid wrap. Thinking of things like file browser where you've got lots and lots of files but not necessarily lists but displaying them as icons in sort of square areas instead. Lastly, if you want to put more complex applications together, you're probably going to look for various types of containers that help to move items or position them in screen with potentially some interaction. Here we have the horizontal split in code, but there's a vertical split as well and that allows your user to move the space allocation around the user interface. We have app tabs which allows you to have different areas of the application separated behind tabs, and also a version of that called doc tabs, more suitable for managing documentation, different documents and you can add them and close tabs away when you're done with those documents. Also you could have a scroll around just about any content if you want to have your window be smaller than the content that is currently visible. What I've showed you so far, the content was basically keeping the user interface open. The default window size is so that all of the items can be visible at the same time. And so scroll can help us to shrink that down a little bit. But a container can have any layout that you want. You can just say container new and pass it a layout and then the objects that it should be responsible for. And that layout could be anything. You can implement the layer interface which simply says how big should something be at its minimum and what do you do to lay things out internally? But the last two illustrations there, the darker colored one there is the border, but the second is lots of different layouts in different containers brought together. So you can see how it's possible to build up a complex application with the basic functionality that I've already showed you. There are various other common activities in a graphical application that you might be familiar with the dialogues, things that we might want to be displaying to our users on a fairly like a confirmation dialogue. Are you confirming this next step? We could have our input, we could display information, or we could have the need for a color to be chosen. All pretty standard ways that we might ask users for information. And these are all provided through the dialogues package in find. Lastly, there is also the file dialog. You can open files and save files. This is where things get a little bit more complex because a file is actually not such a concrete thing as you might imagine. Like a color. We can pick a color, but when we're looking for file input, it may not be a specific file on the system that we're looking for. So working with files in a platform agnostic way is a little more complex. So I wanted to show you this illustration about how we can open a file with the dialogue package we'll call show file open and in a similar way to the collection widgets, we use callbacks here instead of a standard constructor. Our callback is going to be executed when the user has made their choice, and so we have some checks to make in our code here. Firstly, we ask if there was an error. Did something go wrong when they were picking their file? If so, we'll show an error. Also, it's possible they pick nothing, in which case the reader to the file would be nil. So we will return then as well. The rest of this is handling what we should do with the file that we were passed. Now you'll notice the parameter is a URI read closer. It's not a file at all. It's like a reader, in fact. So we will use ioutil or the replacement in the IO package to read all of the content into our variable data. If there was no error, then we will make sure that the file is closed when we're done, or rather the stream of data. We will set the text of our entry widget for this illustration to the content of the data. So we've essentially opened a text file and dumped it to screen as this is a URI read closer. We have an additional function on top of the standard readcloser functionality, the ability to get its URI, that is the universal resource identifier, I think. So by doing that we can find out where this data came from. It might be a file path like you have seen in, I suppose, file based access in a web browser. If you've built your web server, you'll be familiar with it. It could be a remote source on an HTTP server. So you might look at that and find it's a URL inside it, or it could be something completely different based on the data provider that's available on the current system. Of course if something went wrong, we'll show an error again, and that is all passed into the show file open. And we also tell it which window to display the dialog in, because in fine, minimizing the number of windows open is desirable. And so we display dialogues inside a window rather than separate to them. So I showed you before that it can create a file open dialogue like that, relatively familiar, and we're looking at files, but we won't always be looking at files. And this is why it's important to not assume that there is a file there. Here I've just opened the same code on an iOS app, a fine based iOS app, and it has allowed me to pick files based on what's available on the current system. You might notice that this is a standard picker from iOS and it's allowing me to access data from the web through iCloud. Equally, I could use that for importing data from other applications like Dropbox or my gallery app, and in those situations it's actually going to be streaming data directly from one app to another. And so there was no file there at all, which is why this is so much more flexible. And you should consider taking this pattern if you're working with files in your application. Goodness, this has been a bit of a fly through. Apologies for there's just so much to cover, but there are so many things I didn't manage to show you. You can have a main menu in your window, you could have a system tray if you're running on a desktop based runtime and that code is still the same code running in your application, you just do a runtime check to see that it is. In fact, you can use data binding as well. This is a slightly more advanced topic, but it means that you can have your data source separate from your user interface code, and you will be able to wire those together with our data binding package that uses events and a two way data binding model so they can stay in sync without having to depend on one another. And as you saw earlier, there is the find demo app that covers a huge amount of the things that you can see, and probably all of the functionality is demonstrated in there at some place, but that's the standard toolkit. We also have a great community out there that are contributing their own work as well. The ability, because of Go's packaging system to just import an external source and call the constructor it makes available and we'll have a widget in our UI. It's going to work just like any other widget. So here I've just used the Find X package, which is the community contributions to the find project, to create a new map widget. And then I display that in my window and I have a map. Similarly, there's a terminal. You can drop a full blown terminal into any find based application by using the terminal package, which is one of the fine repositories. And it's just there another widget in your application. So many possibilities here, it's just impossible to cover them all. Hopefully. This looks like a joyous thing that I was demonstrating. It's just so easy to get started. In fact, hundreds, in fact hundreds of thousands of people have given this a go and built applications of their own. There's a number of open source projects that you can absolutely check out. If you go to apps find IO, you can find some of these fantastic applications out there. Terminals, games, music players, chat apps, notes, all sorts of things. If you're wondering where to get started or how you might build something, it's a great place to look because all of these applications are open source and well coded to describe how the application is put together. At Finelabs we are working on an app builder, so you don't even have to do the coding. You can drop into a project and visually put your application together. You can find out more and sign up to be a tester at fission app if that is interesting to you. But of course it doesn't have to stop at a single application. You could, if you wanted, go bigger. And in fact the community has done just that. There is a desktop environment called Find Desk that is part of the Phishos distribution, which is a Linux based operating system where all of the applications are fine applications. You can see a whole load of them on screen there, like the chess game, text edit calculator. And in fact an application for managing your applications, all written using the technology that you've seen in this presentation. And of course we have a lovely login manager as well to complete the look. Indeed, you can see we're running on that system now with virtual desktops and a little terminal at the top. There's all sorts of things that you could do with this, including an integration with that application editor that I mentioned earlier. There we can see the calculator app for example. Hopefully that has inspired you to check it out, have a go and build something that you can imagine but haven't figured out how to code. If you'd like to learn more, then just feel free to jump right in. We've got a load of documentation at docs find IO or if you prefer video. We've got a find IO YouTube channel with plenty of tutorials and demonstrations. If you prefer to read books, then you can check out building cross platform GUI applications with fine. That's published by Pact and available on Amazon and in Barnes and Noble and good booksellers everywhere. I'd really appreciate it if you would leave a review of the book if you enjoy it. Of course, this project would not be possible without the contributions of everybody who's been involved over the years. We have a fantastic team, but of course we're always grateful to welcome new people in. Whether you're interested in coding, testing, writing, documentation, or helping us with the design, the sites, anything that you see, it's all open source. You can get started wherever you'd like and it's hosted at our GitHub organization, starting with of course, the main library, which is in the fine repository. It would be lovely if you wanted to support our work through sponsorship. Do check out the URL. We've got so many amazing sponsors that have contributed over the years, but it's not just monetary. If you can help us in any way, do reach out and just help to be part of the future of this project. Thank you so much everyone. I hope that you've enjoyed this talk, and I also hope that you enjoy the rest of Comp 42. Have a fantastic day and hopefully I'll see you at another event sometime.