GNOME Bugzilla – Bug 767732
ocrfeeder cannot be launched with the .desktop file
Last modified: 2018-03-18 14:13:15 UTC
In ocrfeeder.desktop there's the line Exec=ocrfeeder -i %f which is what you use to open a user-provided image, but it does not work if there's none. If you try to simply launch OCRFeeder from the GNOME shell launcher it won't work ("ocrfeeder: error: -i option requires an argument").
I can confirm this. There should be two desktop entries: one with: NoDisplay=True Exec=ocrfeeder -i %f The other with just: Exec=ocrfeeder
Created attachment 366231 [details] [review] Patch for command line parsing A better fix for this, IMHO, is to simply accept image filenames on the commandline as positional arguments, instead of requiring the -i flag. The attached patch does that, using argparse instead of the deprecated optparse. It still supports the -i form for backwards compatibility, and allows mixing and matching so e.g. `ocrfeeder -i one.png -i two.png three.png four.png` will open all four PNG files as images. ocrfeeder.desktop.in is also updated to remove the -i flag.
(In reply to Frank Dana from comment #2) > A better fix for this, IMHO, is to simply accept image filenames on > the commandline as positional arguments, instead of requiring the -i > flag. I actually like this solution, it would simplify things a lot.
Created attachment 367174 [details] [review] Updated patch to accept image filenames as arguments I'm attaching an updated patch, because I noticed that my last one inadvertently removed an import. I'm not sure how that happened. I also fixed the argparse import to be more narrow about what it pulls in. The only argument I can see against doing this is that ocrfeeder appears to have the ability to save "project" files (ZIP archives with the file extension .ocrf), which presumably then might be loadable from the command line. But it doesn't currently have that functionality even without my patch, and in fact .ocrf files aren't recognized as being associated with ocrfeeder at all. (They open in file-roller as archives.) Still, I acknowledge that granting ocrfeeder the ability to load .ocrf files is complicated by this patch.
Hi Frank, I had already replaced the OptionParse by the ArgumentParser but since I didn't have time to clean it up I hadn't pushed it... for 2 years (been a bit busy with two kids now)! Having the "-i %f" in the desktop no longer aborts the program but just prints a warning and continues. Sorry it took me so long to address this.
Cool, I see that does work now. The command-line help for -i is a bit weird, tho: ======== ./bin/ocrfeeder --help usage: ocrfeeder [-h] [-i IMAGE1 [IMAGE2, ...] [IMAGE1 [IMAGE2, ...] ...]] [-d DIR] [-v] The complete OCR suite. optional arguments: -h, --help show this help message and exit -i IMAGE1 [IMAGE2, ...] [IMAGE1 [IMAGE2, ...] ...], --images IMAGE1 [IMAGE2, ...] [IMAGE1 [IMAGE2, ...] ...] images to be automatically added on start-up. Use the option before every image path. -d DIR, --dir DIR directory with images to be added automatically on start-up -v, --version show program's version number and exit ======== It took me a while to get it looking right for my patch, which output: ======== usage: ocrfeeder [-h] [-i IMAGE1 [-i IMAGE2...]] [-d DIRECTORY] [IMAGE [IMAGE ...]] ocrfeeder 0.8.1 positional arguments: IMAGE image(s) to be automatically added on start-up. optional arguments: -h, --help show this help message and exit -i IMAGE1 [-i IMAGE2...], --image IMAGE1 [-i IMAGE2...] images to be automatically added on start-up (For backwards compatibility.) (etc...) ======== (I couldn't convince it to output "--image IMAGE1 [--image IMAGE2...]" so eventually I gave up. But other than that it's accurate.) Huh. Actually, in my testing, even though the help says "Use the option before every image path", with the latest code `ocrfeeder -i image1.pnm image2.pnm` loads the two images as multiple pages. `ocrfeeder -i image1.pnm -i image2.pnm` only loads image2.pnm and ignores image1.pnm completely. That's actually a good thing, though, because if -i accepts multiple arguments, you can change the desktop file to use %F instead of %f (something I'd neglected to do, in my patch). Multi-selecting images in Nautilus and choosing "Open in ocrfeeder" will then load them all in as multiple pages. With %f, it launches multiple instances of ocrfeeder, one for each page. I tested the %F change, and it works with both my patch (using the positionals) and your current ocrfeeder code (passing multiple filenames after -i).
> Having the "-i %f" in the desktop no longer aborts the program Wait a minute, but does launching the app from the GNOME launcher actually pass "-i %f" to OCRFeeder or simply "-i" ? Because what I'm seeing is the latter.
Correct. Without a filename, it'll run `ocrfeeder -i`. Hmm, which still doesn't seem to work for launching ocrfeeder. I thought I'd tested that, but it seems I was wrong. `ocrfeeder -i ""` will produce a warning: 2018-03-14 03:14:20,605 WARNING: Could not load image "": does not exist ...and then continue to launch with no image loaded. But `ocrfeeder -i` with no additional arguments results in: usage: ocrfeeder [-h] [-i IMAGE1 [IMAGE2, ...] [IMAGE1 [IMAGE2, ...] ...]] [-d DIR] [-v] ocrfeeder: error: argument -i/--images: expected at least one argument So it doesn't appear that the .desktop file with "Exec=ocrfeeder -i %f" will work even after this change. Unless I'm looking at something wrong?
(In fact, trying to launch ocrfeeder from the Gnome Shell menu produces that same usage error, in the user journal:) Mar 14 03:20:30 teevey ocrfeeder.desktop[11528]: usage: ocrfeeder [-h] [-i IMAGE1 [IMAGE2, ...] [IMAGE1 [IMAGE2, ...] ...]] Mar 14 03:20:30 teevey ocrfeeder.desktop[11528]: [-d DIR] [-v] Mar 14 03:20:30 teevey ocrfeeder.desktop[11528]: ocrfeeder: error: argument -i/--images: expected at least one argument
Okay. I guess I didn't test without an arg, only with a wrong path. I am okay removing the -i altogether. Seems like the best approach now. And we can add the second desktop file for opening with an argument if needed later.
Yes, I guess the simplest from the user's point of view would be to drop -i altogether, so I guess we're all talking about this: * "ocrfeeder" launches the program * "ocrfeeder <img>" adds the specified image on startup. With that I don't think we need a second desktop file.
That's a very good suggestion... Don't know why I didn't think of that before. I believe I had thought of reserving the positional arguments for opening project files, but arguably this makes more sense for images (and we can even use it for both later) so let's do it like that. Pushed to master: https://git.gnome.org/browse/ocrfeeder/commit/?id=f5f1b076993ec0ba94250f21051e049072c7e230