Lmms: New Theme - Window Contrast

[tresf]

Per https://github.com/LMMS/lmms/issues/2587#issuecomment-226069613

_On June 17, 2016 @grejppi wrote:_

I'm concerned about the lack of contrast between overlapping windows:

Here's a close-up example:

Despite the tone of some of the conversations over in #2587, this isn't about opinion, it's about general usability, which is currently suffering due to some decisions made with this new theme.

It would be an injustice to the hard work put into this theme to not resolve these prior to an RC2 release.

[RebeccaDeField]

I just want to clarify that in my last comment the opinions that I posted were representing the two sides of feedback I have received from other LMMS users, not my own personal opinion (My personal changes go on the LSP whereas the default theme follows the opinion of the majority). I hope it didn't come across any differently. :sweat_smile:

I have no problems with what @budislav suggested and wouldn't mind if the theme goes in that direction if someone has the time to take that on.

The difference between the overlapping windows in the classic theme and this theme is the window border color so I believe that this could be fixed by adding more clear outlines around the windows. I'm thinking that #14171a would be a good shade but I anyone can suggest a different color.

[tresf]

The difference between the overlapping windows in the classic theme and this theme is the window border color

Although borders help, this statement is grossly misleading. The difference between the classic theme and this theme is much more than a border or a background color. Here's a side-by-side.

I just want to clarify that in my last comment the opinions that I posted were representing the two sides of feedback I have received from other LMMS users, not my own personal opinion

I think you explained that well in #2587, which is why I'd like the team to focus solely on usability in this thread. I'd like an interface that doesn't camouflage windows for an RC2.

[RebeccaDeField]

I was under the impression that this thread was specifically about this:

I see now that this issue encompasses more than I thought, and after re-reading your previous comments on this topic I think that there was a misunderstanding.

You had asked earlier if the simple palette was intentional. The answer is yes, but this can absolutely be changed by the team. :smile: So far the solutions that have been proposed are...
(a) Just changing the background and border color
(b) Updating the contrast in an image editing program and then updating all of the elements

If I am understanding correctly, neither of these will work, but I think I have an idea that might accomplish what you are setting out to do...

Let's identify all of the specific problem areas with contrast and build a list of them. Solutions for those areas can be introduced by the more design orientated contributors here that are willing to donate their time.

This is just what comes to mind but if you know a better way to go about this just let me know! Thank your for time on this as always :+1:

[tresf]

"Lack of contrast with overlapping windows" is the bug and the task should be done by those that spearheaded the theme.

[BaraMGB]

What's about a drop shaddow? :smile:

[Spekular]

Drop shadow looks good to me, but is that a mockup? I thought it might be
difficult to implement.

[BaraMGB]

That's no mockup 😊. And it's quite easy to implement.

[Umcaruje]

@BaraMGB Do active and inactive windows have different drop shadows? That could make them even more distinguishable.

[musikBear]

That's no mockup :blush:. And it's quite easy to implement.

@BaraMGB is there a substantial CPU usage increment? afaik, shadows rendering always cost cpu
In flash that is not negligible. What is the situation in cpp?

[BaraMGB]

Do active and inactive windows have different drop shadows? That could make them even more distinguishable.

Not yet, I tried this between teeth brush and breakfast. It uses only a QGraphicsDropShadowEffect on Subwindow. But I think we can make this themable.

@musikBear I don't think it cost more than the shadow on the title bar label. It's the same effect. But sure, we have to proof that.

[RebeccaDeField]

What about a drop shadow?

Brilliant idea. This would also work quite nicely with the light border giving the window contrast against the shadow.

We might want even see if we can get a border around the actual Title _Bar_ as the selected title bar seems to blend a bit with the shadow.

I don't think it cost more than the shadow on the title bar label.

We should probably test it before pulling it in so see if the CPU usage is worth the usability. :+1:

Here is a list of the solutions for the contrast that have been come up with so far...

• Tweak background color
• Tweak border color (this may not apply if we use the shadows)
• Lighten tracks in Song Editor
• Add shadows to windows
• Add border to Title Bars

If anyone has anything else to add, please do! :grinning:

[musikBear]

@BaraMGB :+1:

[BaraMGB]

Okay, for all who wants to test the shadow and play around with this, here is the branch: https://github.com/BaraMGB/lmms/tree/SubwindowShadow

There seems to be a qt bug. If I add this shadow, the window title disappears. If I remove the shadow from the window title the title appears again. seems we can't have both: window title shadow and window shadow at the same time.

I also noticed a cpu peak on moving the subwindow with shadow ( @musikBear ) . I don't know if it's worth to implement this. Perhaps we find a better way for contrasting the windows to each other.

