Tech Over Tea - EasyEffects Left GTK4 For Qt6 & KDE | Wellington Wallace

Episode Date: January 16, 2026

Today we have the developer and maintainer of the EasyEffects project to talk about the project transitioning from GTK4 and Libadwaita over to Qt with Kirigami leaving the GNOME ecosystem and in some sense becoming a KDE app.==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Website: https://wwmm.github.io/easyeffects/Repo: https://github.com/wwmm/easyeffectsPatreon: https://www.patreon.com/wellingtonwallaceLiberapay: https://liberapay.com/wwmm==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. Plans had to change very rapidly before we got started, because right now, there is a cloud flare outage. So we had to suddenly change what we're talking on, but now we are here. So today, I have someone from the Easy Effects project on to talk about why the change from GTK to cute, and I guess just a lot of the history of the project.

So how about you explain who you are and what the project is? Well, my name is Wellington. I'm a physics professor here in Brazil in a federal educational institution. My academic background is probably different from what most Linux users would expect. My background is entirely in physics. being more specific experimental physics and by if I remember well

somewhere the last year of my PhD that I started to really get involved in software development was that as a requirement for doing the physics work or were you just interested in doing software development? Quite often when you are doing experimental physics,

you have to write some kind of software. In my case, specifically, it was software intended to automate device management. Sometimes you need to do a chart or control what the equipment is doing. So most of the time that's what I was doing. But by the end of my PhD, I needed to do Monte Carlo simulations. My work involved the measurements of magnetic nanoparticles, and in order to better understand what I was seeing in my measurements,

I started to do Monte Carlo simulations. That's when I really started to write software. At the time, nothing that involved the user interface like its effects there is now. They were mostly common line applications. I used the open CL at the time to parallelize the calculations, this kind of thing. So a little bit about controlling devices and another about the simulation to better understand the data that we're getting.

So how do you go from that to doing easy effects? Or I guess at the time when it started, it was Pulse Effects. Yes. This start was also a little non-traditional. Let me say this way. One day I was using Buezioidius Bielkeme and suddenly, one of the other chainers just went missing. Okay.

without reason. Yeah, it's not something cool to tell to non-Linix users, but that is what happened. Suddenly, I do not remember if it was the right channel, the left channel, suddenly there was no water. Then I started to consider the possibilities. Well, should I report the bug? But after that time, because of the audience,

used to that horrible mailing list way of dealing with things. And at this point, I was not used. to interact with open source projects. So it was not encouraging. I looked at that, well, so reporting didn't see it very appealing. Fixing the problem, well, I was not to, I didn't know anything about fossilized gold basis. So at some point, I realized that even if that problem was fixed,

I was not satisfied with just the equalizer. So I decided to do my own solution after that event. At the time, I was already used to, I'm not sure how people pronounce G-streaming. Yeah, G-stream. The moment has a little bit. At the time, I was already used to use G-streamer for physics experiments for students. For example, doing a chart show in the other way,

that the microphone was capturing. So I used a lot at the time, the Python language, to control the streamer and look at what the microphone was capturing. So it felt natural to write a small script that was put in place

in a pipeline that took the sound that was being sent to a pulsio, but new sync, did some processing, and then played it at the South Carolina. So that's how it started. It was a problem. And then, in the end, I decided to do a small solution that did not have a graphical user interface. It was just a Python script running the terminal.

When was this? Like, how many years ago was it? question. I'm not sure for how long I have been doing this project anymore. Has you changed the repo? Like, has it always been on that GitHub page it's on now? Oh, it was always on GitHub. Okay, I should better go check the commit then. Let's find out. I stopped counting a few years ago. I'm not sure how long now. January, 2017, it looks like, March 2017? Yeah, that's what it's saying here.

Somewhere around that point. Yeah, it's possible. So it's been quite a while now. It has been quite a while. It's not the first time this project goes through a major change. Like I've just said, it started as a Python script. No, no simple. plus no C, no C came eventually when, because I started as a Python, it started as a Python script

that was not able to automatically move applications to it virtual C. So that's when C started when I needed to interact with Postaldo API. So it was that moment where most of it was still in Python, but with some custom-reading wrapper for post-a-odules API. But it was not a pleasant experience, by the way. It was one of the reasons why I left Python Devine. The more I needed to interact with C libraries, the worst it was to keep the application using Python.

At some point, I had to write too many rappers. So I had to go to a language where I could talk directly to the libraries that I had to use. So it was one. You felt like there was like a lot of additional overhead work you had to do trying to work in Python? Yeah, if there is something that is a fact that taught me, is that that that I should avoid wrappers. Every time I used one, I regretted it. This happened while I was using Python

when I needed to talk to post-Oad this API. Eventually, at some point, the same thing started with DTK because naturally I was using the wrapper for Python. And it didn't take long to get to get to to a point where I needed JTK functions that were not wrapped by the wrapper. It is horrible. So it was quite clear that rely on wrappers.

It is easier when we start, but when the application becomes more complex, at some point you will need something that the wrapper does not happen. Right. And I guess, oh, sorry, going. So that's probably was the main reason why I didn't stay on Python. The second, if I remember well, it was performance. At some point, I started to notice that that's not a good choice. It's time to move off.

So what made you want to expand out the application? Because initially it was just this very simple Python script. And eventually you started bringing in this graphic interface for it, additional effects and all of this extra stuff. But why did you want it to do even more? So before doing this, and maybe even before I started to use postiotis building Equalizer, I used the nowadays people will use a pipe wire's filter chain for that that is configured. editing a few text files to put in place after that time. At the time, we did this with post-o-do, but with a lot more limitations.

There was a very limited choice of plugins that you could put there. But in general, the problem with this approach is when you need to experiment with the parameters. When you already know how you have to set the plug-ins, it's not a big deal, but when you are still trying to figure out the proper values, it's a lot easier to have a window where you put the values in to see on the fly, how the audio is being changed. So the main reason why I put a graphical interface in the Python script was to be able to change on the fly what the filters were doing.

So that was the reason for it to get a gratuously interface. The other features, they actually came when other people started to get interested in what the application did. So I would say that more than half of what this effect is does were put there because of users requests. For example, at the time I created this application, I had no need for a microphone pipeline. Video configures were not a thing I had to do like, for example, we are doing now. So I was just, I just got about effects for the output of application, not input. One day, one user suggested that it was cool, it was within my reach to do it. So I did.

The same thing happened to almost everything else. most of the plugins that are there quite a lot of the functionality it was because people requested if I could do it it was fun to do so it was done so if I understand correctly the graphical interface started as a way to

more easily test the filters and then people realized that was useful and then started adding in extra functionality they also felt was useful and eventually it kind of became this big application for doing lots of audio effects to your input and output devices, I guess. Yes, I didn't start with big ambitions. It was just solving an immediate problem that I had. Eventually, I thought, maybe this will be useful for other people.

