Examine the impact of desktop file parsing changes to commonly used desktop files

[meator]

Issues like #175 and #174 (comment) have brought this to my attention.

It looks like Wine desktop files do not work with the current system. This is (to my knowledge) a bug in Wine, its desktop files do not conform to the Desktop entry specification. But it still means that the new update could have broken some desktop files.

I am thinking about introducing a long-only flag which would enable the old desktop file parsing if the user wants it. I could introduce several modes such as a) off b) try the new parsing, if that fails, try the old one c) force old parsing e) try to detect whether the parsed desktop file was generated by Wine and if yes, enable old parsing.

I could also implement some escaping hack to make the escapes Wine tries to use in its desktop files work.

The thing I'm unsure about is what the default should be. If anyone is reading this, I would appreciate any feedback. The current behavior is a) (because the old desktop file parsing was completely replaced in r3.1). I was thinking about making b) the new default. This will be subject to change in versions r3.2>, support for the old system should be ideally phased out.

[ph919imperial]

For me, distrobox-export generated .desktop files are also broken because of extra spaces between the Exec arguments. The parser fails to read the arguments so distrobox uses the default container name, breaking the app launch.

[meator]

@ph919imperial Thanks for reporting! I'll try to make all these desktop files functional in the next release.

It is unfortunate that j4-dmenu-desktop will have to employ hacks to be able to support nonconforming desktop files.

[meator]

My plan

I want to create a whole system for enabling "hacks"/backwards compatible behavior. This system would have only two states as of now (but this could be expanded in the future):

1. fully conformant behavior
2. Wine hack: enable backslashes while parsing the Exec key

I don't think that each hack should have it's own flag (my WIP version uses --desktop-file-compatibility). It should be a long-only flag. The usage could look like this (assuming that wine and distrobox are valid hacks (I have made distrobox up)):

j4-dmenu-desktop --desktop-file-compatibility=wine

j4-dmenu-desktop --desktop-file-compatibility=wine,distrobox

The "fully conformant behavior" state should be mutaly exclusive with all other states (you can't have strict behavior and enable Wine hack). Reusing the same flag (--desktop-file-compatibility) for this would lead to poor UX in my opinion.

My current solution is to create a second long-only flag which would be mutaly exclusive with --desktop-file-compatibility.

Completions

I have been trying to implement these changes in completion scripts. I don't really care about the Bash completion script, I don't think I will be implementing mutal exclusivity there (unless it is simple to implement, which I assume it is not in Bash). ZSH supports this. Fish's completion system is simple but limited. I wasn't able to find any resources about implementing mutaly exclusive flags in its completion scripts, but I think that it should be possible. I will do further research.

UI

I am still not sure about the proper way to make a proper UI for this (which flags to add, how to name them and how they should behave). This isn't really a thing that can be fixed later, I can't really change these flags after I put them in a released version. I want to make sure that the UI I implement is correct and meets user's expectations.

I currently only need two states, so adding a --fix-wine would be the simplest solution. But I assume that more hacks will be needed in the future, so I want to make an UI that could accommodate this goal.

My WIP version uses --desktop-file-compatibility=standard to enable strict behavior. I do not like this approach, because I intend --desktop-file-compatibility to hold several values if the user requests it. As mentioned above, invocations such as --desktop-file-compatibility=wine,distrobox should be possible. But --desktop-file-compatibility=standard,wine would be invalid. The standard key would be mutaly exclusive with all other keys. This is an unintuitive edge case. It is difficult to implement this in completion scripts. The strategy I have described above splits the standard state into a separate flag, which is easier to deal with.

Default behavior

The Wine hack will be enabled by default.

Distrobox

I have yet to examine Distrobox's behavior. The Wine hack could fix Distrobox too, I'll have to test that. If that doesn't work, I could introduce a third state/"hack" for Distrobox.

Old parsing system

The "simplest" solution would be to reintroduce the old parsing system, under which all desktop files worked as expected.

I will not remove the new desktop file & Exec parsing system. It is more correct and it gives j4-dmenu-desktop tighter control over the program and its arguments. It took quite a lot of work to implement it correctly (it must integrate well with i3 IPC mode, with Terminal=true apps, with --wrapper, with --no-exec external executors and more). The new system works better in some of these areas.

I would like to avoid adding the old parsing system back. If I had to add it, I would have to implement all the edge cases I listed above twice. Some of them are difficult to implement right, so this would add work. It would require extensive testing.

But if enough users report issues with the new desktop file & Exec parsing system (due to invalid desktop files that rely on nonstandard behavior), I will have to add the old system back.

If that will be necessary, I will support both systems. I will use the new one by default. Detection of faulty desktop files could be implemented. If that is the case, j4-dmenu-desktop could fall back to the old system.

[meator]

https://bugs.winehq.org/show_bug.cgi?id=57329