Port to Qt and new LSP 1.2.15 features #2960
Comments
Do we need this? We do not wrap the crossover plugins. |
No, you're right. |
|
I understand the hold control thanks to this. But the balance mix/dry is really needed? I can't test it now, but aren't mix and dry levels enough? Anyway I was also thinking to begin to slowly switch plugins based on plain GTK UI with grids of spinbuttons to the Libadwaita preferences rows. I feel having all plugins structured like the Filter with two columns of preferences rows is more clean and ordered rather than having a bunch of spinbuttons like the old way. For compressors/gates I'd like to keep the stackview, but with controls ordered in preferences rows inside every pages. But if the app will eventually switch to Qt/Qml, this would be useless... I don't know. Update: The only old one I'd like to keep it's the Equalizer. Maybe moving only the tones and the balance controls in a bottom preferences rows because they prevent the page to be more shrunk horizontally. But overall it's the only structure I will keep as it is because having an Equalizer with horizontal bands/rows feels very weird. |
I also think they are enough considering EE purpose is not as broad as the typical digital audio workstations.
I have been thinking about doing this for a while. Feel free to do it.
I agree. It is probably the most that can be done there.
Yes. It makes sense. Horizontal sliders there will feel out of place because no one else does this in a equalizer.
Not at all. My intention is to replicate our current layout as much as possible. I still have a lot to do in the fastgame repository I've created for its qt port but so far it is becoming like this
If you compare to the images of its current libadwaita window https://github.com/wwmm/fastgame you will see that putting some style differences aside the layout is the same. Considering that I am working more under the hoods than on style they are already quite similar. Just keep on doing what you have always done. Unless it is impossible to replicate outside of adwaita it will be in the Qt port if it actually happens. |
But this control is weird. If I change it, should mix/dry levels change accordingly? In example, if I set 50%, I expect both levels to be at something below 0 dB and not
Ok. I was also wondering about the features that now we have for free. In example, the list sorter and the search entry. We don't sort the lists (we did before with vectors, but it was useless since it's done by GtkSorter) and do not implement the search function directly (except for the community presets, but only to extract the last part of the string). Are there these features in Qt? Besides, talking about Qt apps, I notice that qBittorrent UI does not have good borders on Gnome. See:
Will Easy Effects have the same style? |
I admit I am also a little confused. Maybe the balance is being applied after the dry/wet values are applied. Let's say that we have dry at 20% and wet at 70%. Maybe instead of changing the percentages the balance is mixing the signals resulting from these operations using a different mixing percentage. But if that is the case it feels somewhat useless. So I imagine something else is going on...
I did not get to the part where I will have to think about the listview filtering/sorting yet but it seems to be done through https://doc.qt.io/qt-6/qsortfilterproxymodel.html. So I do not expect this to be much trouble. I am more concerned about what to do about the database. That is why I do not dare saying that the port is guaranteed.
I finally had time to do some tests on my laptop where I still have gnome as desktop. That situation sucks indeed. After spending some time searching about what the hell is going on with the borders I figured it out and it is not good. It is the "war" between KDE and gnome about client side decorations all over again... If you launch a Qt app in gnome in x11 mode through There is a closed issue about this situation in the Mutter repo that was closed without any intention of fixing this on their side... They seem to expect this to be fixed by third party plugins... Or that each toolkit that is not gtk figure by themselves how to make things to be good in managers that support only CSD... So Qt has to find its own way, SDL too and so on... For now the solution for the border is installing https://aur.archlinux.org/packages/qadwaitadecorations-qt6. I did it and Qt6 apps were fine after that. A similar package exists for Qt5... Qadwaitadecorations still is actively developed by Fedora's people and was not abandoned like the previous attempts. At least not yet... Yes, this situation is definitely frustrating. And in some ways unfair. Being stuck to a toolkit just because gnome does not want to provide a minimal server side decorations for wayland apps when they do it for x11 apps is not reasonable... Well... For the time being I will keep my investigations about this issue while I keep porting fastgame to Qt. EE code base is big enough for the same movement to take many months or more than a year anyway. So there is no need to take a decision now. There is time to watch how this csd mess evolve. Maybe some improvements will be made to Qt's csd support in the next releases. Maybe the plugins will become more mature. But at least on gnome's side it is clear nothing will be done... |
|
I installed Anyway, what I like about Libadwaita is that they are building an adaptive toolkit that will be suitable for both desktop and mobile devices. This mean Easy Effects could be more usable on mobile phones in the future. What we miss now is a wrapper system for widgets. Basically at the moment Libadwaita is doing adaptive layouts in two ways:
Luckily they have this in the roadmap. Widgets should be always visible, but they wrap on shorter widths. This is the best solution. In example we can retain the same layout for desktops but showing both effects list and effect box on mobile devices just having one on top of another, so the user just have to scroll vertically without having to hide one of them. The same could be done for effects boxes. In example the Filter effect can show the two adw preferences groups in horizontal orientation on desktops, but on mobile devices they will be displayed in vertical orientation. I don't know if Qt has something similar on its roadmap. |
The plugin author seems to have the intention to have the plugin upstreamed to Qt someday. I hope he succeeds...
Qml has touch devices as its main target and the kirigami library developed by KDE's developers add some facilities to it in this regard. For example that side panel in my last images can become like this
I think I've saw somewhere a way to detect if Qt is on mobile or not. So it is probably possible to switch modes on the fly. It is just that for now I am forcing it to be like a standard side panel. Maybe kirigami/qml has some edge on this because of the fact Qt is actually used on multiple platforms while gtk is multiplatform only on paper. And KDE is the one Valve is using on Steam Deck. Also along the way I think I've seen Android code to make packages for some kde kirigami apps. I doubt there are many using these kde apps on Android. But it is probably more than people using gtk/adwaita on mobile. But honestly I think that on both libraries some level of redesigning is necessary in order to be good both on desktop and on mobile. Issue #2955 is there to prove that just using the library is not enough unless the app is very simple. |
I actually have this line in the code for the custom spinbox https://github.com/wwmm/fastgame/blob/05972cea61fbe08a96bb7f5fce1259c9a0dd96e2/src/contents/ui/FgSpinBox.qml#L38 |
|
Irony of fate, after the new Qt update, I got issues with their apps. I had to uninstall the decorations patch... |
Same thing on my laptop. After recompiling the plugin the apps stopped crashing. But there is no border... Until this becomes a part of Qt or gnome goes back in that horrible decision, what is very unlikely, this will keep happening... |
|
It turned out all apps using the latest version of Qt are broken on Gnome. -_- |
By broken do you mean there is no border but everything else is fine or broken as in the apps do not even open? Before removing or recompiling the plugin in my laptop they did not open. But after recompiling it they work. But without borders. In other words the plugin does nothing until it is updated to the latest Qt. |
The app opens, but it's not visible. Do you confirm that recompiling against the latest Qt version resolves the issue on Gnome? Which app did you test? Fastgame? Can you open Qt apps from Arch repo? |
I tested fastgame and |
|
Just to confirm things I've updated my laptop again and tried |
|
So you recompiled qBittorent? It's not showing yet to me. I had to install the Flatpak version to use it. But I compiled a small Qt6 app from AUR and it's working, maybe all the apps should be recompiled? |
No. I did not express myself well. First I removed the There was no need to recompile qbittorrent here. |
|
Well, I don't know how they work to you, but upstream qBitorrent was not working to me, even after removing qadwaita decorations. I also opened a thread on Arch forum and other people have the same issue. |
Strange. I do not even have KDE installed in my laptop. Just the minimum amount of dependencies that were necessary to install qbitorrent from the stable Arch repo and to compile and run fastgame there. My guess is that there is some kind of configuration somewhere breaking Qt. |
|
Now upstream qBittorrent works properly, but Chromium v124 is broken (not visible with ozone=wayland flag). What about your laptop with Gnome? |
It is fine if I just click on its launcher icon. I imagine that in this case it is using x11. If I use |
|
In the desktop where I use KDE and the hardware is completely different |
|
Same to me. |
|
As this discussion's topic has already diverged 😄 I will put this information here for the future. It seems that Qt 6.8 will fix the lack of borders on GNOME https://doc-snapshots.qt.io/qt6-dev/whatsnew68.html:
|
I'm waiting Arch repo to release Qt 6.8 and try out this new style. But on EE I don't really mind about the GUI since the app should work in background most of the time. Anyway, since I see you are working on the porting to Qt, I wonder if there will be a way to completely close the GUI or Gnome users should have it open for the whole session. This may seem a dumb question, but some apps like qBittorrent have the tray support disabled on Gnome, which means the app is shutdown if the GUI is closed. Will it be the same for EEqt or could we close the GUI but still having the service running as the current version? |
I definitely want it to work fine in the background also in GNOME. Now that you talked about it I decided to do some tests on my laptop where I still have GNOME. If the Although any of the tray extensions solves the problem forcing people to have an extension is not nice. I will try to see what else can be done in this case... I thought GNOME was just not showing the tray icons. But they didn't even keep in place the bare minimum for apps that use tray to keep running in the background... I thought I could get away with some form of basic interprocess communication to make the window visible again when the user clicked on the launcher icon but this clearly is not going to work if the default behavior is crashing on GNOME =/ |
|
This is not promising... ^^ I can always send the app to an empty workspace if I should keep it opened, but this seems a regression since now I have it closed the whole time... |
|
I'm not sure what apps actually do when attempting to close to tray, in any case a tray clearly cannot be assumed to exist in gnome. But it is possible for an app to not show any window, which will lead to the app being listed as a background app in the gnome top right system control menu. This feature may only work properly for flatpaks though, other install types may not show up in the background app list at all. |
|
OK. Anyway I'm having issues registering on KDE bug tracker. I filled my email address, but I can't get the mail with the confirmation link. Can you do it? Maybe you already have an account. |
|
In any case it seems I still have to wait for QtGraphs to mature a little more. It is almost doing everything we need. Some of the downsides of QtCharts were fixed but some of its features like logarithmic axes were not ported to QtGraphs yet.
Hum... Strange. I created one yesterday. I received the confirmation link almost immediately. Did you take a look at your spam folder? |
Yes. I'll try to use another email... |
Ok. While you try this I will get my laptop where I still have GNOME and test if it is also broken here. |
This is going to take some time. I've forgot it has been a long time since the last time I updated this laptop 😄 |
I'm not receiving anything. Maybe they banned my name. In the past (4-5 years ago) I had an argument with some KDE devs on PulseEffects not working good on Plasma at the time (then I moved on Gnome)... |
Ok. Let me try on my laptop first to see how it is there. There is still 1 GB of updates to be done from the initial 3 GB. |
|
I received the email now. If I can end the registration, I'll open the ticket issue. Update: I did it. But it says bugs should be reported on https://bugs.kde.org/ |
Oh... I totally forgot about this site. It makes sense. I came back from lunch and did some tests on GNOME. As soon as I opened EasyEffects it was using the light theme instead of the dark one. But I've noticed something curious. When I used GNOME settings to alternate between light and dark theme EasyEffects suddenly started to follow what I was doing on GNOME settings. So it is not totally broken. |
|
Another test. After a logout EasyEffects went back to the light theme. And again after alternating between themes on GNOME settings it started to behave correctly again. So the regression seems to be that the configuration is not persistent. After a logout something is reset somewhere. |
Please add this discovery here: https://bugs.kde.org/show_bug.cgi?id=497790 Anyway, yes, I installed Alligator from upstream and it's happening as you say. When I close the app, the theme is reset, but it's applied when the theme is switched. |
|
@wwmm I'm trying to test the Crossfeed in the Qt port, but I'm having some issues. I included Besides, since this is not an LV2 plugin, I don't understand where the bind of controls is done. Usually, in LV2 plugins, there are I saw you didn't make the binding in Autogain and Crystilizer, so I suppose it's automatically done in But for Autogain, you did it for the
Update, I saw the original Update 2: I'm not good with those CMake things, but somehow I managed to do it. Now it's compiling... |
|
I noticed that the effects lists in the Qt port is not sorted by the locale strings, unlike the libadwaita version:
|
It isn't a binding. The database is essentialy a c++ class that wraps Qt config framework for ini files. In the simple cases we are just reading the output of the class getters directly.
Oops. Instead of setting the translated name as sorting role I've used the name column. It should be fixed now. |
|
@wwmm Can we do something to fix the height here?
The ideal solution would be to set a maximum height, but it seems not possible from what I saw in the documentation. If not really possible, maybe a bottom margin so that we can see the rounded corners... |
In the cases where a widget is inside a layout we can use Is the bottomInset enough to fix things on your side? |
|
In cases like the one for |
|
The bottom border may be visible, but the popup still collapse on the bottom border of the main window (to me it's not a big difference). I know this is an edge case since I'm reducing the window height too much, but I think it's not ideal. Besides, if I increase the
There should be a way to set the maximum height. If this widget does not implement the layout, maybe we should wrap the stack in another widget that implements it? I mean the ideal style should be what we already have in the Libadwaita stable version. Open the settings popup and reduce the height of the main window. The popup automatically reduces its height and the margin to the bottom border of the main window is retained.
|
That is the same that happens in the . The behavior becomes the one we have on libadwaita but the first page becomes like this I admit I considered doing this to all of our menus at some point. But I am not sure if people will like a super tall menu with few entries. |
One option would be to do the same here. Creating one "general" and "spectrum" tab again. The problem with tabs in the header is that having many of them does not look good if there is not enough space. |
|
As I see, this implicit height changes whenever we resize the main window. So can't we do something like the following? implicitHeight: Math.min(
height_of_the_content_inside_the_overlay, // do not remember the property to get it
preferencesSheet.parent.height - 2 * preferencesSheet.header.height - preferencesSheet.y
) |
Maybe. I will try to do some tests tomorrow. |
|
I had some time to test it now. As far as I can see it is working very well. I've updated the qt branch with this solution. |
|
Nice, I will try it out tomorrow. |
Yes, tested it, it's like libadwaita. |
|
Regarding #3612, there's still an issue on the height of the presets sheet overlay which I couldn't fix. The local/community presets stackviews are displayed correctly, but the autoloading one is collapsing on the bottom border of the window. I tried to do everything: remove the
There's also another issue related to the effects list which includes also the Spectrum and the Output Level which shouldn't be selectable by the user:
|
I think it is caused by the fact that I think that the height property will have to be use a conditional and take a slightly different value when the autoloading tab is visible. |
Fixed. There was no need to have them in the plugins map. The easiest solution was to remove them from there. |
|
I did some adjustments to the presets sheet height. It is a little better now. |
I wonder if there's something new we can implement. https://github.com/lsp-plugins/lsp-plugins/releases/tag/1.2.15
Anything else?
The text was updated successfully, but these errors were encountered: