On Fri, Dec 27, 2013 at 3:01 PM, Kevin Krammer <[email protected]> wrote: > On Thursday, 2013-12-26, 15:34:03, Jerome Leclanche wrote: >> I'm sorry, you're right. I should have been clearer. >> >> I need this functionality for intents, but I was just trying to >> display that I'm not the only one actually needing it (and that it's >> not just theoretical). > > I have to admit I didn't follow that closely enough, but wouldn't the program > authors have to specify the invocation for intents instead of relying that the > program without arguments is the correct one?
Not specifically - intents don't inherently run a program any more than the shared-mime-info spec does. They only determine which programs should be ran. For DBus-activatable apps this is a non-issue of course but not all programs are like that. > >> Currently, Wine creates the sort of desktop >> files I pasted in the original post. This causes runners (like >> lxqt-runner) to think those programs should be displayed when you >> start writing "env" (they are completely irrelevant and the use of >> "env" is an implementation detail). > > Hmm. I guess if you type "env" you would like to have /usr/bin/env as a > suggestion, no? > The runner that searches $PATH would detect that already. > > If there is a runner that gives suggestions on .desktop file Exec lines then > those are relevant hits as well. I would have guesses that the .desktop > runner only checks name and description though, since the command line is > usually hidden from the users and wouldn't tell them anything. Yup, all well and good, and the current behaviour on the runner's side is the correct one. However you're unlikely to want nearly every Wine app if you type in "env". Currently, /usr/bin/env is the only way to modify the environment for the program being ran, which creates this conflict. > >> I should probably have written two separate mails for this but this >> seemed relevant. Anyway, that specific use case is fixed with an >> Environment key, which would be easy enough to implement (and >> backwards compatibility would be unharmed). > > Sure, though I am not convinced that it is necessary, mostly because it is > only one of potential runtime requirements. > A start script can easily deal with environment setup additional to any other > setup stage, e.g. launching a service. It can even make decisions on the > already existing environment, like the user as Ma Xiaojun mentioned > > Anyway, not really related to the No Args use case. Yeah, as I said earlier I should have written two separate emails as those bits are only loosely related. The way I see it, there is an existing runtime requirement of modifying the environment (and if you think about it for a bit, it's not surprising). I would cast a strong vote in favour of an Environment key to solve that issue. systemd's service files are a good glimpse of various requirements on an app's side. Of course they are more thorough as more than just startup is required (systemd also wants shutdown and reload/restart and has a heap more functionality), but some of it overlaps and this is a good example of one I'd say. > >> More generic: >> desktop files make the assertion that starting a program is inherently >> the same *with* and *without* arguments. This is declaratively very >> annoying, because it prevents programs from having a different command >> line for args / no args. > > True, good point. > >> I guess it is too late to fix it, but my backwards-compatible proposal >> would do the job for apps that care about it. If it's missing, we just >> assume the app starts the same way with and without args. > > I don't think it is, there is always room for improving the spec. > > After thinking about it a bit more the name ExecNoArgs might be a bit > confusing. The command line specified in it could very well have arguments, > just no variables. > > Also, if present but empty, that could be treated as "cannot be launched > without file/urls". Agreed on the name; I don't like it either I just needed a clear example. I don't think it's too late to fix the spec from an implementation point of view, but it does feel like it's too late to convince people this is worth the modification (and I don't have time to defend tooth and nail fixes to all my pet peeves). The "present but empty" functionality has interesting potential. > > Cheers, > Kevin > > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > J. Leclanche _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
