UI question

[Kenneth Sloan-2]

I have a question about the best way to maintain a small (<10) set of category names.

The plugin I just wrote for a specific project now appears to be more generally applicable.  On the one hand, it is nice to have custom labels for categories, as a reminder for the user, and to make the resulting output files more self-documenting.  On the other hand, if seven projects are using the plugin, each with their own set of labels, it seems silly to hard-code the labels into the program.
Of course, my first version has hard-coded labels, specific to the original project.

The obvious solution is to have the plugin read the labels from a file.  This is my current default design.  This has only one downside - the user must SPECIFY the file.  That added interaction is just enough to make me look for a better solution.  

One possibility is to make the location of this meta-file standard.  Then, different users would only need to edit that file (probably copying their specific version to the canonical one, true file).  This would be perfect - except for the problem of specifying the location of that file.  Making this work on all platforms seems like more trouble than it is worth.

Is IJ.Prefs the right way to handle this?  I already use this method to save a small number of numeric parameters in another plugin.  It looks like one way to do this is to specify Prefs keys something like:

MyPackage.MyPlugin.Category_1
MyPackage.MyPlugin.Category_2
...
My Package.MyPlugin.Category_9

and include an interaction to edit or accept the current defaults (along with a checkbox to "Remember these")

BTW  - the categories will be indicated by single digit keypresses - I suspect I'll reserve '0' for "other" as an all-purpose "none of the above".

Another idea would be to use a single Prefs key to hold a String giving the path (on the local machine) to a file containing a list of categories.  This has the added advantage of making it easy to switch from one set to another (in the case that two projects are using the same machine).  I think I like this better from the point of view of the user interactions I expect - even though the code to implement it is a tiny bit more complicated.  I expect that I would display the current default categories (either hard defaults, or from a file if the Prefs key is set and the file can be opened) along with an option to "Change to a different Categories file?"  Initial setup would require the user to create the file, and point my plugin at that file on the first invocation.  Switching between sets would require a single file navigation step.  And, it only requires ONE key:

MyPackage.MyPlugin.CategoryPath

Finally, it occurs to me that it would STILL be good to have a hard-coded set of defaults, which could be selected instead of (or in the absence of) an actual file.

In the "Bridge Too Far" realm, it might be nice to have IJ.Prefs keep track of SEVERAL previously defined Category files, and offer the user a choice.  But, I'm not that ambitious...yet.

Any other ideas?  Is there another IJ-specific technique  I haven't stumbled across, yet?

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Wednesday, 1 April 2020 02:41:45 BST you wrote:
> One possibility is to make the location of this meta-file standard.  Then,
> different users would only need to edit that file (probably copying their
> specific version to the canonical one, true file).  This would be perfect -
> except for the problem of specifying the location of that file.  Making
> this work on all platforms seems like more trouble than it is worth.

Hi Kenneth,
The Colour Deconvolution plugin also uses a file to store the stains vectors,  
which is saved to the standard plugins folder. That should be standard across
platforms.
On the first run of the plugin if the stains file does not exist, it is
created with a number of built-in vectors as examples, but one can add more
vectors to it afterwards or modify the existing ones.

If you want to have a look at the source:

https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/
fiji/colourDeconvolution/Colour_Deconvolution.java

Line 287 onwards.

The location of the stains file is defined via:
 String libDir =IJ.getDirectory("plugins");

and the file us created:

 File file = new File(libDir,"colourdeconvolution.txt");
etc.

Hope this helps and that all is well.

Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Gabriel-

Thank you.  I will look at the code today, but this sounds exactly what I
am looking for.  The key piece of information was that the plugins
directory is considered the right place to save this kind of information.

I will probably save a structured file, allowing for multiple sets of
labels.

I’m also still considering using IJ.Prefs. Are there any guidelines on how
complex (mostly how long) a “preference” can be?  For example, is it
reasonable to make a single “preference” be as complicated as:

( (Group A (a1) (a2) ... (a9))
(Group B (b 1) (b 2) ... (b 9))
...
)

