Use gtk4 for linux desktop

@robert-ancell

Use case

Currently linux desktop flutter apps are created with GTK3. GTK4 brings border-radius to the bottom windows and a bright window border in the dark theme. It would be nice to benefit from these visual changes in flutter linux desktop apps

Proposal

Upgrade the linux desktop flutter apps to use gtk4 or add a second option to create linux desktop windows with gtk4 instead.

Thanks in advance

CC @robert-ancell

Are GTK3 and GTK4 interoperable—i.e., can a GTK4 app use GTK3-based libraries?

If so, it should be relatively straightforward for someone to do this themselves in their own app just by altering the template-generated runner (which is something we expect developers will do in general), and then it's just a question of when/how we want to have it in the template.

If not, this would be a major undertaking involving engine work, various tool changes, and substantial impact to the plugin ecosystem.

@stuartmorgan

@stuartmorgan

My experience is limited here, I need to forward this question to Robert.
There is a documentation how to migrate to gtk4 here:
https://docs.gtk.org/gtk4/migrating-3to4.html

Yes, I saw that, but it doesn't appear to answer that question.

"Using GTK 2/3 and GTK 4 in the same process is not supported"

https://github.com/GNOME/gtk/blob/80a8b59f2480e5e7b73959c158d94de89661379b/gtk/gtkmain.c#L482

That's unfortunate; that will make this quite difficult. It will need a design document for how the transition will be managed across the ecosystem, taking both existing apps and existing plugins into consideration.

GTK 3 and 4 are not interoperable. The main issue is plugins, which could be using any GTK3 API that may not exist anymore in GTK4. I see we have the following options:

Keep using GTK3 for as long as possible. This is what has traditionally happened for systems that are just using GTK as the means of opening a window. For example Firefox kept using GTK2 for a long time. This creates a future issue to do a migration when GTK3 is no longer supportable.
Leave it to the app developer to modify the runner themselves. This is reasonably easy to do if you're not making heavy use of plugins, and perhaps we can put some flags in the CMake build files to make this easy (with appropriate warnings).
Provide an option to the Linux runner to choose GTK3 or GTK4. Plugins would then check this flag and adjust their code if necessary or generate a build error if they can't support GTK4. I think this is the most practical solution.
Make a second GTK4 runner, with a new plugin ecosystem. I'm not recommending this.
Switch to GTK4 at some point, and require all plugins to update. I'm not recommending this.

The engine itself uses GTK though, which means option 2 doesn't work unless I'm missing something. And option 3 will require us to build and ship two copies of the engine.

The engine itself uses GTK though, which means option 2 doesn't work unless I'm missing something. And option 3 will require us to build and ship two copies of the engine.

Ah yes. I had thought about that previously but then forgot about it :) Yes, I think we'd have to build two engines, and the runner choose the appropriate one. I guess that's do-able?

Without knowing anything about how hard it is to port flutter to gtk4 but my guess is that the apps made for the linux desktop are kind of rare currently, maybe this is still a time to make the switch even if it breaks some of the current linux desktop flutter apps.

Without knowing anything about how hard it is to port flutter to gtk4 but my guess is that the apps made for the linux desktop are kind of rare currently, maybe this is still a time to make the switch even if it breaks some of the current linux desktop flutter apps.

GTK4 is reasonably new and not yet widely available. In Ubuntu, it was first available in 21.04, which means the first LTS release will be 22.04. We really couldn't drop GTK3 support until that is the oldest supported LTS release, as that would mean people on older versions of Ubuntu couldn't run Flutter apps (well, they could via snaps of course). I would expect a similar timeframe for other Linux based systems.

As part of the multi-window work I was looking at the GTK4 window APIs. It seems we are not able to make popup windows in GTK4 (it has specific widgets for this but we want an empty window with Flutter content). So this may be another blocker to supporting GTK4 in Flutter. The design direction of GTK is that it is an application toolkit, but we're really using it as a platform library. This is an understandable position by the GTK developers (they don't want to support every use case) but it suggests that it might not be a good fit for Flutter. I expect this may only get more complicated in later versions of GTK (e.g. GTK5).

Oh, that sounds tricky.
Is there a possibility to include the rounded window corner "tricks" from the Handy window package directly in the flutter repo?

The goal is definitely you shouldn't need Handy window for basic things like this.

The goal is definitely you shouldn't need Handy window for basic things like this.

Sounds promising. Yes this is the only reason this package exists. :)

It seems we are not able to make popup windows in GTK4 (it has specific widgets for this but we want an empty window with Flutter content). So this may be another blocker to supporting GTK4 in Flutter. The design direction of GTK is that it is an application toolkit, but we're really using it as a platform library. This is an understandable position by the GTK developers (they don't want to support every use case) but it suggests that it might not be a good fit for Flutter. I expect this may only get more complicated in later versions of GTK (e.g. GTK5).

