+1, this consolidation makes sense.

• actually add new file

• fix text and apply error type

Please see my comment and other comments

In D22310#493134, @ngraham wrote:

How about only setting the width and height explicitly for the back and sort buttons, and adding TODO or FIXME comments so that we know why it's set?

How about only setting the width and height explicitly for the back and sort buttons, and adding TODO or FIXME comments so that we know why it's set?

• more cleanup

• fix text elide after hovering items

Actually sorry, just found a UI regression.

Very nice.

Thanks, much better! Just one more little thing, then ship it.

In D22332#492786, @ngraham wrote:

+1, but I found two little issues:

• The MouseArea's height is quite short, so it's hard to get the cursor into the right place. I would recommend making it span the full height of the player bar rather than simply just filling the area of the slider.
• When scrolled, the handle's movement on the volume slider is instantaneous, but for the playback position slider it lags about half a second. This is not related to this patch here, but it making it scrollable makes this pre-existing issue more prominent.

• make MouseArea span the whole height

+1, but I found two little issues:

• The MouseArea's height is quite short, so it's hard to get the cursor into the right place. I would recommend making it span the full height of the player bar rather than simply just filling the area of the slider.
• When scrolled, the handle's movement on the volume slider is instantaneous, but for the playback position slider it lags about half a second. This is not related to this patch here, but it making it scrollable makes this pre-existing issue more prominent.

• update and rebase

I actually found a bug: when the icon height and width are not specified, actions using dynamic icons won't work (e.g. icon is dependent on some variable) . The icon will not be displayed. This should probably be investigated, but for now I would like to continue with the specified icon size

In D22310#491944, @ngraham wrote:

As before, I don't like how FlatButtonWithToolTip requires that every button manually specify its own size. I think the FlatButtonWithToolTip should have an adequate default size so that this boilerplate isn't necessary.

+1, this makes perfect sense IMO. Code looks good!

As before, I don't like how FlatButtonWithToolTip requires that every button manually specify its own size. I think the FlatButtonWithToolTip should have an adequate default size so that this boilerplate isn't necessary.

• always enable playlist toggle action

New look:

In D22204#491507, @mgallien wrote:

In D22204#491479, @astippich wrote:

I would very much prefer to merge the code as is and improve afterwards as it touches various place and would be a pain to rebase.

I cannot review it now but it can go if you follow on with any issues that would be found. Sorry for my lack of time.

No worries. Stay cool!

In D22204#491479, @astippich wrote:

I would very much prefer to merge the code as is and improve afterwards as it touches various place and would be a pain to rebase.

I would very much prefer to merge the code as is and improve afterwards as it touches various place and would be a pain to rebase.

+1 for merging them; I noticed the same thing. Maybe that should even be done first or in this patch.

+1, let's use the existing styling here for consistency.

In D21911#488263, @astippich wrote:

So, do we find an agreement here?

So, do we find an agreement here?

Thanks

In D21943#488075, @astippich wrote:

I will commit once the binary factory is on 5.60

I will commit once the binary factory is on 5.60

• raise frameworks requirement

• cleanup and bring back boundsBehavior: Flickable.StopAtBounds

• https://bugs.kde.org/show_bug.cgi?id=380441
• https://bugs.kde.org/show_bug.cgi?id=406897 :not sure about the ratio between cost/added value; To me this is something that I find not very urgent.
• T5230

In D21943#487811, @ngraham wrote:

Though since D21944 is in a framework, perhaps once it lands, we should increase Elisa's frameworks dependency version here, or else the menus will look ugly.

Though since D21944 is in a framework, perhaps once it lands, we should increase Elisa's frameworks dependency version here, or else the menus will look ugly.

In D21943#487761, @ngraham wrote:

@mgallien QQC2 can be styled in multiple ways; the screenshot is just showing the desktop (aka Breeze) style. LGTM in conjunction with D21944.

@mgallien QQC2 can be styled in multiple ways; the screenshot is just showing the desktop (aka Breeze) style. LGTM in conjunction with D21944.

What is the reference of the patch for the desktop style ?

In D12992#486880, @lshoravi wrote:

Using @abetts prototype: No blockers, incorporating the given teal and green colours given by mgallien is TODO.

Otherwise, the blocker would be to find what visual profile Elisa has so that we can work around that.

Using @abetts prototype: No blockers, incorporating the given teal and green colours given by mgallien is TODO.

There is no timeframe. :) I was just hoping this doesn't get abandoned, because it looks rally nice.

Doable! What timeframe are we thinking?

@ognarb, I will take a look at it and see if I can help.

Not the bug is still here:

Still, an external drive but Baloo is now disabled. If you want, I could try enabling Baloo again to see if the bug appears again or not.

In T7597#190058, @ognarb wrote:

Btw retried Elisa with my big music collection, and it works now. :)

Btw retried Elisa with my big music collection, and it works now. :)

Eventually, all metadata should be optional...
I think for database insertion the track title is still the only one that is a hard requirement, but this should also be removed.

Turns out that was some leftover code :) so the ToolButton does the correct sizing. I'll just abandon this one here and open a new one. Thanks for insisting! :)

LOL! That's probably because of the height of the player bar being hardcoded rather than sizing itself according to its contents + top and bottom padding (an anti-pattern best moved away from in QML user interfaces). I think basing this on a ToolButton rather than a Button is more semantically correct since that's what it is, so +1 if you want to do that.

In D21945#484564, @ngraham wrote:

True, but then again these are basically glorified ToolButtons, and you don't need to set the size for every ToolButton; it has a correct default size and you only override it as needed. It just seems odd to me that we have to do this at all, and I feel like it points to a problem in the component itself. It should have a correct default size without us having to tell every instance of it how big it needs to be.

Maybe I'm just being a grumpy pedantic old man though. :) I'll let @mgallien decide.

True, but then again these are basically glorified ToolButtons, and you don't need to set the size for every ToolButton; it has a correct default size and you only override it as needed. It just seems odd to me that we have to do this at all, and I feel like it points to a problem in the component itself. It should have a correct default size without us having to tell every instance of it how big it needs to be.

In D21945#484533, @ngraham wrote:

Maybe we could just make the aspect ratio fixed to square in the FlatButtonWithToolTip control? Then we wouldn't need any custom sizing in the player control bar because the width would be limited by the height, which would be correctly chosen based on the height of the player bar.

Maybe we could just make the aspect ratio fixed to square in the FlatButtonWithToolTip control? Then we wouldn't need any custom sizing in the player control bar because the width would be limited by the height, which would be correctly chosen based on the height of the player bar.

In D21945#484135, @ngraham wrote:

In D21945#484108, @astippich wrote:

Why that? If you do not specify a button size, the style will automatically scale it. Also happes with a plain QML Button

I'm saying that it makes sense to do this change in one place (the parent control) rather than in n places (all the instances of that control).

In D21945#484108, @astippich wrote:

Why that? If you do not specify a button size, the style will automatically scale it. Also happes with a plain QML Button

• fix previous commit

• use Layout.preferredHeight/Width