[ImageJ-devel] [fiji-devel] Custom starting of Fiji (was Fiji updater operates on what directories and what file types?)

[Poczatek, Joseph Collin]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140103/2c4950ca/attachment.html>