go podcast()

Dominic: 00:01

Hello there. I'm Dominic Sompierre and you're listening to Go Podcast. Today I'm joined by Andy Williams and we are talking about, guess what, the Find Toolkit. Before we dive into the interview, I'd like to remind everyone that, there's a channel on the Gopher's Slack. So if you are in there, it's Go Podcast in one word.

Dominic: 00:30

So Go Podcast. So, I mean, if you want to join, we are, we are there. So today we will talk about, fine, this is a great project. I mean, this is one of those things that makes you think, you know, wow, we can do that in Go, this is crazy. You know, compared to, let's say, you know, Kubernetes and those kind of things where it was meant to be used with Go in a sense.

Dominic: 00:58

So I mean, building a UI toolkit for many desktop and mobile targets is kind of impressive. So on that, leave you with my interview with Andy. Hey, gophers. So I'm receiving Andy Williams today. Thank you very much for being here, Andy.

Andy: 01:20

Oh, not at all, Dominic. Thank you so much. It's really a pleasure to be able to speak on your podcast. Hello, everyone.

Dominic: 01:25

So I I assume that most, you know, every gopher has probably heard your name at some point. The the project fine is extremely popular. So I mean, could you could you describe yourself a little bit? I'd I'd like to know a little bit more on your background before we jump in into into the project itself. So, you know, what about you?

Andy: 01:46

Yeah. Okay. I'll I'll do my very best. So I am based in the UK. I travel travel around a fair bit.

Andy: 01:53

Lived in different places up and down the country between England and Scotland. I, had a pretty standard traditional education. Went to university to study computer science. And I think by the time I got there, I'd already been programming fairly, in-depth for a couple of years. I got into Linux and open source way before they were popular.

Andy: 02:17

And just had a bit of ambition, I suppose, to to push the boundaries and try and build something new. I graduated, here in Edinburgh and have been either a coder or a technical founder of various different businesses. Since then, I've been in startups mostly. I think about 10 different companies. Sometimes I find the company myself.

Andy: 02:41

Other times join other people and help them out along the way. So I've had a a lot of varied projects that I've been working on and Yeah. Enjoyed every step of it actually.

Dominic: 02:50

Interesting. So would would you say that most of those startups were web based or they or they were like desktop desktop application or what what were they?

Andy: 03:01

Lots of different things. You're right. Web is probably predominant. Most of the software has been delivered through a browser. However, the first one I worked on was actually developer tools, back when I was working in Java.

Andy: 03:15

But we were doing community support. We were doing training and building tools to support the Maven ecosystem if that means anything to anybody. And then, one of the others that stands out, was, yeah. A friend of mine from from university asked me to to join his mobile company and we actually got off just before the smartphone revolution kicked off. We we rode that wave for about 6 or 7 years and grew Scotland's largest mobile apps agency.

Andy: 03:47

So very little of what we did there was delivered through the web. And in fact, the cutting edge of mobile was, and I think still is actually, quite an exciting place to be as well.

Dominic: 03:56

That's interesting. Wow. Okay. Yeah. Yeah.

Dominic: 03:59

And what what brought you to Go actually? So let's let's let's I imagine that before you start find, you dabbled a little bit in Go.

Andy: 04:11

I don't know if I should confess here or if I should just like be really excited about the fact that I didn't know any Go before I started fine. I I knew that I wanted to create a project that made it easy for anybody to build applications that look good that looked good out of the box but were also really just easy to learn and develop with. And it was part of the process of imagining how that could come together that I found Go. So I sometimes joke when I'm doing presentations that I have been programming in Go for 2 weeks less than the age of the fine project.

Dominic: 04:49

Nice. That that is so surprising. So, yeah. So I I think there's a couple of things to unpack from this. So what happened at that time?

Dominic: 05:00

Why were you looking at building, I would imagine, a UI kit for the desktop? Maybe not a UI kit, but let's call that a UI library to build desktop application at that time.

Andy: 05:14

So I had been sort of playing in this area for a while. A few years before this, I was part of the enlightenment project as well where we were building UI on a desktop for for Linux. That was very heavily c based. One of the best looking desktops I think I've ever used. No.

Andy: 05:33

I was not a graphical guy there like Rasterman. He was he was the lead on that project and did most of the amazing looking stuff. But I coded it up. Learned a lot of things. But c was a a difficult language to love, honestly.

Andy: 05:46

Very powerful but had its problems. And I had gone through a couple of companies, notably the the mobile side of things. Learned what good UX can look like and the difference it makes to customers. And I had, left that company and probably gone through 1 or 2 others as well. And I just realized how difficult it was to make good looking software on all different platforms.

Andy: 06:10

And somehow the fragmentation of, different platforms seemed to be getting worse not better. Like, the more powerful platform companies became, the harder it was to be able to deliver across multiple types of devices. So I just thought, okay. We we should we should make this better and, desktop was the best place to start because it didn't have many of these, you know, multimillions going into developing a platform. I think possibly Windows was was strong.

Andy: 06:41

Mac OS was, I don't know, waning I suppose under the dominance of iOS at that time.

Dominic: 06:46

Mhmm.

Andy: 06:46

So desktop was just yeah. It was an easy place to come in and and show how how how quickly you could get up and running and build something that looked good.

Dominic: 06:55

Interesting. So this, enlightenment, what was that for the elementary OS Linux distribution if I'm not mistaken?

Andy: 07:03

No. I don't think, I don't think there's an overlap there. The names are similar, but enlightenment goes back further. I think it started about 97 something like that. I got into it, around 2,002 when it hit version 0.16 and I worked with them on that through to version 0.17 which would you believe took 13 years to go from 1 version 2 to another.

Andy: 07:31

They did tremendous work to basically rebuild the entire graphical stack and all the multimedia stuff that could be built on top of Linux. And it sat for a for that a lot of that time alongside gnome and kde as the desktops of dominance. And Elementary OS I believe was a new UI built on top of the GTK stack but I could be wrong about that. I love what Elementary has done with their APIs and their their usability. It's a a really great project as well.

Andy: 08:03

It's not one I know very well But it's yeah. Very separate to different different approach to the enlightenment.

Dominic: 08:09

Alright. Yeah. I'm I'm not super knowledgeable of of those things. I I was I was using I three when I was using Arch before I had to switch to full time screen reader mode. But

Andy: 08:19

yeah. Yeah.

Dominic: 08:20

So so let's return a little bit. So so I'm curious. So so you were saying that you were seeing some problem in the ecosystem out there that it was, you know, potentially difficult to create a an application for the desktop and maybe targeting the mobile as well. That is that is looking good. Am I mistaking by saying that?

