Pushed new branch T25605-View-direction-change-in-render-window-menu.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 9 2019
Missed it. "improve python 3 integration", "migrate to improved python 3 integration". Potato, Potahto
Aug 8 2019
@neher What's wrong with T26566: Migrate to improved Python 3 integration?
Pushed new branch T26559-Python3.
Aug 7 2019
It's MITK_USE_Python3 now instead of MITK_USE_Python. On macOS CMAKE_FRAMEWORK_PATH can be used to hint our CMake script to find a specific version of Python as Python 3.7 does not work at the moment.
Pushed new branch T26588-GetData.
Pushed new branch T25595-New-render-window-access.
LayoutManager has been added in T24215.
Aug 6 2019
Render window menu is now available (T24215).
However, QSplitter were added to the MxNMultiWidget so that resizing via mouse-dragging is also possible.
Pushed new branch T24215-Remove-stdmultiwidget-dependency.
@neher Relevant changes are in rMITKDIFFb55a6f64c48e: Rename MITK_USE_Python to MITK_USE_Python3. The other commit is just some rectified formatting of CMake script. Please merge into master.
Pushed new branch T26566-MigrateToImprovedPython3Integration.
Aug 5 2019
Pushed new branch T26561-FixPhantomConfigurationCancelation.
Pushed new branch T26562-FixTyposInIGTUSTrackingNavigationCalibrationView.
Pushed new branch T26546-FixCppRestSDKAndBoostIncompatibility.
Pushed new branch T26559-ImprovePython3Integration.
Prepared fix for CTK: https://github.com/commontk/CTK/compare/master...kislinsk:fix-pythonlibs-handling
Yes, I know, cancelled working on it on Friday as it was pretty late. It is addressed/will be fixed in T26559: Improve Python 3 integration.
Unfortunately, now numpy is not found anymore on Windows and Ubuntu. See nightlies.
Just a comment. Python wrapping is handled independently. We should talk to Michel about this.
Aug 4 2019
Aug 2 2019
Bug(s) in CTK:
If you ask for all the nodes from data storage then you get also child nodes in random order. In the previous implementation, visibility of all child nodes of widgets are set to True when the widgets node is reached. Nonetheless, child nodes visibility were afterwards set to False in the outer loop.
Now the loop is only done on nodes in the first level that contain data, therefore crosshair nodes stay always visible.
Could you elaborate on this? I don't get it: aren't we processing each single data node inside the data storage?
In Ubuntu 18.04 data storage is accessed in random order therefore the visibility of crosshair was set randomly. Fixed in branch: T19683-ShowOnlySelectedNodesCrosshairVisibility-RandomAccess.
Pushed new branch T19683-ShowOnlySelectedNodesCrosshairVisibility-RandomAccess.