And when other people started to use, they started to start. suggest new functionality and whenever it was easy to do. I implemented it. Eventually, other people started to collaborate, especially flat-packed people, started to collaborate, because package management, it's just not my thing. I do my own package, my own custom Art Linux package, but maintaining for other people, no.

Right, that makes sense. So I'm assuming because you have the AUR, the package build, I'm assuming you use Arch Linux yourself then? By the time I started this project, I was already using ArchLilinix. I have been using Linux for more than 20 years. I have used more distributions than I can remember now. But Arch Linux is already the one I've used the most. I probably have been using the literature for 10 years, I would say. The Lita has been quiet.

It was actually the first place I announced these effects was probably on Artigan's Forum. Awesome, awesome. So as the project progressed, it got a GUI, it got that, Was the first GUI that GTK3 GUI, the old one it had? Or was there a different one before that? Different one took it, do you know? Yeah, so the original GUI it had, before you did GTK4, what was the GUI written in then?

G2K3. Okay. Yes. First through the Python wrapper, then there were all those problems, I mentioned. before. So I went to J2K and M, the C++ plus rapper for JTK. Not sure. Not sure how people pronounce its name. I've never heard anyone say it. Your guess is as good as mine. I'm not sure, but in any case, it is the C++ plus plus rapper for, and there is a

was I like C, but let's say that I like C with moderation. So I didn't really want to go full C language when writing the user interface. So I decided, well, let's try to not go too far away from C++. So I used the wrapper. But eventually, I started to need. calls, GTK functions that the wrapper did not have. So it was the time when I moved to full GTP3. What made you go with GTC3 at the time?

So the reason for GTCK, as much as some people may not believe, it was the best tool at the time. So the reason is, like I mentioned before, mentioned before, I was already used to use G streamer to do some problems. And although you can use G stream outside of GTK, you can't use it in a QQ, it is more straightforward to use the streamer in GTK when you need to bind properties from one side to another. You can't do it on other two cases, but the truth is, the streamer talks the same language of digitators. So it is easier, it is faster to buy.

So as the application needed this streamer, being more specific, the application would still need the streamer if we were still using post office. Actually, the one that you made the G streamer not necessary was pipe wire. That was the next thing I was going to ask you about. Paulseudo does not offer what we needed to not use G Stream. And while you are still using G Streamer, it makes a lot more sense to use G2K. That was the only reason.

It was easier to find the graphical interface properly. to GSTreamer properties using G2. So what was Pulse Audio not offering? I think a lot of people have a lot of negative opinions about Pulse Audio, and I think it's a good thing. We've left that one in the past. But for what you were doing here, what could it not do that G-Streamer kind of became a requirement at the time?

So what Post-Odio was missing and probably still is, still is an API that allows you to build filters that will process order. That was the main reason this streamer was there. Because you can load a virtual device, you can move the applications to this virtual device. You can make the order of a virtual device to go to the sound card. What pulse order is missing is what should be in the middle. How are you going to put your plugins processing the other? So Pipwire has this by design.

It has its own API that allows you to write your filters, it just inserted in the middle. At first, we were still using the streamer when I moved to Pipery because, well, you are rewriting a considerable amount of code. So initially, I tried to do as little change as possible, but I already knew I could not use the stream. That was the reason why I moved to pipeline. So, J-Stream works for that, but it has some challenges. When I first, my first attempt is actually didn't work well. There was a difficulty involving the synchronization of the

G-stream pipeline clock with pipe wire clock on the virtual device. Eventually, I was lucky enough to find a combination of parameters that made the whole thing work. But the first attempt is there was a lot of lack of synchronization, like I say, between video and the other. That was the main problem in my first attempt is still. using Python, which was the lack of synchronization between video and the other when I put the streaming the needle. So I'm going to remember now which parameters solved this, but eventually I found a combination of parameters that made the whole thing usable. So all these little problems, they naturally go as a way when you use pipe wire. So after moving to it, there was no need to stay on the screen.

And from a usability point of view, there were some side effects that were hard to deal with when you are using the stream for that. Because, for example, when people open the desktop or the management or Pavook control, I'm not sure how people tell that. This streamer pipeline will be seen as the stream of any other other player. So sometimes something broke the other group because it is not clear that it had a, let's say, higher purpose. So sometimes people moved it around and the water was broken. So it never felt like a proper solution. That's the main.

That's one of the disadvantages. But it served as well for quite a long time. But always kind of felt like this add-on on top of Pulse Audio rather than being something that nicely fits in there. Yeah, it was more a hack than a proper solution. Right, right. That's the truth. It is not the better way to solve the problem.

It was the only available way to solve the problem. It is more like that. There was nothing else that could be done without the other server providing the proper tools to do that. Well, unless you wanted to fundamentally. change it and make it, you know, rely on the Jack API, which creates a whole other set of problems? I think that before starting these effects, I tried a few times to put global effects on my desktop by a combination of LV2 plugins and Jack 7.

It was not a pleasant experience. I eventually just stopped the whole thing. But one of the problems, some people don't like Postal. I'm not sure how this is nowadays. 20 years ago, people really hated Postal. I never shared that feeling, but one of the problems of not using post-order and now pipe wire, is this is the kind of application where you want an easy way to move other streams to its virtual device. Hmm.

So you don't want to all the time to manually put applications there. You want the application to be able to do that itself. And I'm not sure the jack server provides this. Maybe it doesn't. Jack is all manual routing. Yeah, I do not think this anyway. Actually, I post-word was the one that brought this to the Linux work. I do not think before it this was possible. Probably not.

So the next major shift. Actually, when did... Hold up, let me just think this one through my... I'm forgetting how to pronounce words now. So... Did the shift to pipewire and GTK4 happen at the same time, or was one of them much earlier than the other? Pipwire probably came first. Okay, okay.

If I remember well, I think that the previous major change was using G2K4. So, I guess, I can probably guess why the move was done from G2K3 to G2. G2K4, it was the logical next step. But if you have some more comments on why that change was made, and also the addition of, were you using LividWater as well? Yes. What eventually I came to regret, but let's talk about that later. But from GTP3 to 4, besides the usual, it is the next version,

J.K4 brought something that it was really a step forward, that it was how you deal with list view there. Dealing with lists in JG4 is a lot better than it felt in JTK3. But it was not a move without resistance from some users, not as much as now, But still, JTK4 was the version that left behind completely three icons. So not everybody was pleased when we moved to JTK4, taking this consideration. But it was definitely less resistance when you were moving from QT to JCPK and back and forth. No doubt. But three icons were something that people requested from day one.

