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

It seems like that bug should be fixed in FlatButtonWithToolTip then.

with different styles, this can look like:

Do we even need to manually specify the width and height at all? To me they look just fine without these lines:

Basically a tweaked 21430984e5a4 up for review, which I reverted since @ngraham raised concerns

qqc2, with patch for desktop style

In D21920#482449, @ngraham wrote:

If you do so, you may hit https://bugs.kde.org/show_bug.cgi?id=405541. But maybe you can find a clever way around that (or just fix it) that I didn't find. :)

If you do so, you may hit https://bugs.kde.org/show_bug.cgi?id=405541. But maybe you can find a clever way around that (or just fix it) that I didn't find. :)

This is a CCBUG: 405144. You could probably upgrade it all the way to BUG: by porting the menu, too.

@lshoravi ping! Any chance we can finish up work on this icon and get it in?

In D21911#482191, @ngraham wrote:

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

In D21911#482195, @mgallien wrote:

In D21911#482191, @ngraham wrote:

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

I do not think it is such a good idea.
We should better try to use the passive notification by using more components from Kirigami instead of removing them.

In D21911#482191, @ngraham wrote:

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

+1, though these messages are currently not very useful because they're not actionable. If loading or saving of the playlist failed, what can I do about it? it's not clear. Especially for persistent messages, it's worth it to try to make them actionable somehow. Options include a better error message, a "Try again" button to preserve the illusion of user agency, etc.

Thanks

Thanks

Thanks

+1, makes sense!

This has always bugged me.

• limit button size so that it does not expand past the delegate height

Forgot to check the album view, buttons are currently too big

Thanks

I am looking at it.

Perfect!!!! The code looks good and the behavior is now excellent. I can clearly see what has focus and navigating the whole app with the keyboard is a breeze. It looks great too. I'm not totally sold on having all the backgrounds animate their opacity and color (we just got rid of that in QML comboboxes in fact), and it feels like something that should be in the style rather than hardcoded in the app. However that's a really minor aesthetic jusgment call and we can think about it later (or not). Huge +1 for landing this. Great work!

• emulate focus beahvior of list view as shown in feedback
• fix views displaying tracks to have the same focus logic than playlist
• fix keyboard focus issues whith NavigationActionBar and tab navigation
• fix focus issues in ListView of single tracks
• fix qml warning in FrequentlyPlayedTracks and RecentlyPlayedTracks views
• fix small differences between list based views
• Elisa sidebar with colored backgrounds
• improve focus handling of view selector list
• solve some keyboard focus issues
• fix tab focus handling in some list views (playlist and album view)
• for consistency, put the same behavior for generic grid views
• add mostly the same focus behavior to file browser

In D21081#472324, @ngraham wrote:

In D21081#471893, @ngraham wrote:

I think the leftmost sidebar list items with text and icons are just fine; no need for a fundamental change there. :) All I think needs to happen is that the selected list item should be indicated by giving it a blue or gray background like all other list items have, rather than changing its text color or drawing a frame around it.

Here's a patch for this patch that more or less does what I have in mind:

P395 Elisa sidebar with colored backgrounds

