Multiple desktop file entries are shown

Question

Multiple desktop file entries are shown

FunctionalHacker opened this issue 5 years ago · 7 comments

As the title says, the launcher has been showing multiple entries for (I think) all desktop files.

Here is a screenshot

Answer 1 · 2020-01-09T14:24:48.000Z

Thank your the issue and good to see you again :) If my eyes are not deceiving me, one of them is the history entry (in white) and one is the actual desktop file.

I am aware of this behaviour, but I always felt it's not worth going through the effort of attempting to sort out items that are already appended from history. We can't sort -u since we need to keep the order of items (we do want the history at the bottom).

Existing solutions found on the internet usually deal with duplicates not appearing again, while we need more or less the opposite behaviour.

Maybe this could be adapted so it cleans out the PROVIDERS while using HIST_LINES as a reference... dunno

So I have not yet found a simple solution for this and could not bring myself to dig deep into this, honestly. If you have some ideas on how to do this elegantly or could even provide a PR, then I'd happily look at it, though

Answer 2 · 2020-01-09T17:31:12.000Z

Thanks for the info. If I find the time, I can try to whip up a PR during the weekend, but no promises 😄

Answer 3 · 2020-01-16T19:42:14.000Z

Okay I have to say that I think my bash/unix skills are not to par to be able to fix this. I hope somebody else will take on the challenge 😄

Answer 4 · 2021-05-29T03:11:51.000Z

should we expect this behavior to disappear? it's still annoying))

Answer 5 · 2021-05-30T05:32:38.000Z

For now, it is a conscious tradeoff because I believe the cost of fixing it is too high.

We'd have some 10k lines to check for duplicates (while keeping sort order) on every invocation, so it might come at a performance penalty in addition to the complexity of the implementation itself.

I would be very happy about suggestions to solve this elegantly though

Answer 6 · 2021-09-12T16:01:19.000Z

I've investigated this a bit too, and from what I found, it's because sway-launcher-desktop looks in multiple directories for .desktop files, as well as binaries. The directories I've found it looks in are:

$HOME/.local/share/applications/
/usr/share/applications/
/usr/local/share/applications/ (which doesn't exist on my system)

Maybe we could make it prioritize .desktop files from $HOME/.local/share/applications/ above the others, as this is commonly used when a user want's to modify a .desktop file in one of the other locations (e.g. making Firefox always use Wayland). What I mean, is that the script would find e.g. firefox.desktop in $HOME/.local/share/applications/, and then if it finds another firefox.desktop in one of the other locations it would ignore them.
Does this sound like a reasonable approach?

EDIT: It does actually does this. Just tested again after deleting the history file, now it doesn't show duplicates anymore.

Answer 7 · 2021-09-14T07:31:03.000Z

EDIT: It does actually does this. Just tested again after deleting the history file, now it doesn't show duplicates anymore.

Yeah there's a test for this behaviour.

This issue here is really about the fact that the contents of the history file are essentially tacked on after the commands and desktop entries have been produced. It is not trivial to remove the duplicates resulting from this behaviour under the constraints that we have (support arbitrary providers & keep history entries at the bottom). Possible, sure, but probably not in a handful of lines and probably not without a performance hit.