https://github.com/NifTK/MITK/commit/da105b8f1ab18fef9a2851039ea2067e5bf2404c
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 2 2016
Sorry, this is the right form:
I missed a parenthesis from the end.
I close this as I could handle this in our application without modifying MITK.
I close this as I could handle this in our application, without modifying MITK.
I put the patch upon the same pull request to avoid conflicts.
All good.
MITKCore compiles and tests pass on Mountain Lion with gcc 4.2.1 (default compiler).
Moreover, the AccessByType is not an ideal solution for 1 at all, because you need to write lots of wrapper functions that create an ImageToItk inside.
I have not noticed 15821, but I have started working on the same issue already.
Fair enough.
There are three things that you can do with the AccessByType macros but not with AccessByItk:
It implements the is_const and remove_const types if the compiler does not support C++ 11. This case works well. I have not tested it with a compiler *with* C++ 11, though.
You're welcome. Thanks for the merge and for the additional fixes.
The pull request is based on the current master and it has two commits, one for both issues. The solution for the second issue is a bit tricky, see the comment of the commit.
It's not #17725 but #17473.
I meant "... as panning the image instead of zooming".
(In reply to Nils Lichtenberg from comment #4)
I could not reproduce the case that the origin changes while the scale
factor remains constant.
Duplicate of #17534 and #17755.
At the end I reverted this fix in our fork because it broke the MITK Display (stdmultiwidgeteditor), and we have that as well.
If you use a non-image plane geometry to initialise a sliced geometry then it will be a non-image sliced geometry.
For the previous comment:
In our viewer the renderers have non image sliced geometries. As far as I see it from the MITK code, it is the same for the MITK display.
I updated my fix to work on the last MITK release.
I meant the call is delegated to GetProperty(...), but that is also fine.
But then, I guess, the other window would have its own menu bar, tool bar, status bar and so on.
Pull request sent:
The patch is here, by the way:
Any thoughts on this?
I have a patch that corrects this, but it caused other problems. The origin, centre and the corner points of the renderers matched, but the crosshair was not exactly in the middle of the voxels.
I just tested it, and it works well now.
Thank you!
Any update on this?
We have been using the fix for a while now, it's tested on the three main platforms.
I'm trying to minimise the number of open tickets, and this seems to be an easy one.
Thanks.
17828 is another duplicate.
I mark it as invalid, as this was already fixed by Sandy on 2013.10.30. Unfortunately, our fork was based on a commit from two weeks before. Moreover, I our fix was not complete, the " ls->m_PropAssembly->VisibilityOff();" line was missing that caused that the last point stayed visible on the screen.
Pull request sent:
https://github.com/MITK/MITK/pull/48
I discovered a bug that might be the consequence of the proposed fix.
I close this as it looks to be fixed.
I shared the test framework with a little unit test.
The pattern that worked for me:
Any opinion about this?
Can it be merged, or should it stay on our fork?
Note that I also corrected a little mistake in the code:
I removed line 329 and 336 because they were in conflict with line 221 and 351.
Please find the patch through the pull request above.
Thanks for all this!
VTK 6.0 patch for OS X 10.9
Just a note.
VTK can be compiled with the patch attached.
VTK will need this patch to be built with XCode 5.1. Even VTK 6.1.
VTK 6.0 patch for OS X 10.9
You mean you merged VTK 6.1 to the master?
Will it be part of the March release?
I found meanwhile that the patch is not complete. You have to add the same OS X options to the MITK external project as well.
The ep_common_args is passed to all the dependent projects that are built as an external project of MITK. That is right.
17885 might be the same, but 17886 is different. It is not a bug but a missing feature, which was provided by the old position event but not by the new one.
I'm preparing for our next MITK upgrade and try to revert the patches that we have been fixed in the upstream.
Hi Tobias,
thanks for dealing with this issue.
As I see, you just committed a fix for this issue which seems to be almost identical to mine. Would you mind cherry picking my fix instead, so that the authorship is kept? I know that's a very trivial change.
I am happy to update the pull request to add the Signed-off-by clause.
Thanks.
Not at all, thanks for the status update.
Now I see that your commit was for the PointSetDataInteractor, while mine was for PointSetInteractor. Then just keep your commit, and also cherry-pick mine. I added the signed-off-by clause to it.
The second issue (588ecb3d) is invalid, it has been fixed in the master meanwhile.
Any update on this?
The bug is potentially there in the 'else' branch as well, when there is no position and all the selected points have to be removed.
I sent the pull request for the first bug.
Have you got the core change request affirmation?
Any update on this?
Pull request sent:
https://github.com/MITK/MITK/pull/39
I noticed the same error in mitk::KeyEvent. It would be worth checking the other event types, too.