But I soon realized that they would not be a thing anymore in the JTK ecosystem. I said no, there's no point in fighting against the toolkit we are using. But from a development point of view, The new way to deal with lists in GTK was one of the main reasons why I wanted to use it instead of JTP3. When did you make that swap to GTK4? Was it early on in GTK4 or did you let things sort of mature a little bit? I assume as it was available in Artinux repositories. Not sure how early, that was exactly, but I started to play with it as soon as it was. This is more or less what always happens.

When I see something new, I usually, well, I will wait for it to be available in Archimpsons, repositories, because this is already going to be too soon for many people already. Right, right. No need to go beyond that. Yeah, if you're going in beta and releases, that's going to create a lot of problems. Like, Arch Linux doesn't always get things immediately, but you can at least assume that when they have it, it's packaged as a stable version. So other distrains will get it eventually.

So when you first made the shift to GTK4, was LibidWater even a thing back when GTK4 first came out? Or was that something later? I don't actually remember. I'm not sure how much it was. I remember that on JTK3, there was leap handy. Yeah, yeah. Something like that. That some people suggested we used. But at the time, whenever it's possible,

I try to not do too much dependencies to the application. I only had a new dependency when there is a situation that it is really hard. or annoying to solve without that library. So initially, I tried to implement some of the things I liked in Libiduator, imperial D.T.K. If I'm not mistaken, I even ask for help to some of the DGK develops. They gave it some suggestions. But the truth is, you have that you...

constant feeling you are reinventing the wheel. It never got as good as the one the way it was providing. Didn't match well the application thing. It was taking more time than I was already to put on that. So at some point, I said, enough. I will just choose this library and that's it. But that was a mistake.

Jutka ecosystem really does. not want you to view libiduete as any other library. So that's one of the reasons for the latest shift. Using it like I used any other library was a mistake. I never asked just directly to GTK developers, but the feeling I have is that the idea is JTK becoming a solid foundation and the cool stuff going to Libidwater. So if you like something that is going to live ad waiter, it's kind of like either you use it or you do it yourself with your certificate. What obviously will require more time.

That is something I have heard other people say where it feels like livered waiter is kind of treated like an essential add-on. to GTK4 and GTK4 there's just a lot of stuff missing that should be there. Yes, most users probably think of Libidwaita

as just something that's providing looks, colors. But the truth is that you have some useful ridicates there that are not available on GTK

It is possible to replicate. I tried worse, but in the end it is not as good without putting as much time as the people develop individually. So that's the problem. I mean, it makes sense for them the model that they are choosing. Like it or not, GPP is, has its focus on Gnong and on Gn. So it makes some sense that you are making Libidwate with Agnome folks and keeping GTK as a solid foundation that you can use for applications that are not wrong in. The issues start when you look at the Libidwaters, see something that's nice and you realize that that's not on G2K. So as I didn't want to

brainvent the wheel all the time, I decided to use it, but in the end, it's not a good thing to do. So that's one of, at some point I started to see random places at the internet, at the internet. If a developer is using liberators,

it's because they are focusing only on genomes. I was reading that and telling to myself, that was not the reason. I just didn't want to invest a lot of time. Really implementing Puget case, some of the things that are good to use it, that are only there. So it is an uncomfortable situation because you are now put on the same boat of people that you never really intended to be on that semi-boat. So I understand and respect to the decision, but for people that are not focusing, only on genome, and that want some of the nicer things that are going to the other side. It is annoying.

So I guess you didn't want easy effects to feel like it was only a genome. That's kind of what you're sure. That was never the point. Obviously, I saw one, like I said before, my whole academic background is physically. It just happened that I've got really involved in writing software. But I do not have a background in, for example, designing. Sometimes I see user, but the interface is horrible. Of course it will be horrible.

You have a physicist in writing your audience. writing your user interface. What do you expect? Something wonderful out of nowhere? Of course, it will be horrible. And one of the nice things that Genome provides and eventually KDE started to provide too was a human interface guideline. So the obvious thing to do when you do not have a background in graphical user interface is using the human interface guideline that. This guideline that the toolkit is providing.

So it was not done with the intent of being a genome-only application. It was what made sense considering the circumstances. That was the point. But when you put Lee Bedwaiter, you start to be seen as someone that is focusing only on genome because that's the purpose of that library. So some people are. People may say, oh, but Kirigami is the same situation.

Not exactly because QT landscape is a lot bigger. They won't, out of nowhere, suddenly, QT is just a solid foundation, and now the good stuff goes to KV. It would not make any sense to do that there. So, J.PK has these exceptional circumstances, let's say this way. What is fine for them?

It makes sense for them, probably. But I think that it has an application that has to look at more desktop's environment. Either you stay with pure GTK, what will mean doing more work or not using what you think is nice? Or you move it to somewhere else. Not much that can be done. I think what Ghanome has done when it comes to creating a consistent ecosystem, like, nobody else on Linux has an ecosystem that looks as consistent as what Ghanome has. And that comes from that encouragement to use Libid Wader, GtK4, and really follow those human interface guidelines. But the problem with that model, and it works great on Gnome, but the problem with that model is the same.

When you take any of those applications outside of Gnome, they immediately stand out and you can very quickly see this doesn't belong here. I used Gnome for many years. I started the Linux world doing KDE, use KDE for many years. At some point, I do not remember if it was Plasma 5. KDE was really having a hard time in managing multiple video outputs. And it was a time of my life where I was still going to video conferences frequently and I needed a desktop that was dealing well with this. So, okay, Gnome, it is. And I used it for many years. It has

definitely a good site. Now I'm the best. back to KDE, but Genome has really good things there. But back to what we were talking about, I still remember when I saw for the first time its effect in a user desktop after we moved to DTK4 and before KDE improved its integration for GDK for application. it was absolutely horrible. Absolutely wrong. Thanks to KDE integration, nowadays, I never, I was never bored by his effect is loop while using KDA. It was okay, but it was okay after their efforts to make G2K4 applications look better. Before that, it was absolutely horrible,

Absolutely vulnerable. So if the desktop you are using do not provide the necessary integration, yeah, people think it is bad now. It was way worth before. Way it was. Are there any other reasons? I know you said in like the GitHub thread, and people sort of have taken that as like, hey, I don't like GCT.

Are there any other reasons why you've decided to make this change, or is it basically just you didn't really want to be seen as a Ghano map? I would say that this was the second most important reason. The first reason, it is related to the effort. We have to put it developing new features as well. was maintaining then and how fun, how enjoyable the process was going. I was totally okay with J.TK while the application was relatively small. When it became bigger, let's say, the journey you have to take to implement some things in J.DK started to not be enjoyable. It may become more clear, it

if I explain why Q&L, because for example, I would not have made the movie if the alternative was traditional QT widgets, for example, because it was pretty much the same situation. Yeah, I've done . I did not like in G2K. So imagine that you have a backend, and there's a place in the user interface

that you need to use that backend, or whatever it is, the C++ plus class for object that you had to use them. In QML, you just expose the object to QML and use it anywhere in your user interface. It is a really straightforward process. So it is not about being able to do or not being able to do something. I could do what I wanted to do in G8. But some of the things required way more effort than I think they should require.

