[MU4 Issue] MU4 main doesn't obey normal window rules

[njvdberg]

Describe the bug The color of the title bar shows which window is active or not. However, the MU4 title bar always has the same color, whether it is active or not. Also active windows create a shadow on the not active windows, giving it a kind of 3D effect. MU4 doesn't obey the systems settings and creates it own shadow.

To Reproduce Steps to reproduce the behavior:

1. Open MU4
2. Open any other application/window
3. Play with window positions and observe behavior of MU4 compared with other windows. MU4 behaves differently.

Expected behavior MU4 should behave as any other application does with respect with window management.

Screenshots In this example the left upper window (kate) is active: The title bar is dark and we see the right lower corner creates a reasonable shade on the right lower corner (MuseScore).

Now exchange the position of both windows: Now MuseScore is the active window but there is no way to tell, the title bar still has the same color as before. Eve worse, the title bar has the same color as the right lower window and there is no way to tell which window is active!

Please note: On Linux, the active window is necessarily on top. See this example In this example the right lower window is the active window and has the focus! This might look strange and unwanted but over the years (at least 2 decades) this model several times showed its strength.

Desktop (please complete the following information):

• OS: Linux (openSUSE) with KDE Plasma

Additional context This issue is most likely related to (#8820)[https://github.com/musescore/MuseScore/issues/8220] and (#8821)[https://github.com/musescore/MuseScore/issues/8221].

[Eism]

@Tantacrul what do you think about this?

[wizofaus]

I assume this is related to the fact that MuseScore now shows a menu where the title bar would normally be, which I originally thought was pretty odd until I realised Visual Studio does the same thing (at, under Windows). And indeed Visual Studio's title bar doesn't change colour to indicate it's active - though there is at least an app icon in the top left corner that does (and is used to access the window's system menu), but it's a very subtle difference. The latest version of Chrome on windows actually draws its tabs on the title bar, and has no app icon to access the system menu - there's a very slight change in colour between it being active and not however. In general I'm actually pretty surprised how many recent apps, including those published by big names like Microsoft and Google don't follow the default window behaviour that was established years ago. I'm not sure what it's supposed to gain other than a few pixels of extra space.

[Tantacrul]

It gains a few extra pixels of space - and that's extremely valuable in a scoring app, where space is at a premium. I'd also add that there are plenty of other apps that do this on Windows (Adobe, for example). As wizofaus mentioned, there are plenty of Windows apps that do it too.

Ideally, it would be nice if we could set stylings that are unique to Linux distros. However, since they're all different, I don't know how difficult that would be to achieve, or what an agreed upon standard might look like.

What I think would be fine is the idea that linux arranges the file menu in a traditional way as long as it doesn't affect the Windows version, which should remain as it is.

If we absolutely have to choose a one-size solution, then we go with the current option as it exists now.

[njvdberg]

I agree gaining a few extra pixels of space is important, however, compared with MU3, MU4 is more spacious. The icons are bigger, there is more space around several items. In this snapshot, MU4 is a the left, MU3 at the right. Even with the standard KDE/Plasma window decorations, MU3 takes less space as MU4, even with MU3 having a toolbar of two rows.

It seems to me gaining some space by using smaller icons and decrease the height of bars so there is enough space for the standard menu bar is much better since it keeps the user experience of the window behavior intact.

This becomes even more important now MU4 no longer shows multiple score in one single window but opens all scores in their own window. Now it is important to easily and quick switch between windows, which is a part of the underlying window manager. But MU4 now ignores the default (and wanted) behavior of the underlying window manager.

So I strongly urge to restore the original Linux/KDE/Plasma/Gnome/... window decorations.

[Tantacrul]

I have noticed the height difference myself. I think we can easily shave a few pixels from MS4, so it is vertically shorter than MS3. We just haven't gotten around to it yet but we will.

[njvdberg]

This also means there is space to restore the default window decorations so the behavior of the MU4 windows is "normal" again? As a matter of fact, this current behavior is really very annoying, especially when using multiple windows, e.g. when engraving a score and having PDF of an example besides it. Bringing windows to the foreground is very difficult now.

[Tantacrul]

Since we are not planning on returning back to the older system of separating the menu items from the top bar, I'm wondering what we can do to fix the problem you are reporting of not being able to bring the app back into focus?

I don't quite understand this problem. Let's say I'm on Windows or Mac: I would use something like alt-tab to bring an app back into focus (at which point it would appear 'in front of' any other windows).