Dominic: 08:41

No.

Andy: 08:41

You're you're absolutely right. Yeah. It it was see, it started because there was not a lot out there. And then, we picked Go, got started. Actually, the the very first version was built on top of the graphical stack that was part of the enlightenment libraries because I I kinda came from there almost directly to brought some of the technology as a an enabler.

Andy: 09:05

But then maybe a year later, I think we we replaced that with a direct to the GPU implementation instead, which of course is much faster. And then I found the good work that a bunch of gophers had been doing in the go mobile project. We tried to to put a bit of work into moving that forward kind of catching up with the ever evolving mobile landscape. But because it was tied to the, what would you say? The life cycle of development of the the main go libraries.

Andy: 09:35

It wasn't moving fast enough for for a young project essentially to kinda bloom. And so we forked that project, integrated it into the tooling, and almost all of a sudden, your applications could could then run on mobile as well. And over time, we're just trying to make sure that all of the platforms we support are fully supported. So any functionality is going to work absolutely everywhere, which ideally gives the best developer experience, a great user experience. But of course, means there's a lot of work to be done behind the scenes anytime we add a new feature.

Dominic: 10:09

Yeah. I can I can imagine that? As you as you came across something like, I don't know, Xamarin maybe on on the dot net world at that time. If I if I recall correctly, they might they might have purchased it already, which which is some yeah. Something that that, you know, could build an an app for mobile and as well, desktop supposedly on the same code base.

Dominic: 10:32

I I never really did that, but, yeah, I I do you check that a little bit?

Andy: 10:37

Yeah. Xamarin was a really great project actually. It was used by 1 or 2 of the teams in the mobile company that I was part of. It delivered some great benefits. There was a drastically, lowered amount of code that you had to write because of the reuse.

Andy: 10:52

It wasn't quite a single code base in the way that fine was going to become because, you could share the code. It was all written in c sharp. They kind of back, put their entire tech stack onto the Microsoft approach when Windows Phone was backed as you know probably the dominant to be emerged in in the race there. They had on the front end basically a c sharp or what you call it? A port of the API or wrapper.

Andy: 11:23

Depending on how you look at it. So you would write Ios front end or Android front end but in c sharp. So you needed still to have separate front end. Just the top layer. So your code base would kinda like be common to most of it but then separate at the top.

Andy: 11:39

So that didn't really provide the the approach that we were looking at. And I've I have a vague feeling that if c is still the main part of your language, you're being held back a little bit by by the legacy or the complications. Yeah. I think Go is just so much easier for people to learn and it remains simple. Like even when you get into the depths of it, you're not having to learn lots of emerging complications.

Andy: 12:05

So I didn't really look too carefully at whether we could build on top of that. Although I I have been inspired by the project and I've I had the opportunity to chat to, Miguel de Casa at one point as well. So the the founder of the project, he obviously sold sold it to Microsoft and is off doing other things. But I I was actually intrigued to see if we could get him, involved in what we're doing here as well because I think they had tremendous ideas and it was basically the bad luck that Windows Phone didn't become the one and only. Because if that was the case, I think Xamarin would would be ruling most of what we do these days, especially on mobile.

Dominic: 12:42

Yeah. Yeah. I I agree. I agree on that. I I did not really heard of fine when it when it launched at beginning, but I was I was intrigued.

Dominic: 12:52

There there were another project called I I think it was under the X umbrella called Shiny. Does that ring any bell?

Andy: 13:00

Yeah. Absolutely. I remember Shiny. I was very excited when I saw that honestly. It was at a slightly lower level.

Andy: 13:07

They were solving the graphical, connecting to the GPU. If I remember, it was mostly OpenGL and how do you get a graphical context on your screen. And it would be about maybe 4 years ago, I looked at shiny and a couple of other projects that existed at the time and wrote my very first technical book comparing the different toolkits that were available, for Go. Because Shiny had been created I think internally to Google by some of the Go team unofficially. Yeah.

Andy: 13:37

Fine had been going maybe a couple of years and I wanted to make sure that we were still on a good path to deliver something that meaningful and there were bindings for gtk and cute. And I think nuclear and immediate mode toolkit had had a go set up as well. And so I made I think it was a a really simple email client in each of these different toolkits throughout this this book. And so I got to know each of them a little bit. And I believe that shiny actually is still a dependency of find at at the lower levels if you are, running the let me get this right.

Andy: 14:15

There's a a mobile simulation and I think that Shiny provides some of the mapping from from the the mobile APIs to the to the desktop ones when you're running it in that kinda, simulated mode. How long that remains, I I don't know because I haven't used the APIs directly. But we, of course, lean very heavily on some fantastic libraries that that make what we're doing possible.

Dominic: 14:37

Nice. You know, I I might ask a a dumb question. I'm sorry. I am not a graphical, you know, programmer myself. So let let me let me see if I understand what what exactly is fine.

Dominic: 14:50

So are you at the end of the of the day just drawing the components straight, you know, inside a canvas or something like that via a I don't know. You you you were you were talking about the the graphical the graphical component directly. So is is it is it mostly what what it was at at the beginning? So let me let me rephrase that, you know, more concisely. So what was the hello world of fine at the beginning?

Dominic: 15:17

Well, is is it is it just to draw some component on on a canvas?

Andy: 15:25

That's sorry. That's just a really good way of asking that question. I hadn't thought about it quite that way around because in my mind, hello world is the lines of code that I show in the getting started tutorials. But if you look back at when find started, hello world was not any, specific basic thing that showed it was possible. The the very first application was writing hello world into a window on the screen.

Andy: 15:54

The API that we have is designed to be an abstracted reasonably high level API for graphical apps. So actually, the way that you interact is mostly describing the widgets and behaviors and how things should be arranged on screen. And so I think the hello the first hello world had a label that said hello world and a button underneath it, that maybe changed the text when you tapped it, which kinda showed the interactions were working, the graphics were working. But it was just excluding imports, I think, 6 lines of code. And that that made it feel hello world to me.

Andy: 16:32

It wasn't a technical proof of concept. It was, you know, it's something real.

Dominic: 16:37

So and and at that time so well well, yes. But, I mean, more like when you decided to go with at at some point, you needed to take a decision to see, you know what? You know, Go is good to to write or or at least to to talk with OpenGL or something like that. I don't know. I don't know what what kind of low level library you are using to output the the the UI itself, but you you needed to do some prototype at first to to pick Go.

Dominic: 17:05

So what what was it like at that time?

Andy: 17:10

