search

wwmm / easyeffects

Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications
GNU General Public License v3.0
6.62k stars 270 forks source link

Theming bugs #2983

Open LebedevRI opened 8 months ago

LebedevRI commented 8 months ago

EasyEffects Version

7.1.4

What package are you using?

Other (specify below)

Distribution

debian sid

Describe the bug

Here's how global passthrough looks here: (one is on and other is off) image image Clearly, that's not how it's supposed to look, because restarting EE results in: image image So somehow the style for the button was in wrong state.

Expected Behavior

No response

Debug Log

No response

Additional Information

No response

wwmm commented 8 months ago

So somehow the style for the button was in wrong state.

Just the style or the button state was actually wrong? Probably just the style because that damn PipeWire bug about the missing right channel forces me to use the global bypass as workaround from time to time and so far nothing unusual has happened with this button on my computer.

Assuming it is just a theme problem it will be necessary to report to libadwaita developers. We do not play with the themes on our side.

LebedevRI commented 8 months ago

Just the style or the button state was actually wrong?

I think, just the style. It's almost as-if the whole button was selected, i mean like the text can be selected image

If only Qt would come up with a gtk front-end, so it could silently transparently replace gtk :/

ameris1 commented 8 months ago

I'd like for you to consider dumping libadwaita. I don't like being forced to use the adwaita theme. I use EndeavourOS and I have access to the AUR and have installed libadwaita-without-adwaita. Flatpak apps don't have access to that package I guess so I still get the adwaita theme instead of my Matcha Dark Sea which I absolutely love.

wwmm commented 8 months ago

I'd like for you to consider dumping libadwaita. I don't like being forced to use the adwaita theme. I use EndeavourOS and I have access to the AUR and have installed libadwaita-without-adwaita. Flatpak apps don't have access to that package I guess so I still get the adwaita theme instead of my Matcha Dark Sea which I absolutely love.

This is the same as asking to rewrite all our code using another toolkit. What is far from trivial. The problem with gtk right now is that there are some useful widgets that are only available if libadwaita is used. They do not exist in pure gtk.

wwmm commented 8 months ago

This is the same as asking to rewrite all our code using another toolkit. What is far from trivial. The problem with gtk right now is that there are some useful widgets that are only available if libadwaita is used. They do not exist in pure gtk.

I mean. We could try to use pure gtk. But then we do not have some of the facilities provided by libadwaita. Instead of doing such a move it would make more sense to use another toolkit. And in this case the amount of work would be really big.

ameris1 commented 8 months ago

Ok. That's fair. I understand how much of an undertaking that'll be.

Till then, there is a work around to get other GTK themes to work: drop the theme's gtk-3 and gtk-4 folder into ~/var/app/com.github.wwmm.easyeffects/config

Just found this by chance a few minutes ago

Screenshot_20240324_194459

LebedevRI commented 8 months ago

FWIW, personally, i would love for EE to be non-gtk based, but i very much expect that to never happen :) EE is basically the only(?) gtk app i use, and that makes me sad, but not as sad as having to constantly pay the price of braind zombie-like decisions like not supporting system tray...

ameris1 commented 8 months ago

FWIW, personally, i would love for EE to be non-gtk based, but i very much expect that to never happen :) EE is basically the only(?) gtk app i use, and that makes me sad, but not as sad as having to constantly pay the price of ~braind~ zombie-like decisions like not supporting system tray...

Do you use Breeze? Because if you've installed EE as I have as a Flatpak, you can download the Breeze GTK theme then paste the Breeze's GTK-3 and GTK-4 folder into the ~/var/app/com.github.wwmm.easyeffects/config directory and it'll fit your QT theme. You may have to logout and back in to see the effects.

LebedevRI commented 8 months ago

Plain old boring debian sid here, no containerization. I'm aware of themes, that does not solve the system tray issue.

CryZo commented 7 months ago

@ameris1 Thanks for your tip regarding libadwaita-without-adwaita - now EE looks just awesome :star_struck::heart:

medmedin2014 commented 7 months ago

I mean. We could try to use pure gtk. But then we do not have some of the facilities provided by libadwaita. Instead of doing such a move it would make more sense to use another toolkit. And in this case the amount of work would be really big.

