rofi -show drun hides options if .desktop names repeat

[unode]

Version

% rofi -version
Version: 1.5.2

Configuration

https://gist.github.com/unode/ddf571a9cd187fde3ca9f34030737c2f

Launch Command

rofi -show drun

Steps to reproduce

• 1 - Copy a .desktop file from a system folder (/usr/, ...) into ~/.local/share/applications keeping its original name.
• 2 - Edit the content of the .desktop file to have a different Name= and Exec=.
• 3 - Launch rofi and see the system .desktop get ghosted by the copy
• 4 - Rename the copied .desktop to have a unique name
• 5 - Launch rofi again and the system .desktop should be visible again

What behaviour you see

In step 3 I could only select the custom firefox.desktop in my home folder.
Doing step 4 fixed the issue.

What behaviour you expect to see

All options should be displayed regardless of the name of the .desktop file.

[DaveDavenport]

This is correct and follows the specification.
https://specifications.freedesktop.org/desktop-entry-spec/latest/

See the ID part:
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id

 If multiple files have the same desktop file ID, the first one in the $XDG_DATA_DIRS precedence order is used. 

[chabad360]

That would be fine, but if the first one is marked as hidden (i.e. by kmenuedit) then it wont show at all.

[DaveDavenport]

I think that is exactly following the specification. Allowing you to disable items this way.

[sardemff7]

I can confirm that.

[chabad360]

I think that is exactly following the specification. Allowing you to disable items this way.

True, except that in a situation where you have your shortcuts organized (cause it seems like the old behavior had it that rofi would show Entry, Entry (1), etc.) so now if you hid the wrong one, you don't see anything...

[DaveDavenport]

I am unsure what you want to us to do?

I think it is important to achieve compliance with the specification.

[chabad360]

I am unsure what you want to us to do?

What I want is just to revert to the old behavior or an option to control it (i.e. rofi.show-duplicates or --show-duplicates, etc.).

I think it is important to achieve compliance with the specification.

Even gnu-utils doesn't have perfect compliance with POSIX, and this is minor non-compliance, yet it removes a lot of confusion and fustration.

[sardemff7]

You must follow the spec and name your .desktop file differently (and edit the Name= key), and it’ll magically work just the way you seem to want.

Edit: bonus points, it’ll work in any compliant tool, isn’t that amazing?

[chabad360]

@sardemff7 Thanks, but no thanks. I'm not gonna spend time going through my applications list to change the names of all the ones marked hidden, so that it will work, that's not time I'm interested in wasting...

Is it that hard to add some sort of non-compliant switch?

I'd gladly try my hand at making a PR but I'm currently very busy doing a lot of other (non-dev) things... Plus I'm not very good with C (yet)

[sardemff7]

Non-compliance is a no-go. If one user is not willing to spend time to fix their setup, we are not willing to spend time maintaining (for years!) code that doesn’t fit the spec and will be used by a tiny minority of users who will eventually move to another tool and never test that code ever again.

[chabad360]

Non-compliance is a no-go.

I understand that, but I don't think that it's necessary to be so strict here as it's not adding or removing from the spec, it's simply not breaking the loop by the first option.
Plus, (yes, two wrongs don't make a right, but) there are many other programs (yes, wildly used ones) that don't perfectly comply with not the free-desktop spec, or even POISIX.

If one user is not willing to spend time to fix their setup

Which will be required after most updates, which really makes it not worth the effort. You may as well go around convincing everybody to make sure their software doesn't generate 2+ .desktop files (which a huge amount of programs do).

we are not willing to spend time maintaining (for years!) code that doesn’t fit the spec

All I'm asking for is the ability to set a flag to ignore this, I (from my experience, I haven't looked over the codebase yet) don't think this is that much of an effort to add, and I believe that it has an extremely low maintenance cost.

who will eventually move to another tool

why do you say that?

[chabad360]

https://github.com/davatorium/rofi/blob/47079270313d0f495952e4569073d268acd57536/source/dialogs/drun.c#L278-L281

These seem to be the lines at fault, now I need to figure out if/how we cat get any args/config options that are set...

[chabad360]

957 is PR that would fix that issue using a settable arg