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

[Unruh, Jay]

I would add to this conversation that it would be very useful for other developers to see what Collin has developed in terms of the Fiji launcher script.  I have had situations where I wanted to launch in a custom way not provided by the built-in launcher.  No reason to figure this out if Collin already has.  Collin could label it "experimental" to prevent naïve users from accidentally using it.  Most of my plugins fall into the "experimental" category anyway-if they didn't I probably wouldn't rely so much on ImageJ.

Jay

From: imagej-devel-bounces at imagej.net [mailto:imagej-devel-bounces at imagej.net] On Behalf Of Poczatek, Joseph Collin
Sent: Friday, January 03, 2014 10:16 AM
To: Johannes Schindelin
Cc: Fiji Developers; ImageJ Developers
Subject: Re: [ImageJ-devel] [fiji-devel] Custom starting of Fiji (was Fiji updater operates on what directories and what file types?)

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/6a3888d8/attachment-0001.html>