By using an unnecessary library dedicated to create only GNOME apps, you locked your app and its future into GNOME ecosystem, this will always make it hard to use EasyEffects on other Linux desktops, especially with the fading of GNOME as the popular Linux desktop. And don't even be surprised for what it's coming from those closed mind devs.

wwmm commented 7 months ago

this will always make it hard to use EasyEffects on other Linux desktops

Although I do have plans to port EE to Qt I have to disagree with this at least partially. I have KDE on my desktop at this moment and the usability is mostly fine. Sure it looks like a GNOME app and has no tray icon. But it is not like EE is always broken outside of GNOME for all users.

By using an unnecessary library dedicated to create only GNOME apps

That is also not entirely correct. There are useful widgets that do not exist in pure gtk. So it is not an useless library. And to some extent having one desktop as main target is not a problem. Something similar happens on Qt/KDE land too. The main problem with libadwaita/gtk/gnome is they deciding to ignore the existence of other desktops/toolkits...

LinuxOnTheDesktop commented 1 month ago

Hello. The immediate problem here is that some users (including me, using 7.1.6-1ubuntu0.24.04.1 on Linux Mint Cinnamon) - or, hold on, is it all users? - cannot tell whether an important setting (viz., the global bypass) is enabled or not. Surely this can be fixed. If the icons at issue are problematic (in that, er there seems to be only one of them), then can't the app using a different pair of icons?

EDIT (for what it is worth): I had adwaita-icon-theme installed but not adwaita-qt6 and the 22 other packages that on my system the latter brings with it. Nor did I have adwaita-qt and its four friends. But installing none of that fixed the problem of the bypass-on icon being identical to the bypass-off icon.

wwmm commented 1 month ago

EDIT (for what it is worth): I had adwaita-icon-theme installed but not adwaita-qt6 and the 22 other packages that on my system the latter brings with it. Nor did I have adwaita-qt and its four friends. But installing none of that fixed the problem of the bypass-on icon being identical to the bypass-off icon.

Nothing you install will fix this because icons do not change automatically when a button is on or off. The application has to force the icon switching. But it was already hard to find an icon remotely close to the idea of a bypass. It will be even harder to find one more icon that represents an off state.

In the Qt port I am considering to keep the bypass idea under the hoods and showing in the in the window just "on/off". It should make it easier to select an icon.

LinuxOnTheDesktop commented 1 month ago

@wwmm

Thanks. If you point me to the icon set - if a single icon set is at issue - then I could help you hunt. That said: though I have not used the program much, I do not see what is wrong with the idea of just having the on/off switch that you mention.

wwmm commented 1 month ago

@wwmm

Thanks. If you point me to the icon set - if a single icon set is at issue - then I could help you hunt. That said: though I have not used the program much, I do not see what is wrong with the idea of just having the on/off switch that you mention.

The annoying thing about icons is that the users usually want the application to follow the system icon theme. But different icon themes do not provide the same set of icons. There is always an icon that is available on some but not on others.

It will be fine to show "turn on/off" instead of "bypass". It just that "bypass" better represents what is actually being done. The plugin enters passthrough mode. It does not completely shutdown as "turn off" would suggest.

LinuxOnTheDesktop commented 4 weeks ago

I appreciate your points.

I was trying to accelerate things: it seems urgent to me that the program have a toggle that show which state the toggle is in. True, the user should be given as good ideas as possible as what each state comprises, but that seems secondary to having a visible difference that is easily discernible. So: how about using the on and off icons for now, and making any improvement only later?

Thank you for your work.

wwmm commented 4 weeks ago

So: how about using the on and off icons for now, and making any improvement only later?

I will try to do this in the branch where the move from gtk to Qt is being done. As the time I have is shorter than what I would like I am prioritizing the work in the Qt port. And as on/off is the inverse of a bypass people that are already used to the current behavior will get confused if things suddenly change out of nowhere. As some things will be different once we move to Qt it is better to let this kind of change that messes with the app workflow for the future.

it seems urgent to me that the program have a toggle that show which state the toggle is in

It does show. It is just that depending on the color theme the toggle button state may be more or less noticeable.