Tabbed view doesn't look like latest GTK4 versions

[baco]

When opening files in tabbed view, the GTK4 widget seems to be using some old version of the widget that doesn't honor current looks.

• OS: Debian Sid
• Neovim version: v0.9.0-dev-810+gb8288df99 (nightly)
• Neovim-Gtk build version: neovim-gtk v1.0.1-120-g9b834b6 (compiled from source)

According to some cannon GNOME applications, GTK4 tabs should look something like this: (GNOME Console on the front, GNOME Text Editor on the back)

But currently, tabs in Neovim-gtk's main branch look like this:

[jacobmischka]

For whatever it's worth, here's gnome-terminal:

[baco]

AFAIK, GNOME Terminal stopped being the canon terminal emulator as of GNOME 41-42(? in favor of a simpler one, GNOME Console (not in favor of the decision here, just stating the facts). Therefore, I don't expect support to GNOME Terminal, from the GNOME team, to continue; hence that's perhaps why they never gave the new GTK4 Adwaita tabs to it.

[baco]

For whatever it's worth, here's gnome-terminal:

Furthermore, according to the package dependencies (and supporting my previous answer), GNOME Terminal got stuck in GTK3, it has never been migrated to the GTK4 widget, just recompiled within the GNOME apps.

Here, a video not so old that peeks over those differences: https://youtu.be/4Vl9Do6VB4Q

[baco]

I think the issue is that according to Cargo.lock the app depends on GTK 4, but perhaps what I'm looking for is the use of libadwaita-rs.

Would that be a feature request then?

[Lyude]

I think the issue is that according to Cargo.lock the app depends on GTK 4, but perhaps what I'm looking for is the use of libadwaita-rs.

Would that be a feature request then?

Yes - but I'm honestly very unsure whether it's one I'd want to actually incorporate or not - as in libadwaita's current state there isn't really much of a way to theme it. That's part of the point though, as it's meant for GNOME focused applications. For something like neovim-gtk, I'm not sure we really would benefit a whole ton from doing that vs. the current downside for users that might not be on GNOME - especially when people's usage of the GUI features seems really varied as is (at least from my experience of looking through people's screenshots of their various setups on github issues here c: ).

Also - there might actually be a simpler way of getting the tabs to look like this, possibly some kind of CSS class or GTK+ option. Someone (me? volunteers welcome) would have to dig to see how libadwaita does this with its tabs.

[Aleksanaa]

I think the issue is that according to Cargo.lock the app depends on GTK 4, but perhaps what I'm looking for is the use of libadwaita-rs. Would that be a feature request then?

Yes - but I'm honestly very unsure whether it's one I'd want to actually incorporate or not - as in libadwaita's current state there isn't really much of a way to theme it. That's part of the point though, as it's meant for GNOME focused applications. For something like neovim-gtk, I'm not sure we really would benefit a whole ton from doing that vs. the current downside for users that might not be on GNOME - especially when people's usage of the GUI features seems really varied as is (at least from my experience of looking through people's screenshots of their various setups on github issues here c: ).

Also - there might actually be a simpler way of getting the tabs to look like this, possibly some kind of CSS class or GTK+ option. Someone (me? volunteers welcome) would have to dig to see how libadwaita does this with its tabs.

Thanks so much for not switching to libadwaita! (since it can cause weird look on kde and some wlroots-based wms.)

I think it's still possible to release with libadwaita, though. Refer to https://github.com/diamondburned/gtkcord4/issues/24 and https://github.com/diamondburned/gtkcord4/commit/9db4256d75257b066ba4540c7c59f54d130ac24e

[Lyude]

I think the issue is that according to Cargo.lock the app depends on GTK 4, but perhaps what I'm looking for is the use of libadwaita-rs. Would that be a feature request then?

Yes - but I'm honestly very unsure whether it's one I'd want to actually incorporate or not - as in libadwaita's current state there isn't really much of a way to theme it. That's part of the point though, as it's meant for GNOME focused applications. For something like neovim-gtk, I'm not sure we really would benefit a whole ton from doing that vs. the current downside for users that might not be on GNOME - especially when people's usage of the GUI features seems really varied as is (at least from my experience of looking through people's screenshots of their various setups on github issues here c: ). Also - there might actually be a simpler way of getting the tabs to look like this, possibly some kind of CSS class or GTK+ option. Someone (me? volunteers welcome) would have to dig to see how libadwaita does this with its tabs.

Thanks so much for not switching to libadwaita! (since it can cause weird look on kde and some wlroots-based wms.)

I think it's still possible to release with libadwaita, though. Refer to diamondburned/gtkcord4#24 and diamondburned/gtkcord4@9db4256

Interesting - it sounds like what we might be able to do then is add libadwaita as a dependency then, but try to only actually connect its activation hooks when we're running in GNOME - which seems like it'd be a pretty good compromise for everyone :)

[PolyMeilex]

Interesting - it sounds like what we might be able to do then is add libadwaita as a dependency then, but try to only actually connect its activation hooks when we're running in GNOME - which seems like it'd be a pretty good compromise for everyone :)

While this is an improvement, it will not fix this issue, it will only inject adw CSS, tabs shown in this issue are simply a different widget altogether with additional overview support.

This is how GTK tabs look like with libadwaita enabled:

But yeah, if you want to stay as platform-agnostic as possible, going with libadwaita is probably not a good idea.