I have updated the diff. Elements focused using tab key will be triggered by Return Key. SpaceBar is assigned global shortcut for play-pause action and won't trigger elements focussed using tab key. Should work for most part.

Ok lets look into it. It might be done through an ugly hack using event filters, but i have to research up a bit.

So maybe it should, or maybe using the space bar should continue to click the selected element when that element was selected using the tab key.

Yes, but elisa doesn't click the elements under focus even through the return key.

For example the mute/unmute button.

@ngraham can you please specify on which element did you navigate to. I tried to replicate it, it does as you mentioned, on the navigation action bar. But not on the elements outside it. And the purpose of the patch was to perform playpause action irrespective of focus. So probably blocking all the tab events of navigation action bar should do the job.

maybe i need to do the job using event filter instead of the usual shortcut mechanism used by Elisa

I notice that after navigating to an element using the tab key, hitting the spacebar does correctly trigger that element rather than doing play/pause, but then the just-triggered element is no longer selected afterwards. We should probably preserve that.

Added context to the diff. Thanks @shubham.

Ok i will start using archanist ASAP

In D17994#391102, @ashwind wrote:

I used archanist to apply the patch. It is working fine for me.

I used archanist to apply the patch. It is working fine for me.

Made the shortcut configurable. I actually did a "git pull" and updated the feature out from a fresh repo. It should work now.

Ok, I will look into it.

Thanks for your patch.

Thanks! I'll let @mgallien land this for you when he's ready.

Name: Ashwin Dhakaita
Email: ashwingpdhakaita@gmail.com

In the meantime, @ashwind, we will need you to provide your full name and email address so we can land this patch with the correct authorship information.

Thank you, @mgallien. I will apply for one after sometime then.

In D18017#390492, @ashwind wrote:

I don't have a developer account. Please land it for me.
Actually, I am new to KDE and don't know about Developer Account. I will sign up for one.

I don't have a developer account. Please land it for me.
Actually, I am new to KDE and don't know about Developer Account. I will sign up for one.

In D18017#390169, @mgallien wrote:

Nice work. Thanks for your help.

In D18017#389338, @ngraham wrote:

Oops, I should have realized that!

BTW @mgallien, it's off-topic for this patch, but I wanted to express my happiness over how good Elisa is these days. It's becoming really excellent. The full-screen view is so beautiful and compelling! I plan to contribute a lot in 2019. Once we get https://bugs.kde.org/show_bug.cgi?id=401969, I'm ditching Lollypop and moving to it full-time.

Nice work. Thanks for your help.

Well, I made the shortcuts configurable.

Sorry, I will look into it. 😕😕

Oops, I should have realized that!

Thanks for your patch.
In order to better integrate it in the application, it would need to be configurable like other existing shortcuts. In order to do that, you can look at the ElisaApplication class.

Very cool!!! Works great for me.

Thank you Sir 😊

This works great, I love it. It's up to the Elisa devs of course, but this gets a thumbs up from me.

Well I cleared up the trailing whitespaces.

Ok.

Thanks for the patch! There are a lot of unintentional trailing whitespace changes here. Do you think you can clean those up?

Sorry, forgot to write a comment. This is not meant to be merged right now, I wanted to start a discussing which type of menu Elisa should use, e.g. the item-based (standard qqc2) or the native one (Qt.labs).
Both currently have issues which need to be fixed first.
I have at least an idea what could be done to fix the item-based solution, and I have no clue what's going wrong with the native solution.

Working good so far. Memory usage seems to have dropped a little with my smaller music collection. Tracks with an empty artist tag are also correctly displayed in the all tracks view.

In D16302#361032, @astippich wrote:

Since this revision is quite large, it's probably difficult to review it properly. I'm going to let it run a little and report back in case I find any issues.

• fix errors when inserting multiple albums with same title
• really cache only artists and not the other people
• fix import of tracks with paths containing particular character like { }

In D16944#362538, @mgallien wrote:

After the tests I had done, I am convinced that we should first fix the stack used by Elisa before pushing this kind of changes.

The menu is no longer a sub window manage by the windowing system. Is this really a good idea ?

In D16302#361032, @astippich wrote:

Since this revision is quite large, it's probably difficult to review it properly. I'm going to let it run a little and report back in case I find any issues.

• rebase
• cleanup

Since this revision is quite large, it's probably difficult to review it properly. I'm going to let it run a little and report back in case I find any issues.

• allow tracks without artist

• reduce overhead from AllTracksModel
• reduce overhead of AllAlbumsModel and make it synchronous
• do not list files too early from Baloo
• keep all files discovered from a source and fix a minor related issue
• add a test for DatabaseInterface::askRestoredTracks
• add albums and artists cache and improve cache usage
• improve management of files not modified since last scan of music files

ping