Sounds like a communication issue. Has this issue been raised with GTK developers, where is that being tracked?
Do we need a popup window? In gtk those are pinned to the parent window. Can't we just spawn a new window if we need one?

I've been continuing to work on GTK4 and will be pushing a update soon. It will be a very big PR, but I've been strategically stacking commits so my initial mega PR, can be split up into less risky incremental reorganizations and compatibility systems to move us forward.

As a follow up to blocker I previously identified. the build environments sysroots version of GTK 4 would be a limiting factor. Flutter currently uses a Chromium sysroot build environment which is primarily Debian Bullseye, with GTK 4 hacked / patched in from Bookworm.

For reference these are the versions

Bookworm: 4.8.3+ds-2+deb12u1 (What is currently available to flutter which lacks some API's we want, but does work)
Trixie: 4.16.12+ds-1 (Potential upgrade to further our efforts to get solid GTK4 implementation)

I have been able to figure out how to make a Trixie based Sysroot for Flutter, and it is working. So might be worth investigating if it has anything to help with popup windows. I will try and port a GTK3 popup example to GTK4. I personally haven't used popups yet, but I have ported 3 of my personal applications to GTK4 and seems to be fully functional.

The sysroot is obviously some scope creep, and will need a separate issue. It's a bit more complicated because sysroot is compiled from chromium repo, and the build artifact is referenced by Flutter and auto downloaded on demand. If anybody has guidance on how to propose a sysroot upgrade, or why using such old version. I assume it relates to backwards compatibility so Flutter can run on older operating systems / Glibc. Is there a policy on how far back Flutter needs to support, or just copying Chromium?

You can find my chromium source for building trixie sysroot here

https://github.com/richyo-codes/chromium/tree/trixie-sysroot-glibc-fix

If you don't want to build it yourself I made a gist of a patch for flutter to use my pre-compiled sysroot I uploaded to a public bucket (obviously do your own due diligence before trusting my binaries)

https://gist.github.com/richyo-codes/eed91b795925f091299ebedcd891412c

Stand by for some updates to my GTK4 Draft PR, and will look forward to discussions on how to move forward.

If I was to propose a minimal first PR to move towards supporting GTK3 and GTK4 in same tree it is something similar to this
master...richyo-codes:flutter:gtk4-compat-trixie

It is essentially the cherry picks of all the #include fixes, GTK3, 4.8, 4.12 Shims, Accessibility compatibility, Glib Compatibility I've gathered in my Flutter GTK 4 journey. (Might need a few more)

If we want to land GTK 4, we got to eat it once bite at a time, because it's a big change. This would put in the plumbing to keep GTK 3 working, while having the bridge to GTK 4.

For the longer view I have a big Mega PR / branch of a functional GTK 4 system, but continuing to need improvement to reach full parity, but also start to take advantage of the improvements in GTK 4 like decorations, accessibility, rendering, vulkan etc.
#186594

I don't really expect it to be merged as it, I'm just looking to get CI/CD testing and review to push things forward. Then my ideal workflow would be to just keep pushing the GTK bleeding edge , and as it matures we can keep cherry-picking compartmentalized patch sets and merge to master and rebase.

Unlike the previously shared instructions for an older GTK 4 branch that required passing --gn-args="use_gtk4=true.

A key improvement I made was that the build support for both by default

libflutter_linux_gtk.so - for GTK3 compatibility preserving original file name
libflutter_linux_gtk4.so - new GTK4 build that can be opted in via linux cmake runner template

This allows us to continue to default to GTK3, but be able to opt into GTK4

You can read docs on how I implemented selection of GTK version via runner templates, and exposing various config flags.
richyo-codes@b780d0b

In regards to GTK3, GTK4 related package & plugin compatibility. I have forked a few projects to add GTK4 compat while keeping GTK3 working as normal to demonstrate a solution of how package compat can be supported.

I am relatively new to the Flutter community, but I've joined the discord if anybody would like to discuss there. I imagine communication will be key to getting something like this landed and your interest keeps me motivated to keep publishing my progress.

@robert-ancell

@robert-ancell

As part of the multi-window work I was looking at the GTK4 window APIs. It seems we are not able to make popup windows in GTK4 (it has specific widgets for this but we want an empty window with Flutter content).

I found your flutter_multi_window_ffi_test project and forked to
https://github.com/richyo-codes/flutter_multi_window_ffi_test

I then made proof of concept modifications to show popups that work identically in GTK3 and GTK4.

I'm sure there is more to validate and improve with pop ups, but this indicates to me it isn't a blocker.

The design direction of GTK is that it is an application toolkit, but we're really using it as a platform library. This is an understandable position by the GTK developers (they don't want to support every use case) but it suggests that it might not be a good fit for Flutter.