The the definition or the deciding factors of whether we picked Go were incredibly not actually the technical implementation side of things. It was, does the language work in a way that I think will help us to describe high level concepts that people will be able to program, sorry, to learn quickly? The development environment is pretty quick. You can compile fast but create application binaries that can be shipped around like their native applications. And you could tell all of those things were true without even having to write a line of Go.

Andy: 17:45

So I think through the decision making process, we were looking at a higher level. What are we trying to achieve here? And a previous CEO at a at a company I was working at helped me to realize that software, how did he say, is infinitely malleable. You can build absolutely anything. So I figured if we get something that looks like it can do what we want to and it conveys meaning in the way that we're hoping, then it's just a matter of time to make the implementation behind the scenes.

Andy: 18:16

So I Yeah. I don't think there was really a a technical proof of concept in that way. Knowing that it could use c behind the scenes if it had to, I guess, made me realize that even if the language lacked something, we could drop down to a library that I had seen in the past.

Dominic: 18:33

Yeah. Totally. Was was that was that difficult to reach the first version? You know, the first version that you that you publicly talked about or showed to someone. How much time it it took?

Andy: 18:50

I I can't remember actually. I think it would probably be, to show somebody what we were doing. It would have been about a month of effort after the basic API had been designed. And I think I started by describing things probably in documentation or in a text file of some sort to get the basic API components figured out to know how the architecture would work. And then like I said before, we kind of built this on top of the graphical stack from enlightenment the EFL which got us up and running quite quickly.

Andy: 19:26

And that was as much as anything, I suppose, proving that we were that I was right in in picking the technologies that it was going to be possible. Then through to the first version that I was really proud to show and have other people utilize. That was, yeah, a lot longer. 6 months, maybe a year, something along those lines. And so I wanted to flesh out enough that you could understand where widgets would be, how their APIs might look.

Andy: 19:54

And we have a separation between the widget level API and the canvas, which is like the the lower level, kind of what you described earlier, how should things appear on screen. We make that available as well. And to get that separation right took a little while and I wanted to flesh out just enough that people would feel comfortable. But that was present within a year of the project starting. Possibly a lot less but I can't remember.

Andy: 20:17

And it was definitely it was just me at the early stages so it's, it took longer than than I care to remember, I think. And then we iterated on that with a a community of people coming along on the project and, worked through to version 1 quite quickly. I remember early possibly about 18 months into the project, we released version 1 like 1.0.0 and sent it out on Reddit and a and a few other places, Hacker News. And there was a lot of great interest. A lot of people saying this is not what goes for.

Andy: 20:51

It's never going to work. Yeah. Which we knew wasn't right because because we could see it working. But one of the criticisms at the time which I I thought about very carefully was you're never gonna be able to maintain this. A project so young trying to do so much can't possibly have a backwards compatible API promise at this stage.

Andy: 21:10

And I understand the wisdom in what they were saying. But we did for maybe two and a half years fit into that API backwards compatibility, and then sadly decided there were 1 or 2 changes that we needed to make for good the benefit of the toolkit. We we made a version 2. So we did break API compatibility, but only once. And the project's been version 2 ever since.

Andy: 21:36

We have a GitHub milestone for version 3, which captures everything that we would have to have breaking changes to include. We're trying to never have to do that. So

Dominic: 21:47

Nice.

Andy: 21:47

We're finding finding ways that we can include what looked like breaking functionality without actually making breaking changes so that we can keep it moving forward. Because that that major break is is a painful thing. And you've got to take your entire community from one to the other. And that's that's a lot of effort.

Dominic: 22:04

Yeah. Yeah. I wonder if if it's something that Go is passing very hardly to to, you know, people that adapt that. The the fact that, you know, if you're if you're going to build something, try to be as backward compatible as possible. It it's, it's helping everyone.

Dominic: 22:21

I'm I'm curious to hear about this this 2.0 release though. Was the breaking change related to how people are, you know, defining their UIs and things like that? Was that at that level? At that level?

Andy: 22:37

The so there was a various number of changes that we put into this break when we were able to lots of APIs that had been deprecated, things that we knew we could have done better. But a lot of those could have just existed. We have deprecated APIs over the last few years as as we learn people's usage patterns. But the thing that's really the one reason that I knew we had to make a breaking change was because at the beginning of the project, I wanted the entire coordinate system to be integer based because the toolkit was going to handle how exactly that was going to map to screen pixels. So we didn't want the users to have, the developers, sorry, to have to worry about how you, you know, make things go between the pixels.

Andy: 23:24

It's either one place or another. Unfortunately, particularly, I think as 4 k displays and the super retina and these iPhones emerged in the 4, 4 times like, you know, when you got 16 pixels into used to be what was 1. Yeah. It became more important to be able to expose to a developer the ability to pixel perfect position something. But also, it was around this time that I wanted to start introducing animations.

Andy: 23:54

And I realized that to be able to do a smooth animation, you have to have sub pixel precision or rather sub abstraction pixel. How would you call it? The, the ability to address a portion that's in between one and another state at the higher level definition. So we had to move to floating point numbers. Well, in fairness, we could have used, an integer with a fixed after the decimal place, that I know is, you know, supported in Go and some graphical packages and font handling particularly will do.

Andy: 24:30

But the overhead to learning that kind of thing and and passing those types of numbers around all the time, it looked a bit too much. So we we went to float 32. And and now your animations will will very beautifully glide across from one side of the screen to another, which is very satisfying.

Dominic: 24:48

Wow. Yeah. This this seems to be, where where where things get complicated. I I would imagine, where you you know, the the the target that fine is able to, to output to is is very impressive, if I can say that. I mean, if I understand correctly, you you could build an application and you could build a desktop application for, you know, Mac, Windows, Linux, but also iOS and Android from the same code base without you know, can we say without any changes?

Andy: 25:20

Yes. Absolutely. You can. That's the entire design ambition. Yeah.

Andy: 25:24

So we have desktop. Like you say, it's Mac, Windows, Linux. We also have support for for some BSD systems. There is iOS and Android and we have pretty good support for the emerging Linux phone systems as well. But of course they're still kinda to be standardized to to some extent.

Andy: 25:44

But but we we like to include them because it's it's an area that's not well served. And with Go's benefit of compiling very efficient binaries, we can actually bootstrap for, applications on those very small devices faster than a lot of the competition. We've seen that benefit also be taken to embedded devices. So it's it's kinda less out of the box supported but we've seen fine apps running on industry sensors, embedded devices in in walls of apartments or, in retail spaces as well. Wow.

Andy: 26:18