And the whole thing is just immensely more straightforward than when you are using Q&L. It would not be with traditional Citiwit, for example. Again, you can do what you need. The problem is the journey. It started to get tired. that was definitely the main reason. I was not to have, it was not being enjoyable anymore.

For example, I talked to before about how much better JTK4 is than JTK3 when you are dealing with lists. But even in this case, when you have a list in J2, and for example, our left panel with plugins, with the filters list there. Sometimes you need to access a given objective

in that list entry, and you can do it. We could do it. It works if it could be able. But it was immensely annoying to do that. The level of indirection, the backs in the middle, to make the information you need, to get where you need, when you need it is really tiring, really annoying.

I didn't mind it when the application was small, but the more it grows, the more annoying it gets to deal with this. And QML is, it likes to take the user run. That's not really nice, let's say. But from a developer point of view, it is a lot better moving. think about the future, to use Q&MEL,

to stay with a tool that it is just too time to use it now. It is the nature, it is written in C. Like I said before, I like C. I give C classes where I work in the C's classes. I like this language, but with moderation, when you have to use it intensely, you start to see the other side is too much. So you have this problem that well, we eventually have to write more C than you were willing to do.

And the alternative to that is to use XML files. That will also have a lot of limitations. So it is a problem that is not going away, like this way. the C limitations will remain there. The X&L Flyers limitations will remain there. And most of these problems are also in traditional QTWIDDICs. So when I was considering, well, I should move on to something else, but then what? It was quite clear that it would not make sense to move to traditional QTWIDDBs.

As much as probably some KD uses, I hate the fact that QMEL was using, I'm sorry. I'm not going to use something that is going to be annoying to use it, just because some people want to frame and customize the application appearance using their favorite tool. It would not make sense. So either I stay or it is QML. because unfortunately there is not much life out of the side of the K&QT. I mean, some people consider electron but no. If you want to have hate threads, that's a good way to get them. I'm okay with JavaScript in some situations like the one that KMiao does.

A full JavaScript application knows. So either you stay or you go some arrest. And I would say that the third reason was treaico. It was the system triad. I have last count of how many people have opened issues about this, sending me emails about this. And it will, it will never. happen in JTK. For the direction that they took, system trade has no place anymore. So as much as you could try to use an external library to do that, it is always that feeling you are fighting against the toolkit you chose to do that case. So it would never happen. And there.

not exactly reason, but something that was becoming a little complicated to solve. At some point I realized that we started to abuse the settings, that is the framework that the applications used to handle configurations. It definitely was not designed to have to put all, as much as configuration options as we're putting that. For example, flatback users, they have to deal with a different settings in the backend. That is immensely slower, immensely slower. It is a nice configuration framework. For example, for people that were developed third-part tools that needed to interact with our settings,

having the Confi service running, it is a good. definitely a nice thing to have but we were paying a performance price using it the way we were using but it is just a minor reason nothing particular concern but when you start to adapt everything we see that some some change needed to be made and it was not the first I hope it is the last major change but It is what happens. I didn't start, oh, I need to make a super big other framework for Linux

so that we can apply global effects. It was not planned in what we became. So a few major rewritings were necessary along the way. All the others purely technical reasons. This last one are a little bit of both. So with the move to cute, for anyone who's unaware of, you've mentioned QML and QWITs a couple of times. For anyone who's unaware of, you know, the cute development experience, can you just briefly explain what those both are? Well, something that is nice in your ML now is, for example, you do not have to do work with XML files.

It is something that resembles JavaScript most of the time. There's some difference here and there. But at least to me, it is straightforward to deal with that. When you are using, I had some experience with the traditional way many years ago. I like and I dislike the QD designer at the same time. I don't like being stuck to the designer. And the alternative to use it would be to write the whole user interface in C++. I like C++ a lot, but not to that point.

Just like I would not have written our GTK user interface purely in C. So either you use you. you do the designer or you write the whole interface using c plus plus because i do i think that the xml files guilty designer creates are not even meant to be massively so it is either using it or do not use it And so nowadays I prefer to do our QML deals with just a text file, something that looks like JavaScript, write it there, how the interface has to be. It's like a UI design. It's probably something that is closer to what people that create websites do.

Right, right. Yeah, it's like a... Compared to how the traditional way works. It's like a UI design language rather than merging all of that into the same thing. So alongside using that, you also decided to use Kirogami from KDE.

I think a lot of people probably aren't aware that kirogami is even a thing. So what is that and why are you using it? So the motivations are not entirely different from what led me to use Libidweight. It is a lot easier to create your own solution when you are using QML compared to how it was on JTP. The experience I had trying to create custom widgets in JTK are not that enjoyable. QML is a lot more straightforward.

So it is possible to stay only on it if you are willing to spend the time that this will require. So at the time, I consider this possibility, so that we could have less dependencies. But there's just a lot of things that Pyriagam already provide. where the provides for free. I mean, I will give one example of something that it was immensely hard to implement in JETK and that Kiriami just gives it to you. At some point, one user suggested that our filters list,

instead of just pressing up and down buttons to change the filters order like it was, It was this way for quite a long time. Someone said that we could just drag and drop the filters to change the other, the effects that being applied. I thought, well, that's cool. But how the hell do I do that? Fortunately, one of DTK developers wrote at the time a blog post where he was explaining

exactly how to do that in DTK for at least this. the view so I'm not to mistake. But even with that blog post, I had super hard time, trying to make that drag and drop work. And in the end, it didn't even look that nice. It do works, but with some visual bleaches that are, I was out there. It will stay this way. I don't care. It was really hard to do that thing. And when I was moving to KD, I thought, oh, no, that again. We not want to go through all that again to do that drag and drop. And although it is less painful to do that in QML, it is going, when I look at how people were implemented drag and drop in QMEL lists, I thought, well, this still feels a little painful.

Let me see first what Pyrigan is doing here. Well, with five or six lines of code, everything is ready because they have already went through the pain of implementing the whole thing in a model. So I thought, oh, honestly, let's just choose the thing. If in the future some kind of catastrophe happens and we need to move away from it, it is a little bit. is definitely less painful to do this and use QML, than it would be in the similar case in JTK. But the truth is, there's quite a lot that Kiribama offers for free.

That honestly, I'm not willing to reinvent the wheel, especially in situations like this one for drag and drop. It looks better. It required a lot less effort to implement, a lot less coal. Not much sense. I do not see much sense in not using it. I know that many people will not like the fact that they will have some KDE dependencies there. I actually did see a post about that.

