GTK dev, here. Just a couple of notes: - *no icons on menu items*: see [issue 6168](https://gitlab.gnome.org/GNOME/gtk/-/issues/6168#note_2386476) for a possible solution; in general, icons in menus are not helpful [except for very well-known metaphors](https://uxmyths.com/post/715009009/myth-icons-enhance-usability), but if people want to add support for them we are amenable to reviewing a merge request. - *no classic file menu*: that's not at all true; there's a whole [menu bar widget](https://docs.gtk.org/gtk4/class.PopoverMenuBar.html). What's different from GTK3 is that menus are constructed from [a model object](https://docs.gtk.org/gio/class.MenuModel.html) instead of using real widgets. - *no window positioning*: true, since GTK4 (and future versions of the toolkit) is designed for Wayland, and Wayland has no global coordinate system; positioning is allowed only for popup windows, since their coordinate space is relative to their parent top level. - *only CSD*: again, true, because Wayland's core protocol only allows for client-side decorations; of course, you don't need to put additional widgets in a [header bar](https://docs.gtk.org/gtk4/class.HeaderBar.html). - *popup menus require compositing*: true, because X11 is deprecated, and X11 without compositing is just plain broken (unless you enjoy tearing and partial redraws on resize). Nevertheless, you can still use uncomposited X11: you just need to load CSS that replaces shadows with real borders.
GTK4 is trying very hard to be desktop neutral, delegating all desktop-specific UI/UX to platform libraries like libadwaita for GNOME, libgranite for Elementary, and even libadapta for Mint. Any desktop environment with its own particular interface guidelines should spend time working on a platform library, but applications can decide for themselves what kind of UI/UX they want to present to their users. GTK4, just like GTK3, allows applications to load custom CSS for styling, so nothing has changed in that regard. If the main objection is that people want to stick to an X11-oriented toolkit, then, of course, GTK3 is going to be preferable to GTK4; the days of X11 are numbered, but the existence of XWayland pretty much guarantees that X11-specific code will continue to run for the foreseeable future. Finally: GTK3's EOL date is contingent on the release of GTK5 (according to [the release plan](https://blogs.gnome.org/gtk/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/) we published in 2016), but we haven't even started the development of GTK5 as of yet; if we started *today*, and assumed that GTK5 took as long as GTK4 did, we'd be looking at 2030 as the earliest 5.0 release; downstream distributors would take additional time to remove GTK3 from their archives (it took most of them 5 years to do so with GTK2). In any case, that would put the entire 3.0 API series lifetime to about 20-25 years. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/discussions/3675#discussioncomment-14982820 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/repo-discussions/3675/comments/[email protected]>
