Hi Johannes, Thanks for indulging me in this conversation.
Couldn't you say the same thing about Fiji shipping with a .desktop file? It does not ship with a .desktop file. It generates it upon startup in Linux. (To be precise, the ImageJ launcher does.) That makes more sense, and I should have realized that looking at the executable path in the .desktop file. Maybe I should think about having the scripts generated... You are welcome to do that, bash scripts are not the way, however. A better way would be to patch the ImageJ launcher to make it possible to ship *limited* configuration via update sites that affects the way Fiji is started. I can see that making sense in that it's cross platform (since the launcher is cross platform), but I can't see how that would get you any granularity. Meaning I want to start fiji in say 2 ways that would be equivalent to: ImageJ-launcher -flagA ImageJ-launcher -flagB And not overshadow starting with no flags. So far, I am quite doubtful, however, that such a support is needed. I might be wrong, but then, I have not been graced with the information about the intended use case requiring those bash scripts. Ok, I was trying to keep my questions narrowly focused, but I guess I ended up too vague. This is related to a conversation on the list from this spring (*) about nrrd files and handleExtraFileTypes. I agree that what I'm doing isn't the cleanest/best but I think it's the lesser evil given all the following facts/constraints (and the ones I forgot): - I need to bypass the standard IJ-io/extraFileTypes/LOCI chain and pass a file arg directly to our plugin. Which is called OpenMIMS (**) btw. - Architecturally our plugin has gotten a little cluttered over the years and while we're trying to refactor things, I don't have the man power to refactor out our file readers right now. - Besides myself I would say that all our users use Fiji without starting OpenMIMS <1% of the time. So they don't really want to start Fiji per se. - I seem to be categorically incapable of keeping even all the Fiji installs in the lab up-to-date/symmetric, let alone those outside the lab, so why not take advantage of the updater? - Like I mentioned above there are 2 ways (sets of flags) we start our plugin with. So we would need 2 "executables". - Our "users demand" a high level of symmetry between at least Linux and OsX in terms of how OpenMIMS/Fiji runs. For example breaking the "one instance of an application" constraint on OsX. And if I have to do crazy things like that, best to have a parallel way of starting Fiji, right? (I know I need more than just a bash script.) - I'm not stepping on/overshadowing any part of Fiji. Or forcing any of this to be used. - Even if I make a mess of things or get to the point I can undo this kludge, the updater makes it a lot easier to back out. So in conclusion, yes I agree that it's not the best but it's probably manageable. Cheers, Collin (*) http://imagej.1557.x6.nabble.com/Fiji-the-nrrd-file-format-and-HandleExtraFileTypes-td5002602.html (**) http://nrims.harvard.edu/about-mims http://nrims.partners.org/wiki/index.php/OpenMIMS_Manual The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
