Old 07-20-2021, 01:26 AM   #1
biopsin
Human being with feelings
 
Join Date: Sep 2010
Location: oslo
Posts: 125
Default [WDL] Linux UX Improvements

Hi,
I noticed a user named gurrgur has made a PR to uplift the GUI a bit
@ https://github.com/justinfrankel/WDL/pull/12

If anyone else have the opportunity testing it,
and maybe leave feedback on how it looks/performs.
__________________
Voidlinux_glibc / gcc_10.2 / libSwell_GDK2 - 11.09.21 /
Reaper_6.36 / NI_KA2 / Dynaudio_BM6
biopsin is offline   Reply With Quote
Old 09-08-2021, 03:34 PM   #2
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Hi!
I didn't know someone made a thread about my PR over here! I was wondering whether I was the only one thinking that REAPER's UI looks kinda old and out of place on many linux distros. It is workable, but there sure is a lot of room for improvements.

The PR attempts to somewhat modernize the UI appearance, but the changes are quite small and there is much left to do. So I was thinking, maybe we could use this thread to gather some ideas on what should be improvend and how!

Here's some ideas on features that I'd personally like to see in WDL/swell/linux:

1. Support for inactive/active window menubar coloring: Many gtk and qt themes do this and it annoys the hell out of me when titlebar color and menubar color do not match.

2. Add ability to toggle drop down list selection using mouse wheel: You can do this on windows and it is very useful, e.g. for quickly changing IR files in ReaVerb without having to click and scroll though a typically large list.

3. Add bottom rounded window corners: Not sure how to implement this, but this is pretty much standard on gnome nowadays.

4. Support rounded corners for various UI elements e.g. buttons and add corner radius properties to libSwell colortheme.
hmnx is offline   Reply With Quote
Old 09-08-2021, 08:34 PM   #3
4duhwinnn
Human being with feelings
 
Join Date: Mar 2017
Posts: 655
Default

Hi, I'd like the bpm control to be on the top or bottom, I hate window juggling just to change it. I'd like the transport and other items to be portable, like how Audacity let's you drag controls where you want/need them.
Cheers
4duhwinnn is offline   Reply With Quote
Old 09-09-2021, 02:45 AM   #4
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Hm, that's not something that could be changed by hacking WDL. That is something REAPER devs would have to implement, and you'd have to create a feature request to let them know.

You have to differentiate between REAPER's custom drawing and the basic widgets provided by the UI toolkit it uses. On windows REAPER uses a native windows toolkit, which gives the menubar or basic widgets (buttons, dropdown menus, text fields, ...) a certain behaviour and appearance. On linux, REAPER uses swell as a replacement for said windows toolkit. Due to swell and WDL being open source, it is possible to change the look and behaviour of the most basic widgets. Basically everything that looks exactly the same on windows, linux and macos is custom drawing and you cannot change it with mere swell hacks.
hmnx is offline   Reply With Quote
Old 09-09-2021, 06:42 AM   #5
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

Quote:
Originally Posted by 4duhwinnn View Post
Hi, I'd like the bpm control to be on the top or bottom, I hate window juggling just to change it. I'd like the transport and other items to be portable, like how Audacity let's you drag controls where you want/need them.
Cheers
You can reposition the transport in REAPER, try right clicking it
Justin is offline   Reply With Quote
Old 09-09-2021, 06:43 AM   #6
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

Quote:
Originally Posted by hmnx View Post
Hi!
I didn't know someone made a thread about my PR over here! I was wondering whether I was the only one thinking that REAPER's UI looks kinda old and out of place on many linux distros. It is workable, but there sure is a lot of room for improvements.
Cool, this looks good, I will merge it in! (also with a couple of small tweaks). Thanks! Edit: merge done, fixed a leak, improved the menu bar hit testing/menu positioning some, too.

Last edited by Justin; 09-09-2021 at 08:23 AM.
Justin is offline   Reply With Quote
Old 09-09-2021, 09:32 AM   #7
biopsin
Human being with feelings
 
Join Date: Sep 2010
Location: oslo
Posts: 125
Default

<3- Thank you Justin
__________________
Voidlinux_glibc / gcc_10.2 / libSwell_GDK2 - 11.09.21 /
Reaper_6.36 / NI_KA2 / Dynaudio_BM6
biopsin is offline   Reply With Quote
Old 09-09-2021, 09:38 AM   #8
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Thanks for merging! Edit: And for ironing out my bugs
hmnx is offline   Reply With Quote
Old 09-09-2021, 10:13 AM   #9
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