The main issue now is how to create the list of labels.  It looks
attractive to allow the use of a general purpose text editor - but it may
be safer to supply a standard template and hide the encoding details.  This
begins to look like the LUT facility - I want a set of named vectors, the
ability to choose among many predefined vectors, and a mechanism for
creating, installing, and perhaps removing one of the vectors.  LUTs are
handled with their own well-known directory, containing files in a custom
format.

Sorry ... just “designing out loud”  I’ll stop now.

Thank you again for the Color Deconvolution example - I will study it.

On Wed, Apr 1, 2020 at 05:29 Gabriel Landini <[hidden email]> wrote:

> On Wednesday, 1 April 2020 02:41:45 BST you wrote:
> > One possibility is to make the location of this meta-file standard.
> Then,
> > different users would only need to edit that file (probably copying their
> > specific version to the canonical one, true file).  This would be
> perfect -
> > except for the problem of specifying the location of that file.  Making
> > this work on all platforms seems like more trouble than it is worth.
>
> Hi Kenneth,
> The Colour Deconvolution plugin also uses a file to store the stains
> vectors,
> which is saved to the standard plugins folder. That should be standard
> across
> platforms.
> On the first run of the plugin if the stains file does not exist, it is
> created with a number of built-in vectors as examples, but one can add
> more
> vectors to it afterwards or modify the existing ones.
>
> If you want to have a look at the source:
>
> https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/
> fiji/colourDeconvolution/Colour_Deconvolution.java
> <https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/fiji/colourDeconvolution/Colour_Deconvolution.java>
>
> Line 287 onwards.
>
> The location of the stains file is defined via:
>  String libDir =IJ.getDirectory("plugins");
>
> and the file us created:
>
>  File file = new File(libDir,"colourdeconvolution.txt");
> etc.
>
> Hope this helps and that all is well.
>
> Regards
>
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
-Kenneth Sloan

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Kenneth,

for some installations, the plugins directory might have no write access
for the user. Therefore, my preferred solution for preferences-like files is
   path = Prefs.getPrefsDir()+File.separator+filename;

This places the file in the same directory as IJ_Prefs.txt. On linux
this is a hidden .imagej directory in the user's home account.

As far as I know, there is no limit to the length of an ij.Prefs entry,
but it must be one line.
I am not sure whether you can have any unicode character in it or only
ascii.

Michael
_____________________________________________________


On 01/04/2020 5:40 pm, Kenneth R Sloan wrote:

> Gabriel-
>
> Thank you.  I will look at the code today, but this sounds exactly what I
> am looking for.  The key piece of information was that the plugins
> directory is considered the right place to save this kind of information.
>
> I will probably save a structured file, allowing for multiple sets of
> labels.
>
> I’m also still considering using IJ.Prefs. Are there any guidelines on how
> complex (mostly how long) a “preference” can be?  For example, is it
> reasonable to make a single “preference” be as complicated as:
>
> ( (Group A (a1) (a2) ... (a9))
> (Group B (b 1) (b 2) ... (b 9))
> ...
> )
>
> The main issue now is how to create the list of labels.  It looks
> attractive to allow the use of a general purpose text editor - but it may
> be safer to supply a standard template and hide the encoding details.  This
> begins to look like the LUT facility - I want a set of named vectors, the
> ability to choose among many predefined vectors, and a mechanism for
> creating, installing, and perhaps removing one of the vectors.  LUTs are
> handled with their own well-known directory, containing files in a custom
> format.
>
> Sorry ... just “designing out loud”  I’ll stop now.
>
> Thank you again for the Color Deconvolution example - I will study it.
>
> On Wed, Apr 1, 2020 at 05:29 Gabriel Landini <[hidden email]> wrote:
>
>> On Wednesday, 1 April 2020 02:41:45 BST you wrote:
>>> One possibility is to make the location of this meta-file standard.
>> Then,
>>> different users would only need to edit that file (probably copying their
>>> specific version to the canonical one, true file).  This would be
>> perfect -
>>> except for the problem of specifying the location of that file.  Making
>>> this work on all platforms seems like more trouble than it is worth.
>>
>> Hi Kenneth,
>> The Colour Deconvolution plugin also uses a file to store the stains
>> vectors,
>> which is saved to the standard plugins folder. That should be standard
>> across
>> platforms.
>> On the first run of the plugin if the stains file does not exist, it is
>> created with a number of built-in vectors as examples, but one can add
>> more
>> vectors to it afterwards or modify the existing ones.
>>
>> If you want to have a look at the source:
>>
>> https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/
>> fiji/colourDeconvolution/Colour_Deconvolution.java
>> <https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/fiji/colourDeconvolution/Colour_Deconvolution.java>
>>
>> Line 287 onwards.
>>
>> The location of the stains file is defined via:
>>   String libDir =IJ.getDirectory("plugins");
>>
>> and the file us created:
>>
>>   File file = new File(libDir,"colourdeconvolution.txt");
>> etc.
>>
>> Hope this helps and that all is well.
>>
>> Regards
>>
>> Gabriel
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Interesting.