And, also we have, web support as well. So you could, if you wanted to, run it through a web browser and serve it from from a file system using, web assembly and and the web GL layer with a little bit of JavaScript gluing it together. But I don't feel the performance there is good enough yet. So I sort of keep it a little bit quiet. It's it's technically capable but I don't think it it puts our our best image out there.

Andy: 26:43

Some applications work great but if you have a lot of graphics changing that have to be pushed through to the GPU, it it can slow a little in a way that none of our other platforms do. But we've not optimized it yet. So we'll we'll definitely get it there, in the coming versions.

Dominic: 26:58

Interesting. And I I I I've read somewhere that you are also starting to, to support Wayland on Linux as not just X11. Right?

Andy: 27:08

Yes. That's correct. We've been working on Wayland actually for for a few years now. The specification has has shifted and the the libraries that we utilize didn't didn't support it well enough to give the robust setup, until recently. So the the version 2.5.0 a couple of months ago added what we would call first class citizen support for Wayland.

Dominic: 27:31

But it is still

Andy: 27:31

off by default, default because we knew that there would be unexpected things still to be resolved. So people can turn it on with, bypassing tags Wayland to the the build process. But it will unfortunately currently, switch the application from compiling an x11 application to compiling a Wayland application due to a technical limitation in one of the libraries. We're hoping to resolve that so that in version 2.6.0 early next year, people will be able to run a Linux binary and it will just boot in x11 or Wayland depending on what's running on the desktop that you launch it from. That's the ambition.

Andy: 28:12

Nice. So we need a few things to align but we're on track.

Dominic: 28:16

Interesting. So I'm I'm a little bit curious from from the 3 platform. Let's say Windows, Mac, Linux. Is is there, is it is it way easier on Windows? Because, I mean, it's out there and I think the API hasn't changed since a long time.

Dominic: 28:35

Is it very hard for you to target those different environments?

Andy: 28:42

There's a lot of work involved making sure that they're all feature parity. On the graphics side, all of the desktop platforms are using open GL. So we don't have a huge amount to do there. However, you'd be surprised on Windows because the drivers are provided essentially by the graphics card manufacturers or the OEMs. There's a big variance in how they're implemented.

Andy: 29:06

So although, particularly Linux but also Mac has more fragmentation in certain ways and maybe maybe fewer installs or or developers, their implementations of the graphics stack are more standardized than the Windows one. Mhmm. And so I have spent oh, goodness. I I can't think how many, days of time has been lost in chasing down a bug where an app on a particular type of computer in a particular mode would crash somewhere deep in the draw process. We found that it was just because the the driver had a slightly different interpretation of a potentially ambiguous usage of a variable.

Andy: 29:51

And so we had to had to build a workaround for that particular graphics driver. Wow. I know. It's it's completely mad.

Dominic: 29:57

Yeah. That that does not sound very interesting, to be frank. I mean, it might be completely impossible to to test. I mean you you have to replicate that. How did you found that that bug actually?

Andy: 30:09

Well, it was reported by by one of the users in the community I think and we were struggling to replicate it. And if you can't replicate a bug, it is incredibly difficult to fix. However, I I have, you know, a a business on the site that does a bunch of fine related things and one of our customers had managed to replicate it. So we were able to log on to their machine remotely and see the problem. So I could understand it, took a load of videos and got as much information as I could.

Andy: 30:40

Went away and I think over a course of 2 or 3 weeks came up with a bunch of hypotheses. And every few days I would log on to their computer, and and see if we could improve the situation. And, we got there eventually but goodness me, I hope that doesn't happen too often.

Dominic: 30:58

Yeah. It's like printing for debugging but now you you need to remote remote access those those output and wow.

Andy: 31:06

Yeah. Absolutely. And if you think about the, like go is fantastic for debugging with the stack that we get but then we have to go from Go into c which makes it a bit more challenging. But thankfully, c has got some pretty good tools as well. But once you get into graphics bugs, you're actually dealing with a bug in the implementation down in the open gel layer.

Andy: 31:27

So like the code is running on the GPU which was like uploaded from a program that's running some c that was instantiated from your go code. So like that many layers of indirection. It's kind of maddening. Empowering. Like it's fantastic that we can do these things and still have a high level API let go.

Andy: 31:45

Yeah. We're solving these horrible, horrible problems so that nobody else has to. That's the way I look at it.

Dominic: 31:50

Oh, yeah. Totally. That that's what I was going to say. I mean, this this this, sounds so far from my, you know, good small and and old world of backing and that, you know, back end web development.

Andy: 32:03

It is very different. And we have a lot of problems that the back end and server development doesn't. But at the same time, like, we can with graphical environments, you write a line of code. And then if you want to, you can see it on your screen and and have it running right there. The little endorphin or the loop that you get each time you make a change is is actually very compelling.

Andy: 32:25

And when you've pulled together enough of a library to have complete applications working, it's it's pretty it's pretty great to see and you yeah. Debugging can take a little bit of time, but we're we're working on making debugging better all the time. And it is it is certainly getting easier. And thankfully, there's there's fewer low level bugs over time as well.

Dominic: 32:47

Very nice. So let's say let's say I want to build a desktop application with Phine. Am I able to compile the same application? Let's say let's say I'm on Linux, for example, or Mac or whatever. Can I can I target other OS's from my development, environment?

Andy: 33:08

Yes. Absolutely. You can. It was one of the the parts of the early investigation or well, maybe not first stage but but second order investigation to make sure that a developer could build for all the different platforms. There's there's 2 ways to go about it.

Andy: 33:23

You can use native tooling, the the standard compiler and that is possible. But because we're using c

Dominic: 33:33

Mhmm.

Andy: 33:33

At some level, you're going to need, the libraries and the the tool chain for the target platform, which can be a little bit complicated to to maintain. If you're, if you're on Linux, you can absolutely do this and your package manager is gonna do most of the heavy lifting for you. But if you're a Windows developer, it's gonna be exceptionally difficult. But we were really lucky, that Luca Corvo contributed fine cross to the community which spins up a dockerized environment. So there's a a container image that that essentially has all of that Linux tooling and the libraries for other platforms internally.

Andy: 34:14

So you could issue a a fine cross command instead of a fine command to package. And that's going to do the I suppose the abstraction of it. Take boot up the image, compile your code, and then shut down with the build in the output directory for you.

Dominic: 34:33

That sounds interesting. So so I guess the the the c dependencies are statically linked with with the binary for the particular

Andy: 34:42

platform? Yeah. Per pretty much. We don't statically link in the graphics driver because that would lead to an application that wasn't actually all that portable. And for Linux, it's the only one where that's a challenge.

