Title Bar Theming Support

[RebeccaDeField]

LMMS is built using Qt and and it uses Qt's QMdiArea (MDI stands for Multiple Document Interface). Every window inside LMMS is a QMdiSubwindow, and they are not themeable using CSS. Their look is hard-coded in the Qt settings for your PC

A solution someone mentioned would be to actually render frameless windows and then draw a custom titlebar on top of them.

I origanally added the issue here https://github.com/HDDigitizerMusic/lmms-alt-theme/issues/5, but @Umcaruje suggested that I add this issue on the main issues tracker.

Edited 2015-11-18 @tresf, added screenshot

[tresf]

Duplicate of #123, which was consolidated into meta issue #1839.

We can leave this open, but we are in dire need of C++ coders, so unless there is movement on this in the next few months, I will close this out and turn the "Modern and Sleek" thread into a meta-issue so we don't bulk up the tracker.

In regards to making our internal MDI-style windows borderless and adding our own themed title bars, close, minimize, maximize buttons, the task is rather trivial for a seasoned Qt GUI developer (or any good C++ coder for that matter), we just need some people to step up. :+1:

[BaraMGB]

I'm on it. But its not so trivial as @tresf said. But I think I can do this.

[Umcaruje]

@BaraMGB I love you

[tresf]

^

[RebeccaDeField]

@BaraMGB Nice work!! I think that if we can code up new title bars for the default, it should be more generic and clean so that I can easily match most of the themes.

Also, what @Umcaruje said.

[programnoir]

Hey there, popping in to say you're the man, @BaraMGB, this is a crucial feature that themers have been needing for a long time.

[BaraMGB]

Okay, I got it. It was much more simpler as I thought at first. Since the Titel Bar belongs to the MDISubWindow widget, I only had to implement a paintEvent and draw the new Title Bar. Simple enough. The old Titel Bar is under the new and gives his functionality through the new one. So I don't need implement the whole window stuff such resize or the buttons. I only add new PNGs for close, minimize and maximize in the theme folder and load them on the right place. That's all.

But now I have to figure out the css stuff. I don't know how to implement that. But I will see.

[tresf]

now I have to figure out the css stuff. I don't know how to implement that. But I will see.

Here's how I did it in the grid patch... aaa798c. You may want to start a Pull Request now against your GitHub repo so that we can make advisement.

default/style.css

qproperty-foo: rgba( red, green, blue, alpha );

c++

Q_PROPERTY( QBrush foo READ foo WRITE setFoo )
QBrush foo() const;
void setFoo( const QBrush & c );
QBrush m_foo

[RebeccaDeField]

@BaraMGB If you can give me the size of the icons for the title bars, I can design the minimize, maximize and close icons for you.

[programnoir]

I feel the need to point out the white space suddenly appearing underneath the scrollbars. The left border seems obscured too. I am out of the loop if this is from a different problem.

[programnoir]

Nevermind!!! Wrong screenshot!!

[tresf]

@BaraMGB If you can give me the size of the icons for the title bars, I can design the minimize, maximize and close icons for you.

@RebeccaDeField we may go vector. Do you agree that we may be able to tackle them all with a font + style sheet + css borders, etc? If so, we can skip the pixmaps for these particular buttons.

[RebeccaDeField]

@tresf If we want to just code up the icons instead of using pixmaps, I could always just create a mockup to give the coders some direction for what it should look like. Let me know if that would be helpful :)

[BaraMGB]

I think @tresf meant svg instead of pixmap.

[RebeccaDeField]

@BaraMGB If so, I design everything in Inkscape so that would work as well.

Awaiting clarification from @tresf ;)

[tresf]

I think @tresf meant svg instead of pixmap.

AFAIK we've migrated almost no icons from PNG to SVG. Please correct me if this assumption is wrong in regards to the new theme.

[tresf]

@RebeccaDeField we may go vector

P.S. This statement was in regards to using pure CSS, not SVG (since a CSS border is a vector, not a pixmap). I realize now how confusing this statement is in the context of images. Sorry for the confusion that it has caused.

What I meant to say was, we should use fonts (which are vector) such as "X" to close, and a bordering box with CSS styling to decorate over an image of a close button.

[Umcaruje]

Do you agree that we may be able to tackle them all with a font + style sheet + css borders, etc?

I think making an icon font and/or doing css hackery for just three icons is a bit of an overkill. Also, css hackery might be fun, but using pixmaps for the close, minimize and maximize icons will mean that users can easily change them in their themes, as opposed to CSS tricks, which require a lot more knowledge.

[tresf]

I think making an icon font and/or doing css hackery for just three icons is a bit of an overkill

Perhaps, but _ □ x in a styled box isn't rocket science either. :+1:

[RebeccaDeField]

Either way sounds great to me. Seems like @tresf could code it up pretty easily. Is there a specific reason that using css might better improve or speed up the program as opposed to just using the .pngs?

I also agree with @Umcaruje. We are low on coders so it might be a good idea to use something that can be easily updated.

Either way, I can't wait to see what it looks like in action. :)

[programnoir]

Actually, it's funny, but I managed to read the Qt Style Sheets reference, turns out QWidget::title is how you style the title bars of all of the widgets, albeit there seems to be a degree of limitations here and there. For example, I have yet to figure out how to change the text inside of the title bar, and it inexplicably seems to get a weird white background. The dialog buttons also disappear. In conclusion, really glad for BaraMGB's contribution.

[Umcaruje]

I fiddled around with @BaraMGB's branch, and must say I'm pretty happy.

Code info here: https://github.com/LMMS/lmms/pull/2516#issuecomment-175626711

[RebeccaDeField]

Great work everyone! I think we should come up with a design for the title bars that matches the Default theme and put that in place :+1:

Here is a link to the Title Bar icons I designed if anyone wants to grab them --> https://www.dropbox.com/home/LMMS%20Theme?preview=TitleBars.svg

[IvanMaldonado]

This looks sweet! I can't wait to see this in action in the 1.2. This and the other contributions you have made about theming support will open a whole new branch of themes.

Thank you so much for doing this!

[Wallacoloo]

It occurs to me that if we were able to have LMMS' subwindows make use of the system theme, then we could save ourselves a lot of effort in the long run - the user would be able to style LMMS just by opening up their OS' appearance configurator (e.g. Aero for windows systems, gnome-tweak-tool for gnome desktops, qtconfig for KDE systems, etc), and we'd gain the benefit that LMMS has a consistent look-and-feel with the rest of the applications on the user's system.

A quick experiment shows for me that lmms' subwindows (the border color, minimize/close icons, background color, font color, etc) don't seem to change look at all when I alter either my system's gtk theme or the qt4/5 theme, regardless of if I build LMMS with WANT_QT5 or not. I'm unsure if this is our own doing (are we explicitly overriding the system's theme in our code?) or a limitation of Qt5 and its subwindowing system. But I think it's worth looking into seeing if we can fix this on our end.

[programnoir]

I'm not sure what you're meaning, but I love that we can make custom themes, and I hope we don't lose that feature. Being able to use the system's theme sounds great, if we can make it optional. Again, I'm not 100% on what you're saying, here, but that's how I feel.

[Wallacoloo]

@circuitfry I'll admit that I don't have a huge amount of experience programming GUIs. But as a user, I always choose applications that follow my system theme when given the choice. For example, I choose Cantata over foobar2000 as my media player because, even though the latter offers extensive internal theming capabilities, the former obeys my system's GTK theme, which makes it much less jarring when tabbing into/out of it and there's a much wider selection of stunning GTK themes out there than there are for any theming system used in only one application.

At least with GTK, the system theme provides a lot of good-looking defaults: application background color, document background color, text color, highlight color, checkboxes and sliders, tons of icons, window border style + window button look and arrangement. These are all complete with shadowing and optional animations (e.g. when checking/unchecking a checkbox, hovering over the window close button, etc) that are again, themeable. There's no way that we're going to be able to replicate these animations & such if we do all our theming by hand.

As an example, here's a GTK theme that I think would suit LMMS well:

It contains good-looking background colors, checkboxes, sliders, drop-down menus and highlight colors (blue and green).

But you can also do more than is easily possible with our current theme engine. For example, you could take Umcaruje's colored window title example & take it further by texturing it, as well as the window backgrounds, etc:

(Note: I dislike the above theme, but it was the first one I could find that shows color & texture)

Trying to extend Umcaruje's theme to be textured with our custom theming system would be, I imagine, more difficult & as said, animations (which the above screenshot can't illustrate) are near impossible.

There are of course lots of places where an application needs to leverage its own theme, too. For example, your system theme won't describe how to render the notes on a piano roll or how to draw a know control. However, it will provide a consistent color palette that you can choose from to make sure these objects look good.

My thoughts are that we should leave the basics (background colors, text colors, window borders) to the system theme when possible, and only make use of our own theming for things where the system theme doesn't provide enough context (e.g. how rounded the piano roll notes are, etc). Keep in mind that you can create your own system themes, so going this route actually makes theming more capable, due to the possibility of animations, etc. I'm not actually sure to what extent Qt can be made to follow system themes, but if it's possible, I think it should be the preferred route.

[tresf]

I'm always a fan of native look-and-feel as an option (perhaps not necessarily as a default) although I don't believe MDI's work with native themes as the rest of the components can.

[RebeccaDeField]

We could try making the users GTK theme the default with the option of selecting a custom theme. Maybe there could be a setting somewhere with a checkbox "Use GTK theme." Chrome does something simalar to that.

I usually prefer themes that have been created manually for pograms. This is just my preference though, and I'm sure a lot of people would prefer it to be like what @Wallacoloo is talking about. That is why I think that having both options is important.

[programnoir]

@Wallacoloo has a significant point, but I will also add that if we choose to rely on the system's default theme, it's going to come with some challenges. I'm not against system themes at all, I love the idea, I'm only stating for the record that it's not as simple as other applications might be. For one, LMMS uses special icons that GTK themes might not provide. We could rely on system colors, but we would need to have icon themes available to go with said GTK themes, too, ones that can be styled to match (I think SVGs actually can do this? I am no expert on SVGs).

The other challenge of course would be platform compatibility. Windows, OS X, and GNU/Linux all have their own system themes, and it's going to be a project in itself to figure out how to make all three work.

That's all that I'm outlining in the discussion. It's not a refutation or an attempt to shut down system themes. I think it can and probably should be done. These are just the obstacles that we have to get over. Artists and programmers are going to have to work together on these obstacles.

[Wallacoloo]

Yeah, it definitely seems like the consensus, and the most reasonable thing to do here, is to continue how we are with the title bar theming. Maybe we can target system theme options during some future UI overhall.

[BaraMGB]

Actually I need to know how to continue with this. I add some QProperys and now one can change the color of the titel bar (and text color and border color) by style.css

[programnoir]

@BaraMGB if you ask me, I think it'd be great if we could turn the title bar into two corner background images and a middle horizontally-repeating background image connecting them together. You could simply draw these three images on top of your current CSS-able rectangle, and if themers didn't want any one of those four graphical elements, they can hide them all using display:none. Bonus points if we can make it possible to set the widths of the corners. If we did this, themers would be able to make those gimmicky techy-looking cyber-frame images that you see on Emerald themes all the time MAN I love those!

[RebeccaDeField]

@circuitfry I think that idea would compliment some of the themes greatly.

I also think that we should move forward with some simpler title bars that match the current default theme for now. Getting something clean and simple in place would greatly improve the interface.

We can definitely put something more complex and customizable in place later.

Of course, this is just my opinion on the matter :)

[IvanMaldonado]

Can I ask the status of this? btw @Wallacoloo How is that gtk theme called? looks pretty.

[BaraMGB]