Thanks for the contribution!

Just pushed some other updates, mousewheels can now scroll menus (and combobox lists...)
Justin is offline   Reply With Quote
Old 09-09-2021, 07:19 PM   #10
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

and added inactive menubar coloring (wonder if we can query Gnome for colors?)

Last edited by Justin; 09-09-2021 at 07:56 PM.
Justin is offline   Reply With Quote
Old 09-09-2021, 09:59 PM   #11
4duhwinnn
Human being with feelings
 
Join Date: Mar 2017
Posts: 655
Default

Many thanks for the tip, perfect and great improvements!
4duhwinnn is offline   Reply With Quote
Old 09-09-2021, 11:26 PM   #12
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Quote:
Originally Posted by Justin View Post
and added inactive menubar coloring
Very cool! Just got around testing it (on gnome) and noticed some things:

1. There is a small deactivation delay when activating a non-REAPER window. Edit: Maybe this is some redrawing issue?



2. Windows shouldn't be deactivated when a (right click) submenu is opened.



3. Windows shouldn't be deactivated when a dialog window pops up. I'm not sure how KDE Plasma handles this, but I assume this is standard behaviour though.

hmnx is offline   Reply With Quote
Old 09-10-2021, 12:13 AM   #13
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

I also noticed a minor bug (related to my initial PR), where the selected item background in a menu is drawn above the surrounding rectangle border. This patch fixes it.