Andy: 34:54

If you're on Mac or Windows, you know, that's part of the operating system stack anyway so it doesn't matter.

Dominic: 35:00

Okay.

Andy: 35:00

We we say that fine has 0 dependencies but in reality you need a fully functioning graphics driver that's relatively up to date. And by relatively I mean since, 2011. So as long as it's, you know, less than 13 years old it's gonna work. That's the idea. There's there's some reasons why that doesn't always hold true because the Go compiler itself can drop operating system support and there's not much we can do about it then.

Dominic: 35:28

Very very cool. So I mean you are being interviewed by a blind person so I I cannot not ask this question. So unfortunately, you know, the binary or the at least the executable is not accessible at the moment. But I I've seen that you have that on your roadmap. And, I mean, I get that.

Dominic: 35:48

It's totally it's a probably a beast to attack. But, but yes. I I do you have any any plan for that? How how will how will you attack this?

Andy: 36:00

Absolutely. I think it's honestly, I think it's the biggest thing missing from the toolkit now is is good accessibility support. When you when you launch a fine app the contents of the window are as I would understand at least basically invisible to the screen reader or whatever accessible technologies you're using because we are just at the low level painting things through the GPU, pushing pixels around. Now the way that we fix that is by working with every single operating systems, API for accessibility to make sure that it understands what's on screen, how you move around them, and the the metadata that that helps people to identify what's going on. Now in one way, we're in a great position because find is a API that is based on that kind of metadata that can be very helpful.

Andy: 36:50

But it when when there's a button we set it up by saying what what label it has. If there's an image it's sort of, you know, based on data that where it's come from rather than just, pixels and constant repainting. So we have the data available to make that possible but at the operating system level every single one of them is different. So unfortunately, it is a massive undertaking. You're right.

Andy: 37:13

It is on the road map. It is one of the very next things that we want to do. But it's that kind of project that's going to probably require some external sponsorship or support to make happen. We're very lucky that we've got a tremendous community and lots of people contribute to the project. But of course as a predominantly open source or rather as a completely open source group, it's predominantly volunteers and a volunteer to a project is most commonly going to work on the thing that interests them.

Andy: 37:44

And so in a way, we have a vicious circle. We don't have people in the team that understand, or require these accessibility features because we don't support it. And so because we don't have those people there, they're not doing the work to make it better. So we need to kick start that so that we've got something that's good enough that people potentially like yourself would come in and help us then to make it better because it had helped you to to get started. So that's yeah.

Andy: 38:10

Essentially, I suppose we're looking for support from from a business or or organization that would love to to see it happen. I know how important it is and I I would love to be able to fill in that last gap in our in our main support areas.

Dominic: 38:23

Yeah. Per personally, I I would be extremely also even happy to to help if I can. So if I understand correctly, so you probably have some kind of, I I would say, a graft, in in, you know, quote unquote plain text of what the UI looked like. And you could you could send that to the screen reader. Did did you did you heard about, the access kit library that that is coming from the Rust ecosystem?

Dominic: 38:52

It's supposed to it's supposed to try to how can I say that? Try you know, try to keep all the OS differences in terms of accessibility and just wrap them into a helper, library.

Andy: 39:07

Yeah. It's a great project actually with a really strong ambition to try and make this more, readily available, I suppose, for for projects like ours or or games and apps that want to implement it themselves. It's a really solid starting point and we might be able to to pull it in if the compilation process allows it and also if licensing does. One of the challenges we have because everything is, as you say, statically linked in, we can't use, lib sorry. We can't use the GPL and similarly licensed libraries because we are matching Go's, BSD and MIT type of permissive licenses.

Andy: 39:47

So with that, you can't use GPL. And because of the static linking, it's practically, infeasible to use the LGPL as well because we would push be pushing a requirement to all developers to have to ship 2 versions of their app or or provide access in in ways that don't make sense. So we only use permissively, licensed and OSI approved, licenses for the project dependencies. And that has stung us a little bit in the past, particularly multimedia which is another area that we're looking into. Most open source libraries are, if I could say, virally licensed.

Andy: 40:27

It's not I don't feel strongly that it's right or wrong but at the moment, you know, we're in a situation where it doesn't work for for us. But yeah. Access kit would be would be a great way to get started. I think, however, describing what's in a window, it would be a first step. But you know, how these items relate to each other and how state changes is probably the the harder one to overcome.

Andy: 40:52

But I am definitely no expert here at all.

Dominic: 40:55

Right. Oh, yeah. It's it's complicated. I do yeah. Maybe you just one last comment be on on this topic.

Dominic: 41:02

Do do you have a way to track the, you know, the focus or at least the where the cursor is? Do do you have that as well inside of your, you know, quote unquote AST of the u of the UI?

Andy: 41:16

Yes. So there's there's kind of 2 things there. What is focused is absolutely part of that tree that's, which it knows that it is focused, because it might want to look different at the time. Mhmm. And the the canvas containing it knows that it owns the focus so that it can, feed events through.

Andy: 41:36

The cursor position is ever so slightly different. That's not really part of the tree because as the cursor moves, you don't want the tree specifically to change. Right. But we do have the events that allow widgets to know if they're being hovered. They can opt into understanding, where the mouse pointer is.

Andy: 41:54

Of course, actually you've you've just stepped into one of the interesting things of, platform specific behaviors in what is supposed to be a platform agnostic toolkit because a mouse or a pointing device of of that type that could be hovered over something is really a desktop specific concept. And so to do that we have abstractions that are not across all types of devices but are sometimes across subset of devices. So your UI could respond to a mouse hovering or, you know, some mobile specific type of interaction but, the API that you'd be implementing is in a subpackage so you're aware that you're making a decision about, you know, in that way, only supporting a subset of devices.

Dominic: 42:42

Yeah. Yeah. That's interesting. I I I feel like I I should I should try to do something. You know, I've been talking about my situation a lot lately, but, you know, I've I've I've been basically using a screen reader full time for, you know, the last 4 years and things like that.

Dominic: 42:59

So, you know, this sounds very interesting to me. I might I might I might try to find some time to at least, you know, let's have a button on on the screen and let's let's try to have my screen reader say that there's a button. I would be I would be intrigued to see if I can if I can do something with that.

Andy: 43:17

That would be completely amazing. Like, absolutely to to have that that somebody with those skills in the project helping us out would would be really cool. And one of the things I I really love about, high level API like Finds is that each version that we deliver can offer way more smoothness or performance or implementation benefits with an upgrade that doesn't impact how the API is used at all. So if we can make even that small but move forward and release it, then every app out there is going to immediately be able to get that improvement as well, which I would see as a really big win.

