Deleted branch from rMITK MITK: bugfix/T27744-ReviseModelFitDemo.

Deleted branch from rMITK MITK: T27100-Revise-DataManager-Plugin-Documentation.

Deleted branch from rMITK MITK: T27100-Develop-integration.

This task was never done but falsly auto closed.

I played around with the different occurances of org.mitk.gui.qt.stdmultiwidgeteditor and org.mitk.gui.qt.stdmultiwidget and changing now both, the id and the page identifyer back to stdmultiwidget (removing editor) now works for me. In the build directory there is also now only the org_mitk_editors_stdmultiwidget.html file present (I deleted the org_mitk_editors_stdmultiwidgeteditor.html).
I am quite puzzled by this "strange magic" and don't know why this is working now even if was not working before.

I totally understand the reasoning and I'm very much confused how everything works. I just hesitate to accept the review because this looks more like a workaround and we may have to dig deeper to understand the real problem here.

I tried using for the id
org_mitk_editors_stdmultiwidgeteditor
instead of
org_mitk_editors_stdmultiwidget

In T27563#233900, @kompan wrote:

The F1 help seems to be looking for \MITK-build\Documentation\Doxygen\html\org_mitk_editors_stdmultiwidgeteditor.html

Where do you see that?

This issue is now observed in Release mode, as well. Ref. T29000

The F1 help seems to be looking for \MITK-build\Documentation\Doxygen\html\org_mitk_editors_stdmultiwidgeteditor.html

I checked and I found the file: \MITK-build\Documentation\Doxygen\html\org_mitk_editors_stdmultiwidget.html analogous to the DICOM browser file. When I open it, it looks like it should (not a blank page).

In T27563#233777, @kompan wrote:

I am currently working on task https://phabricator.mitk.org/T28294 and have added an F1 help file for the standard display (and also a general remark how to use the F1 help for other plugins). The help is shown in the doxygen user MITK user manual, but the F1 help searches for
org.mitk.gui.qt.stdmultiwidgeteditor/bundle/org_mitk_editors_stdmultiwidgets.html and a blank page is shown consequently.

The page id in the plugin xml is:
id="org.mitk.editors.stdmultiwidget"

The page identifier is:
\page org_mitk_editors_stdmultiwidget The Standard Display

and I have added to the MITKPluginGeneralManualsList.dox
\li \subpage org_mitk_editors_stdmultiwidget

and to the MITKPluginManualsList.dox
<li> \ref org_mitk_editors_stdmultiwidget </li>

No, that was just a typo, there is no s. (couldn't copy and paste from the Workbench)

In T27563#233777, @kompan wrote:

org.mitk.gui.qt.stdmultiwidgeteditor/bundle/org_mitk_editors_stdmultiwidgets.html and a blank page is shown consequently.

Is there realy an s before ".html"? So plural? All other appereances you mentioned were singular.

I am currently working on task https://phabricator.mitk.org/T28294 and have added an F1 help file for the standard display (and also a general remark how to use the F1 help for other plugins). The help is shown in the doxygen user MITK user manual, but the F1 help searches for
org.mitk.gui.qt.stdmultiwidgeteditor/bundle/org_mitk_editors_stdmultiwidgets.html and a blank page is shown consequently.

Deleted branch from rMITK MITK: T27498-Set-selection-mode-to-auto-selection.

Deleted branch from rMITK MITK: feature/T28118-Refactor_SegTool2D_and_derived_classes.

@floca Please delete the feature branch mentioned above if this task is resolved.

Hi there! 🙂

Hi there! 🙂

Nvidia AIAA WorkbenchRelease binaries are building or were already deployed.

Deleted branch from rMPT MITK-ProjectTemplate: release/T28000-v2021.02.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T28000-v2021.02.

Deleted branch from rMPT MITK-ProjectTemplate: release/T28000-v2021.01.

Deleted branch from rMITK MITK: bugfix/T28000-BumpDevelVersion.

Pushed new branch to rMITK MITK: bugfix/T28000-BumpDevelVersion.

Deleted branch from rMITK MITK: bugfix/T28000-BumpDevelVersion.

Deleted branch from rMITK MITK: release/T28000-v2021.02.

Pushed new branch to rMITK MITK: bugfix/T28000-BumpDevelVersion.

Pushed new branch to rMITK MITK: release/T28000-v2021.02.

Deleted branch from rMITK MITK: release/T28000-2021-Week-06.

Deleted branch from rMITK MITK: release/T28000-v2021.01.

Pushed new branch to rMITK MITK: release/T28000-2021-Week-06.

Is it really a minor change and we include it in the current release, but still we should not yet officially announce support of system Qt5.

I tried running the Workbench on Linux both with valgrind as well as AdressSanitizer. Unfortunately there is a lot of noise from memory leaks and stuff, but I did not spot anything obvious which could be the cause.

Deleted branch from rMITK MITK: bugfix/T28284-FixRenderWindowMenuVisibility.

It was an alternative code path for handling render window menu visibility on macOS that is no longer needed, resp. now even broke the visibility handling. Now all supported platforms use the same code path and to make it work in the first place without any workarounds, a few adjustmens/simplifications were necessary. The visibility status is no longer coupled to the mouse move event, which was ill-formed from the beginning and resulted in trouble on different platforms like flickering on Linux. The visibility state is now way more effectively coupled to the enter and leave events of the render windows. There's also an immediate reaction now on resize events.

Pushed new branch to rMITK MITK: bugfix/T28284-FixRenderWindowMenuVisibility.

Closing an empty workbench or loaded workbench using X button on the title bar causes this.

What views were opened or data loaded? Or was it an empty workbench?

Attaching full stacktrace herewith:

The fix was merged upstream and this task will be resolved with the merge of the current release branch this week.

In T28285#219856, @nolden wrote:

I did not dive into Windows APIs, so I just hope you know what you are doing ;)

The test looks reasonable and passes also on Linux.

One improvement could be to output the string (and maybe the hex version) in the WARNING output if the conversion fails.

And did you look into boost? There is also some conversion stuff

I did not dive into Windows APIs, so I just hope you know what you are doing ;)

In T28285#219852, @nolden wrote:

I did some Googling, it seems that starting with 2019 release, Windows 10 has a UTF8 mode. It's a bit difficult to enable: "old" control panel -> region -> Administrative settings -> Change System locale -> Enable UTF8

After checking this box, MITK loads the data without code changes, but DataNode name is just a single slash "/" ... ;)

Pushed new branch to rMITK MITK: bugfix/T28285-Local8BitToUtf8.

I did some Googling, it seems that starting with 2019 release, Windows 10 has a UTF8 mode. It's a bit difficult to enable: "old" control panel -> region -> Administrative settings -> Change System locale -> Enable UTF8

Hi you both, thanks for the digging.
I also tend too follow @nolden propsal 1) declaring it a kown issue and 2) returning a meaningfull error message, of invalid characters are used.

That's a thorough dive in the topic ... Yes, toUtf8(), and nicely prints the correct Umlaut in the message box, telling you the file doesn't exist ;) I only had a quick glance around, and since a lot of stuff goes though ITK, and ITK decided to stay with local 8bit as far as I understand, I also think this would be the way to go. But I could really live with declaring this a "Known issue". Maybe something on the application user level would be nice, like

if toUtf8 != toLocal8Bit then show error

Uh, maybe I made it more dramatic than it is. We can also do the complete opposite and stay with toLocal8Bit(). That means, that we only need conversion when writing the path and name into the properties. I wrote a Local8BitToUtf8() function and it works in a first test. We can also use it to pass an UTF-8 string to the GDCM reader. Didn't check for all code locations where to do it but its late already and tomorrow is another day. :-)

I also looked into this and one of the problems/differences to "back in the days" is that Qt nowadays assumes by default that C-strings in the constructor of QString are UTF-8 encoded. So, for example, Marco, if you change toLocal8Bit() in QmitkIOUtil to toUtf8(), you get working strings in the GUI (can be easily tested with a MessageBox::information()), but invalid strings for most of the readers, as they assume the local codepage. So we can have one or the other, but not both at the moment. The thing is that QmitkIOUtil works with QString, but mitk::IOUtil uses std::string in the structure that holds the file path (LoadInfo). This is then later used to be stuffed into StringProperty for the name property or the path property. Qt of course assumes these strings to be UTF-8 and hence we see the ?'s in the GUI.

Ok, the GDCM unicode windows fix was introduced in the 3.0 series: https://github.com/malaterre/GDCM/commit/d4dfa144b941c6cc4da87f9795f7f5aba2bb7481

Ok, I did look around a bit more. To summarize, I guess going for the "local 8bit representation" seems to be the most feasible way, since ITK also assumes this and I think we have a lot of ITK file handling code.

Ok, I debugged to SetFileName @floca mentioned, it gets called from GDCMImageIO::InternalReadImageInformation in ITK

This is a problem that becomes visible in gdcm and it is not the first time that we encouter it.
Currently the gdcm reader fails to open the file. I assume it is correlated with gdcm changes of how to handle filenames under windows in gdcm (gdcmReader.cxx 836ff)

void Reader::SetFileName(const char *uft8path)

Here some conversion between utf8 and utf16 was introduced and this string:

"C:/Users/floca/Downloads/sämple.IMA"

is changed to:

L"C:/Users/floca/Downloads/s�mple.IMA"

and for the later string the loading fails.

Oh no, I can remember similar issues with German Ubuntu and "Arbeitsfläche" ... Basically, CI clients should probably always have a path compontent like /bäh / included to catch new issues like this one, and build system stuff, which is also a candidate.

Additional info: This is not a DICOM reader problem in the first place, as the filename string encoding seems to be unexpected (see screenshot above). Other readers work but the node still appears with a dummy symbol in the data node name.