Feel free to checkout my repo and test it. https://github.com/LMMS/lmms/pull/2516 The color can be changed in the styles.css. This hack paints over the old title bar. Therefore you can't change the height of this. And also this corners can't be changed. I think in this case pictures are a little bit too much for this. Perhaps we can add a gradient? But please at first test this out.

[Wallacoloo]

@IvanMaldonado the first GTK Theme (with the dark colors, blue and green) is Flat-Plat.

[BaraMGB]

Okay, I added a gradient. The properties for the window decoration are now:

• qproperty-activeDecorationColor1
• qproperty-activeDecorationColor2
• qproperty-inactiveDecorationColor1
• qproperty-inactiveDecorationColor2
• qproperty-leftUpperBorderColor
• qproperty-titleTextColor
• qproperty-titleTextShadowColor
• qproperty-windowBorderColor
• qproperty-windowDecorationBorderColor

[Umcaruje]

@BaraMGB I think this is a wrong approach. You should make activeDecorationColor and inactiveDecorationColor properties QBrushes and then easily just define the gradient in CSS, like we do for the song editor

Random example from the Qt Website:

qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1,
                                 stop: 0 #E1E1E1, stop: 0.4 #DDDDDD,
                                 stop: 0.5 #D8D8D8, stop: 1.0 #D3D3D3);

Another thing: why do all of these colors need to be QProperty's?

The decoration color could easily be background-color and the text color could be color. the border could also probably be done by normal css syntax. Also active windows could have their colors defined using the :active CSS selector, which is a valid CSS Pseudo class.

The name titleTextColor is also redundant to me, since there isn't any other text on the windows except the title. It should simply be textColor.

[Umcaruje]

Closed by #2516

[tresf]

Anyone having issues with the maximize/restore functionality of #2516? The top left can be used to restore, the title can be double-clicked to restore, but the top right shows the maximize icon and doesn't do anything once maximized.

[BaraMGB]

@tresf I don't understand you. Can you give steps to reproduce the issue?

[tresf]

@BaraMGB disclaimer, it could be a Mac bug (I was testing a Mac-specific item when I noticed it).

1. Open a new project
2. Maximize the song-editor using the maximize button in the upper right corner of the song-editor window
3. Try using that button to restore (doesn't work)
   • Expected behavior, the maximize button should turn into a restore button and clicking it should restore the song-editor window.

The screenshot provided in the above post illustrates that a maximized window on Mac still shows the "Maximize" icon. A work-around for this behavior is to double-click the title bar, or to use the context menu from the opposite corner.

[BaraMGB]

@tresf Can you provide a full screen screenshot? I think, I have a clue what's happen on mac with the title bar. On Linux the title bar disappear and these three buttons are shown in the main window menu bar. I think, on mac there isn't a main menu bar. BTW I wonder, what's happen on Ubuntu with Unity? In Unity the menu main bar looks similar to the mac. I have to check that. That's on Gnome:

[BaraMGB]

On Unity it's ugly but no bugs:

It's really strange: you can drag this bar and drop it on all four edges of the window or have it as floating window. Canonical hacks a lot only for looking like mac. :clap:

[tresf]

@BaraMGB what you are describing is correct, the title bar stays on Mac. Is this something we can accommodate?

P.S. we turn off the Unity behavior in our desktop shortcut:

https://github.com/LMMS/lmms/blob/master/cmake/linux/lmms.desktop#L9

[BaraMGB]

@tresf I have tried to fix that blind. Can you test this branch? Or should I make a pull request yet? https://github.com/BaraMGB/lmms/tree/SubWindowDecoMac

[tresf]

Quick testing.... No luck with this patch. Doesn't seem to enter the block as the maximize button never changes to the restore button.

        m_maximizeBtn->show();
+       if( isMaximized() )
+       {
+           m_maximizeBtn->hide();
+           m_restoreBtn->move( middleButtonPos );
+           m_restoreBtn->show();
+       }
    }

[BaraMGB]

@tresf I think about it.

[BaraMGB]

Okay, next try. I implemented an own restore slot. Sorry, new branchname : https://github.com/BaraMGB/lmms/tree/SubwindowDecoMac @tresf