Reshuffle packages. #121
Merged
Reshuffle packages. #121
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit has two goals: - It aims at integrating the 'revised' package into a sensible package hierarchy. - It aims at decoupling the generic Mastodon* interfaces and mother classes from the Mamut* classes that implement them, and are specific to a runnable application. Here is the logic for the second point. In this repo you will find 1) Mastodon base classes and 2) the classes for the MaMuT application. 1. Mastodon base classes. There are base classes and interfaces to derive and implement to create an application (or 'app') specific to a topic. What we call 'topic' could be 'segment, track and lineage cells objects in 2D'. The name of these classes is normally prefixed with MastodonSomething These classes are like abstract classes. By themselves, they cannot be made to something an end-user can run. The core classes of an app would derive a model for instance from a org.mastodon.app.MastodonAppModel and derive an org.mastodon.model.AbstractSpot to store location of objects. 2. The MaMuT application. These classes are part of an app, whose topic is 'tracking and lineaging cells, with cells represented as ellipsoids'. This app is the final and central application of Mastodon. When end-users and us speak of Mastodon, we mean this one. It is based on the org.mastodon.mamut.importer.Model and on org.mastodon.mamut.importer.Spot. Because this app is the successor of the MaMuT project (Wolff, Tinevez, Pietzsch et al, 2018) the classes of this app are called MaMuTSomething. With this commit: - They are all located in the org.mastodon.mamut package. - None of the Mastodon base classes depend on these classes. To achieve the last point, I had to move many classes around, and introduce some specific interface hierarchy. For instance, there is now a package org.mastodon.app.plugin, that defines interfaces for a generic plugin system, and that is implemented for the MaMuT app in org.mastodon.mamut.plugin.
Some users reported issues with spot features that are not computed (e.g. spot intensities in weird images). With this flag we can make a UI that will simply force the selected features to be computed for all objects ignoring whether they are up to date or not.
It is better to simply make a custome feature computer for special needs.
We had to add implement a new method from the Listeners.List interface.
They are set properly in the parent pom now.
The previous version with a feature update stack with too complex for something that ought to be simple. This new version takes a much simpler approach, resuling in much fewer classes and also lower memory and disk footprint. The idea implemented here is that, instead of tracking when a spot or a link is modified, we simply remove modified spots and links from the features. This way the modified objects appear with empty values after they have been modified (or created). Features that want to implement incremental updates simply have to recompute values only for objects with missing values. In case of issues (there will be), a flag in the feature computation service allows to force the recomputation over all objects, ignoring their status.
tinevez
force-pushed
the
reshuffle-packages
branch
2 times, most recently
from
fbe9446
to
69d9655
Compare
|
@tinevez Great, thanks! Could you please look at the TODOs I added in d3a41e2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR has two goals:
Here is the logic for the second point. In this repo you will find 1) Mastodon base classes and 2) the classes for the MaMuT application.
There are base classes and interfaces to derive and implement to create an application (or 'app') specific to a topic. What we call 'topic' could be 'segment, track and lineage cells objects in 2D'.
The name of these classes is normally prefixed with
MastodonSomething.These classes are like abstract classes. By themselves, they cannot be made to something an end-user can run. The core classes of an app would derive a model for instance from a
org.mastodon.app.MastodonAppModeland derive anorg.mastodon.model.AbstractSpotto store location of objects.These classes are part of an app, whose topic is 'tracking and lineaging cells, with cells represented as ellipsoids'.
This app is the final and central application of Mastodon. When end-users and us speak of Mastodon, we mean this one. It is based on the
org.mastodon.mamut.importer.Modeland onorg.mastodon.mamut.importer.Spot.Because this app is the successor of the MaMuT project (Wolff, Tinevez, Pietzsch et al, 2018) the classes of this app are called
MaMuTSomething.With this commit:
org.mastodon.mamutpackage.To achieve the last point, I had to move many classes around, and introduce some specific interface hierarchy. For instance, there is now a package
org.mastodon.app.plugin, that defines interfaces for a generic plugin system, and that is implemented for the MaMuT app inorg.mastodon.mamut.plugin.