1	diff --git a/src/qml/ViewSelector.qml b/src/qml/ViewSelector.qml
2	diff --git a/src/qml/ViewSelector.qml b/src/qml/ViewSelector.qml
3	index c391a34..a8f9a8c 100644
4	--- a/src/qml/ViewSelector.qml
5	+++ b/src/qml/ViewSelector.qml
6	@@ -91,19 +91,18 @@ FocusScope {
7
8	Rectangle {
9
10	- border {
11	- color: ((viewModeView.currentIndex === index && rootFocusScope.activeFocus) ? myPalette.highlight : "transparent")
12	- width: 1
13	- }
14	-
15	- Behavior on border.color {
16	- ColorAnimation {
17	- duration: 300
18	+ color: if (viewModeView.currentIndex === index) {
19	+ if (rootFocusScope.activeFocus) {
20	+ return myPalette.highlight
21	+ } else {
22	+ return myPalette.mid
23	}
24	+ } else if (itemMouseArea.containsMouse) {
25	+ return Qt.rgba(myPalette.highlight.r, myPalette.highlight.g, myPalette.highlight.b, 0.2)
26	+ } else {
27	+ return "transparent"
28	}
29
30	- radius: 3
31	-
32	anchors.fill: parent
33
34	Loader {
35	@@ -197,14 +196,6 @@ FocusScope {
36	duration: 150
37	}
38	}
39	-
40	- color: (viewModeView.currentIndex === index || itemMouseArea.containsMouse ? myPalette.highlight : myPalette.text)
41	-
42	- Behavior on color {
43	- ColorAnimation {
44	- duration: 300
45	- }
46	- }
47	}
48	}

In D21081#471893, @ngraham wrote:

I think the leftmost sidebar list items with text and icons are just fine; no need for a fundamental change there. :) All I think needs to happen is that the selected list item should be indicated by giving it a blue or gray background like all other list items have, rather than changing its text color or drawing a frame around it.

In D21081#471808, @mgallien wrote:

In D21081#471745, @ngraham wrote:

Humongous improvement so far! One thing that sticks out is that the left-most sidebar list still needs the new style for selected categories so that it matches other list-style items:

Thanks for your review.
When I saw it, I was already working on the left most sidebar. I am hesitant to keep the current design with only the text and icon used to indicate state of an entry. I find it simpler but still easy to use. At the same time, it could break consistency (even though it is not music content but application UI state).

In D21081#471745, @ngraham wrote:

Humongous improvement so far! One thing that sticks out is that the left-most sidebar list still needs the new style for selected categories so that it matches other list-style items:

Humongous improvement so far! One thing that sticks out is that the left-most sidebar list still needs the new style for selected categories so that it matches other list-style items:

@jguidon any news on this?

• emulate focus beahvior of list view as shown in feedback
• fix views displaying tracks to have the same focus logic than playlist
• fix keyboard focus issues whith NavigationActionBar and tab navigation
• fix focus issues in ListView of single tracks
• fix qml warning in FrequentlyPlayedTracks and RecentlyPlayedTracks views
• fix small differences between list based views

This is functionally much better! Now I can tell where the keyboard focus is. Visually I think it's a small improvement but we can do even better for the list and grid items and also be more consistent with how other apps generally handle this.

• use a rectangle around the current item with focus in view selector
• use rectangle borders to show the active focus in most elements

Works for me, thanks.

Ping.
I would like if possible to get this in before end of next week to have in the 0.4.0 release.

In D21080#462505, @ngraham wrote:

Looks good now! BTW it's unrelated to this patch, but I notice that song length display in the playlist has regressed in the last day or two:

In D21081#462497, @ngraham wrote:

This works, but to be honest I really dislike this focus rectangle in every view where it appears in Elisa. I don't think it matches Elisa's visual style at all. See how the blue rectangle touches the vertical line on the left, but it's a few pixels away from the line on the right? And it also isn't actually framing anything since Elisa's views don't use gray frames. So it appears "out of the blue", so to speak.

I feel like a cleaner focus indication style for a modern app like Elisa is to highlight the particular control or list itemthat currently has focus, rather than drawing a colored frame around an entire view. For example in your screenshots, instead of drawing a blue frame to indicate that the view has focus, I would make the song highlight blue rather than gray. This actually communicates more information: not only does it tell you that the view has focus, but you also clearly see which exact element within the view has focus.

Looks good now! BTW it's unrelated to this patch, but I notice that song length display in the playlist has regressed in the last day or two:

Can't test, but seems fine.
Thanks for informing! :)

This works, but to be honest I really dislike this focus rectangle in every view where it appears in Elisa. I don't think it matches Elisa's visual style at all. See how the blue rectangle touches the vertical line on the left, but it's a few pixels away from the line on the right? And it also isn't actually framing anything since Elisa's views don't use gray frames. So it appears "out of the blue", so to speak.

This looks much better, thanks. It makes sense that font.pointSize should be rounded to an integer value.

try to include only the correct commit

an extra commit from 0.4 is included

In D21043#462261, @ngraham wrote:

This now works!

However I'm left to wonder why all this rigamarole with TextMetrics is even necessary at all. I notice that if I remove all the TextMetrics components, and let the labels auto-size themselves by removing Layout.fillWidth and Layout.maximumWidth, everything works fine except for the artist label, which gets elided. But I notice that it only gets elided when the point size is set to elisaTheme.defaultFontPointSize * 1.5. If I change the multiplier to 1, 1.4 or 2, it works. However a multiplier of 1.5, 1.75, or any other odd value triggers the bug. This is reproducible for all fonts and sizes that I tried.

I don't understand this bug, but a less invasive workaround might be simply to change the multiplier a bit rather than do all this stuff with TextMetrics.

elisa.patch3 KBDownload

• use Math.round to avoid having a font.pointSize being decimal

This now works!

• fix corner cases by adding an extra length

I'm afraid even with this latest update to the patch, I still see elided text. :(

In D21043#461888, @ngraham wrote:

11 pt Ubuntu font. I see the same thing with default 10 pt Noto Sans though:

As you can see, it's even worse with default settings since the four-letter album name gets elided too.

• use the correct way to get the width of the text

11 pt Ubuntu font. I see the same thing with default 10 pt Noto Sans though:

In D21043#461657, @ngraham wrote:

For me this patch re-introduces the original bug (https://bugs.kde.org/show_bug.cgi?id=406483).

Would this be for music visualizations, by chance? As in spectrum analyzers, etc?

For me this patch re-introduces the original bug (https://bugs.kde.org/show_bug.cgi?id=406483).

In D21039#461350, @broulik wrote:

Does Plasma crash because of this or Elisa?

Does Plasma crash because of this or Elisa?