Flowblade 2.14 Video Editor Released, GTK4 Port Hopefully Ready Next Year

[ssokolow]

always the same thing, gtk vs qt flame war. nothing new, the question here is this video editor is good or not?

Not a very productive way to say that. Anyone can trivially respond with some variation on "No, because GTK prevents it from being good."

[logical]

always the same thing, gtk vs qt flame war. nothing new, the question here is this video editor is good or not?

Yep, it's pretty much the same bitchfest over and over for any article that mentions GTK/GNOME.

[ssokolow]

Yep, it's pretty much the same bitchfest over and over for any article that mentions GTK/GNOME.

I honestly didn't used to care before they started making it more and more difficult for non-GNOME GTK applications (Inkscape, GIMP, etc.) to feel natural on non-GTK desktops (eg. KDE with the Breeze GTK3 theme), so congrats GTK maintainers. You're making adversaries of people who don't give a crap aside from how it affects their day-to-day use.

[lumks]

And yet GTK 3 is the only version of KDE's Breeze theme that can't seem to turn off the buggy shadows on menus in non-libadwaita applications like Inkscape... and, though I stopped developing for GTK at the 2-to-3 transition because Qt had nicer building blocks, I've seen various other developers lamenting the libhandy-to-libadwaita transition forcing them to either maintain vendored widgets or accept Adwaita theming semantics to get functionality they used to get with non-adwaita theming via libhandy.

Uhm, sure. If they want libhandy widgets in GTK4, they need to port libhandy to GTK4. Libhandy was not part of GTK3, just another library. So what do you expect? Libadwaita is not the succesor of libhandy, but partially inpired by it and granite.

People in the real world care about whether an application is buggy, and those bugs are in GTK, not Inkscape, so they show up in any and every GTK 3 app I haven't yet managed to find a replacement for.

I'm with you on the fact, that bugs should be fixed. But the original context was that something is using GTK and that GTK doesnt support and or implements everything. Thats not a bug, but by design. For example expect the filechooser/dialog to go away in GTK5.

And yet, in the GTK 2 era, there was a lot less duplication of effort because the GTK maintainers were much less rigid about people sharing their effort.

GTK2 era we had like 10 people caring for the entire linux ecosystem of 15 apps.

Again, there's a reason Cinnamon, MATE, COSMIC, and the LXDE→LXQt transition didn't come into existence during the GTK 2 era.

None of them came into existance because of something related to GTK. Also LXDE never transitioned to LXQt. Both of them exist now.

The thing you probably want to say is "It would be so cool if GNOME was about to build and share software with everyone else" And yes, that would be cool, but there is not enough money, time and people to do this. Thats why nowadays GNOME is its own platform. To target and focus on it's very own vision.

[ssokolow]

Uhm, sure. If they want libhandy widgets in GTK4, they need to port libhandy to GTK4. Libhandy was not part of GTK3, just another library. So what do you expect? Libadwaita is not the succesor of libhandy, but partially inpired by it and granite.

They have a funny way of showing it when you see things like this:

GNOME 41 will come with libadwaita, the GTK 4 port of libhandy that will play a central role in defining the visual language and user experience of GNOME applications.

-- https://adrienplazas.com/blog/2021/0...ibadwaita.html

and so Libadwaita is a direct Libhandy successor.

-- https://blogs.gnome.org/alicem/2021/...ibadwaita-1-0/

Libadwaita is being developed as a successor to Libhandy 1.4.

--- https://gnome.pages.gitlab.gnome.org...ibadwaita.html

I'm with you on the fact, that bugs should be fixed. But the original context was that something is using GTK and that GTK doesnt support and or implements everything. Thats not a bug, but by design. For example expect the filechooser/dialog to go away in GTK5.

It's needlessly and gratuitously inconsiderate to the application ecosystem that built up around GTK 2. They made no noises that they were unhappy with their libraries becoming the backbone of so much, so people expect them to act as resonsible stewards of the situation they implicitly encouraged.

GTK2 era we had like 10 people caring for the entire linux ecosystem of 15 apps.

That's so hyperbolic that I don't feel it would be productive to respond.

None of them came into existance because of something related to GTK. Also LXDE never transitioned to LXQt. Both of them exist now.

LXDE is essentially the legacy support branch of LXQt. I was there while they experimented, decided, and wrote wiki articles about the process.

The thing you probably want to say is "It would be so cool if GNOME was about to build and share software with everyone else" And yes, that would be cool, but there is not enough money, time and people to do this. Thats why nowadays GNOME is its own platform. To target and focus on it's very own vision.

See previous comment about the social expectations their behaviours during the GTK 2 era set up. (And no, disputing that with me won't change anything. It's just how the social dynamics work and I'm merely the messenger.)

[lumks]

They have a funny way of showing it when you see things like this:

…

From a GNOME perspective it is obviously a libhandy successor, from a GTK it's not.

It's needlessly and gratuitously inconsiderate to the application ecosystem that built up around GTK 2. They made no noises that they were unhappy with their libraries becoming the backbone of so much, so people expect them to act as resonsible stewards of the situation they implicitly encouraged.

GTK2 was a different time. At that time GTK and GNOME was pretty much the same, that only changed around half way in GTK3 development, when people were unhappy that GTK is pretty much focused on GNOME and was finally changed with GTK4. GTK4 is now essentially the GTK3 design concept at the end and you're expected to use an own platform design library (libadwaita, granit,...) if you want more.

That's so hyperbolic that I don't feel it would be productive to respond.

None of what we talk in here is in any form productive, but just useless noise. It's not a bugtracker and developer also dont like phoronix forums much. You probably know that already.

LXDE is essentially the legacy support branch of LXQt. I was there while they experimented, decided, and wrote wiki articles about the process.

Why do you think an already low on people project would keep up and extent an legacy branch? It's not that either of them has a big userbase to lose. tbh at this point that the LXDE/Qt could vanish over night and most LXDE/Qt distro user wouldnt even notice for years and years.