My understanding is GTK3 was designed in age of X11 and Wayland was after thought.
GTK4 was designed for Wayland and adjusted / removed API's that no longer work or make sense in Wayland's philosophy, security model and protocol. So while this API change is major I don't know if there is a trend that makes it undesirable for use in Flutter.

X11 to Wayland is a one time shift.
I don't know what GTK5 will bring, but GTK4 still provides lots of value and seems like a pragmatic improvement worth doing in Flutter to ditch the X11 baggage.

My PR would allow choosing between GTK3 or GTK4 and continue to rely upon all this existing GTK functionality:

GtkWindow / app lifecycle
main loop
keyboard/mouse events
clipboard
DND
IME where possible
accessibility bridge
settings / theme hints
file chooser / portals

From there it might make sense to find more direct Wayland or platform solutions if GTK4 isn't adding enough value or is found to no longer be best kit for Flutter.

My understanding is GTK3 was designed in age of X11 and Wayland was after thought. GTK4 was designed for Wayland and adjusted / removed API's that no longer work or make sense in Wayland's philosophy, security model and protocol. So while this API change is major I don't know if there is a trend that makes it undesirable for use in Flutter.

GTK was designed from the bottom up as an X11 client with higher level widgets built on top of that. When Wayland was added, that made things a bit more complicated because now you had to make the Wayland parts closely match the X11 based model. With GTK4 this has flipped around and it's being designed more as top down, with the lower layers being changed to a model that works better on different backends and allowing better performance optimization. That does impact us using it in Flutter as there are times we want specific low level behaviors that are no longer requirements of GTK.

The sysroot is obviously some scope creep, and will need a separate issue. It's a bit more complicated because sysroot is compiled from chromium repo, and the build artifact is referenced by Flutter and auto downloaded on demand. If anybody has guidance on how to propose a sysroot upgrade, or why using such old version. I assume it relates to backwards compatibility so Flutter can run on older operating systems / Glibc. Is there a policy on how far back Flutter needs to support, or just copying Chromium?

The sysroot is in scope, as without it this can't be built! It's using an older version because that's what Chromium provides and to change that we'd have to work with the Chromium project to update the versions. We also considered if we could use our own sysroots or something else but didn't progress with that. Supported releases are on https://docs.flutter.dev/reference/supported-platforms, though we were recently talking about increasing those. The general answer is "where the majority of Flutter users are".

It seems we are not able to make popup windows in GTK4 (it has specific widgets for this but we want an empty window with Flutter content). So this may be another blocker to supporting GTK4 in Flutter. The design direction of GTK is that it is an application toolkit, but we're really using it as a platform library. This is an understandable position by the GTK developers (they don't want to support every use case) but it suggests that it might not be a good fit for Flutter. I expect this may only get more complicated in later versions of GTK (e.g. GTK5).

Sounds like a communication issue. Has this issue been raised with GTK developers, where is that being tracked? Do we need a popup window? In gtk those are pinned to the parent window. Can't we just spawn a new window if we need one?

This is referring to a popup at the Wayland layer. I haven't seen a GTK issue on this, but it's not something that application developers are likely to need. There's also the issue that even if this change was made in GTK this would make it even harder to migrate Flutter users as you would require the absolute latest version of GTK which is not present in most platforms people deploy to. There were other GTK features like a11y at the first attempt of GTK4 porting that also had this issue (they should be commonly supported now).

The sysroot is in scope, as without it this can't be built! It's using an older version because that's what Chromium provides and to change that we'd have to work with the Chromium project to update the versions.

My upgraded sysroot testing has been informative to help me experiment the new API's in later GTK releases. However, the reality is we have to build for the oldest OS we want to be able to support. And I don't expect policies on backwards compatibility to change anytime soon.

However, I think there is some hope!

Compile against the oldest supported GTK4 sysroot. Right now this is GTK 4.8
Generate or maintain optional function-pointer bindings for newer GTK4 APIs.
Opportunistically resolve those symbols at runtime with dlsym() or g_module_symbol() if available (User running newer OS)

All the new API's I've identified that are absolutely essential are accessibility related. Perhaps there are some other fringe API's we might need. They all seem additive to the core baseline we get from sysroot, and not in hot execution paths.
So if we want GTK4 in Flutter this is probably only way to do it. My understanding this is fairly common technique, and can be done securely because the GTK 4 shared object is already being loaded anyways, we are just binding additional functions if they are there.

Also, GTK4 supports Vulkan backend but GTK3 not