Someone complaining that the change brought in 200 megabytes of KDE dependencies into their desktop. I'm assuming they do everything on, you know, Genome probably don't have any. Yeah, sure. It would be super nice if all that could be going to provide this. All these facilities were there. They are not. So the alternative is do it yourself, everything. Honestly, like I said before, I tried that path into decay. It was not pleasant. I do not see how this would be pleasant here. So, yeah, people who have an additional dependencies, it is what it is. It does not make sense to make my life harder because of this. After all, I still have my work, I still have to give classes.

Who knows how many decades yet? It is one thing if you have full time on that. If I wear a If I work only with open source, sure, I would consider that. But this isn't my current situation. So people will have to accept additional defense. I mean, whenever I do a major change like that, I keep a legacy branching it. I did see that, yes. If someone is willing, if someone is willing to take a head,

the main branch. I mean take a head somewhere else because I'm not to have time to get involved. Oh you have the legacy branch for the really old versions? Oh you still have the Pulse audio legacy branch? Oh it is there for some time. Some people provided the patches for post effects when it was not compiling anymore or things like that. I mean I just missed that merge the whole thing, if it will help, no problems. I just do not get involved with it anymore. So if somebody was really interested and said, hey, I want to keep the GTK4 version alive

and they were willing to submit patches for it, you would be willing to accept those. As long as the only thing I have to do is merge the full request. Not a big problem. But testing the patches, no. Right, right. No, that's understandable.

If you're not interested in working on it yourself, then I do think if someone wanted to maintain it, it would probably make more sense to fork off of that branch, just because, you know, it sounds like you're not really that interested in reviewing the patches and stuff like that. A lack of time, most. and like I've said somewhere before it is not being that enjoyable

developer with GTP anymore so it would not make sense to put energy in this it would probably be better if people just create their new repository for this with this being such a big shift going from GTK over to Cute

I'm assuming hasn't been without its problems. I'm sure there have been some things which made more sense in GTK that did cause issues after you swapped. Things you'd do, relearn, new approaches, things like that. Some of things are more straightforward in GTK. For example, mostly for lack of time to put the necessary energy, splitting the graphical interface, from the background that applies the effect, we are essentially an application that pretends to be a service. This effect is not really a service.

It is just a graphical interface application that hides its interface and pretends to be a service running the background because splitting the two fingers would make it. will require a communication between both sides that obviously is going to require a lot of effort. So doing that in GTK is a lot more straightforward. They have a flag that you just set it and the GTK takes care of the whole process of keeping the application running the background, as well as making

ensure you have only one instance of the application running because this is important. It does not make sense to have multiple instances of these effects is running because one instance will try to undo what was done by the other instance that is running. And for some reason, QQQA does not provide this out of the box. So I had to create my own solution to ensure that there is only one instance running, my own solution to keep the process running once the windows closed. So there are some small things here and there that are indeed more straightforward when you use D.

For example, the configuration framework that is the settings. For external projects to interact with us now, we will have, they will have to do this through a local that I had to implement. So this is something that the sections naturally does on its own. Obviously, there's a performance price for that. But the truth is, this is something you get for free when you use JitK, which is there, you use, and when you use QT, you have it to find your own way. So there's definitely some things here and there that

are more straightforward when we are using to take. It is quite capable, quite capable to kit. It is more the whole libidweight situation, plus my personal preference is that when the application became too big, I didn't like anymore some of the workflows that we need, but by no means it is a bad for kit. despite people. Sorry, I've got a bit of a cough right now.

I had to keep me to my mic. I hope I haven't coughed into the mic. I hope you haven't heard that. Anyway, ignoring that. Moving on from me being sick for way too long. Anyway, so you've mentioned a couple of times already

how you're a physics professor, you kind of expect the you should expect the kind of UI a physics presser is going to make. Like, you said it yourself, like, and I know, and I know people have said, oh, the UI was bad before, the UI is bad or worse now. I did see that when you actually made the change,

there were some KD people that sort of jumped into the thread at the end to say, hey, if you want to get involved with UI discussion, stuff like that, Have you gotten involved with that? Do you have some plans to, you know, further improve the UI for what Easy Effects is doing right now? Yeah, I believe that for quite some time, we will have to focus on polishing. Where they're using the face. Right now, we are still in that moment where there is a flood of bug reports as well. You'll never have enough people testing. So inevitably, this will happen. There is one KTA developed that has provided some patch.

I'm not sure for how long he will be able to keep that, doing that. But some changes have already been made. He is looking at other things. And once feeling this comes down a little, I would try to put some effort there in the interface. talk more to them. I talked a little to them in the Matrix channel, but there are more things that we'll have to look because just moving from one toolkit to another required a lot of effort. If along the way I would try to pay attention to what is KDE human interface guidelines saying?

It would take forever. So first let's make this work. Right. In a another two-key. Now we can't try to take a look at this kind of thing. Again, I'm a physicist, so as long as my will is concerned, it will it works. So now is the time for people that has actually an experience with this, that works with this kind of thing to provide at least some feedback about what has to be changed or not. Even In vain then, it will still be a challenge because you definitely will not please everybody. Yeah, no matter what, for example. It's a complex application.

It's going to always be difficult to make perfect. Yes. For example, talking again about our filters list in the side panel. We have there one button that enables or disables the effect and another button that You can delete, remove this effect from the list. So thinking about these two buttons, we have two big groups of users. One that you always want to see those buttons,

and another group that you do not want to see those buttons. You can't do both things like the same time. Either you show the buttons or you hide the buttons. So what we decided a few days ago was let's just put a configuration option. If you do not want to see the buttons. Now you're getting the idea. You want to see the button. But you can't do that always.

There will be some cases where it will stay that way. So that's the problem. I know that some people consider these effects interface cluttered. But the moment you try to hide something, there's a group of people that come complaining that now they have to click more to do what they were able to do before. So there will have to be a compromise between clicking more or less. And I hope that people that actually work with a graphical user interface will give some feedback requires. but otherwise it will stay ICTEs

yeah like I have I'm recording this with OBS right now and OBS kind of has that same problem where it just does a lot of things and you can't really hide that information without just making the application less useful Blender has the same problem InkScape has the same problem

to some extent Gimp has the same problem These are all really complex applications and it's really difficult to provide everything a user wants to do and have that be clear without just putting everything inside of menus upon menus and that's just annoying to use. Yes, that's right. In this case, it was one menu. It was not nested menus. It was just one. It was one. It was one. It was one. extra click. That was enough to annoy some people. So people want a beautiful interface, but at the same time people don't want to click one extra time to achieve the same feature. I don't know. I'll solve this. Honestly, I have no idea. I said it in my video. I think the direction the application is going looks good. I think there are definitely areas where it could immediately be improved, like, some padding around things.

And I did notice that the... Padding is probably one of the few cases where people seem to agree. It's about spaces and padding. Everything else, you start to see people splitting. Yeah, yeah. In very different groups. So this is probably what we're going to. is going to be easier to fix, I hope.

Because anything else, you really see that people do not agree with each other. I think at the end of the day with this, though, it doesn't, yes, it's important that people can do what they need to do, but it's not crucial, as this isn't the kind of application that you're always interacting with. one of those things where you set what you want to set and then you just leave it running in the background. I saw some users saying that, but not that people that like the imaginary war between Kiti and JTK take these into consideration. For many years, the ones that were annoyed were the ones that hated JTK.

I have lost out of how many complaints I had to listen. How could you write such an important application? use GTK. Throughout since the beginning, people complained by the fact the application was written in GTK. Now the situation went the other way around. Now the people that love GTK and hate the hate guilty, oh, I will fork the product, I will. It is the same thing.

So there are some situations that you can be in your imaginary war, stay there. After 20 years using Linux, I do not care anymore. Honestly. I just accept that I can't please both of these groups. I will always annoy one or the other. It is what it is. Why, as you said about Electron earlier, you can annoy both of them and use that? This could be a possibility, right? everything in electron and annoyed both sides. If I were not among the people that would also be

annoyed, I would have considered moving to electric. I mean, I love VES code. I use VES code, but I think that people are exaggerating quite a lot when they

write some applications using JavaScript all the way. I don't know. So now that everything has been ported over, what do you have as sort of future plans for the project? Like, where does it go from here? Hopefully not another toolkit change.

Like, that would be a lot of extra work. Yes, I also hope that's not going to happen. For the next month, the next month, definitely, polishing the use interface. If the polishing will place people, I'm not sure. But that's the plan. Maybe additional filters,

depending. I do not have many people working with the factors. Usually we try to add as few, filters as possible. Usually, like I said in some issues before, we try to do as much as possible with as few filters as possible. We have to take consideration maintenance too. Sometimes people ask for different versions of plugs we already have. It's not reasonable. It is mostly, if we look at the last, probably the last four, five years, you will see mostly two people taking care of his effects code.

Besides me, there's digital one. I think she's Italian. And that's it. We can't duplicate functionality just because people want a diversity of plugins. Not enough people to that. So I will consider new filters as long as they do something that can't do well or at all with the ones that are there. So there are some requests about new filters. I would like to take a look.

We have to polish the interface. If possible, I would like to make Q&L use a little less memory, but that may not. be doable, not sure. One user recently asked to extend the alcohol. Our convulter now, right now we do not support through stereo impulse response files. So I'll try to take a look into that too. I think it is doable.

Right now, we only support the stereo two channels impulse response files. So that's something I would like to take a look. And something else that has been needing improvements for quite a while. It is our building guide, our manual. And right now, it is accessing away that I'm not really happy. So right now we are using a So I remember well

WebKit to load it It's essentially a mini web browser Building its effects through an activity Too heavy needs too much memory But the problem was initially I tried to just make the user web browser To load our manual our manual, but then we realized it just would not work in flatback.

And the flat pack is important in his effective history. So I do not want to have a broken feature in the flatback package. So one of the things I have to look at is how to make the manual work in flatback without requiring the web engine view that you could be. provides and we are using now. It is just too heavy. So, it works.

I would say that usability itself is fine, but it is a huge dependence. That it is a lot of memories. So that's something I intend to change at some point in the next model.

I might be mistaken, but I think in the Gimp Flatpack, it can open its documentation in the browser. So I don't know if maybe that's something to see how they're doing it. I almost spoke in Portuguese now. I think that Ginty is loading its website. I'm not sure if it is loading a local web page installed together with the factory.

So we could consider that? to create a website somewhere with the manual and it just, it's just that there is a, I mean, there are mixed feelings among developers and users about not having an offline manual. So going full online and this means that without connection, no manual. Yeah, yeah, yeah. So we have to make a decision about this. if we are just going to go full online or trying to make the offline manual work with flatback. I'm not sure what we will have to do.

I'm sure there's going to be a lot of discussion about the different approach. And I'm sure no matter what you do, like you were saying before, someone's getting complained about it. Ah, well, it's not valuable. I think that for now these are the main parties I don't remember now if there's more

Going back to something about Kiragami One of the things I find very interesting in It's a big difference between the KDE space and the Gnome space In the Gnome space There's this big push for everything

To be Libid Wader But I've spoken to KDE devs that hate Kirigami and want nothing to do with it and would rather build applications through some other means. And this has created a problem in the KDE space where there's like four or five different ways to make an application. There's like definitely problems there, but it definitely gives you a lot more sort of flexibility in the way you want to go and build something.

Yeah, it does. I have much follows what is happening. between KD developers about PyriGyGyGAMI specifically. From my point of view, I'm using it like I use any other library. There are some things it does for me. If it stopped doing, I will find my own way. That's it. Not much problem in that.

For example, although not fully functional, it does some interpretation. there's some integration when it comes to application appearance, famous in the other desktop, that obviously I would have to take care of this myself if I do not use it. So I really want to avoid having to write my own code to interact or deal with user customization. So I personally don't have a problem. in not using it as long as there isn't a lot of things we have to re-implement out of nowhere on our side. So we don't have a strong feeling about this. The last time I looked at this, it felt to me that the KDA develops that they did not like it were more in favor of the traditional

we get what's fine if they prefer this way i'm not sure about how it is the feeling among the ones that prefer kill and yell if it is also every library has its shotgun so it's not like pyrgyam is perfect as long as it provides what i need to do you not see much problem Over this whole conversation, I think the thing that I can say very confidently is you're not very attached to the tools you use. If something you're using just stops doing what you need, you're like, okay, time to find the new one then. Yes. I do not share that dispassion, let's say, that some people have there. I take the tool that's going to make my life easier.

Like I said before, I used to get on when KDE stopped working properly. Seriously. I'm not going to walk around with a broken system that can't... We're using multiple monitors when I need to use multiple monitors. If it's not working, it's time to move on. So I do the same thing with the libraries. At the moment, pipe wire decayed better than post-order. I stopped using post-order.

It's the same idea anywhere else. If Kigarmy, Sondel is becoming horrible. Well, Falky, OMEL, it is. I hope that's not the case, but I would like to benefit from what is being improved on KDE side, but something unusual happens. That's the advantage QT has over decay. It has a much broader landscape. So it is not dependent on what happens in KD.

So if there is a disaster in KDLAND, QT will survive this disaster. So I do not explain. they need to go away from it. Let's talk. They seem like they're doing quite well right now, so hopefully nothing changes into the future. So if people wanted to help out with easy effects, where are some areas right now that you feel like are kind of underserved? What do you think needs the most help in the project?

Um, looking. To what is in place right now, Graphical Interface is definitely top priority. The features that users request that require changes in backend are really tough to do. I'm not sure if they will ever be doable. For example, for many years, users have requested

