{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibwk264yurvvzc3orqahduacwflcf6cybbgvsoqeq7yh7k2i2i6de",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3ml4wqi2hqh22"
  },
  "path": "/viewtopic.php?t=33412&p=273508#p273508",
  "publishedAt": "2026-05-05T18:56:00.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> What I worry about with Qt is that it has fairly quick turnover/deprecation; there tend to be a lot of breaking changes between Qt versions. While that's fine with native UI programs, it becomes more problematic for something as large and complex as XUL interaction in our code.\n\nThat is my fear as well, and why I was considering biting the bullet and doing GTK4 in a few years, even though it would be twice to three times as much work as Basilisk-Dev's Qt port for results that are not guaranteed to be appreciated. If a lot of our users are indeed on XFCE, which is going GTK4... and GTK3 eventually stops getting security updates. Well, that's the situation where I would want to do that. Not because I _like_ GTK4 or think it's a good option, but because doing nothing starts to have a price, and GTK3's main appeal is basically that it gets security updates and distros are more likely to ship it, not that it's the best version of UXP on Linux in the opinion of most Linux users. If that changes, it becomes effectively worthless... not better for NPAPI, not good for old themes, and also unsupported upstream. Which would mean users would shift to GTK2 even more, and pull our Linux support even more firmly in the direction of alt-Linux and old machines. Which means GTK4 (or Qt, or SDL, or EFL, or whatever) would effectively have to take the place of GTK3 at that point.\n\nBut yeah, I feel like Qt changing too quickly is the biggest potential mark against it, because that means going out of the frying pan and into the fire. We ideally want the opposite of that... something that changes slower than GTK but is still focused on remaining compatible with XWayland long-term, if not Wayland directly. I really hope we never have to do a native Wayland port, and I know you don't like that idea either, but in all honesty, if I heard XWayland was going away and it was either do native Wayland or be relegated to distros that still ship custom forks of X11. I'd be strongly considering Wayland. But I would much rather stay on XWayland as long as possible, not just out of laziness, but because I genuinely don't know where mainstream Linux will be in 5 or 6 years. Maybe it will be on Wayland, maybe it will still be split between X11 and Wayland with XWayland as a more permanent bridge than people would have liked, or maybe a third new thing will start being pushed and all the people who ported to native Wayland will turn out to have essentially wasted their time.\n\nThough it's really hard to say which toolkit is better supported nowadays... KDE is supposedly becoming more popular, which could mean better long-term support for Qt versions in the future if more stuff is built on it. Linux is in an annoying state of flux right now... flux between GNOME and KDE, flux between X11 and Wayland, and it's hard to trust anything enough to commit to a direction.\n\n* * *",
  "title": "Browser Development • Re: Linux Pale Moon with Qt toolkit",
  "updatedAt": "2026-05-05T18:56:00.000Z"
}