Is this really already resolved?

Pushed new branch T25590-ModelFit_docs.

Nice!
That's cool. Thanks for the effort! Will be very usefull also for our model fit and CEST work!

@steint : Cool thanks for following up on this! Very valuable.

Pushed new branch T25589-MatchPoint_docs.

In T25105#167423, @kalali wrote:

We do not need to move the whole functionality to the data storage, just the geometry processing part.

What do you exactly mean with geometry processing part? Does "to the storage" mean, into the class or into the file?

In T25105#167258, @kalali wrote:

Would it be reasonable to move the UpdateStatusBar functionality to the data storage as well

No, I don't think so. It is not job of the DataStorage to update the status bar.

Yes, partially. We have no crashes, but

In rMPb391c8f57e95af28e70921ac63cbfaed8792821d#131627, @gaoh wrote:

@hentsch I get build errors with the current master (in ubuntu), without your commit everything is fine.
Do I have to change something with cmake flags?
The last lines before failure:
/home/hanno/myDocker/Matchpoint/src/Code/Algorithms/ITK/boxed/mapITKRigid3DMattesMIHeadNeckRegistrationAlgorithmTemplate.tpp:128:25: error: ‘zSize’ was not declared in this scope

region.SetIndex(2, zSize / 3);

that would be great.

Pushed new branch T24987-mitkFunctionAddLibrarySearchPaths.

Discussed it. For now we will implement an simple solution (simelar to the legacy modulconf pattern) to add additional path from the eps cmakeexternals script.

@nolden Could you please "unraise" your concern now. It is spoiling my statistics/dashboard. Thanks ;)

GCC error was fixes. Thanks for the hint.

@kislinsk : Do you know the/a reason why this task wasn't merged and closed after positiv review? Seems like it was forgotten some how.

@kislinsk , @kahl: Is there a reason this is not merged into the master and closed? The review was already done and positive.

I think the reason is that this Service has now a new (correct) autoload rule and the continuus clients are not cleaned. This combiniation leads to the service being load twice.

Propertylist has more strict behavior. Only none empty strings are allows as property key. Property list now also implements the PropertyOwner interface.
Introduced with T25441: Name DataNodes with DICOM data appropriately by using dicom tags

Pushed new branch T25441-fix_tests.

Pushed new branch T25442-fix_tests.

Still open, as nobody was assigned so far and had time ;)

We discussed it today with the following results:

Pushed new branch T25441-fix_gcc.

Good idea that would really help.

@hentsch Is there a reason this is still open. Seems to be mergeable to the master, isn't it?

@kahl : If you work on a task (e.g. this one; thank you!) please claim it, that everyone sees that you are assigned. If you have stopped working on the task, its fine in its unassigned state.

You pointed in the right direction. The operator == currently checks complete equality. So also the number of time points and frames must be the same; and must have the same value. This is not the case in your on-the-fly-generated operand. Tempering with the == is not trival, because there are use cases where it realy matters if there is the same geometry and not only the same value. There are thoughts to implement posibilities to express TemporoSpatialStringProperties more compact, but thats no quick solution.

As far as I can see (had to dig through the commits) All changes of this branch, have already been cherry picked to the master at some point. (Don't know if they are also already in the current beta brunch).