Dominic: 43:55

Right. Yes. Yeah. Because to be to be frank, I I'm I'm also guilty of of not paying much attention, even me. I I I've been legally blind all my life, but accessibility is just very, very important for me for for the last 4 years.

Dominic: 44:10

So so, yes, I I if I can if I can do anything to help, I I would, you know, would just be happy to do that.

Andy: 44:16

Oh, fantastic. Yeah. I mean, we'll we'll definitely take you up on on that right right away. Yeah. So when

Dominic: 44:23

you were talking about the multimedia, so what are we talking here? Are we talking about having a I don't know. A video player and and as a as a component?

Andy: 44:34

Yeah. That was that was the main one. Audio is actually reasonably well served already. There's a there's a couple of libraries out there. Particularly, I think the work that was done, the by the ebiten engine is widely utilized, to play sound and they have done a great job to support mobile devices as well.

Andy: 44:51

So if you use that, you'll get sound in any platform that the fine apps are are delivering on which is pretty great. It is video. That is the tricky one. We really want to provide this support, but we haven't found haven't found a way yet. There are 1 or 2 proof of concept project where we have used go bindings to either a c library that we can discover at runtime or a pure go implementation.

Andy: 45:19

But of course as early stage projects go, the support for different formats is relatively limited so it wouldn't really deliver a robust video player. It might help somebody to put a particular type of video into their app which which might be enough. But synchronizing audio and video, it's just so much complexity in there, even if you've got a a library to support it. So it's gonna take a lot of work. But like I said, mostly it has been licensing that's that's held us back.

Andy: 45:50

So, every time somebody finds a newly licensed multimedia project, we we check it out and see if it's going to work. But yeah. In the meantime, to keep applications feeling alive, we just put more into the animation API and made it made it so that people can have their applications feel like they're yeah. A good multimedia experience, but actually embedding videos on unfortunately not. We can we can push people out to the browser where, of course, there's fantastic support for all sorts of things that we don't have embedded.

Andy: 46:22

But that's the best that we can do at the moment, unfortunately.

Dominic: 46:25

So do you have a component to to embed embed a browser actually? Is is is is it there already?

Andy: 46:33

I knew I shouldn't have said browser, man. I'm just lining myself up. No. There is no embedded browser. And fine, there is a long standing ticket on our GitHub where we track everything that says here's all of the reasons why we're never going to embed a web browser.

Andy: 46:49

But the ticket hasn't been closed because the conversation is ongoing because things can change. However, I mean partly there is again, there's licensing. There's a big technological challenge. Browser engine is probably going to have some sort of widget toolkit inside it for the forms if nothing else. Mhmm.

Andy: 47:10

And of course we don't want to bundle another toolkit in order to be able to have some browser functionality. So you're kind of signing up to a fork of the webkit project utilizing fine widgets entirely which just it would be a whole life's work in itself I think. However, one of the one of the main reasons I defend for, not putting it in or not not considering it is that the vast majority of requests for embedded web in an app are either a bad user experience or part of an incremental development of an application or replatforming of an application which also I think would be a pretty per user experience. So instead, we provide an API that allows people to launch a web browser at or you know, launch a location into a web browser. And that way, we don't have to do any of the hard lifting at all.

Andy: 48:02

We don't have to bundle complex libraries or integrate with them. And the user gets a clean definition of when they're leaving the application to go and work with a web browser. And for me, it just feels right because if I'm gonna go and use the web, I want to have my browsers and my bookmark, sorry, My password manager and the ability to come back to it later. So largely embedded web in native is something that I just felt isn't right and it's kind of been a bit of a workaround so we're just not going to enable that workaround. So that's Yeah.

Andy: 48:36

It's kind of one of the hard lines that that we have taken but there's there's plenty that you can do and we've got full support for rich content through the markdown language instead. So if you just want something that's marked up, there are ways to do it and they are a lot lighter than, you know, loading a web instance and having to handle the HTML, CSS, and and JavaScript to make that work.

Dominic: 49:02

Nice. So wait wait wait a minute, Andy. So are you are you telling us that there is some companies out there that are moving from their web apps down to a desktop application?

Andy: 49:17

Yes. Absolutely.

Dominic: 49:18

That's incredible.

Andy: 49:20

I know. Right? It seems it seems bizarre. But I think if you step back from it, it kind of it kind of can make sense. So why did so much move to the web?

Andy: 49:31

Well, one reason and one reason I think is a really big one is because it was so easy to build something that you could then distribute essentially to the entire world. Right? The promise was the web would just work. You code it once and it and it works in all of these different places. Now I don't know what you think but to me it seems like that's crumbling away a little bit.

Andy: 49:49

Browsers seem to be behaving more differently. Like there was a period when they were pretty well aligned and now they're not again. And the javascript libraries are getting more complex. I don't know if it's in response to this or not but we're actually seeing more websites being created in a way that is not compatible with all different browsers. So you've got a huge amount of maintenance is now appearing.

Andy: 50:11

And on the flip side, technology is like find and and other notable projects out in the ecosystem are making it easier and easier to build applications that will work absolutely everywhere. And with stores that you can ship these applications to, discovery is no longer a problem either. So I do think that it's now easier or it's approaching at least equilibrium building native apps for all platforms versus delivering something on the web for all platforms with a bonus. You don't have to maintain it and you don't have to host it. It is only improvements that you want to make that require any development effort at all.

Andy: 50:48

So with that hat on, think it's quite logical that we're seeing businesses shifting at least a certain class of their product off the web and back into native applications.

Dominic: 50:59

Yeah. I like that. To be frank, it's it's like a little bit of music to my ear. I'm a little bit fatigue of the web. I think I can say that I've been building web applications since 2000.

Dominic: 51:11

I think I'm, I'm in my right to say that, at some, you know, sometimes I'm just a little bit fatigue about that. And I I've been saying that on this podcast for a long time, but, yes, for me, having a you know, for me, what I would like on the web is to have a a UI a UI toolkit that that is handled by by the OS. So I just want to put that button on the screen and I want it to look great on windows, on Mac and on, and on Linux. And not have, not have to style it myself, not have to think about that. I want to put a a daytime picker and and just have something that works.

Andy: 51:51

Absolutely. No. I I completely agree with you. I'm just thrilled that you used the example of a of a daytime picker because there is still isn't really one on the web. But in the next version of find, we've already included 1.

Andy: 52:03

So there you go. There's a a win right away. If we could just get over the accessibility hurdles, you'll be covered.

Dominic: 52:09