the ability to apply different filters to do different applications. More or less what the API does on Windows. That requires a complete changing this effect. It's not an additional, the whole application has to be rewritten for that. Because right now we have one effect pipeline and we redirect to it. So if now the idea is having multiple different white lines, naturally the user interface has to allow this to be configured somehow. So the whole mess that the interface is right now will become worse. And on top of that, probably there will be people that do not need this level of control

that we want the current way to be able to stay. So try to imagine design and design. user interface that will do what is done about, but at the same time allowing one different pipeline for each other application to be. The issues are still open there. I do not want to close it. Maybe a solution will be found someday, but I do not see this happening in times. But in the past, I also thought that dragging filters around.

to change the order, would not be doable, it eventually became doable. So there was something else people also was to do that. It was in certain multiple instances of the same filter, for example, having multiple compressors. It took a long time, but eventually it became possible to do that. That was actually one of the advantages of moving to pipe wire also. Doing that in G streamer was incredibly harder. So once we moved to pipe wire, instead of multiple instances, moving filters around in the pipeline,

became a lot easier once we moved to pipeline. It's not impossible. I think one of these two we did in G stream, but it is a lot harder to do this. So there are some features we have now that seem almost impossible. So that's why I did not close this issue yet about different facts for different but this one, different from the others, it will require immense changes to the graphical use interface. I do not see how this could be done with the interface IZH is now.

The other major feature that this may be, if someone is willing to put effort, it would be more doable it is related to being able to load arbitrary plugins we target very specific filters because I've said before we we try to do as much as possible with as less as few filters as possible some people would like the freedom to do to put there whatever plugin right loading they want what would be really cool. It would be really nice to be able to do that. But it kind of

it was one of the restrictions you have when you do not intend to become a full digital digital audio workstation like Ardor. Yeah. Yeah. Yeah. That was never the point. It was never. I'm not a musician.

I'm not an audio engineer. I do not need a full digital audio station. Most of the people that contributed to the approach also do not. And probably for many users, the complexity would not necessarily be welcome. I think that is a fact is in a place that it needs to be. Linux already rise for digital audio workstations. So I see that some people would like us to become one. But it would still be cool to have the ability to load multiple different filters.

But for example, our preset is framework is not going to play nice of this. It will be a big challenge because it is really handy-repping specifically for that. Major changes will be required for that. Our preceptors are not designed considering the idea that we'll suddenly load. We write a custom interface before in JETK now in KML for each plug. What are you going to do? We will do that for the arbitrary filter the users putting that too. So it is not going to be easy.

If there's someone that wants to slowly prepare the code base in this direction, I'm not against being able to do that. I just do not see this being easy to do. It will be incredibly hard to support you. One user recently even suggests, it would be nice if it could use that, which is very common Windows, which is VST. Yeah, yeah, yeah.

Yeah, there are users that you want to use a VST plug there. I mean, it's not going to be easy. Yeah, I saw an issue about hosting external LV2 plugins from a few years back. Yeah, it is exactly that. But again, in the past, we were not able to load native windows that come know if the filters and now we can load some of them. So maybe things will change by it, but it is not an easy thing to do. So I do not intend to work on that right now.

There are other things that I think have higher priority. But it is a place where someone could help to improve things if they are willing to do. expect a lot of challenges than that. But it is needed. But it kind of feels like a big scope creep on the application. Yes. I'm not sure if it is almost like becoming a full digital workstation. What isn't really the idea.

the idea, that's the problem. It would bring the application to a level of complexity that. It could be hidden behind a configuration option, obviously. So, I don't know. No, I understand the hesitation there. Like, especially if you're not, if it's not functionality that you would be using, it's like, it's hard to justify. wanting to work on it, especially when a lot of the users aren't really asking for it.

It's one or two people here and there. Yes. It is a very specific group of people. The feeling I have, it is a group of people that want to do more serious work involving music creation, but do not want to deal with the jet silver. So they want to do this in pipe warrior, but without the jack in the middle. Although pipe wire can replace nowadays some of what jack there. So I don't know.

I'm not sure exactly why they want such a higher level functionality in an application that is essentially created to apply global effects in just that. Maybe there are VST plug filters somewhere they really need to use for some reason. I'm not sure. I don't know. I'm not a guy who's doing audio production stuff, so I could not tell you what they're looking for. So when it comes to the UI change, have you paid much attention to the complaining that people have been doing? The people that open issues, yes.

The random deal is at the web, sometimes when I want to laugh a little. That's so honest. By the way, when people open issues, I try to read it well, consider what you can ask if it is doable or not. Obviously, if someone comes asking, I could go back to the gate?

No, obviously it's not. not going to happen. But depending on what it is, I'm very open to suggest. Like I said before, most of what is affected does. It is not because I felt the need, but because people ask and it was doable. So obviously, if there is something that it is doable and it is not going to require that I give up my work to pick my life. entirely to maintain that. Yeah, as well, I can't see that it's not a big deal. The problem is that sometimes people are not reasonable. They really expect that someone working his free time

will suddenly maintain something that is not being enjoyable, that is complicated to maintain. I mean, there has to be a compromise. As long as I should say something reasonable, reasonably easy to do. And to maintain, that is important. There's no point in just throwing something there. Yeah, now it's broken and what?

So it has to be something that we can maintain, like I said before. If we look back at the last years, it is essentially me, an Italian woman. A few collaborators more interested in make reflect back working and that's all. So we have to take into consideration our limitations when it comes to the number of people.

One person, two person. We have to look at what is being asked and evaluate if it is something that you can maintain working as time goes by. So as long as it is something like this, no problem. The web is always fun. People think that there is some magic button that you... Especially when not many people are actually willing to help with testing. Moving from GTK to KD took more than one year. Very few people actually helped with testing.

And it was quite clear that there was a very big buy. among the ones that were testing. Mostly Art Linux users running KDE or GIMON. And obviously, when people that are using other desktops, other distributions, got the application, new issues, starts up here. There's no way the difference of that, solve that,

if people do not study it. It was a situation where we We're going slowly, hoping that people would test, and the users were waiting for its effects to get to their repository. At some point, when we polished as much as we could, I decided to make a release. There won't be more people coming here to test. Some situations are just impossible. One guy who reported a few days ago an issue involving the army architecture.

I do not use the army. How the hell? To know that something is broken in the army. No way. Another issue that is hitting lots of open-suse

users is related to open-sise decision to put a release candidate to the next pipeline version. Not true. Why they decided to do something like Jesus 50, even archimonyxed didn't do that.

And unfortunately, for some reason, that release candidate is broken when his effects is running for the vast majority of open-souza. There was one or two that said, ah, for me, it's okay, but most of them, these effects with this release candidate, no other. I don't know. They did not have time to investigate. So there are some situations. Usually, we have problems with users in distributions with super old packages.

This time, OpenSuse innovative with super new packages that are not even considered stable yet by PactWAR develops, and it is in the stable OpenSuse repository. There was a flood of user reporting. I have no award anymore. I have no water anymore. And when you look at the version, yes, it is again the release candidate for the next.

