Ok, I now see how this is working out. So the existing code tries to turn the first ref send to the application into a command line argument by waiting for the first ref to arrive, suppressing the event for it and copying it over to argv.
I think we should remove this workaround, IMHO it causes more trouble then it solves:
It is not reliable. The application might have already parsed the argv before, thus not receiving the file even if the application does otherwise the right thing (listening to FileOpen events). Cases where argv is parsed before Qt gets initialized include Picard and Audacious¹
It works only for a single file. As soon as one selects multiple files for “Open with” it breaks unless the application implements FileOpen. And if it implements FileOpen this hack is not needed anyway.
It does not work for the case where the user drops a supported file type on the deskbar, this will always require FileOpen support.
I think the proper way would be to remove this workaround and instead see to patch affected applications for FileOpen support. I have updated my pull request to remove the workaround completely.
If you think we should still keep it I would suggest making it opt-in instead. E.g. we could set an attribute (e.g.
QT:REF_TO_ARGV) on the executable and only apply the workaround if this attribute is set. Or if you really want to have it default, at least have a way to opt-out of this behavior. What do you think?
¹ I previously reported Audacious would be working, but that was not true. I fooled myself because Audacious as a player remembers the files already opened. Actually Audacious does not work with the current approach, as it parses argv to early, and also not with the patched version, as it does not handle FileOpen. Proper thing would be to patch Audacious for FileOpen support.