Oh, yeah. Totally. Yeah. Well, and and I was building also desktop application at first. And to to return a little bit to the distribution aspect, you know, I was building in in vb6 at first, and and the amount of complexity of distributing DLL and things like that on Windows, was was crazy back then.

Dominic: 52:28

So I can totally see a company at this point launching an internal tool. And instead of going, you know, web, they could just deploy that to their to their employees. And that's it. You know, there's a lot of there's a lot of, benefits to having desktop applications.

Andy: 52:48

Absolutely. It's funny actually. You reminded me there with the installer comment. I think that is another factor of why desktop applications kinda disappeared a little bit. The idea that you have to go through an install process to use a piece of software, compare that to the web where you just load it and it's right there.

Dominic: 53:05

Yeah.

Andy: 53:06

And one of the requests that I see come into the project on a not regular basis but certainly there's been a few of them are to have support for generating an installer for each of the platforms that the applications are going to be run on. And I can't really get my head around it because like Go applications we're distributing single binaries at least as far as we can. On macOS it does need to be a little directory bundle. There's always exceptions to a rule but the idea is it's a single, artifact that you can install and you install it by copying it onto your computer and once it's there it runs. Like how we trained the world to think that that software had to be more complicated than this?

Andy: 53:51

I don't know. I feel like we've just made software harder for no particular good reason. I'm trying to unwind some of the bad stuff that has frustrated me over the last 20 years.

Dominic: 54:01

Oh, yeah. I hear you on that. Yeah. That that sound that sounds very interesting. So let's let's jump a little bit on on the community aspect.

Dominic: 54:09

I'm, you know, I'm extremely interested interested just to hear, well, you know, fine is looks gigantic from my point of view. It seems seems to be very huge. So, we all know that open source is not easy. You know, there's a I would expect that there's a lot of people asking things and other people asking other things. So how are you handling all that?

Dominic: 54:35

How are you keeping your sanity with your your your popularity? Because, I mean, I I I don't yeah. It's it seems to be a very, very hard from my my point of view.

Andy: 54:48

I I think you summarized it really well. So I'm I'm trying not to laugh too heavily because your sentence is based on the the premise that I've managed to maintain my sanity and I'm not entirely sure if every day feels like that. It there's there's obviously two sides to everything and the fact that the project has become really popular is tremendous and and I try to remind myself every day that's a little bit harder that, you know, what we're doing what we're doing here really matters to people and the reason that it's become busy and there's lots to deal with is because more people want to get involved and so therefore, you know, we're we're trying to do more of a good thing. So that's one of those things that that gets me through. Now the Go community is tremendous.

Andy: 55:34

It is, I think, by far and away the best open source or even technical community of any any sort I've seen online and I've I've been through a few, like yourself. It's really welcoming. It's very friendly. In the odd occasion when something comes up online, in a moderated space that is not by any means friendly or pleasant, it gets removed without question and often very quickly as well. So that that helps.

Andy: 56:04

I find that occasionally I do need to defend against some things that are said less less than friendlierly, especially if it is directed at one of the community members, one of the contributors trying to work on the project because, you know, these are, like I said, all volunteers. They're putting their time in because they want to see the project succeed. And for some reason some people, forget that and they assume that their needs are for some reason more important or, you know, they're more entitled to be heard than the reasons that we didn't or haven't yet done something. And on a an issue tracker, when a member of the team is trying to understand a problem, I think it can sometimes come across like we don't believe people or, you know, we're questioning them in some way. So it is it is occasionally necessary to to moderate things.

Andy: 56:58

There's like I said before, there's 1 or 2 tickets where we outline why we're not going to do something. They can get a bit flamy, but, you know, if that happens you lock it down and and move on. We've been very lucky that there aren't too many folk who've taken exception to anything but, as a good friend of mine who's who's big in open source here in Scotland, Mike McQuade has said in the past there's, can be significant downsides to open source and you kinda I guess you just have to learn to to let it pass you by and and ignore. Remember that you don't actually owe anything to these people. You've done a lot of work, and that they're happily making use of.

Andy: 57:45

So I yeah. I I try to remember that But I mean, I do, still reel a little bit from, a post a couple of weeks ago, I think it was. I can't remember the context, which is probably helpful. But somebody had decided that we weren't either understanding their problem or helping them out as much as they thought we should or, maybe they didn't see the logic in the conversation that we were trying to have. And they got very offended and posted a sentence into our forum.

Andy: 58:18

I think it was discord. Which included words I can't repeat repeat on the podcast but ended with and you should all die. And I just thought why? Like, literally why would anybody write that stuff? But, you know, we say I'm sorry that's not okay here.

Andy: 58:34

Delete the post and and move on. And try to remember that there was obviously something that was very much frustrating that individual and that we should learn from what was motivating them to be so frustrated rather than to remember the the situation itself.

Dominic: 58:52

Yeah. Yeah. That's that's difficult. I'm I'm coming from a world where where I mostly build, you know, small SaaS myself. And, you know, when I lose a customer, it's like the end of the day for me.

Dominic: 59:05

It's like I'm I'm like not feeling good for one day, but but but yeah. It's I I would imagine it's like 100 x for you. So but but, yes, you know, you created something and people really, really like that. This is extremely difficult, but, yeah, maintaining that is is is is a major challenge for you. So I'm I'm just a little bit curious here.

Dominic: 59:29

Are you, you know, are you working on fine? Is it your job?

Andy: 59:37

Yes. I think that's probably the easiest answer to that question.

Dominic: 59:40

Yeah. Okay.

Andy: 59:41

So I mean I started the project as exactly that. It was a project. A side project. Something that had been niggling at me for years and I just wanted to solve a problem. And I went through the process of writing I think the first book and realized that the problem that I saw was, you know, a legitimate area that could be worked on.

Andy: 01:00:00

And as the community gathered around I thought okay this is this has momentum. You know, this is something that could could exist outside of my own enthusiasm to do it. And I mean we've been very very very lucky with the community in the fine project itself. We've had over a 130, contributors. It's I mean, the the reach is kinda huge and the across the different chat channels, the, Slack and Discord and things, we've got about 2,500 people I think, in the channels, talking about it.

Andy: 01:00:32

So there's that. I think it was, probably during the pandemic, I started to shift most of my focus onto this project. The the work that I'd been doing, I think, at the time was technical leadership consulting like helping helping companies with their with their architecture or help their CTOs train up or or hire the right people. And that was harder to do when I couldn't see people face to face. So I switched to the project pretty much full time.

Dominic: 01:01:05

Nice.

Andy: 01:01:05

