+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?

In D21006#460908, @mgallien wrote:

Currently, Elisa is not really an application built around the idea of having a big and complex application menu bar.
This is the reason why you see only one menu.

In D21006#460601, @trmdi wrote:

Why is it like this:

instead of this?

I mean, can we have some more Menu instead of only Elisa ?

In D21006#460544, @ngraham wrote:

Seems to work perfectly. My only UI suggestion is to hide the hamburger button in the window when exporting the menu like this.

Why is it like this:

Seems to work perfectly. My only UI suggestion is to hide the hamburger button in the window when exporting the menu like this.

So much better now!

Yep, a cleanup of my Baloo database fixed it, so that looks like a Baloo bug rather than an Elisa bug. Upgrade works now.

In D20944#459666, @ngraham wrote:

I'm not sure whether it's related to this or not, but now I get stuck on a particular song again. I can paste the full log, but the last item seems revelant:

org.kde.elisa.baloo: LocalBalooFileListing::triggerRefreshOfContent "/home/nate/Music/Franz Ferdinand/Franz Ferdinand/10 Come On Home.mp3" file does not exists

Sure enough, I deleted that song a few days ago.

I'm not sure whether it's related to this or not, but now I get stuck on a particular song again. I can paste the full log, but the last item seems revelant:

In D20879#458857, @ngraham wrote:

Out of curiosity where on disk is the database located, and is it safe to blow away for testing purposes?

In D20929#458998, @pino wrote:

Looks ok now, thanks for the changes.

Looks ok now, thanks for the changes.

• simplify the QDir::rename usage

• remove the #if

In D20929#458881, @pino wrote:

Or, even better, just unconditionally use QDir::rename? This way there is no need to maintain two different code paths with a number of arbitrary #ifdef blocks.

Or, even better, just unconditionally use QDir::rename? This way there is no need to maintain two different code paths with a number of arbitrary #ifdef blocks.

Seems sensible.

Out of curiosity where on disk is the database located, and is it safe to blow away for testing purposes?

In T7567#183516, @jguidon wrote:

Hello,

Just to keep you updated about my progress, I could read a radio stream within Elisa. I also could get some information from the stream like the current played song and update the information in the interface (in the headerbar and the playlist).

In D20879#458165, @ngraham wrote:

It would be nice to fix it without re-importing, yes. If that's necessary, it should happen automatically. Does that already happen for people who upgrade from one stable release to another?

Just to keep you updated about my progress, I could read a radio stream within Elisa. I also could get some information from the stream like the current played song and update the information in the interface (in the headerbar and the playlist).