The sysroot is in scope, as without it this can't be built! It's using an older version because that's what Chromium provides and to change that we'd have to work with the Chromium project to update the versions.“sysroot”这个组件是必需的，因为没有它就无法构建这个程序。它使用的是较旧的版本，因为这是 Chromium 所提供的版本。要更改这一情况，我们需要与 Chromium 项目合作，以更新相关版本。

My upgraded sysroot testing has been informative to help me experiment the new API's in later GTK releases. However, the reality is we have to build for the oldest OS we want to be able to support. And I don't expect policies on backwards compatibility to change anytime soon.我的升级后的 sysroot 测试工作对我了解新 API 的特性起到了很大的帮助，这将有助于我在后续的 GTK 版本中尝试使用这些新功能。不过，实际情况是，我们必须为那些最古老的操作系统进行开发，因为我们还需要支持这些系统。而且，我认为关于向后兼容性的政策短期内不会发生变化。

However, I think there is some hope!不过，我觉得还是有一些希望的！

Compile against the oldest supported GTK4 sysroot. Right now this is GTK 4.8在最新的支持版本上进行了编译，使用的是最老的 GTK4 系统根目录。目前使用的是 GTK 4.8 版本。

Generate or maintain optional function-pointer bindings for newer GTK4 APIs.为新的 GTK4 接口生成或维护可选的函数指针绑定。

Opportunistically resolve those symbols at runtime with dlsym() or g_module_symbol() if available (User running newer OS)如果可用，可以使用 dlsym() 或 g_module_symbol() 在运行时解析这些符号（用户正在使用较新的操作系统）。

All the new API's I've identified that are absolutely essential are accessibility related. Perhaps there are some other fringe API's we might need. They all seem additive to the core baseline we get from sysroot, and not in hot execution paths.我识别出所有那些绝对重要的新 API，这些 API 都与可访问性相关。也许还有一些其他不太常见的 API 也需要使用。这些 API 似乎都是对我们从 sysroot 处获得的核心功能进行补充的，而不是在关键的执行路径中使用的。 So if we want GTK4 in Flutter this is probably only way to do it. My understanding this is fairly common technique, and can be done securely because the GTK 4 shared object is already being loaded anyways, we are just binding additional functions if they are there.所以，如果我们希望在 Flutter 中使用 GTK4，那么这种方法可能是唯一可行的方式。据我了解，这种技术相当常见，而且可以安全地实现——因为 GTK4 的共享对象无论如何都会被加载进来，我们只需要将额外的函数绑定到这些对象上即可。

Maybe you can support both GTK3 and GTK4 desktop backend: For older GNU/Linux desktop using GTK3. For newer GNU/Linux desktop (e.g. Ubuntu 26.04 LTS, Fedora 44+), just check its GTK4 version, if their GTK4 version is above of GTK4.8, then change it to GTK4 automaticly (

@LFRon

@LFRon no need to support gtk3, look at this: #94804 (comment)

And if somebody deliberately chooses not to upgrade to GTK4, that's their issue then. There are some users still on GTK2, tough luck, we can't support them. We should move to GTK4.

@LFRon no need to support gtk3, look at this: #94804 (comment)

And if somebody deliberately chooses not to upgrade to GTK4, that's their issue then. There are some users still on GTK2, tough luck, we can't support them. We should move to GTK4.

Nice, so when this GTK4 backend could be merged on Flutter upstream (

Navigation Menu

Repository navigation

Use gtk4 for linux desktop #94804

Use case

Proposal

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Use gtk4 for linux desktop #94804

Description

Use case

Proposal

Activity

stuartmorgan-g commented on Dec 7, 2021

Feichtmeier commented on Dec 7, 2021

stuartmorgan-g commented on Dec 7, 2021

jpnurmi commented on Dec 7, 2021

stuartmorgan-g commented on Dec 7, 2021

robert-ancell commented on Dec 7, 2021

stuartmorgan-g commented on Dec 7, 2021

robert-ancell commented on Dec 7, 2021

Feichtmeier commented on Dec 7, 2021

robert-ancell commented on Dec 7, 2021

47 remaining items

Feichtmeier commented on Jun 18, 2026

robert-ancell commented on Jun 18, 2026

Feichtmeier commented on Jun 18, 2026

KristijanZic commented on Jun 21, 2026

richyo-codes commented on Jun 21, 2026

richyo-codes commented on Jun 21, 2026

richyo-codes commented on Jun 22, 2026

robert-ancell commented on Jun 22, 2026

robert-ancell commented on Jun 22, 2026

robert-ancell commented on Jun 22, 2026

richyo-codes commented on Jun 22, 2026

LFRon commented on Aug 12, 2026

LFRon commented on Aug 12, 2026

KristijanZic commented on Aug 12, 2026

LFRon commented on Aug 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions