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).

In D20880#458660, @Nilsolm wrote:

In D20880#458531, @mgallien wrote:

Thanks for your work.
Please can you add the required version for Kirigami in the CMakeLists.txt file ?
Apart from that, this is fine for me

Gladly. That would just mean setting the required Kirigami version to 2.5.0 instead of using the required KF5 version, right?

In fact, kirigami2 has the same version than other KF5 frameworks. I will land your patch without the CMakeLists.txt change. Sorry for that.

In D20880#458546, @ngraham wrote:

Nice! Can you provide your full name and email address so we can land this with correct authorship information once @mgallien has accepted it?

@mgallien looks like we already have Kirigami listed in CMakeLists.txt, and I think Units has been around in it since forever-ish.

Sure, name is David Koermendi, email is nilsolm(at)vivaldi(dot)net.

• allow proper load of embedded cover even when database has wrong data

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?

In D20879#457489, @ngraham wrote:

Yep, confirmed that this fixes the issue for all of my albums that lacked art, after re-importing the library. Thanks!

In D20879#457489, @ngraham wrote:

Yep, confirmed that this fixes the issue for all of my albums that lacked art, after re-importing the library. Thanks!

Yep, confirmed that this fixes the issue for all of my albums that lacked art, after re-importing the library. Thanks!

4fc83654f413

@bcooksley thanks for your help

First jobs started - https://build.kde.org/job/Extragear/job/elisa/

Thanks for the information.
I have added a stable branch.
Could you please run the DSL Job Seed job?

The lack of stable builds for Elisa is due to a lack of stable branch definitions in logical-module-structure in the kde-build-metadata repository.
(See the existing Elisa section)

Thanks @bcooksley for your help.

• implement more methods to inhibit sleep (support Gnome and Logind)
• prevent sleep again on Plasma workspace
• remove the calls to logind inhibit interface: does nothing right now

Hello,

In T7567#181665, @jguidon wrote:

Hi,

According to the libvlc documentation, the method libvlc_media_new_location should be nice with some URL: https://www.videolan.org/developers/vlc/doc/doxygen/html/group__libvlc__media.html#gae1d3baee3f4610c6fe5818defcad3e6f .

I am motivated to take a look.