OK, sorry for the confusion. At least the behaviour is very similar across platforms. I filed a new bug report here: https://savannah.gnu.org/bugs/index.php?64102

Same bug was described here: https://savannah.gnu.org/bugs/?56116
but discussion closed. Behavior in Win11 is exactly the same as described in that report.

@alepplew: How are you using KDE on Windows 11?

Until Qt5.15 (pending), Qt/QProcess actually never stopped relying on SIGCHLD:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/3rdparty/forkfd/forkfd.c?id=1814142b7a11#n371

Only Qt5.15 will use CLONE_FD:
https://lwn.net/Articles/636646/

Amazing observation Stefan Brüns comment #54, comment #55.  Thank you a lot.

All openSUSE users:

sudo zypper remove samba

And the native file dialog works in a second!!

This is indeed not a solution bug a huge step forward.

Regarding the removal of the watcher thread, I do not have enough insight about this.

The cause of the issue becomes quite obvious when using strace ('strace -tf -etrace=%signal,%process octave --gui')

[pid  3329] 14:36:53 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f43fde40030}, NULL, 8) = 0
[pid  3329] 14:36:53 kill(3351, SIGTERM) = 0
[pid  3329] 14:36:57 rt_sigaction(SIGCHLD, {sa_handler=0x7f43fa87efc0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO|SA_NOCLDSTOP, sa_restorer=0x7f43fde40030}, {sa_handler=0x7f43fcebfbb0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f43fde40030}, 8) = 0
[pid  3329] 14:36:57 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f43fde40030}, NULL, 8) = 0
[pid  3330] 14:36:57 exit(0 <unfinished ...>
[pid  3331] 14:36:57 exit(0 <unfinished ...>
[pid  3330] 14:36:57 <... exit resumed>) = ?
[pid  3331] 14:36:57 <... exit resumed>) = ?
[pid  3330] 14:36:57 +++ exited with 0 +++
[pid  3331] 14:36:57 +++ exited with 0 +++
[pid  3333] 14:36:57 exit(0)            = ?
[pid  3333] 14:36:57 +++ exited with 0 +++
[pid  3334] 14:36:57 exit(0)            = ?
[pid  3334] 14:36:57 +++ exited with 0 +++
[pid  3335] 14:36:57 exit(0)            = ?
[pid  3335] 14:36:57 +++ exited with 0 +++
[pid  3336] 14:36:57 exit(0)            = ?
[pid  3336] 14:36:57 +++ exited with 0 +++
[pid  3337] 14:36:57 exit(0)            = ?
[pid  3337] 14:36:57 +++ exited with 0 +++
[pid  3329] 14:36:57 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process 3356 attached
, child_tidptr=0x7f43f537cdd0) = 3356
[pid  3356] 14:36:57 rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f43fde40030}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f43fde40030}, 8) = 0
[pid  3356] 14:36:57 execve("/usr/bin/testparm", ["/usr/bin/testparm", "-d0", "-s", "--parameter-name", "usershare path"], 0x7f43ac1b7c40 /* 106 vars */) = 0
[pid  3356] 14:36:57 arch_prctl(ARCH_SET_FS, 0x7fb2f255b900) = 0
[pid  3356] 14:36:57 rt_sigaction(SIGRTMIN, {sa_handler=0x7fb2f36dc6b0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fb2f36e92d0}, NULL, 8) = 0
[pid  3356] 14:36:57 rt_sigaction(SIGRT_1, {sa_handler=0x7fb2f36dc750, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fb2f36e92d0}, NULL, 8) = 0
[pid  3356] 14:36:57 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
[pid  3356] 14:36:57 exit_group(0)      = ?
[pid  3356] 14:36:57 +++ exited with 0 +++
[pid  3347] 14:36:57 <... rt_sigtimedwait resumed>{si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3356, si_uid=1000, si_status=0, si_utime=1, si_stime=0}, NULL, 8) = 17 (SIGCHLD)
[pid  3347] 14:36:57 rt_sigtimedwait([HUP INT QUIT PIPE ALRM TERM CHLD XCPU XFSZ VTALRM],  <unfinished ...>
[pid  3329] 14:37:27 kill(3356, SIGKILL) = 0
[pid  3329] 14:37:57 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process 3395 attached
, child_tidptr=0x7f43f537cdd0) = 3395
[pid  3395] 14:37:57 rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f43fde40030}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f43fde40030}, 8) = 0
[pid  3395] 14:37:57 execve("/usr/bin/net", ["/usr/bin/net", "usershare", "info"], 0x7f43ac1b7c40 /* 106 vars */) = 0
[pid  3395] 14:37:57 arch_prctl(ARCH_SET_FS, 0x7f4ee2795440) = 0
[pid  3395] 14:37:57 rt_sigaction(SIGRTMIN, {sa_handler=0x7f4ee39826b0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f4ee398f2d0}, NULL, 8) = 0
[pid  3395] 14:37:57 rt_sigaction(SIGRT_1, {sa_handler=0x7f4ee3982750, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f4ee398f2d0}, NULL, 8) = 0
[pid  3395] 14:37:57 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
[pid  3395] 14:37:57 exit_group(0)      = ?
[pid  3395] 14:37:57 +++ exited with 0 +++
[pid  3347] 14:37:57 <... rt_sigtimedwait resumed>{si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3395, si_uid=1000, si_status=0, si_utime=3, si_stime=1}, NULL, 8) = 17 (SIGCHLD)
[pid  3347] 14:37:57 rt_sigtimedwait([HUP INT QUIT PIPE ALRM TERM CHLD XCPU XFSZ VTALRM],  <unfinished ...>
[pid  3329] 14:38:27 kill(3395, SIGKILL) = 0

1. testparm is spawned
2. 30s timeout
3. 30s kill timeout
4. net is spawned
5. 30s timeout
6. 30s kill timeout

The processes are spawned by KDE the KIO SAMBA integration:
https://cgit.kde.org/kio.git/tree/src/core/ksambashare.cpp#n124

QProcess::waitForFinished() never gets the SIGCHLD signal as it is stolen by sigwait (rt_sigtimedwait([... CHLD ...]).

This is a well known problem, see e.g. https://bugreports.qt.io/browse/QTBUG-56338

Octave is actually using two handlers for SIGCHLD, once via sigaction from the main thread, and once via sigwait from the interrupt watcher thread.

Even without QProcess coming into play the signal handling is indeterminate, as each signal may be delivered either to the dedicated thread or to the main thread.

As far as I can see, the fix is trivial - just disabling the signal watcher thread solves the problem.

I cannot reproduce this issue in KDE neon with Octave 5.2

Done: https://hg.savannah.gnu.org/hgweb/octave/rev/1002b49ce7b3

My final patch for this issue file #45439 .  If it does not any harm to other display managers, it makes me want to save my work with Octave 5.0.0 again ;-)

Kai, I have no objections. This is probably the best we can do right now.

Just a remark regarding the new preference. Why are you checking the existence of the settings key? When the key is not present, value () just returns the default value.

@Mike and @Kai, it's nice to see that we are in the same page. Sorry for the misunderstanding.

I'd like to test it myself in a production system via flatpak to see if this is something more or less general. @Mike, do you think trying Octave's development version is sth easy in flatpak? I recall packaging it myself once from a patch from you. But did it only once and quite some time ago. If you think this is feasible, would you please guide me again on how to proceed for testing this issue in my system?

Thank you!

Kai, thanks for testing. The example code also uses the non-static variant, although it is weird that its works in the non-octave context. What about saving/loading the workspace. Do you experience hangs when doing this?

@Kai, TeXStudio seems to use static members of QFileDialog only. In octave this is the case for loading and saving the workspace, whereas the editor is creating own instances of QFileDialog. Does the issue also show up when you are saving or loading the workspace?

> I don't use KDE so I have no way to test this, the GNOME native file dialogs work just fine for me (and a much improved user interface over the Qt default style).

I submitted this issue in the first place because using Gtk or non-native Qt dialogs in KDE is a pain in comparison to the native dialogs. I think any KDE user would say similarly.

I really hope this improvement is not reverted. I also hope remaining issues are fixed, of course.

I use KDE and am willing to test, but unfortunately I don't have the time to learn how to compile from the sources myself.

Have you tried removing all of Octave's Qt settings

mv ~/.config/octave /tmp

and then starting a dev version of Octave that has been installed somewhere locally?  I just want to see whether re-creating the qt-settings file and the octave_kbf.pap file would help.

Regarding comment #32 : Yes, On my system there are many fonts installed (texlive, etc.)

Is there a way to pre-select a default font for calling those dialogues?

Mmm, that behavior reminds me this: https://github.com/rstudio/rstudio/issues/1889#issuecomment-357050688

Could this same thing happen now in Octave? Do you have a lot of fonts installed in your system?

Also, I am not using any NFS shares.  In fact, These two messages came up in a shell window from which I had launched the Octave GUI.

Trying to convert empty KLocalizedString to QString.
kf5.kio.core: KSambaShare: Could not find smb.conf!

So, I'm very sure that I'm not reaching out to any external drives and experiencing network timeouts.

> @Torsten: Can you test and confirm the problems with KDE Plasma 5, too? Or did I something wrong?

KDE neon uses KDE Plasma 5 as well, a more updated version than the one you referred too though, but this shouldn't in principle be a problem. Of course the more testing the better.

If somebody would package the Octave default branch as a flatpak or a deb, I would be happy to test.

Sorry for not having tested the GUI of the default branch for a while.  But if Octave 5.0 gets released with this, I will have serious usage problems with "hangs" on every "save" or "save as" action.

At work I use Octave with "openSUSE 15.0" which is the latest stable and maintained branch of that Linux distribution.  It uses:

- KDE Plasma 5.12.6 (https://software.opensuse.org/package/plasma5-desktop)

- QT 5.9.4 (https://software.opensuse.org/package/libqt5-qtbase)

Which are not too ancient, I hope.  The changes of comment #21 and comment #24 have only been tested with KDE Neon on one system only, right?

@Torsten: Can you test and confirm the problems with KDE Plasma 5, too?  Or did I something wrong?

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/bb0c58796275 adds the possibility to select another encoding and reload the file in case of detected decoding errors.

On Kubuntu in my virtual box the file dialogs are working well without freezing octave. Are there any other experiences with file dialogs on Kubuntu after the patch for this bug?

I second it from a user point of view. It's not that difficult to convert a file encoding externally (after a fast search on the internet if one is not familiar with it), and it's the easiest/cleanest implementation for Octave.

The first option was not bad either, maybe the best for a naive user, but most likely much more complicated to implement in Octave, and perhaps out of scope.

Maybe we could add a menu entry "Convert to UTF-8..." (or whatever the current encoding is) that would open a dialogue from which the user could choose the source encoding (maybe with heuristics).
But that doesn't feel very streamlined.

Alternatively, we could display a dialogue if the heuristics detect a different encoding that advices the user to convert the file with external tools.

Or we could leave it up to the user entirely to find that something is odd and convert the text encoding with an external tool.

What do editors in other IDEs do?

I don't know whether this would add more confusion than it would help.
At the moment the same codepage is used for displaying and executing m-files (by default). The codepage that is used for executing m-files is defined globally.
With these potentially new heuristics for the editor, a user might be confused if their file displays correctly in the editor but seemingly uses different (incorrect) strings on execution.

For the same sake, it might even be useful to completely remove the codepage selection from the file opening dialog...

I propose to implement some automatic encoding detection (although not 100% reliable) which is also used by notepad++ or other programs. In addition, of course, the change of the encoding has to be made accessible via the menu actions.

I would like to implement one class of dialogs without adding another user preference. If we decide to use native dialogs, default line endings and text encoding can be changed in the preferences dialog but for a single file only changing the line endings are already accessible via the menu actions. Changing the encoding would have to be added to the menus.

A more serious problem is, that there is no automatic detection of the file encoding. Missing the related combo box in the open file dialog box, only files with the default encodings are read correctly.

Given this impact in functionality, I will re-enable non-native file dialogs for the editor. Native dialogs for testing will still be available for loading/saving the workspace.

I just recognized that I have missed the save as dialog. This one can not use native dialogs since it is modified for choosing line endings and text encoding. The latter also holds for opening editor files where the encoding can be selected. This is now disabled with my patch since only non-nantive dialogs can be extended by own ui elements.

I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/daebd587961d
Now, octave uses native file dialogs, but look and feel strongly depends on the contents of the environment variable QT_QPA_PLATFORMTHEME.

Excellent, thank you!

If somebody would compile the patched version as a flatpak and/or deb package, I am willing to test it in my KDE neon User Edition on top of Ubuntu 18.04.

Once we have a patch, I would give it a try myself, but compiling octave from scratch is hardcore and I don't have the time to deal with this at this point.

I hope some Octave dev + KDE user, can give this a try, which should be relatively straightforward for that developer.

If we get a patch, I guess we can ask for that in the maintainers mailing list.

Assuming this is no longer necessary, do we want to make Qt5.5 the minimimum required version throughout Octave and particularly in the documentation and configure.ac?

This is related to https://savannah.gnu.org/bugs/?38305  which was fixed by these changes https://hg.savannah.gnu.org/hgweb/octave/rev/6bd74153c3ae

Indeed, I cannot use native (KDE) open/save dialogs in Octave 4.4.1 (tested in flatpak package).

However this referred to an old conflict in Qt4, which does not seem to apply anymore. If for instance one uses the uigetfile command instead, the the native dialog emerges and nothing seems to fail or break.

Users workflow will appreciate reverting these changes if as I think they don't apply anymore.

(Original discussion at https://github.com/flathub/org.octave.Octave/issues/28).