TaskServicethat lets you register
Taskobjects and a task can have subtasks recursively, and then we can have a GUI that shows a progress bar for a task with an expandable triangle widget to show the next layer of progress bars below it. And to replace ImageJ's current progress bar with this better one. But as with so much in SciJava, this work was never completed.
TaskServicein SciJava Common now with
Taskobjects that you can create—and the
DownloadServiceuses it. I'd be happy to chat about requirements and whatnot any time, if you or @NicoKiaru or anyone has time and interest to develop it further. Perhaps all that would be needed is the user-interface portion of it now.
DownloadServicetasks to the
TaskServicedirectly, this is where we are.
component:script-editor, from back when the Script Editor lived in imagej-ui-swing. Since then, it moved to its own repository at scijava/script-editor, since it is more general than images. I wanted to transfer those five issues from imagej-ui-swing to script-editor, but you can only transfer an issue between repos of the same org. So! I created a new repo imagej/scijava-issue-shuttle and moved the five issues there. Then transferred scijava-issue-shuttle from imagej to scijava. But now, I'm not able to transfer the issues again from scijava-issue-shuttle to script-editor; no repositories appear on the list. Furthermore, two of the issues seem to have partially incomplete transfers, such that they still say they are "transferring" at the bottom. I fear they may be hosed now. So the end result is five deleted issues, i.e. five broken links, without successfully landing them at their new destinations in the end.
gh issue transfercommand line function, and it gave me an informative error: "Old issue cannot be transferred from private repository to public repository". Once I changed scijava-issue-shuttle to public, I was able to move them to the script-editor repo. Next time I'll try that command directly across orgs, and see if it works.
But there is no timeline and it contains goals that I do not fully support because they lead to eternal stasis: e.g https://github.com/scijava/incubator/blob/main/README.md#backwards-compatibility is unrealistic in a changing world, I agree that one should minimize this but it is necessary to break things if the old stuff is in the way and makes everything bad
Yeah, the timeline is unfortunately vague as I am transitioning to other projects in our community (e.g. napari-imagej), and @ctrueden has been stretched thin. The driving project behind SciJava 3, SciJava Ops and ImageJ Ops2, is nearly ready, but it of course depends on a bunch of components in SciJava 3.
logpackage in SciJava Common. It breaks backwards compatibility, naturally. Once SciJava Log2 has been released, any desired breaking changes would warrant SciJava Log3.
I also don't see who is actually working on this to make it happen, from the fiji meetings I read that you guys are all about doing pyimagej and writing papers at this time. Our own Fiji independent projects are currently using pom-scijava but we have bumped the release version so we can use modern stuff on the side of 8-compatible libraries (which works fine).
I was/am the driving force behind this, but now I'm only spending about one day a week on it. Furthermore, the incubator projects are in serious need of code review.