Thanks for the contribution.

Thanks for the contribution.

I am hesitant to integrate this pull request. I can understand the concern regarding invisible planes and agree that that should be solved. However just making all helper objects visible by default overshoots that target in my opinion.

Haha, oups, as you can see, I didn't actually remember what I did :)

Erm, I was mostly looking at the pull request you linked and that one just adds an unneeded line in

void mitk::LookupTableProperty::SetValue(const ValueType &value)

I agree that there's a Modified() in LookupTableProperty but the bug is related to ColorProperty. You know your code base much more than me so maybe these properties are super related and I'm not aware of it but... why is LookupTableProperty relevant?

Hum, looking at it right now, I agree that it looks random :) I know that I tried doing the simple way (like goch's snippet) in the "logical" places but it wasn't working. I don't remember why though so I'll try again and keep you updated.

Seems to build and test fine. Thanks for the contribution.

Seems to build and test fine. Thanks for the contribution.

I'm with Caspar here. This is a typical floating point precision issue which would preferably be resolved by using something like std::min() and std::max() when assigning lower/upper values.

Pushed new branch T22843-external-context-menu-icons.

The fix seems very random to me. Instead of just dividing the lower threshold by two , would it not be better to catch and correct the error at the place mentioned above?

Pushed new branch T22810-Add-tolerance-to-surfacetoimagefilter.

This should not be necessary, as there already is a Modified that is called:

Pushed new branch T22820-const-getters-for-fiber-bundles.

PR: https://github.com/MITK/MITK/pull/198

Thanks for the hint. It turned out in the end that the default cubic interpolation simply messed with labels on the rotated view planes...

Maybe the rotation matrix is not set for the clipping plane? Just guessing...

Thanks for the clarification, that explains the rotation of course. We are having problems with some other tools (e.g. with the clipping plane plugin) that came up just in these cases with (permuted) non-unity matrices. Apparently, that is then unrelated with these fixes.

What do you think is wrong? It looks correct to me.

In some cases, the fix leads to unexpected results (see attached). That is, re-init / global re-inits cause image rotations.@Miklos, maybe you have an idea where to start fixing this issue?

Finally, a new, improved and shinny PR: https://github.com/MITK/MITK/pull/196

It took me a while but I tested a little more and:

• Forget my PR, it's not good enough. It was a wonderful fix for OS X (the menus are unusable without my fix) but it doesn't fix the next point
• There are visual glitches on Windows too. (Probably linux too), let me explain.

Quickfixed Segmentation plugin. Need to investigate further.

Pushed new branch T22572-Fixes.

I updated the PR because the limit was applied only in one of the undo models. (The verbose undo model overrode the function in which the superclass applied the limit.)

Thank you! 👍

Something for the Bug Squashing Party tomorrow, thank you! 👍

For reference the pull request:
https://github.com/MITK/MITK/pull/187

Pushed new branch T22603-EigenIncludeDirFix.

Okay, thank you! We keep that in mind.

Pushed new branch T22602-UmlautsInDataManager.

In T22602#96071, @maleike wrote:

I think my pull request does not worsen the current state but slightly improves on name editing in Data Manager. So it could be integrated regardless of further encoding cleanups.

Thank you @aurelien! 👍

@maleike What's the status. Should we merge the PR for now or wait for more fixes?

👍

Pushed new branch T22610-DitinguishBetweenMissingHelpPagesAndMissingHelpContext.

@neher

T22572-no-common-legacy

👍

In T22607#96129, @kislinsk wrote:

@maleike Did you add your Email address associated with the commit to your Email addresses here on Phabricator?

@maleike Did you add your Email address associated with the commit to your Email addresses here on Phabricator?

In T19825#70270, @wegner wrote:

added and signed off pull request iwegner:bug-19825-SegFault_in_IGTTrackingToolbox_pluigin

https://github.com/MITK/MITK/pull/135

@maleike Regarding attachments, simply drag & drop them into the comment text box. 💡

I spent quite some time now on understanding what is happening. Attached to this task are my detailed notes (see two comments further down).
The overall situation is complicated, so I need to meditate on it for some time before any further changes. Discussions are welcome.

Seems to be related to the migration towards ILifeCycleAwarePart views, as the old Activated/Deactivated stuff apparently doesn't match to the new mechanism. For example, the interactions don't work because the selection is explicitly cleared in the Deactivated() method when clicking into the editor. I fixed the QmitkPointSetInteractionView so far. Needs to be tested manually, though, as it's always a strange feeling when simply deleting code and it still seems to work (again).

@maleike Did you try to use QString::toLatin1() instead of QString::toStdString()? AFAIK this is used rather often in MITK.

@maleike I think the current policy could be best described as "free for all"
However I am fully in favor of using a consistent conversion and policy and am open for suggestions. UTF 8 as internal string encoding seems reasonable to me and should harmonize reasonably well with Qt.
The most trouble would probably be the interplay with other, especially file system related, toolkits.
itksys is a problem you already encountered. I believe boost filesystem is currently not used anywhere, Poco might be another issue. I believe tinyxml supports UTF8 as well.

In T22602#96049, @goch wrote:

However as modern systems tend to support unicode filenames as well we might even want to consider changing the behaviour in QmitkIOUtil

I do not see an issue with it. EncodeName is really the wrong function to use at this point, as it was designed for encoding file names into platform/locale specific 8 bit.

Wait a little, there's more to this, I'll probably add to the first commit!

I just fixed the original description, the encodeName() originates from a commit by @zelzer, not @floca (the commit I originally cited just reused the pattern in multiple other lines)

@goch As you put some effort in these things as far as I know, is there something against the PR?

Hi, cool PR! 👍
Only had a very straight forward merge conflict and a forgotten migration from std::vector<mitk::DataNode*> to QList<mitk::DataNode::Pointer>. However, the interactions doesn't work anymore. For example, neither segmentation, clipping plane, nor point set work. I start to investigate what's going on, or what isn't.

Pushed new branch T22572-no-common-legacy.

Well it depends on the details but it is possible that if a public method doesn't make no sense anymore, a strategy could be to mark that method as deprecated in the class declaration and making a no-op out of it in the class definition. The more interesting question is if code from other clients would still work as they expect or if they would need to follow a migration guide.

Haha, ok, you're right, I don't want to do that. I don't know much about the deprecation process, so here's one question. Lets say my code is ok, the bug is fixed, but I deleted one public method somewhere because it made no sense anymore and it's incompatible with what I did. Are you telling me I must keep the old implementation along my new implementation for the next version(s)? The old implementation is buggy; it would make no sense to keep it.

The thing is, if you change public interface, you must go through the deprecation process. And you don't want to do this. 😄 Especially if it is simply a cosmetic change. Thanks for looking into it again.

Yes, I changed the public interface. I understand that you don't want to change it because some people might be using it, but all changes are related to the RenderWindowMenu. I doubt anyone outside of MITK is using this class.

It's hard to understand what you actually did to fix the issue as you touched large portions of the code. It also seems like you changed the public interface? Please describe the bug precisely and why the QSplitter is causing the trouble and what's needed to fix the issue. Also, please simplify your commit to the bare minimum necessary to fix the issue, as otherwise it is too confusing to review, thank you. :-)

Thank you, @goyette. 👍

Pushed new branch T22464-CrosshairRotation.