I'm not sure why they did that. Okay. Yeah. There were a few cases of Zorin. Not sure how the distribution is called. Yeah, Zorin. There were some Zorin users. But in this case,

it was the usual problem of having very, very old particular release. This is like new. It is also horrible that in 2025 we still have distribution using such an old-unold pipe wire releases. But this is the more usual situation. Having problems with people using release candidates is something new. That I was not expecting. I was expecting the other because when we moved to QT, we had to switch.

the FlexPact runtime, what came with the need to use a newer pipeline release. So these issues, Zordi users had, I was expected because we tried to keep compatibility with that super old pipeline release as much as we could. Eventually, it was not possible. We had to switch for a different runtime. I think that there were also other problems not involved in pipeline that made keep compatibility with that release a nightmare. So that is an issue I was expecting. But people using release candidate in a stable repository, no. So these combinations are hard to deal with because most of the people involved in these

effect development uses either KDE or genome. And most on Art Linux, maybe one uses Fedora, not sure. So whenever it affects goes through a major change, and this new version goes to someone uses, using a completely different environment. All things considered, it's not as bad as I was imagining it would be. Most of the noise is the usual war between the Kielke. I mean, considering how much has changed it,

it has been mostly a smooth experience. I mean, I can control people's passion. Well, you said you've been using Linux for 20 years, so I assume basically nothing has changed when it comes to the, the war between GTK and Q? No. It is really tiring in this situation. This imaginary war between GTK and the QT

and between client-side decorations and the server-side decoration that in a way involves the two two kids again. It has been since forever. After two decades using Linux, you started to lose patience, patience with this. Okay, just do your thing.

It is really annoying, really annoying. And unfortunately, it is something that does not seem it will change anytime soon. Definitely not. It is probably going to stay this way. It is what it is. I do not have any problems. Some TDE users probably will hate me for what I'm going to say, but I actually like client site decorations.

I do not have any problem with it. Honestly, I'm okay. I'm the kind of guy that is okay with how Gnomi looks. I'm okay with how KDE looks. I'm okay with client site decorations. I'm okay with service site decorations. I don't know. Maybe it is what was left from the Windows user

me. I mean, my last Windows was Windows 98. It has been a long time. But maybe that is something, I don't know, this is the moment where I'm kind of like a Windows user. That's not just there, I use it. That's all. Of course it would be nice. So if all programs were integrated with your desktop, unfortunately, I do not see this happening.

see this happening anytime soon. I don't know. Some people have the highest expectation about the unit project that KD develops are doing. I'm not sure. If that will be some kind of magic bottle.

That's at least the plan? I don't know. I know they're putting a lot of work into doing the whole union thing. I don't know how well it's going to work. It's still kind of a while away until we really, see it manifest.

Yeah, I also have not followed this, so I'm not sure how well this is going to be or not. It is a tough problem to solve. People wanted the application to just suddenly look like everything else in the desktop they are using. But unfortunately, we do not have this level of cooperation between the two kids. And to force this level of cooperation to happen, you would need the kind of control that Apple has on macOS. It is not there. So honestly, I just accept the whole situation. I used the KDE applications when I was okay, and I used genome applications when I am in KDE.

Honestly. But I know that most people do not feel this way. Well, I'm running a window manager right now, so I kind of just use the applications I want to use. I don't, I'm not really tied to an environment. Yes. I can't remember the last time I used a window manager. Maybe Flux Box? I don't know.

I used the Flux Box at some point in my life when I was a Linux beginner. I like the year too. I'm not sure why I stopped using it. I know that at some point I went to KDE and stayed there for a very long time. If I remember well, I was using the controversial KDE for while writing my master's dissertation, if I'm not mistaken. A long time ago. I started on KDE3, use the 4, use the 5.

At some point in plasma 5, I moved to the non. And back to KDE now, the few years. But window managers, I think, flux box was the only one. XFCE I used for some time along the time ago. but sure for how long. But most of that time, it was Z the KDE or the non. Yeah, that makes sense.

Like, if it's not, like, it's a good desktop environment. Like, they're both good desperate environments. I know people will argue about, I want to use this one or that one, but, well, look, they're both really long-running projects. They both clearly have, like, they both do things really well. that's why they've been around for almost 30 years now. It makes sense. Yeah.

Well, it has been a fun episode. I enjoyed this. Yeah, it was fun to speaking English after more than 15 years. I guess it was not as bad I was imagining it to be. Yeah, I don't think anyone would have guessed it had been 15 years with how that went. I think, I think, like, it went really smoothly. Yes, yes. Well, I was at some point, I'm not sure.

When I was starting my PhD, was probably the last time I actually talked to someone in English. Not many reasons to do that in Brazil where I live. I listen to English content, quite often, but talking, but talking, not. for me. Right, right. It is, I still remember enough, so it's okay. So if people want to, I guess, we'll do some sort of outro here.

If people want to get involved in the project, is the easiest way just to head over to the GitHub and just get involved? Yes, definitely. Yes, definitely the easiest way. It's just to open an issue. to get heard. Or like in some cases that happened in the past, people already came with patch.

For example, one of the filters, the standards we use, how the hell you are pronounced that. Vlad S-P-A? L-A-B-S-P-A-L-A-B-S-B-A. Oh, um. I don't know. But actually, the one that provided support for this kind of filters, it was not me. Someone came out of nowhere with the whole thing already implemented.

It was just merging and move on. So that's that. Sometimes this happens, things like it happens. Someone had to raise the solution and just come with the full request and do it. But if the person prefers to first discuss, that's definitely the best place for that. Also, you do have a bunch of donation things on the GitHub as well, if people want to support that way. Oh, if people want to support that way, it was always nice, although,

I mean, it's not to the point where I can live in my work and do only that. But yeah, it is nice. I don't know. I'm there to see some money coming, but it is just a small thing that it does not make. I still have to go to work, as usual. Is there anything else you want to mention? Not sure.

Anything else? Maybe have patience. people take it easy, but I'm not sure there's anything else to say. It's okay. Well, I guess I'll do my outro and then we'll sign off the episode. So my main channel is Brodie Robertson. I do Linux videos there six-ish days a week. Sometimes I stream as well.

I've got the gaming channel, Brodie on Games. Right now I'm playing through Silk Song and Yakuza 6. And if you're watching the video version of this, you can find the audio version of basically every podcast, platform and the video version is on YouTube. How do you want to sign off the episode? I'll give you the final word. Oh, it was a pleasure being here.

Like I said before, quite a long time without talking English, so it was a fun experience. I hope this clarifies a little about the people that are really raging right now, what was as happy or not. And, like I said before, people willing to contribute in some way are welcome on the third page. Provide some feedback or things like that. Awesome. I guess so just end the recording then.