Code:
diff --git a/WDL/swell/swell-menu-generic.cpp b/WDL/swell/swell-menu-generic.cpp
index d47e8040..ed522217 100644
--- a/WDL/swell/swell-menu-generic.cpp
+++ b/WDL/swell/swell-menu-generic.cpp
@@ -593,7 +593,8 @@ static LRESULT WINAPI submenuWndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM
             {
               HBRUSH brs=CreateSolidBrush(g_swell_ctheme.menu_bg_sel);
               RECT r2=r;
-              r2.left = cr.left;
+              r2.left = cr.left + 1;
+              r2.right = r2.right - 1;
               FillRect(ps.hdc,&r2,brs);
               DeleteObject(brs);
               SetTextColor(ps.hdc,g_swell_ctheme.menu_text_sel);
This is what the change looks like:


Last edited by hmnx; 09-10-2021 at 01:05 AM. Reason: update patch (don't use SWELL_UI_SCALE)
hmnx is offline   Reply With Quote
Old 09-10-2021, 06:30 AM   #14
elcalen
Human being with feelings
 
Join Date: Sep 2019
Posts: 160
Default

Since we're talking about menus, maybe I should mention again this weird issue I have on Gnome with glitchy shadows around various dropdown or context menus. I've mentioned the issue before (https://forum.cockos.com/showthread.php?t=248722), but didn't get any solutions...

In a nutshell, sometimes the drop shadows around menus start flickering, or shadows get left behind when closing a menu. I've only ever encountered this issue with Reaper, and on Gnome (though I haven't tested very many window managers—but I know it didn't happen on Compiz that I used prior to moving to Gnome last year). It's a fairly minor aesthetic annoyance, but still, would be nice to know what's causing it...

EDIT: this is with current Reaper 6.36, and prior versions.

Last edited by elcalen; 09-10-2021 at 06:39 AM.
elcalen is offline   Reply With Quote
Old 09-10-2021, 07:55 AM   #15
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Yeah I know those glitchy lingering shadows, but weirdly enough I haven't observed them in a while. Maybe some Gnome update fixed it? Might have been the Gnome 40 rollout that happend a while ago on manjaro.

Which version of gnome are you running?
hmnx is offline   Reply With Quote
Old 09-10-2021, 08:58 AM   #16
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

Quote:
Originally Posted by hmnx View Post
Very cool! Just got around testing it (on gnome) and noticed some things:

1. There is a small deactivation delay when activating a non-REAPER window. Edit: Maybe this is some redrawing issue?
Edit: I think this should be fixed now, woot!


Quote:
2. Windows shouldn't be deactivated when a (right click) submenu is opened.
Fixed this (and some other bugs), added your patch above, and added inactive-menubar-text configuration too.

Quote:
3. Windows shouldn't be deactivated when a dialog window pops up. I'm not sure how KDE Plasma handles this, but I assume this is standard behaviour though.
For me on gnome and xfce it does show the window frame as inactive when a dialog window is up...

Last edited by Justin; 09-10-2021 at 09:19 AM.
Justin is offline   Reply With Quote
Old 09-10-2021, 10:48 AM   #17
elcalen
Human being with feelings
 
Join Date: Sep 2019
Posts: 160
Default

Quote:
Originally Posted by hmnx View Post
Yeah I know those glitchy lingering shadows, but weirdly enough I haven't observed them in a while. Maybe some Gnome update fixed it? Might have been the Gnome 40 rollout that happend a while ago on manjaro.

Which version of gnome are you running?
Yeah, I'm on Debian Bullseye, which is still on Gnome 3.38. I know 40 is a pretty big update, so that could certainly be a factor...

Edit: I have been meaning to upgrade to the current Debian testing version though, and looks like that's moved to 40... So maybe I'll use this as an excuse to finally check that out...

Edit 2: Welp, looks like Debian testing hasn't actually transitioned to 40 yet, after all... Some packages are confusingly listed as being version 40, but others (including gnome-shell) are still 3.38, and nothing major seems to have changed... And flickering still happens.

Last edited by elcalen; 09-10-2021 at 11:53 AM.
elcalen is offline   Reply With Quote
Old 09-10-2021, 07:42 PM   #18
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

aand pushed a commit to allow scrolling comboboxes with mousewheel without opening them first
Justin is offline   Reply With Quote
Old 09-11-2021, 04:09 AM   #19
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Quote:
Originally Posted by Justin View Post
Edit: I think this should be fixed now, woot!
Hmm, this commit https://github.com/justinfrankel/WDL...97ba36f2ca18b9 does not seem to play well with gnome 3.36.8 (Ubuntu 20.04), gnome 40.4 and xfce 4.16 (both Manjaro). Though it works fine with KDE Plasma 5.22.5 (Manjaro). The problem is that the menubar gets deactivated for a short amount of time when dragging the window. I think the old behaviour might be a better tradeoff since at least it works the same across desktop environments and the menubar does not flash when dragging windows.



Quote:
Originally Posted by Justin View Post
For me on gnome and xfce it does show the window frame as inactive when a dialog window is up...
From my testing, KDE Plasma and XFCE seem to deactivate the main window when a dialog pops up. Gnome is doing something different, where the main window still uses active colors but there is a dimming animation which makes the window look like it was using inactive styling. This is the case for both Gnome 40.4 and 3.36.8. But it really can't be helped when there is no consensus among window managers, and to be honest, it is a rather small and insignificant detail
hmnx is offline   Reply With Quote
Old 09-11-2021, 04:39 AM   #20
FeedTheCat
Human being with feelings
 
FeedTheCat's Avatar
 
Join Date: May 2019
Posts: 665
Default

Quote:
Originally Posted by Justin View Post
aand pushed a commit to allow scrolling comboboxes with mousewheel without opening them first
!!! Awesome!
FeedTheCat is offline   Reply With Quote
Old 09-11-2021, 05:24 AM   #21
FeedTheCat
Human being with feelings
 
FeedTheCat's Avatar
 
Join Date: May 2019
Posts: 665
Default

A gnome-specific issue with comboboxes: When a menu exceeds/overlaps the top bar it is no longer clickable/selectable.

The top 2 (1.5) menu entries in this screenshot can't be clicked.



In practice that means that the default preset in certain plugins is only accessible by using the arrow keys. I'm guessing that there isn't an easy fix, so it might not be worth the attention, but there probably won't be a better time to bring this up
FeedTheCat is offline   Reply With Quote
Old 09-11-2021, 08:00 AM   #22
biopsin
Human being with feelings
 
Join Date: Sep 2010
Location: oslo
Posts: 125
Default

Does mouse back/forward work for anyone in the Media Explorer,
I mean traversing up or last entered folder?
both act like left click and plays just the file beneath the pointer.
__________________
Voidlinux_glibc / gcc_10.2 / libSwell_GDK2 - 11.09.21 /
Reaper_6.36 / NI_KA2 / Dynaudio_BM6
biopsin is offline   Reply With Quote
Old 09-11-2021, 08:13 AM   #23
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

Quote:
Originally Posted by FeedTheCat View Post
A gnome-specific issue with comboboxes: When a menu exceeds/overlaps the top bar it is no longer clickable/selectable.

The top 2 (1.5) menu entries in this screenshot can't be clicked.



In practice that means that the default preset in certain plugins is only accessible by using the arrow keys. I'm guessing that there isn't an easy fix, so it might not be worth the attention, but there probably won't be a better time to bring this up
Ah grr, this only occurs on Gnome 3.36 here when not on Wayland, thanks Gnome bug... let me see how I can fix, hmm...

Last edited by Justin; 09-11-2021 at 08:28 AM.
Justin is offline   Reply With Quote
Old 09-11-2021, 09:15 AM   #24
FeedTheCat
Human being with feelings
 
FeedTheCat's Avatar
 
Join Date: May 2019
Posts: 665
Default

Quote:
Originally Posted by Justin View Post
Ah grr, this only occurs on Gnome 3.36 here when not on Wayland, thanks Gnome bug... let me see how I can fix, hmm...
Thx for looking into it. If it works on Wayland it's probably not worth fixing. I think most people that stick to X do it because of Nvidia (me at least), and apparently their newest drivers have better support for Wayland.
FeedTheCat is offline   Reply With Quote
Old 09-11-2021, 11:06 AM   #25
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 13,635
Default

Quote:
Originally Posted by FeedTheCat View Post
Thx for looking into it. If it works on Wayland it's probably not worth fixing. I think most people that stick to X do it because of Nvidia (me at least), and apparently their newest drivers have better support for Wayland.
Ah, was able to fix the root of the problem (we were using the monitor coordinates instead of the workspace coordinates). (pushed that).

Also made the instant-menubar-color-change when switching apps configurable and automatic (enabled on Wayland, which doesn't send inactivation messages while moving window frames, at least on Gnome)...
Justin is offline   Reply With Quote
Old 09-11-2021, 11:22 AM   #26
FeedTheCat
Human being with feelings
 
FeedTheCat's Avatar
 
Join Date: May 2019
Posts: 665
Default

Quote:
Originally Posted by Justin View Post
Ah, was able to fix the root of the problem (we were using the monitor coordinates instead of the workspace coordinates). (pushed that).

Also made the instant-menubar-color-change when switching apps configurable and automatic (enabled on Wayland, which doesn't send inactivation messages while moving window frames, at least on Gnome)...
Really cool! Looking forward to the next pre-release
FeedTheCat is offline   Reply With Quote
Old 09-12-2021, 12:49 AM   #27
elcalen
Human being with feelings
 
Join Date: Sep 2019
Posts: 160
Default

Unless I've totally missed some recent developments, I think there's still a lot more people using X than Wayland... Heck, I wouldn't even know how to enable Wayland in the first place... (Also I, like many, many people, am in fact using Nvidia drivers, if that is indeed a factor...)

Edit: welp, looking into it, I just learned that at least on Debian Wayland is supposedly enabled by default in Gnome, *unless* you're using Nvidia drivers. Since I've been on Nvidia for a long time, I honestly had no idea that that was even a thing, or that it was already in such wide use... But my point above still stands, there's lots of people using Nvidia, and there's also lots of people who don't use any of the major desktop environments and probably don't have Wayland. So I think X is still definitely worth fully supporting.

Also, I've definitely encountered that menu over the top bar bug before (on Gnome 3.38), so thanks for addressing that.

Last edited by elcalen; 09-12-2021 at 02:11 AM.
elcalen is offline   Reply With Quote
Old 09-12-2021, 04:14 AM   #28
hmnx
Human being with feelings
 
hmnx's Avatar
 
Join Date: Mar 2019
Posts: 9
Default

Quote:
Originally Posted by elcalen View Post
Unless I've totally missed some recent developments, I think there's still a lot more people using X than Wayland... Heck, I wouldn't even know how to enable Wayland in the first place...
I don't think you have to worry on that part. Although most desktop environments are moving towards wayland, there are still plenty which will stay on X for while. A good example is xfce and Justin was explicitly testing for that

Quote:
Originally Posted by Justin View Post
and added inactive menubar coloring (wonder if we can query Gnome for colors?)
Did some investigation on the latter part.. It can be done but its a bit tricky due to gtk3 using css for theming. I have implemented a prototype in python which generates a libSwell.colortheme from the user's gtk3 theme. It mostly does the job, but has some issues because the way colors need to be extracted somewhat depends on implementation details of the theme's css. Also I believe some widgets which combine various UI elements don't expose styling information for their internal components. For example, a checkbox always comes with a label but we want to know the colors of the checkbox fg and bg specifically and not the color rules for the combined thing.
hmnx is offline   Reply With Quote
Old 09-13-2021, 08:13 AM   #29
FeedTheCat
Human being with feelings
 
FeedTheCat's Avatar
 
Join Date: May 2019
Posts: 665
Default

Happy to find out that the changes made it into pre-release (even though not explicitly mentioned in the changelog). Everything works great here, and the scrolling on comboboxes is really useful for presets etc. Thanks Justin!
FeedTheCat is offline   Reply With Quote
Old 09-13-2021, 08:24 AM   #30
audiojunkie
Human being with feelings
 
audiojunkie's Avatar
 
Join Date: Nov 2011
Posts: 228
Default

For those concerned about using Wayland: Wayland as the your default, along with XWayland should do just fine for your X apps until you no longer need X.

Last edited by audiojunkie; 09-13-2021 at 08:25 AM. Reason: Edited for clarity
audiojunkie is offline   Reply With Quote
Old 09-13-2021, 09:50 AM   #31
elcalen
Human being with feelings
 
Join Date: Sep 2019
Posts: 160
Default

Oh, it wasn't that I was *concerned* about Wayland. I'll welcome it when it's actually properly supported for my system. I was just simply stating that—to the best of my knowledge—it's not all that common place yet and there's still lots of people on pure X, and probably will be for a long time to come... Which really has nothing to do with this thread, though.
elcalen is offline   Reply With Quote
Old 09-13-2021, 09:57 AM   #32
audiojunkie
Human being with feelings
 
audiojunkie's Avatar
 
Join Date: Nov 2011
Posts: 228
Default

Quote:
Originally Posted by elcalen View Post
Oh, it wasn't that I was *concerned* about Wayland. I'll welcome it when it's actually properly supported for my system. I was just simply stating that—to the best of my knowledge—it's not all that common place yet and there's still lots of people on pure X, and probably will be for a long time to come... Which really has nothing to do with this thread, though.
It's all good! 😊👍
audiojunkie is offline   Reply With Quote
Old 09-13-2021, 01:37 PM   #33
SmajjL
Human being with feelings
 
SmajjL's Avatar
 
Join Date: Nov 2013
Location: Sweden
Posts: 2,437
Default

I think Gnome's Wayland seems most mature/stable atm because no blurry apps or screen going blank like can happen with KDE Wayland-session and, all AMD here *yeah*

Starting to like Gnome! it can be a tad more compact now and, GTK just feels more Linux for some reason

They say X have issues that could be "impossible" to sort out (what ever those are) and Wayland more secure

Gnome is default on some distros ya know even if some devs will stick with Xfce until 2155..

*me hides*
SmajjL is offline   Reply With Quote
Old 09-19-2021, 05:23 AM   #34
elcalen
Human being with feelings
 
Join Date: Sep 2019
Posts: 160
Default

Quote:
Originally Posted by elcalen View Post
Yeah, I'm on Debian Bullseye, which is still on Gnome 3.38. I know 40 is a pretty big update, so that could certainly be a factor...

Edit: I have been meaning to upgrade to the current Debian testing version though, and looks like that's moved to 40... So maybe I'll use this as an excuse to finally check that out...

Edit 2: Welp, looks like Debian testing hasn't actually transitioned to 40 yet, after all... Some packages are confusingly listed as being version 40, but others (including gnome-shell) are still 3.38, and nothing major seems to have changed... And flickering still happens.
As an addendum to this, Debian testing has now *actually* transitioned to Gnome shell 40. I haven't had a chance to use Reaper much with it yet (I only upgraded this morning), but during a quick test I didn't spot any of the shadow flickering I mentioned earlier in this thread. Fingers crossed that it's actually fixed in Gnome 40... (Although if it was in fact an issue with Gnome 3.38, it's weird that I only ever encountered it with Reaper...)
elcalen is offline   Reply With Quote
Old 09-25-2021, 09:19 AM   #35
Nixon
Human being with feelings
 
Nixon's Avatar
 
Join Date: Dec 2011
Posts: 333
Default

Maybe that's the right place to post this.

(Justin as Linux build is not experimental anymore where is your preferred place for Linux related bug reports?)

If I scroll on a waveform, the file list or the shortcut list (both directions) in media-explorer the arrange view moves too.

Just seems to happen if media-explorer is docked.

preferences is set to scroll under mouse
v6.36+dev0924 - September 24 2021
mx linux 19.4 xfce 64 bit

Last edited by Nixon; 09-25-2021 at 10:02 AM.
Nixon is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 11:08 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.