[RebeccaDeField]

@BaraMGB Would it be possible to create a shadow using borders? We could use a double border around the windows, one that is the border that we are currently using and the other at, say, 5px. The second border could be transparent (using rgba) so that the windows still have a shadow, just a flat one. Please see the very rough mockup below.

I'm not sure if this would work, but please let me know as I don't believe this would use very much CPU.

[BaraMGB]

Wanna reference this issue https://github.com/LMMS/lmms/issues/2704
For change the color of the tracks it should be solved I think.

Would it be possible to create a shadow using borders? We could use a double border around the windows

I don't think that is the right approach. In my opinion, we should decrease the contrast and increase the brightness just a little bit. On your screen the colors may be fine but I have an old notebook. All colors fades to black. It's hard to see the elements of the gui. At next we could add a bright border to the windows. And if we decided to implement the shadow we should make an option in the preferences to turn this off.

That's my opinion.

[Spekular]

+1 for border shadows from me, fwiw.

[musikBear]

I also noticed a cpu peak on moving the subwindow with shadow ( @musikBear )

@BaraMGB Good find!
@RebeccaDeField Im not too sure about borders. Looks a bit strange where several intersect, BUT! We also need to find a useable solution!
If borders _is_ that solution, then i am not dead against it at all. For me _function_ is always the priority :)

[RebeccaDeField]

@musikBear @BaraMGB I'm not quite dead-set on the border shadow either (just the first idea that came to mind to cut CPU usage), but it might be worth giving a try. :)

I have some other ideas in progress as well.

[M4rotte]

Reassure me… all this cosmetic shadow stuff will be de-activable?

I'd like to use my CPU to render sounds when using LMMS, not to draw some bling-bling shit…

[Spekular]

@M4rotte may I suggest using a command line for your music production? That should avoid any "bling-bling" that might use a few CPU cycles to let you see what's going on.

With the new theme, shadows are necessary to avoid windows blending into each other, unless we find something better. They look good too, imo. If you don't want that, you can use the old theme instead.

[M4rotte]

@Spekular thx for your sarcastic answer. If I can still use a theme that is low on CPU usage I'm happy :) Also, I should test this new theme…

[Umcaruje]

@M4rotte Thanks for calling shadows bling-bling shit…, that's something I'll remember.

Anyways, any option that adds significant CPU usage should be made configurable in the performance menu, and we have enough community members that stress this issue, so you don't have a lot to be worried about.

[musikBear]

we have enough community members that stress this issue

Hello.. 'waves vigorously with the keyboard from an seriously outdated low end pc*
:speak_no_evil:

'enough'... :hamster: :heart_eyes:

[RebeccaDeField]

I have a couple of ideas that I would like to add. This is in relation to what Tres said here #2878

We could color-pick the colors in the classic theme and change the value of all of the colors to match so that the new theme has the exact same contrast as the classic theme, but the colors match the ModernNoir pallet.

We could make the necessary changes to the ModernNoir theme and package it in the next release, but let the classic theme be default and this theme be the alternative option.

[Umcaruje]

We could make the necessary changes to the ModernNoir theme and package it in the next release, but let the classic theme be default and this theme be the alternative option.

No, I would strongly dissagree about leaving the classic theme default.

This contrast issue is nothing that can't be solved. We can temporarily rename the themes to 'default' and 'modern' just for the RC2, but after that return the themes to the way they were and keep this the default theme

[BaraMGB]

I figured out how to change the track color.

[tresf]

@BaraMGB great. One problems is the title bar being essentially the same color as the toolbar background and side-bar when it has focus. Can we get the title bar more visibly identifiable when it has focus?

[BaraMGB]

@Umcaruje can you make a branch where we can contribute to? So we don't disturb the release candidate procedure. And we can easily merge it if it's done. What do you think?

[RebeccaDeField]

@BaraMGB Great! :+1: Is there any way we could make the background behind the tracks lighter than the window bg, then the actual track buttons lighter than that? This might have even more contrast/less blending.

I think that the double border (without transparency) was a great step in the right direction for the title bars.

I also feel that the rounded corners being straight instead will help.

We could lighten the title bars entirely so that the color is not as close to the bg color.

[BaraMGB]

Is there any way we could make the background behind the tracks lighter than the window bg, then the actual track buttons lighter than that?

Everything is possible. But I don't understand you. 😁 can you make a picture with arrows?

@tresf you are right. I set the title bar color on the list.

[RebeccaDeField]

@BaraMGB Awesome and no problem. Will make a pic when I get the chance.

[Umcaruje]

@Umcaruje can you make a branch where we can contribute to? So we don't disturb the release candidate procedure. And we can easily merge it if it's done. What do you think?

That's a great idea. let me create a branch.

[Umcaruje]

@BaraMGB @RebeccaDeField made a new branch: https://github.com/LMMS/lmms/tree/theme-contrast

Whatever you do concerning the new default theme, should be directed to and based off that branch and not master. When you're doing a Pull request, just compare your branch to this branch and not master, and when you pull to your branch pull from upstream theme-contrast rather than upstream master

I spoke to @tresf and the current default theme will probably get reverted for the RC2, but the goal is to fix these issues on the separate branch and reinstate the theme back for the 1.2 release.

[RebeccaDeField]

@Umcaruje Sounds good :+1:

@BaraMGB Please see very rough example of my previous comment.

[BaraMGB]

@RebeccaDeField :

[RebeccaDeField]

@BaraMGB Make some color tweaks and took out the borders in GIMP. What do you think about something like this? The active and hover colors might also need some work if we change up the colors.

[Umcaruje]

@tresf:

This patch was just merged into the theme-contrast branch. Is it ok now? what else needs improving? I want to help out with these contrast issues so we roll out RC2

[tresf]

@Umcaruje thanks for the status update. I think this helps quite a bit.

I'd say anything that stands out in @grejppi's screenshot.

But to be specific:

• The title bars
• The background of the MdiArea versus the background of the subwindows.

[Umcaruje]

Would a lighter subwindow border like this help out?

And actually the mdiArea does have contrast in my opinion:

How would you like to tackle the titlebars?

[Spekular]

If it were up to me I'd remove the gradient.

[RebeccaDeField]

@Umcaruje I think there are a few other things we can implement to help with this as well. I really think that the rounded corners should be turned to straight corners. I also think that the double stroke that @BaraMGB mocked up once will help greatly. Especially how it wraps around the entire window.

I believe that darkening the BG will add some more contrast to the title bars. Great work team!

[Umcaruje]

I really think that the rounded corners should be turned to straight corners.

I don't think that is possible. In the code we are drawing straight rectangles and lines, but its just because we are drawing over the original subwindow it defines the actual shape.

[RebeccaDeField]

I don't think that is possible.

In that case, you can disregard the straight corners bit in my comment.

[tresf]

Yes, the edges are better than nothing for sure, but if you zoom out just a bit, you'll see it's not immediately obvious where windows are.

Windows 10 suffers this problem too due to it's obsession with flatness and seems to skirt around it using a mostly white interface foreground combined with pretty heavy drop-shadows (which I believe were ruled out for performance reasons).

So I started thinking of other dark applications, like GitHub's Atom software. In the case o Atom, they're a single-window-interface, so it's not a fair comparison, but they put a clear distinction between content and toolbars. From 5 feet away, you know where the code lives and you can quickly recognize the location of components.

[RebeccaDeField]

@tresf I understand that the ideas I mentioned may not entirely solve the contrast problems you are having, but I think, as you said, that it can help. Let's make PR's for the ideas that help and just keep it up until it looks right. :+1:

Ideas so far...

• Darken background color
• Tweak border color, size and wrap around the whole window
• The sidebar is another area that might be worth playing with to give a bit more contrast.

The biggest struggle specifically with overlapping windows (not regarding the other areas that could benefit from more contrast) is that the windows are the same color. We can't use shadows, but borders are a good start. We could try thicker, light borders (like 3px) that wrap around the whole window.

Any other ideas are welcome. :)

[BaraMGB]

@RebeccaDeField :
I really think that the rounded corners should be turned to straight corners.

@Umcaruje :
I don't think that is possible. In the code we are drawing straight rectangles and lines, but its just because we are drawing over the original subwindow it defines the actual shape.

Probably, I found a solution for this.

[BaraMGB]

Seems to work, at first. I want to stress this a little bit today.

[BaraMGB]

Another idea : in previous versions of lmms we had a tiled pixmap background in the MdiArea. I guess it would increase the contrast a lot. That's not cosmetic purpose alone.

[RebeccaDeField]

@BaraMGB Maybe you could use a similar pattern to what @Umcaruje used in his LMMS mockup. I also created a couple of low-poly background ideas that I never used but they are still in the source files.

[Umcaruje]

status update:

This is how the theme-contrast branch looks now

[RebeccaDeField]

I'm making a PR for some other color updates as well. Will post an update here when it's done.

[BaraMGB]

@Umcaruje @RebeccaDeField what's about making the active FX line lighter?

I've also removed the gradient here.

Edit: perhaps the master channel should have it's own color. So the user can see it is a special channel.

[RebeccaDeField]

@BaraMGB Don't have a problem with it, but would love the color to be the same as the lighter track labels for consistency :)