Can we not try and solve this specific issue rather than reverting to a standard menubar? In general, I would have thought an active window should always be on top, as you say @njvdberg and I'm surprised you're having this issue, since I'm not seeing it on Win/Mac

[MarcSabatella]

It’s conceivable this new menu layout is related to why I can’t get Orca to read anything in MU4 unless I first manually click to open a menu, and then it seems to have no concept that this is in fact a menu. Orca only reads the menu for me, BTW, and only through this back door. I’ve been unable to get it to recognize that MuseScore 4 is an open application otherwise - it doesn’t even read the title bar because there is none I guess.

[MarcSabatella]

Btw, I realize that Orca does seem to work for some, but perhaps the difference is different window managers handling these special windows differently. I’m in debian (edit: not "denial" as spell check originally had!) "buster", not running any Linux window manager, as my Linux environment is running in a container within ChromeOS.

[njvdberg]

@Tantacrul In MS-Windows, when clicking in a window this window get the focus and is raised. Now wherever the mouse is this window is active, stays active, will get all events until another window gets the focus. I think Mac is similar.

However in KDE, I use some different settings (for the last 22 years)

• for focus: "Focus follows mouse"
• "Click raises active window" is disabled.

This means I don't have to click in a window to get the focus to that window, just move the mouse in that window is enough. Also the active window is not automatically raised, even when I click in a window is partly covered by other windows. To raise a window, I have to click on the frame of the window (or title bar, which is part of the frame). This might sound strange for an MS-Windows/Mac user but, once used to it, it has proven to be an very efficient way of work. I vaguely remember good old CDE and HP-VUE had a similar behavior, that's why I adapted KDE to this.

In my normal work the active window is not always on top, it is not necessary and sometime not wanted. I often partly overlap an active application with e.g. a help reader, PDF reader, source editor to make optimal use of the screen. This also makes it possible to rearrange overlapping windows on a more or less fixed position which makes navigation through the windows very efficient.

Using alt-tab is very annoying, especially when are quite a lot of windows open (6-8 is the minimum), it take relative a lot of time while I see the window I need and can just click on the frame. Is this much easier and fully supported by the windowing system.

Also, since MU4 doesn't have normal application frame, all feature related to it are lost. Features like rearranging the buttons on the title bar (a lot of features aren't even supported by MU4). Altogether this makes MU4 quite an annoying application on Linux.

Based on experiences of the new title bar of MU4 on Linux I must conclude the advantages of this new title bar (which I honestly don't see) don't outweigh the disadvantage of loosing all valuable features offered by the underlying windowing system. Instead of trying to solve all separate issues I think it is better to make sure the title bar of the windowing system is used.

[Tantacrul]

OK, I understand now.

The purpose of moving the menu where we have (similar to plenty of other applications) is to save crucial vertical space - mainly on Windows devices.

MS4 has a quite different layout to MS3 and I think this extra space is needed for Windows devices.

I would love to be able to just have this applicable for Windows without it having the impact it does on Linux. It seems wrong to me to undo a very valuable space-saving approach and I'd much rather investigate whether there is a way we can have an exception for Linux. For sure, we have removed this menu from Mac builds because they are not relevant.

@Eism or @RomanPudashkin, any ideas about how we could keep native menu bar functionality for Linux?

[RomanPudashkin]

@Tantacrul https://github.com/musescore/MuseScore/issues/8221#issuecomment-951695093

[MarcSabatella]

I'll be interested to see if this does turn out to be related to why I can't get Orca working. To me, that would be a strong justification of the apparent decision to roll back the changes on Linux. But I'm certainly open to alternatives, as I otherwise have no specific attachment to title bars.

BTW, on re-reading my comment above regarding that, I realize there was a very unfortunate autocorrect-caused typo, I wrote "I'm in denial buster" which sounded like I was being sarcastic and rude, but what I actually had tried to type was "I'm in debian buster" - eg, the Debian 10 release of Linux, aka "buster"! Fixed, and sorry if that offended anyone!

[Eism]

@MarcSabatella you should make these changes for testing Orca

[DmitryArefiev]

Tested on latest master build on LinuxMint 20.2 - FIXED in #9611

@njvdberg Please try on your side (with latest master) to make sure all work as expected on Linux OS. Thanks!

[njvdberg]

@DmitryArefiev Sorry for not responding earlier, I was on a holiday few week ago and missed this message afterwards. However I can conform issue is solved. Thanks.

[DmitryArefiev]

@njvdberg That's good news! Thanks!