feat!: integrate libadwaita and its widgets and styles #222
Conversation
|
Oops, completely missed the recipe part, should be fixed with the last commit |
|
Ok, it seems ubuntu 22.04 has libadwaita version 1.1.7 and debian has version 1.2 while this patch requires >= 1.4. What do you think about this? Do you see any way forward? |
|
First of all, thank you for the contribution, it looks like you've put a lot of work into this PR. However, I have some concerns:
With that in mind, I don't think I would want libadwaita to be the default/only choice for the UI. But you've already put a lot of effort into it, and there are several options to go from here:
|
It sure is, and even with libadwaita this doesn't really change
In fairness, libadwaita can still be themed, the same way gtk3/4 can: with unsupported css hotloading. Plus most apps on a desktop look inconsistent: steam, jetbrains ides, wine apps, any browser that's not falkon on plasma or epiphany on gnome, electron apps like element, and qt apps look just outright broken in anything but plasma. gnome apps do look inconsistent in plasma compared to qt apps, but they don't look any less inconsistent when they use the breeze theme on top.
I think this is rather subjective, I think it looks out of place in all desktops, since it uses the old gtk3 adwaita style that only legacy apps use at this point. On the contrary, libadwaita being very flat looks more at home on any desktop
Well, yes, but you don't really use libadwaita for the theme itself. As you can see from the screenshot the real benefit of libadwaita is the vast amount of pre-made widgets that you can just use instead of reimplementing them in vanilla gtk. This of course requires additional styling so having a "theme" on top of the widget collection is basically a necessity, the same way that libhandy (libadwaita's predecessor for gtk3, using the old adwaita style) had additional css shipped with it, and making it look broken on many themes that didn't properly support it.
Yes, this is a problem, but it would be solved by #224 😄
Nothing is written in stone, we can work on design changes. I also thought that the sidebar looks rather empty, and I was thinking that maybe we could have some always important stats showing there, like temperature, clock and fan speed, but that's just an idea.
It's also useful for running the application in a smaller window, possibly having a game running on the main screen, and having something like a chat on a second smaller screen, with a very small LACT GUI on the side. But this is ultimately preference and as I said above we can revert back to the stack switcher, or use a completely different style altogether
In theory yes, but it means basically duplicating libadwaita's widgets and style. This would be an additional, likely unwanted maintainance effort and would make the codebase a lot bigger and messier.
If you really want this, I think that a better approach would be to have parallel branches, I'm afraid having a build flag for such a massive difference (functionally it's the same but the widgets are compleltey different) would make the code a big spaghetti mess. It might be possible to make the two hypothetical versions a little bit closer API wise but that's not necessarely going to make things easier.
That's basically how the situation is right now 😄 My fork is the libadwaita version if you want to see it that way That was a long comment! Hopefully we can keep the conversation going, I'd really want to see this merged one way or the other EDIT: another interesting idea: if you think the GUI is feature complete, you could think of keeping the current one around as a "legacy" version, and having the libadwaita version be the main one. |
This is the unfortunate truth, but that doesn't mean that we need to contribute it. Also, for QT theming there are options to make it fit better in gnome, and there were initiatives to make it part of QT (though I'm not sure about their status)
I disagree, at least they use the right colours and somewhat similar element styles
Having a Flatpak would be nice, but I would still want there to be native packages that include the GUI for LTS distros
I would be fine with this. If you (or someone else) are willing to maintain it, I can give permissions for a branch. There could also be a workflow to build packages and publish it on an alternative release. Doing a build flag using cargo features to conditionally compile libadwaita versions of pages would be fine too if the differences are not that big (ideally it would just be different blueprint files using the same rust implementation) Other approaches could work too. The main thing is that I want the plain GTK version to remain the "main" one, with libadwaita as an alternative. |
Off topic I guess 😅 but I've tried many different options myself, I found no way to make qt/kframework/kirigami apps look anything but broken outside of plasma
Colors in libadwaita can be somewhat non-invasively changed with something like Gradience, and in-app icons are still overwritten by the plasma theme without having to take any extra steps
Unfortunately, as of right now this looks like it's fundamentally incompatible with supporting older distros like debian stable and ubuntu lts. EDIT: maybe another option would be to rely on PPAs or other third party repos, but I don't know if that's desirable or not
I can try and keep this libadwaita version around, but I can give you no guarantees unfortunately, that's why I'd ideally want this merged rather than having it separate. A big refactor to the GUI would probably result in a huge mess of a merge conflict that's gonna be quite hard to solve
Eh, it's probably not gonna happen: there are fundamental differences between the two versions both in widget hierarchy and choice |
|
I changed the navigation to a bottom bar view switcher, I think it makes a bit more sense compared to an almost empty sidebar, while still allowing for an adaptive UI. I will also try to make the new code in this PR a bit more modular, along with other changes I'm planning to the adwaita-less plain gtk4 version, to explore the possibility of having this merged as a feature.
|
|
So, I ended up managing to gate libadwaita behind a cargo feature, so in theory now the pipeline should pass. As you suggested initially, I tried to keep the new style as much as possible without doing too much custom stuff. I'd also like for you to review the actual code, and see if you think there's anything that needs changing. |
There was a problem hiding this comment.
Overall I'm glad that it looks feasible to support both libadwaita and non-libadwaita using feature flags - I think this solution will satisfy everyone
But I think it's worth splitting this into several pull requests - like setting up the infrastructure with the cargo features and package builds, adding some basic widgets, then adding more ui etc. Currently there are many somewhat separate things going on this PR - libadwaita, redesign of the non-libadwaita version, code refactoring/restructuring etc and it's a bit hard to keep track of everything at once
And another thing - after recently adding blueprint file support I've been migrating widgets to them one by one, so currently it's a mix of part blueprint and part in-code ui, and I think if there's a redesign of something then it's a good opportunity to use blueprint for the new/updated component where it makes sense (either for moderately big ui trees or for reusable components, for simple things it's sometimes not worth the required boilerplate)
lact-gui/Cargo.toml
Outdated
| @@ -15,7 +16,7 @@ gtk = { version = "0.7", package = "gtk4", features = ["v4_6", "blueprint"] } | |||
| tracing = "0.1" | |||
| tracing-subscriber = { version = "0.3", features = ["env-filter"] } | |||
| anyhow = "1.0" | |||
| libadwaita = { version = "0.5.3", features = ["v1_4"] } | |||
| libadwaita = { version = "0.5.3", features = ["v1_4"], optional = true } | |||
There was a problem hiding this comment.
I think it would be convenient to alias libadwaita to adw, similar to how gtk4 is renamed to just gtk. Makes it easier to type out full symbol paths
There was a problem hiding this comment.
should be fixed as well
| #[cfg(not(feature = "libadwaita"))] | ||
| #[derive(CompositeTemplate, Default, Properties)] | ||
| #[properties(wrapper_type = super::PowerCapSection)] | ||
| #[template(file = "ui/oc_page/power_cap_section_gtk.blp")] | ||
| pub struct PowerCapSection { | ||
| #[property(get, set)] | ||
| pub current_value: RefCell<f64>, | ||
| #[property(get, set)] | ||
| pub max_value: RefCell<f64>, | ||
| #[property(get, set)] | ||
| pub min_value: RefCell<f64>, | ||
| #[property(get, set)] | ||
| pub default_value: RefCell<f64>, | ||
| #[property(get, set)] | ||
| pub value_text: RefCell<String>, | ||
|
|
||
| #[template_child] | ||
| pub adjustment: TemplateChild<OcAdjustment>, | ||
| #[template_child] | ||
| pub reset_button: TemplateChild<Button>, | ||
| } |
There was a problem hiding this comment.
If the children are the same between different versions, then you can just change the template attribute based on features with cfg_attr
It ended up being more doable than I was expecting fortunately, but as you might expect the libadwaita version is a bit more polished, giving that there are actual widgets with proper implementations to support the new design language. In the long run I think it would be a good idea to just keep one version around, for sake of maintainability mostly. Plus I think that this might very well be a systemd-type situation, where there's some mystique around libadwaita and some people just hate on it since it's different and not what they're used to, even in terms of theming. I think once that's out of the way, and once distros catch up to newer versions of the library, it could be a good idea to drop the plain gtk version altogether, but that's ultimately your decision to make.
Understandable, but I don't know how easy it would be or how much time it could take. To be completely honest while the diff is quite big I think that it's rather readable, mostly thanks to the excellent project structure. I'll see if I can get around to it.
I can agree in principle, I'll see what I can do, but I can already tell you I'm not really too fond of the ergonomics of gtk templates in rust. |
GabMus
force-pushed
the
feat/libadwaita
branch
from
4bdb1a2
to
35fa139
Compare
…features/extensions window
…n to set it as transient for
GabMus
force-pushed
the
feat/libadwaita
branch
from
da66937
to
f8d1f3b
Compare
GabMus
force-pushed
the
feat/libadwaita
branch
from
68ed007
to
336cae5
Compare
|
Some new screenshots since stuff changed since the initial ones. Note that the icon in the about dialog is broken because the app isn't actually installed. Plain GTK
Libadwaita
|
|
Any updates on this? How can we get this emrged? |
|
I'd like to get this merged eventually, but first i need to finish up the packaging in #227. I also have some reservations about the design - I think it would be best if this PR only added the new libadwaita ui, and changes to the plain gkt one would be done separately |
Sure, we can talk about it here, and we can make changes
I understand but it would be a lot of work... |
|
The packaging is done in #227 As for the UI: In the libadwaita version, I like how most of the UI looks. Some of the icons on the bottom navigation bar are missing on my system but that's probably an issue with my configuration. For the OC page, there are some minor adjustments i'd like to have: i think it would make sense to group all of the clockspeed/voltage settings under one category, it doesn't really make sense to have a category just for the warning label and advanced button. As for the plain GTK version, I'm not a big fan of all of the changes. I'd like to keep the headerbar tabs, and i think the current information lists design with less spacing between the items (and also less scrolling) looks better. This is why i'd like the non-libadwaita changes to be in a separate pr - so they can be reviewed one by one. Applicable to both versions: i'd probably want to keep the clocks/voltage adjustments are sliders, so there's a visual indication of the range that the values can have |
Can confirm that they also seem missing on my end when running on my steam deck. It's likely some missing package in plasma, will see if there's anything that can be done about that.
Assuming you mean one listbox, this is what it looks like (sliders are coming back, too, next commit)
|
Should be fixed
Moved the stack switcher back to the headerbar, although this keeps the app a bit too wide IMO. I think we can come up with another solution, like maybe moving the stack switcher to a toolbar under the headerbar? Ultimately up to you.
I would disagree, having all that info smushed together like that decreases legibility without really adding much value: it's static data that you don't really need to keep an eye on, so having it spread out I think makes more sense. A notable exception to this that I kept pretty much the same as the original is this section here:
Having this section more compact does add value: it's real time data that you may want to keep an eye on all at the same time, and that's why I didn't change it.
Also done :) |
|
The missing icon issue should also be fixed, the only thing that I'm not 100% sure about is that I had to install the thermometer icon for the temperatures tab. Unfortunately no built-in icon seems to be appropriate for temperatures, so the two options we have are: a. install our own (that's what I'm doing in the last commit) up to you |
|
Any updates? |
|
I'm sorry, I can't accept the PR as is. It should be split into smaller, incremental changes adding the new libadwaita UI. |
|
@GabMus would u be willing to rebase this on the current version 0.5.1 I would like to add this application to Gnome for Slackware or GFS |
Hello! I took the liberty of integrating libadwaita into LACT, but differently from #214 I didn't just add it to the project, I also redesigned most of the applicatiojn to use libadwaita's widgets and style where applicable.
I think that this way LACT does look better overall and it's possibly even a bit more usable, plus using libadwaita means one doesn't have to reinvent the wheel and can instead just use widgets that are already available in the library, following a consistent desing language.
Have a look at the screenshots below, let me know what you think, and thank you for the amazing work!
Screenshots