Currently the IntroPart is activated but not top level and thus hidden behind the editor. I think I can remeber it differently in earlier version and besides that I think it makes more sense to show the intro part topmost if it is displayed and not on stand by.
Description
Description
Revisions and Commits
Revisions and Commits
rMITK MITK | |||
Restricted Differential Revision | rMITK956f7971d12a T27549 Rechecked if IntroPart was created in OpenIntro and enforce its… | ||
Restricted Differential Revision | rMITKaf8e86e1c90f Rechecked if IntroPart was created in OpenIntro and enforce its visibility. |
Related Objects
Related Objects
- Mentioned In
- T27638: 2020 Week 31
- Mentioned Here
- rMITK166bffff1578: Max length param readf
Event Timeline
Comment Actions
I am not sure if I find the reason/solution. But at least it seems to be a sensible work arround.
Following observations:
- MITK Diffusion has not such problems, but they use there own application/plugin/windowadvisor. In the diffusion window advisor the IntroPart is coded to always being shown, thus no problem.
- The IntroPart is activated correctly, but afterwards in QmitkExtWorkbenchWindowAdvisor::PostWindowOpen() mitk::WorkbenchUtil::OpenEditor() is called which brings the editor up front again.
- I could not identify any code change that triggered the change in behavior of blueberry (but as I wasn't shure since when the behavior changed, the search was only very shallow).
- You can circumvent the proplem, if you check in QmitkExtWorkbenchWindowAdvisor::PostWindowOpen() after mitk::WorkbenchUtil::OpenEditor() if a IntroPart is there and force its showing (again).
Comment Actions
I think I can remember it differently in earlier version
I checked installer 2016 / 2018 and some 2017 BlackSwan Demos and couldn't find a scenario where the Welcome Screen was the active tab, but anyways.
I also built 166bffff1578 to see if it has anything to do with my changes related to the multi-widget refactoring but couldn't see any difference.