<div dir="ltr">Hi Grant,<div><br></div><div style>Thanks for bringing up this issue. I have added a comment to the corresponding Trac ticket:</div><div style><br></div><div style>    <a href="http://trac.imagej.net/ticket/1706">http://trac.imagej.net/ticket/1706</a></div>

<div style><br></div><div style>Regards,</div><div style>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 4:13 PM, Grant B. Harris <span dir="ltr"><<a href="mailto:gharris@mbl.edu" target="_blank">gharris@mbl.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ImageJ2ers,<br>
<br>
We've recently run into the problem of having multiple versions of MicroManager installed (for testing our plugins under different versions).  This made me realize that there are some issues with ImageJ2 preferences that we may want to address.<br>


<br>
Right now, Prefs are stored in the userRoot() by Class<?> and name.<br>
<br>
I don't think that this allows us to support any of these scenarios:<br>
- multiple applications (that use the application framework)<br>
- multiple versions of the same application<br>
- multiple instances (contexts) of the same application<br>
<br>
I all of these cases, they will stomp on each other by reading/writing the same Prefs.<br>
<br>
<br>
I'd like to propose an extension to the Prefs mechanism which follows:<br>
<br>
When an application launches, if it does not find a node for itself (applicationA/v2.0), it could optionally copy or translate the values from an old version node (applicationA/v2.0).  The Prefs class could provide some helper methods for this.  The Prefs nodes could be something like this:<br>


<br>
userRoot()<br>
    /applicationA<br>
        /v1.01<br>
            /...<br>
        /v1.02<br>
            /...<br>
     /applicationB<br>
        /v2.0<br>
            /...<br>
<br>
To deal with multiple instances (contexts) of the same application, it might make sense to have the prefs stored by context (perhaps under a node for application and a node for each version.  It seems that each instance would need to have an identifier, and this identifier would need to be set when the app. (re-)launches, perhaps using a command line argument.<br>


<br>
While less common, the ability to have multiple instances (contexts) of the same application can be useful in two use cases I can think of: 1) running instances running headless on a server, 2) having multiple users of an application on the same OS user account (like 'guest').  A context identifier would also enable separate prefs settings for these situations.<br>


<br>
Using context identifiers, perhaps the Prefs nodes could be something like this:<br>
<br>
userRoot()<br>
    /applicationA<br>
        /v1.01<br>
            /...<br>
            /cID1<br>
                /...<br>
        /v1.02<br>
            /...<br>
     /applicationB<br>
        /v2.0<br>
            /cID1<br>
                /...<br>
            /cID2<br>
                /...<br>
<br>
For example, if a context identifier is provided, the app. would use the nodes under /applicationA/v1.01/cID1... and if a context identifier is not provided, the app. would use the nodes under /applicationA/v1.01/...<br>


<br>
Perhaps Prefs could be Contextual, and then use getTitle(), getVersion().<br>
(For the context, I suppose one kluge would be to add something to the Title...)<br>
<br>
There may be some related issues, e.g. in ConfigFileParameters, this is hardcoded: CONFIG_FILE = "ImageJ.cfg";<br>
<br>
Thoughts?  Ideas?<br>
<br>
(I've added this as an issue ticket in TRAC.)<br>
<br>
-- Grant<br>
<br>
<br>
______________________________<u></u>_________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/<u></u>listinfo/imagej-devel</a><br>
</blockquote></div><br></div>