10 strings seems on the small side for a file, but a bit large for a direct
entry in Prefs.  I’ll have to think about it (and maybe write initial code
for both versions).

Right now, I’m leaning towards one file, with an XML-like structure.  I
guess my LISP background is starting to show...

On Wed, Apr 1, 2020 at 11:03 Michael Schmid <[hidden email]> wrote:

> Hi Kenneth,
>
> for some installations, the plugins directory might have no write access
> for the user. Therefore, my preferred solution for preferences-like files
> is
>    path = Prefs.getPrefsDir()+File.separator+filename;
>
> This places the file in the same directory as IJ_Prefs.txt. On linux
> this is a hidden .imagej directory in the user's home account.
>
> As far as I know, there is no limit to the length of an ij.Prefs entry,
> but it must be one line.
> I am not sure whether you can have any unicode character in it or only
> ascii.
>
> Michael
> _____________________________________________________
>
>
> On 01/04/2020 5:40 pm, Kenneth R Sloan wrote:
> > Gabriel-
> >
> > Thank you.  I will look at the code today, but this sounds exactly what I
> > am looking for.  The key piece of information was that the plugins
> > directory is considered the right place to save this kind of information.
> >
> > I will probably save a structured file, allowing for multiple sets of
> > labels.
> >
> > I’m also still considering using IJ.Prefs. Are there any guidelines on
> how
> > complex (mostly how long) a “preference” can be?  For example, is it
> > reasonable to make a single “preference” be as complicated as:
> >
> > ( (Group A (a1) (a2) ... (a9))
> > (Group B (b 1) (b 2) ... (b 9))
> > ...
> > )
> >
> > The main issue now is how to create the list of labels.  It looks
> > attractive to allow the use of a general purpose text editor - but it may
> > be safer to supply a standard template and hide the encoding details.
> This
> > begins to look like the LUT facility - I want a set of named vectors, the
> > ability to choose among many predefined vectors, and a mechanism for
> > creating, installing, and perhaps removing one of the vectors.  LUTs are
> > handled with their own well-known directory, containing files in a custom
> > format.
> >
> > Sorry ... just “designing out loud”  I’ll stop now.
> >
> > Thank you again for the Color Deconvolution example - I will study it.
> >
> > On Wed, Apr 1, 2020 at 05:29 Gabriel Landini <[hidden email]>
> wrote:
> >
> >> On Wednesday, 1 April 2020 02:41:45 BST you wrote:
> >>> One possibility is to make the location of this meta-file standard.
> >> Then,
> >>> different users would only need to edit that file (probably copying
> their
> >>> specific version to the canonical one, true file).  This would be
> >> perfect -
> >>> except for the problem of specifying the location of that file.  Making
> >>> this work on all platforms seems like more trouble than it is worth.
> >>
> >> Hi Kenneth,
> >> The Colour Deconvolution plugin also uses a file to store the stains
> >> vectors,
> >> which is saved to the standard plugins folder. That should be standard
> >> across
> >> platforms.
> >> On the first run of the plugin if the stains file does not exist, it is
> >> created with a number of built-in vectors as examples, but one can add
> >> more
> >> vectors to it afterwards or modify the existing ones.
> >>
> >> If you want to have a look at the source:
> >>
> >>
> https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/
> >> fiji/colourDeconvolution/Colour_Deconvolution.java
> >> <
> https://github.com/fiji/Colour_Deconvolution/blob/master/src/main/java/sc/fiji/colourDeconvolution/Colour_Deconvolution.java
> >
> >>
> >> Line 287 onwards.
> >>
> >> The location of the stains file is defined via:
> >>   String libDir =IJ.getDirectory("plugins");
> >>
> >> and the file us created:
> >>
> >>   File file = new File(libDir,"colourdeconvolution.txt");
> >> etc.
> >>
> >> Hope this helps and that all is well.
> >>
> >> Regards
> >>
> >> Gabriel
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
-Kenneth Sloan

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Wednesday, 1 April 2020 17:00:45 BST you wrote:
> for some installations, the plugins directory might have no write access
> for the user. Therefore, my preferred solution for preferences-like files is
> path = Prefs.getPrefsDir()+File.separator+filename;

Good idea. I guess, though, that in Kenneth's case, if the user cannot access
the plugins folder, it would not be possible to install the plugin either :-)

Cheers, take care everybody!

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Stein Rørvik]

You say "... seven projects are using the plugin, each with their own set of labels, ..."

In this case I would say it would not make sense to store the labels in neither the prefs file nor the plugin dir, as that would only be useful if all samples used the same labels.

Instead, try using the built-in List.* functions to store the labels as key-value pairs, and store the list as a text file in the data directory. Datasets sharing the same labels may share a common label file further up in the directory tree. An advantage with this is that the labels will follow the data if you should need to relocate it later.

Stein

Sendt fra min iPhone

> 1. apr. 2020 kl. 19:31 skrev Gabriel Landini <[hidden email]>:
>
> On Wednesday, 1 April 2020 17:00:45 BST you wrote:
>> for some installations, the plugins directory might have no write access
>> for the user. Therefore, my preferred solution for preferences-like files is
>> path = Prefs.getPrefsDir()+File.separator+filename;
>
> Good idea. I guess, though, that in Kenneth's case, if the user cannot access
> the plugins folder, it would not be possible to install the plugin either :-)
>
> Cheers, take care everybody!
>
> Gabriel
>
> --
> ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&amp;data=02%7C01%7Cstein.rorvik%40sintef.no%7Cb51cfb0d96574f94eb4708d7d662766d%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637213590699954109&amp;sdata=36ZUmDNTOOOVr7WFsd4xpkdtJ1jtGw%2FCPYclT3iG%2FGk%3D&amp;reserved=0

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Sorry - this is a pure Java question, but it's related to this thread:


Before I write it myself...

Does anyone know of a simple way to parse a string into a list of strings, given information about grouping characters - such as '(' and ')'?

That is - given something like:

"(A (B C) D ((E)))", return:

"A", "(B C)", "D",  "((E))"

It looks simple enough to write, but also general purpose enough that perhaps it already exists.
Actually, it looks like something I might assign to students in a first course in programming.  I just don't want to re-re-re-invent the wheel.

I'm thinking of something like:

String[] parseList(String input, char leftParen, char rightParen);

or (better)

List<String> parseList(String input, char leftParen, char rightParen);

Think of it as an extension of String.split()

I will be grateful if it turns out that I'm simply ignorant (and someone points me at an existing method).

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Fred Damen]

Greetings,

If you are into perlre voodoo then this is easy...

On linux 'man perlre' or google 'perlre'.  Everyone copies perlre so I
would assume that java's String.split also follows it.  Post the question
on stackoverflow.com and they will compete for the most cryptic /
efficient RE possible to solve your quandry...

Enjoy,

Fred

On Thu, April 2, 2020 10:59 pm, Kenneth Sloan wrote:

> Sorry - this is a pure Java question, but it's related to this thread:
>
>
> Before I write it myself...
>
> Does anyone know of a simple way to parse a string into a list of strings,
> given information about grouping characters - such as '(' and ')'?
>
> That is - given something like:
>
> "(A (B C) D ((E)))", return:
>
> "A", "(B C)", "D",  "((E))"
>
> It looks simple enough to write, but also general purpose enough that
> perhaps it already exists.
> Actually, it looks like something I might assign to students in a first
> course in programming.  I just don't want to re-re-re-invent the wheel.
>
> I'm thinking of something like:
>
> String[] parseList(String input, char leftParen, char rightParen);
>
> or (better)
>
> List<String> parseList(String input, char leftParen, char rightParen);
>
> Think of it as an extension of String.split()
>
> I will be grateful if it turns out that I'm simply ignorant (and someone
> points me at an existing method).
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael P Ellis]

I think what you are looking for is a Recursive Descent Parser

This is a classic part the first stage of processing nearly every program language.

Fortunately this is a very well trodden path and there are also libraries to help to the heavy lifting work for you.

Just Google something like “Recursive Descent Parser” in Java

> On 3 Apr 2020, at 04:59, Kenneth Sloan <[hidden email]> wrote:
>
> Sorry - this is a pure Java question, but it's related to this thread:
>
>
> Before I write it myself...
>
> Does anyone know of a simple way to parse a string into a list of strings, given information about grouping characters - such as '(' and ')'?
>
> That is - given something like:
>
> "(A (B C) D ((E)))", return:
>
> "A", "(B C)", "D",  "((E))"
>
> It looks simple enough to write, but also general purpose enough that perhaps it already exists.
> Actually, it looks like something I might assign to students in a first course in programming.  I just don't want to re-re-re-invent the wheel.
>
> I'm thinking of something like:
>
> String[] parseList(String input, char leftParen, char rightParen);
>
> or (better)
>
> List<String> parseList(String input, char leftParen, char rightParen);
>
> Think of it as an extension of String.split()
>
> I will be grateful if it turns out that I'm simply ignorant (and someone points me at an existing method).
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Ellis (Managing Director)
Digital Scientific UK Ltd.
http://www.dsuk.biz <http://www.dsuk.biz/>
[hidden email]
tel: [phone]

The Commercial Centre
6 Green End
Cambridge
CB23 7DY

=== END OF EMAIL ===


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Thanks - but Googling "recursive descent parser" just gives me lots of links to instructions on how to write one.  None point at a production quality package.  After teaching CS for >40 years, I already know how to do that.  I remember once writing a table-driven parser as a HW assignment eons ago...in /360 Assembler.

I was hoping for a Java implementation of a very lightweight version of XML.

There's always the option of simply using XML, but that seems like swatting a fly with a sledge hammer.