And ever since then it has been an almost full time piece of work. And the reason I say almost is because I feel like I have 2 full time jobs now. There's the fine project, the community work, the feature development, and the bug fixing. And there is a company, that I started called Fine Labs with with other members of the community who have been involved as well which is fantastic. And we do products around it.

Andy: 01:01:33

We, you know, we contribute to the community and the open source but we build stuff separate to it. And, that kinda needs funding as well. And of course business direction. You've got to do the recruitment and the sales and all of those things. So like that's my other full time job.

Andy: 01:01:50

So between those 2 I I keep pretty busy. But it's really really important to me that anybody that comes to the fine project or, you know, opens their first issue, asks their first question, they are gonna have somebody helping them out as quickly as possible. I I hope, you know, that people will get an an answer or at least a first response within an hour but that's not really possible with the GitHub side of things. It takes a bit longer to understand issue reports and things like that. But if folk drop into one of the channels, there's a great group of people who will be looking to help out.

Andy: 01:02:23

And I think everybody gets a chat and a bit of understanding really quickly. And I I think that's a big part of why the project has has grown so quickly.

Dominic: 01:02:32

Wow. Yeah. Yeah. This is impressive. Congratulations.

Dominic: 01:02:36

This is you you are you yeah. You you've reached something, you know. Don't don't never forget that that you you all know that, you know, you succeeded where, you know, most people are failing, which is, you know, it is hard. It is just hard. No matter what you are doing, if you are building a SaaS, it's it's very hard.

Dominic: 01:02:53

Building an open source project is is probably even harder, I would say. And, and yeah. Yeah. I it it gave me a lot of, inspiration. And, yeah, I I I I want to to make it accessible.

Dominic: 01:03:07

Now I I I would I would love to rebuild a desktop application myself. I I was I was enjoying that. And, Yeah. Yeah. Find Find seems seems to be very, very nice.

Andy: 01:03:19

Well, I mean, I I'm glad to hear you say that. I wish, actually, if if one thing could change, it would be that I would have more time to build apps with fine. Which sounds like perhaps the stupidest thing ever because it it is my project. It's it's what I live and breathe. Yeah.

Andy: 01:03:35

But there's so much to do inside the the project or with the business, things like that. That there's not that much time really that goes into me sitting back and thinking, oh, what app will I build next? But when I do, I really enjoy it. And so I don't know if you will have noticed or not but there is a desktop environment built with fine which is what I use when I'm coding. I think a few people kind of use this day to day.

Andy: 01:04:00

So everything on screen top to bottom, task switcher and and utility applications are all fine apps which I quite enjoy. I I seem to have my tech, I don't know, roots in Linux and on the desktop for some reason. But also more recently I've been spending time building an app builder. We're I think we're calling it a universal app studio because the idea is you you create an application largely visually but with some code potentially as well. And this is going to then compile up your application for all different platforms.

Andy: 01:04:34

So we're we're trying to solve not just at the developer level but at kind of more, I don't know, business enabling or or helping people get into it. I I think the one of the H's I've learned that I love to scratch is helping people get into this tech or or into building something that they didn't know they could do before. So in a kind of meta way, we're now using the tech to build a platform that helps other people to get the benefit of it. You know, because they're not already good developers or maybe they're not even developers at all. I don't know.

Dominic: 01:05:07

Yeah. That that's what I was going to say because yeah. For for me, when I when I when I started, I was I was really impressed when people were opening Microsoft Access at that at the time and they were able to to build, you know, what what we could call internal tools for for a company these days.

Andy: 01:05:23

Yeah. Yeah.

Dominic: 01:05:24

So, so yeah. It's, it's interesting. Cool. Cool. Andy, so I I think we will wrap up on that.

Dominic: 01:05:31

But, you know, do you have any any last comments? I I I would encourage everyone, you know, if you are like me a little bit and you want to I don't know, just just a small change in your life, maybe maybe just, you know, leave the web development on the side for a couple of times and just just, you know, just discover what what it would be like to create a desktop desktop app. I think, the fine toolkit is is a great option.

Andy: 01:05:59

Oh, well, thanks so much, Dominic. That's that's really fantastic too. I I I really appreciate the stuff you've said as well about, you know, where where the project's at and what's been achieved. I I simply couldn't have done this without the community. And I I mean every single person that's either touched the code base or or come along to chat about it or has, you know, been part of the Go community before.

Andy: 01:06:19

There's there's so many good people. And, I keep really enjoying seeing what people are building with it. So anybody that drops into a channel and and advertises their app or, maybe submits it to be to be listed because we have, on the website we've got apps dot find. Io that lists open source applications that people are interested in sharing. So there's I think about a 130 examples of apps, that that people have built there.

Andy: 01:06:45

And I think that helps me double down on the idea that all the time we're helping other people learn because it is open source. It's examples of what people have been encouraged to do themselves. And, yeah, if other people listen and and want to try it out, do have fun, I hope. If if you got any feedback, good or bad, jump on one of the channels. Let us know.

Andy: 01:07:05

Always keen to hear what people are, yeah, building, succeeding with, or or struggling with. Because like I like I tell people, if anybody comes in and says this might be a daft question, there are no daft questions. If you're not sure about something, we need to know because the documentation should be better or the examples need to be clearer or we need to signpost, so that there you know, people feel empowered right away as opposed to wondering if they should even ask.

Dominic: 01:07:30

Oh, yeah. Totally. Very

Andy: 01:07:32

very well. Congratulations. Sorry. Congratulations on the podcast as well. Like, it it takes a lot of hard work to build any community and the people that listen to this are very much benefiting from the work that you've done as well.

Andy: 01:07:42

So yeah. Well done for you too.

Dominic: 01:07:45

Alright. Yeah. Thank you. Thank you very much for your time, Andy. And, I I hope we we can we can talk a little bit.

Dominic: 01:07:50

Yeah. Maybe maybe if I if I if I'm successful with, making it, accessible a little bit, we, you know, we could we could, a version 2 chat maybe.

Andy: 01:08:01

That would be fantastic. Yeah. Absolutely. And hopefully, I'll see you online somewhere and we can chat about how things are going and Yeah. See if we can bring that together.

Andy: 01:08:08

Thanks. Thanks so much for your offer and, yeah, for reaching out as well. It's been a really great chat.

Dominic: 01:08:13

Alright. Thank you. Alright. That's it for this week. I would really appreciate if you can talk or share about this podcast.

Dominic: 01:08:24

It's it's always helpful. Also, another way to support this show is by purchasing my course. There's always a link in the show notes. So on that, see you next week.