Improvements to project sorting

[alanocallaghan]

Feature request

Is your feature request related to a problem? Please describe.
Project sorting is not persistent across QuPath instances, and does not update based on updated metadata values.
Nice-to-have would be to add metadata values when images are dragged and dropped, but I feel that's going to be a stretch goal.

Describe the solution you'd like
In order of priority/feasibility:

1. Project sorting persists
2. Sorting is updated when metadata values change
3. Dragging & dropping a file into a project sorted by metadata value sets the corresponding value.

Describe alternatives you've considered
Manually re-sorting on project opening and when values change, and manually setting metadata values.

Additional context

ImageSC posts:

• https://forum.image.sc/t/qupath-feature-request-persist-image-sorting-per-metadata/91406/4
• https://forum.image.sc/t/qupath-sort-by/85398

[alanocallaghan]

Can somewhat resolve item 2 by adding this:

				ImageRow selectedImageRow = getSelectedImageRow();
				refreshTree(selectedImageRow);

to the end of actionAddMetadataValue, although this isn't a particularly robust way of doing it in case metadata are edited elsewhere

[alanocallaghan]

Seems like 1. might require changing the Project interface, which is really not ideal

[petebankhead]

Yes. We can make changes, but need to be cautious and ideally keep the Project interface as simple as we can.

The thinking is that we want projects to not necessarily be backed by files on the local file system. So you might have a QuPath project that behaves like a 'view' on an OMERO project (for example).

I think this idea is already used by QuPath Edu - see here.

[alanocallaghan]

An alternative could be to smuggle in an implementation of stored sorting with a Manager, but that seems like a bit of abuse of the existing facilities.

The obvious way to make one change that permits any future extensions is to add a Map<[String?], [Object?]>, but that's got its own set of problems (security would be a big one).

[petebankhead]

Yes, map is tempting but a bit scary.
Somewhat relevant: #1289

[alanocallaghan]

smuggle in an implementation of stored sorting with a Manager, but that seems like a bit of abuse of the existing facilities.

Actually wondering is this so bad after all? Could have a class that manages sorting by metadata key(s), then use a manager to store/retrieve associated settings for the project in [something, maybe a file]. Not too dissimilar philosophically to loading/saving classifiers in the grand scheme of things

[petebankhead]

True. I'm not a big fan of managers, especially if we just expect to store one value, but it should work without needing to change much.

Or what do you think of a project supporting Map<String, String> so it doesn't attempt to handle arbitrary objects?

Thinking about it, we could also easily add a getSortKey() method (and setter) with default null implementations without breaking anything (and then include a corresponding String field in the default project itself). Although I'm not sure the current shorting is as flexible as we'd like, and setting the sort key kind of suggests that it will be applied to getImageList() but it wouldn't be.

Although now that I think about that, it couldn't really be applied to getImageList() because it's really more of a grouping than a sorting... so you'd need something like Map<String, List<ProjectImageEntry>> getGroupedImages(String key) to use it meaningfully. So maybe it's more of a getGroupingKey()...

[alanocallaghan]

True. I'm not a big fan of managers, especially if we just expect to store one value

My thought was to store an in theory arbitrary amount of grouping/sorting keys (but realistically only up to 2 or 3) that can be applied sequentially, as well as whether each is used in ascending or descending order. This would let us handle the nested grouping/sorting described in #1289 The advantage here is we're free to save whatever we need into the manager's save state without needing to revisit project if we add new grouping features.

Or what do you think of a project supporting Map<String, String> so it doesn't attempt to handle arbitrary objects?

This has its own kind of code smell I think, but yeah doesn't have as many issues as handling Object.