On the other hand, some of my other plugins *do* use XML (mostly to parse instrument manufacturers' external file formats).  So that's an option.

But, what I actually need here is *very* lightweight, and is best viewed as something at the level of String.split.  So...I'll write it, tomorrow.  I'll try to make it look as much like String.split as possible (except that I'll return a List rather than an array.  ...shudder...

Sorry for the mostly off-topic thread.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael P Ellis]

Ah, so is the depth of nesting is not relevant? i.e you only want to split it into chunks, more or less tokenising it?

— ME

> On 3 Apr 2020, at 07:48, Kenneth Sloan <[hidden email]> wrote:
>
> Thanks - but Googling "recursive descent parser" just gives me lots of links to instructions on how to write one.  None point at a production quality package.  After teaching CS for >40 years, I already know how to do that.  I remember once writing a table-driven parser as a HW assignment eons ago...in /360 Assembler.
>
> I was hoping for a Java implementation of a very lightweight version of XML.
>
> There's always the option of simply using XML, but that seems like swatting a fly with a sledge hammer.
>
> On the other hand, some of my other plugins *do* use XML (mostly to parse instrument manufacturers' external file formats).  So that's an option.
>
> But, what I actually need here is *very* lightweight, and is best viewed as something at the level of String.split.  So...I'll write it, tomorrow.  I'll try to make it look as much like String.split as possible (except that I'll return a List rather than an array.  ...shudder...
>
> Sorry for the mostly off-topic thread.
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Ellis (Managing Director)
Digital Scientific UK Ltd.
http://www.dsuk.biz <http://www.dsuk.biz/>
[hidden email]
tel: [phone]

The Commercial Centre
6 Green End
Cambridge
CB23 7DY

=== END OF EMAIL ===


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Correct.  All I'm aiming for here is:

        List<String>   <-->  String

After spitballing many levels of ambition, I think I'm going to settle for a version that strictly reserves the characters '[', ']', and ','.

With that restriction, I can use  String.toString() to convert from a  List<String> to a String, and use a very simple parser to convert from String to  List<String>.

Anything more ambitious seems to lead inexorably to re-inventing (and then recoiling in horror and simply using) XML.  The core issue is that List.toString() is many to one.

The specific application program can deal with multiple-levels, as needed.  Of course, at the moment I only have ONE specific application program in mind, but...

This is only a small step up from simply stuffing everything into IJ.Prefs key-value pairs, but I hope it will be about as easy to use, and slightly more general-purpose.

I'm also hoping that the resulting file will be simple enough to edit using a standard text-editor, so I don't have to write code to create and manage the label sets.

There's still the issue of where to store the file.  I'll probably use IJ.prefs for that, and include an easy way to change/initialize that preference in the same interaction I use to select a label set from the set of label sets.

BTW - does anyone know offhand what format List.toString() uses in a Locale where ',' is used as the decimal separator?  I don't have a machine handy setup for that Locale - but some of my collaborators  use that Locale, so I try hard to make all my plugins Locale-sensitive (mostly when writing output files).


--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Keneth,

it seems you refer to 'List' as the interface in
java.util.AbstractCollection, no the java.awt.List class.

The AbstractCollection.toString() documentation says:

   This implementation creates an empty string buffer, appends a left
square bracket, and iterates over the collection appending the string
representation of each element in turn. After appending each element
except the last, the string ", " is appended. Finally a right bracket is
appended. A string is obtained from the string buffer, and returned.

 From this I would conclude that it is always a comma, irrespective of
the locale (I can't try because I have the US-English version of the
operating system and all software on my computer).

Michael
__________________________________________________________________________

On 03/04/2020 7:43 pm, Kenneth Sloan wrote:

> Correct.  All I'm aiming for here is:
>
> List<String>   <-->  String
>
> After spitballing many levels of ambition, I think I'm going to settle for a version that strictly reserves the characters '[', ']', and ','.
>
> With that restriction, I can use  String.toString() to convert from a  List<String> to a String, and use a very simple parser to convert from String to  List<String>.
>
> Anything more ambitious seems to lead inexorably to re-inventing (and then recoiling in horror and simply using) XML.  The core issue is that List.toString() is many to one.
>
> The specific application program can deal with multiple-levels, as needed.  Of course, at the moment I only have ONE specific application program in mind, but...
>
> This is only a small step up from simply stuffing everything into IJ.Prefs key-value pairs, but I hope it will be about as easy to use, and slightly more general-purpose.
>
> I'm also hoping that the resulting file will be simple enough to edit using a standard text-editor, so I don't have to write code to create and manage the label sets.
>
> There's still the issue of where to store the file.  I'll probably use IJ.prefs for that, and include an easy way to change/initialize that preference in the same interaction I use to select a label set from the set of label sets.
>
> BTW - does anyone know offhand what format List.toString() uses in a Locale where ',' is used as the decimal separator?  I don't have a machine handy setup for that Locale - but some of my collaborators  use that Locale, so I try hard to make all my plugins Locale-sensitive (mostly when writing output files).
>
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Thanks for all the comments.  I wrote the first draft of the code this afternoon and am currently polishing and wringing it out.

The API looks like:

public class ListIO
   public static String toString(List<String> l)
   public static List<String> parseList(String s)

Strings may not include '[', ']', or ','  except as part of well-formed sub-lists.  The expected usage is that user programs will construct simple Lists and use toString() to encode them.  These created Strings are safe to use as List elements at the next level.  With those restrictions, parseList() should perfectly invert toString().  In practice, this means that user programs can't use these three characters in any Strings that they generate directly.

As expected (and desired), the implementation is dirt-simple.  All the work went into waffling back and forth on various design issues.

With that done, I return to the issue of where to store the Strings.  I may simply stuff them in a Prefs key-value pair for starters, since I don't expect the Strings to get all that large, in practice.  But (I hope) that's an orthogonal issue.

If anyone is curious (or a glutton for punishment), I will provide the source to anyone who contacts me directly, off-list.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html