{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidzoogujvo6r3kdemul4kbyurgrxfyzuyvnhiyfnnhq6wcjs6ltbm",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3ml5rltujbi62"
  },
  "path": "/viewtopic.php?t=33412&p=273536#p273536",
  "publishedAt": "2026-05-06T02:50:38.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> I don't follow XFCE development, but Google AI says a gtk4 transition is uncertain. They don't have a native Wayland solution yet (only third party compositors). Gtk4 actually removes some X11 functionality. It's a terrible toolkit, only useful for mobile UIs.\n\nWell, if we're being honest here, Wayland in general is terrible and more designed for mobile UI... but mainstream Linux is adopting it whether we like it or not, and I guess what I'm trying to say is that I'm not eager to see UXP get fully \"legacy-binned\" on Linux after 2030 due to its toolkit, if you know what I mean. The one thing that might keep GTK3 viable longer than expected is the fact that some popular forks of GNOME are using it, and it already has Wayland support, but... well, we'll have to see.\n\n\n> Concerning toolkit the answer is easy. Gtk3 all the way in the next 5 to 10 years. When Qt 7 is released then Qt 6 becomes attractive (as a stable target). Gtk4 isn't a realistic alternative IMO.\n> I don't think you have to worry about Wayland. XWayland will always be around even though Wayland users might not want to use it.\n\nHmm... well, I would believe 5 years, though I honestly want to have a successor to GTK3 lined up by 2030 just in case. Like, if we could be 100% sure GTK3 would get security updates well into the 2030s, maybe even into the 2040s, ensuring distros will keep shipping it, then we might even consider trying to do Wayland support on GTK3 at some point (probably after 2030), because I suspect it matches up with what MATE/XFCE/Cinnamon will be doing if their current direction holds and they _don't_ pivot to GTK4 for Wayland. But if GTK3 will be dead by then, and those projects will be doing GTK4, then it might make sense to grudgingly do GTK4 as a Wayland-only toolkit (but only if for whatever reason SDL and Qt are ruled out as long-term strategies).\n\nI guess I need to come clean about what's going on my mind. The fact that the GTK2 fork people came to our forum specifically looking for support, even trying to sell us on becoming their embedding engine and wanting us to hitch our wagon to theirs worries me. Some would see a life raft, but I see something more like... vultures circling overhead. If you get the metaphor? Even if I don't love GTK4's mobile-looking UI (as you put it), or Wayland's lack of features... I'd still rather work like a dog to implement that ugly compromise with my own two hands, than put my faith in the hands of small one-man projects trying to keep stuff dropped by mainstream distros alive, and thereby accept UXP being legacy-binned in a way that may be hard to recover from. Do you get why that actually makes me feel uneasy about what people see when they look at our project, if I'm getting the bad feeling someone looked at us and saw an opportunity to entrap us, and make us dependent on their own personal brand of legacy support because they see desperation, rather than helping us move the project forwards so it can run on everything rather than _just_ legacy-oriented systems?\n\nThough, given that we already have a preliminary Qt6 port and a preliminary SDL port kind of ready, we could probably clean up and press one of those into service if worst comes to worst... maybe GTK4 specifically isn't something we'll have to bite the bullet on, even if we do have to move to _something_ eventually. I do think I could make it work... but again, it would involve enough widget overrides and hand-written replacements for libadwaita that it would be almost halfway to writing my own widget toolkit for UXP. Plus, people might not be happy with it because I'm sure I could make the result look \"okay\" with custom themes, but it probably wouldn't integrate well with people's system themes since I think libadwaita and GNOME integration would be needed for that (and I'm sure no one would like the results of that).\n\n\n> Fedora is a bleeding edge distro upstream from RHEL that aggressively drops older technologies to reduce their maintenance burden. Fedora's decisions may or may not influence the decisions on the Debian/Ubuntu side; Debian and Ubuntu aren't testing grounds for anything, they are the product. Fedora is dropping Xwayland, Debian/Ubuntu/Mint don't have to and may not. And your users (with some notable exceptions) are not using Fedora.\n\nHmm... I don't think Fedora is dropping XWayland any time soon, or at least I haven't heard any officially announced plans along those lines. I get why you think they would do it sooner rather than later, though. RHEL has enough enterprise customers with old X11 applications to keep XWayland around for a while. So I'm not... terribly worried about that, at the moment. Fedora is a little faster than some, but it's pretty far from being bleeding-edge like Arch.\n\nThis can be a tough discussion to have sometimes, because... it feels like there's a lot of pressure to just accept the \"old stuff celebration legacy bin\" and not fight it even a little so that we can be sure of running on mainstream Linux in 5 or 6 years? Like... yes, I get that that stuff exists. Yes, I get that we can continue to support it easily. But I do not want our project to be wholly dependent on random forks and generosity of distros slightly more forgiving than Fedora (that usually go the same path just five years later after some internal drama anyway). That just... doesn't seem like a very logical direction to me.\n\n* * *",
  "title": "Browser Development • Re: Linux Pale Moon with Qt toolkit",
  "updatedAt": "2026-05-06T02:50:38.000Z"
}