bugGNU Octave - Bugs: bug #54607, Native open/save file dialogs have...

 
 

bug #54607: Native open/save file dialogs have poor performance in KDE

Submitter:  avlas <kupiqu>
Submitted:  Fri 31 Aug 2018 05:46:41 PM UTC
   
 
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Performance
Status:  Need Info Assigned to:  ttl
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 24 Apr 2023 09:19:07 AM UTC, comment #64: 

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

Albrecht <alepplew>
Mon 24 Apr 2023 08:19:36 AM UTC, comment #63: 

This report and the one you are referring to are both about delays with the native file dialog on KDE.
You are on Windows and not using KDE. Additionally, the behavior is independent on the "native file dialog" setting for you. So, what you are seeing is different from what is reported here.
Please open a dedicated report for the issue you are seeing to not side-track this report.

Markus Mützel <mmuetzel>
Group administrator
Mon 24 Apr 2023 08:13:29 AM UTC, comment #62: 

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.

Albrecht <alepplew>
Mon 24 Apr 2023 08:10:22 AM UTC, comment #61: 

Not using KDE as far as I know. Installed Octave 8.1.0 using the windows 64bit installer. When calling uigetfile the file selector populates only after appr. 60 s. Subsequent calls are sometimes, not always populating faster. Unchanged by "use native file dialogs" preference setting.

Albrecht <alepplew>
Mon 24 Apr 2023 06:25:44 AM UTC, comment #60: 

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

Markus Mützel <mmuetzel>
Group administrator
Sun 23 Apr 2023 12:35:55 PM UTC, comment #59: 

Exactly the same problem on Octave 8.1.0 (GUI) running in Windows 11
This is independent of "use native file dialogs" checked or not.

Albrecht <alepplew>
Mon 17 Feb 2020 08:43:34 PM UTC, comment #58: 

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/

Stefan Brüns <stefanbruens>
Mon 17 Feb 2020 07:23:27 PM UTC, comment #57: 

In comment #1, I wrote

> It does look to me like Qt 5 no longer installs its own signal handler for SIGCHLD in the QProcess implementation, so this may indeed be safe now for Qt 5.


Apparently that is no longer true. It may have been true a few years ago, for some versions of Qt 5 between 5.5 and 5.9. But many redesigns have been made to the unixy implementation of QProcess since then, so it appears to be relying on SIGCHLD yet again.

The bottom line, again, as before, is that a program must coordinate all parts that depend on SIGCHLD. If Octave handles SIGCHLD, then any library or framework linked with it into the same process space can't rely on SIGCHLD, and vice versa.

If this is going to keep happening with Qt, and if Qt asserts that they are doing things correctly, then Octave either needs to overhaul its signal handling logic yet again, or we need to make the GUI a completely separate process.


Mike Miller <mtmiller>
Group Member
Mon 17 Feb 2020 03:22:57 PM UTC, comment #56: 

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.

Kai Torben Ohlhus <siko1056>
Group Member
Mon 17 Feb 2020 02:54:08 PM UTC, comment #55: 

openSUSE users can test these packages:

https://build.opensuse.org/package/show/home:StefanBruens:branches:science/octave

Others may either pick up the patch, or verify that uninstalling samba (server) also cures the problem.

Stefan Brüns <stefanbruens>
Mon 17 Feb 2020 02:48:36 PM UTC, comment #54: 

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.

Stefan Brüns <stefanbruens>
Fri 14 Feb 2020 09:47:42 PM UTC, comment #53: 

If this issue is still present in 5.2.0, XDG_SESSION_DESKTOP and/or XDG_DATA_DIRS could be examined. If KDE is detected, non-native file dialogs are automatically selected overwriting the user's preference.

Torsten Lilge <ttl>
Group Member
Fri 14 Feb 2020 08:23:41 PM UTC, comment #52: 

I cannot reproduce this issue in KDE neon with Octave 5.2

avlas <kupiqu>
Fri 14 Feb 2020 09:00:31 AM UTC, comment #51: 

Reopen because other systems (ALT Linux https://en.altlinux.org/Main_Page) are affected next to openSUSE
as well, see

https://github.com/flathub/org.octave.Octave/issues/96

I try to investigate on this again...

Kai Torben Ohlhus <siko1056>
Group Member
Sat 17 Nov 2018 09:46:52 AM UTC, comment #50: 
Kai Torben Ohlhus <siko1056>
Group Member
Fri 16 Nov 2018 09:52:44 PM UTC, comment #49: 

Kai, thanks for the patch, it is working for me on Ubuntu with Gnome. Could you please push it?

Torsten Lilge <ttl>
Group Member
Thu 15 Nov 2018 10:29:21 PM UTC, comment #48: 

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 Torben Ohlhus <siko1056>
Group Member
Thu 15 Nov 2018 07:48:16 PM UTC, comment #47: 

Torsten, that is right (comment #46), thanks for this remark =)  When completing the patch, I just omit this check.

Kai Torben Ohlhus <siko1056>
Group Member
Thu 15 Nov 2018 05:56:41 PM UTC, comment #46: 

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.

Torsten Lilge <ttl>
Group Member
Thu 15 Nov 2018 10:47:42 AM UTC, comment #45: 

I propose the following (not yet complete) patch (file #45431):

1. Native file dialogs stay default
2. There is a qt-option "use_native_file_dialogs=true" to revert this decision in case of problems (configurable via the "General" preference tab).
3. Long term goal: remove this option.

If you (especially Torsten) agree on this approach, I will complete this patch for all occurrences of QFileDialog), roughly those of cset in comment #21.

Kai Torben Ohlhus <siko1056>
Group Member
Wed 14 Nov 2018 10:09:25 PM UTC, comment #44: 

@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!

avlas <kupiqu>
Wed 14 Nov 2018 10:04:14 PM UTC, comment #43: 

@Torsten, I hope to be helpful with my testing ;-)

"File > Load workspace/Save workspace as" hangs the first time as like as other QFileDialogs.

Kai Torben Ohlhus <siko1056>
Group Member
Wed 14 Nov 2018 09:52:42 PM UTC, comment #42: 

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?

Torsten Lilge <ttl>
Group Member
Wed 14 Nov 2018 08:39:29 PM UTC, comment #41: 

Thank you for all the feedback.

Comment #36: Now I really tried a clean installation to /usr/local, removed everything in my home directory, especially the folder ~/.config/octave with qtsettings (I almost stick to the default settings anyway...) But no change :(

One observation here: when the starting first time save as-dialogue hangs (~5 minutes), or at any subsequent call (1 second), a process of

/usr/lib64/qt5/plugins/kf5/kio/file.so

starts and vanishes some time after closing the dialogue.

Comment #39:

> ... 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 agree with you completely, too, and want them to work.  But it is not the case for me, so I propose an option to opt-in non-native-dialogues in the hope this option becomes deprecate in a near future.

Comment 40: Even nothing to win here.  I tried to copy and paste the demo code from the tutorial (disregarding any functionality) from the official tutorial [1] into Octave [2] and recompiled.

It is like witchcraft: The stand-alone tutorial works like a charm, in Octave [2] the very same code causes this hangs.

[1] http://doc.qt.io/qt-5/qtwidgets-mainwindows-application-mainwindow-cpp.html
[2] https://hg.savannah.gnu.org/hgweb/octave/file/edc02d5eeac6/libgui/src/m-editor/file-editor-tab.cc#l2178

Kai Torben Ohlhus <siko1056>
Group Member
Wed 14 Nov 2018 07:18:52 PM UTC, comment #40: 

@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?

Torsten Lilge <ttl>
Group Member
Wed 14 Nov 2018 06:57:16 PM UTC, comment #39: 


> ... 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 agree with you completely. I wasn't saying that the change makes no difference to me as a GNOME user. I was saying that the GNOME native file dialogs are a much better interface for a GNOME user than the standard Qt non-native file dialogs. But the GNOME native file dialogs do not have any issues with hanging or timing out like the KDE plugin appears to do for some, so this bug does not affect me.

Mike Miller <mtmiller>
Group Member
Wed 14 Nov 2018 06:17:27 PM UTC, comment #38: 


> 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.

avlas <kupiqu>
Wed 14 Nov 2018 06:06:25 PM UTC, comment #37: 

Kai - the issue with SIGCHLD and the KDE native file dialogs was the original reason why Octave switched from native dialogs to Qt dialogs in the first place. See patch #7948.

As I mentioned in comment #1, this problem was supposedly fixed in Qt 5.5, so Qt programs ought to be free to use SIGCHLD however they wish and not interfere with this plugin, but from my point of view this is only what I have read.

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).

Mike Miller <mtmiller>
Group Member
Wed 14 Nov 2018 03:55:26 PM UTC, comment #36: 

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.



Rik <rik5>
Group administrator
Wed 14 Nov 2018 03:37:57 PM UTC, comment #35: 

My build of dev (hg id e142769913f8) still has this problem.  I am sure it is related to the way Octave uses qt5.  Another qt5-application I use (TeXstudio) runs those native save-dialogues without problems... regardless of the fonts or whatsoever I have installed or connected via network.

I don't want to leave this item open forever.  Was it possible to make it optional to use the native dialogues, as TeXstudio does?  Octave has a qt-config file.  I think it is possible to adapt such an option.  Maybe it was not required to wrap the QFileDialog like TeXstudio does:

https://github.com/texstudio-org/texstudio/blob/master/src/configmanager.cpp#L456

https://github.com/texstudio-org/texstudio/blob/master/src/filedialog.cpp#L7

Another interesting thread to follow about KDE and VLC trouble turned out to be an issue with improper signal handling "SIGCHLD" by qt:  https://marc.info/?l=kde-core-devel&m=129572435508899&w=2  But I really have no idea how to investigate this.

Kai Torben Ohlhus <siko1056>
Group Member
Mon 05 Nov 2018 09:05:40 PM UTC, comment #34: 

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?

Kai Torben Ohlhus <siko1056>
Group Member
Mon 05 Nov 2018 08:50:10 PM UTC, comment #33: 

I have tested with Plasma 5.5.5, Qt 5.5.1, but no shares mounted and a small test system (so no large number of fonts).

Torsten Lilge <ttl>
Group Member
Mon 05 Nov 2018 08:19:00 PM UTC, comment #32: 

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?

avlas <kupiqu>
Mon 05 Nov 2018 08:12:07 PM UTC, comment #31: 

Good news!  I can confirm Guillaume's observation of comment #27.  The first time calling "save as"/"save" on an editor file, or calling "uiputfile()" (comment #29) it takes 5 Minutes on my system for this dialogue to appear.  All following calls happen within a second.  After Octave GUI is closed and started again, the same problem again.

On the shell window I started Octave (via "./run-octave --gui") there is no output like in comment #30, and I do not mount NFS shares.

This makes the problem less serious than I initially thought.  But the whole Octave GUI is unresponsive for 5 Minutes and it looks like crashed :-/

Any idea how we can test what is wrong with KDE/my system?

Kai Torben Ohlhus <siko1056>
Group Member
Mon 05 Nov 2018 04:37:21 PM UTC, comment #30: 

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.

Rik <rik5>
Group administrator
Mon 05 Nov 2018 04:31:22 PM UTC, comment #29: 

@Kai: I'm using Kubuntu 18.04 which has Qt 5.9.5 and KDE 5.12.4.  Native dialogs seem to work.  I used "Save As" to save the workspace and uiputfile() in the Command Window for testing.

Rik <rik5>
Group administrator
Mon 05 Nov 2018 04:21:22 PM UTC, comment #28: 


> @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.

avlas <kupiqu>
Mon 05 Nov 2018 04:10:31 PM UTC, comment #27: 

Same OS and I also observe that the file dialog window becomes unresponsive for a very long time the first time it appears. In bug #54885, I suggest it might have to do with mounted NFS shares, could that be the case for you too?

Guillaume <gyom>
Mon 05 Nov 2018 03:31:25 PM UTC, comment #26: 

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?

Kai Torben Ohlhus <siko1056>
Group Member
Mon 24 Sep 2018 10:31:12 PM UTC, comment #25: 

I'm getting native dialogs now on the default branch.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Mon 24 Sep 2018 08:12:49 PM UTC, comment #24: 

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.

Torsten Lilge <ttl>
Group Member
Sun 23 Sep 2018 07:07:01 PM UTC, comment #23: 

Sounds great!

If there would be an easy way (e.g., flatpak or deb package with the applied patch), I'd rapidly test it myself in KDE neon (on top of Ubuntu 18.04), but I guess it's tricky to build it.

avlas <kupiqu>
Sun 23 Sep 2018 06:49:00 PM UTC, comment #22: 

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?

Torsten Lilge <ttl>
Group Member
Fri 14 Sep 2018 06:26:06 PM UTC, comment #21: 

I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/cfdc768b661c
which allows native dialogs for all file dialogs. When loading a file into the editor, the user is asked whether to close the file or to continue editing when decoding errors are detected.

Next, I would like to implement the possibility to change the default encoding and reload the file as third choice for the user when decoding errors occur.

Torsten Lilge <ttl>
Group Member
Mon 10 Sep 2018 07:32:33 PM UTC, comment #20: 

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.

avlas <kupiqu>
Mon 10 Sep 2018 07:24:19 PM UTC, comment #19: 

I think, I like the second option.

Other IDEs I know provide encoding selections in the open/save dialog. But these IDEs are only editing the files and do not interprete them like we do with octave.

Torsten Lilge <ttl>
Group Member
Mon 10 Sep 2018 06:59:06 PM UTC, comment #18: 

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?

Markus Mützel <mmuetzel>
Group administrator
Mon 10 Sep 2018 06:18:32 PM UTC, comment #17: 

Markus, you are right. Having the link between editor encoding and encodung used for running m-files it is no good idea to change encodings in the editor. Dropping the encoding selection from the file open dialog would perfectly solve one of the the problems with native dialogs. Let me summarize

  • Opening a file always uses the default encoding
  • Saving a file always uses the default encoding
  • Open questions
    • How can a user open a file with another encoding?
    • Should we allow changing the encoding of a single file?






Torsten Lilge <ttl>
Group Member
Mon 10 Sep 2018 10:23:58 AM UTC, comment #16: 

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...

Markus Mützel <mmuetzel>
Group administrator
Mon 10 Sep 2018 07:16:36 AM UTC, comment #15: 


> 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.


Sounds great. I think that would be the best of the alternatives

avlas <kupiqu>
Mon 10 Sep 2018 04:58:31 AM UTC, comment #14: 

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.

Torsten Lilge <ttl>
Group Member
Sun 09 Sep 2018 06:44:31 PM UTC, comment #13: 


> 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.


- I guess this issue happens mostly when the user starts using a file coming from elsewhere, and most likely the user does not even know what encoding the file is in. If that is the case, the user may try and error in the non-native open dialog until gets lucky (or gives it up out of frustration), or can use the terminal to identify the encoding (e.g., chardet in Linux) and modify it (e.g., iconv in Linux) to the desired default.

- I wonder if this issue could be partly workarounded (to the first order approximation) with a fallback encoding? For instance, in KDE I use the Kate editor, which allows to configure the default encoding and a fallback encoding (in my system, Universal and ISO 8859, respectively). I think this could be a good compromise for most of the cases, assuming that the user does not play with >2 file encodings very regularly.


avlas <kupiqu>
Sun 09 Sep 2018 04:50:37 PM UTC, comment #12: 

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.

Torsten Lilge <ttl>
Group Member
Sun 09 Sep 2018 10:44:22 AM UTC, comment #11: 

Hi Torsten, do you think we could have an option for this?

Many may think differently, but I (and I guess others) prefer the look-and-feel, navegability and consistency of native dialogs than having the possibility to configure line endings and text encoding options at saving (which can be done in the editor anyways).

avlas <kupiqu>
Sun 09 Sep 2018 06:40:21 AM UTC, comment #10: 

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.

Torsten Lilge <ttl>
Group Member
Sat 08 Sep 2018 07:00:18 PM UTC, comment #9: 

Thanks @Torsten for the patch.
 
Look and feel being theme specific is a feature in my opinion, so the application doesn't look different from others, in particular Qt others.

I don't know about the particular env variable though. I don't see it in my env, but I assume that if not present, look and feel defaults to the system theme.
 
I'm willing to test this out. @Mike, could we build a flatpak package out of it?

avlas <kupiqu>
Sat 08 Sep 2018 06:46:17 PM UTC, comment #8: 

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.

Torsten Lilge <ttl>
Group Member
Sun 02 Sep 2018 02:20:01 PM UTC, comment #7: 

@Torsten: I tried to use 'hg backout' to reverse the original changeset but too much has changed and I found I couldn't figure out which bits of code to keep during the 3-way merge.  I think the original changeset will have to be reversed manually.

Rik <rik5>
Group administrator
Sat 01 Sep 2018 01:51:55 PM UTC, comment #6: 

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.

avlas <kupiqu>
Sat 01 Sep 2018 01:48:15 PM UTC, comment #5: 

I will provide a patch and can also do some testing in my KUbuntu-VM. However, it would be better to have more test cases.

Torsten Lilge <ttl>
Group Member
Sat 01 Sep 2018 11:32:22 AM UTC, comment #4: 


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.

avlas <kupiqu>
Fri 31 Aug 2018 11:01:57 PM UTC, comment #3: 

Assuming this does work, I would rather we not put a hard requirement on Qt 5.5 at all.

We could certainly document that Octave works best when used with the latest versions of Qt. If we do something like that, we might as well recommend the current LTS Qt 5.9 or later.

If this does work, and we do make the change to go back to native file dialogs, and a particular user builds Octave with Qt 4.8 or Qt 5.2, the build will succeed and almost everything will work perfectly correctly. Only if they are running the GUI in a KDE desktop environment, will there be any issue with the open file dialog box hanging the program.

Mike Miller <mtmiller>
Group Member
Fri 31 Aug 2018 10:12:40 PM UTC, comment #2: 

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?

Rik <rik5>
Group administrator
Fri 31 Aug 2018 09:31:00 PM UTC, comment #1: 

Testing whether this is safe should be easy for anyone who can compile Octave and run it on a modern KDE Plasma 5 desktop.

It does look to me like Qt 5 no longer installs its own signal handler for SIGCHLD in the QProcess implementation, so this may indeed be safe now for Qt 5.

Actually Qt 5.5 or newer, since that was the first released version with the overhauled the QProcess implementation in this commit: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=1814142b7a11

Mike Miller <mtmiller>
Group Member
Fri 31 Aug 2018 05:46:41 PM UTC, original submission:  


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).

avlas <kupiqu>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Carbon-Copy List
  • -email is unavailable- added by alepplew (Posted a comment)
  • -email is unavailable- added by stefanbruens (Posted a comment)
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by siko1056
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by kupiqu (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 24 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-03 mmuetzel Dependencies- bugs #60722 is dependent
    2020-10-20 siko1056 Dependencies- bugs #59311 is dependent
    2020-02-17 stefanbruens Attached File- Added 0001-Disable-signal-handler-thread-avoid-duplicate-signal.patch, #48434
    2020-02-14 mtmiller Severity3 - Normal 2 - Minor
        SummaryNative (KDE) open/save dialogs are not used Native open/save file dialogs have poor performance in KDE
    2020-02-14 siko1056 Item GroupFeature Request Performance
        StatusFixed Need Info
        Open/ClosedClosed Open
    2019-04-16 siko1056 Dependencies- bugs #56116 is dependent
    2018-11-17 siko1056 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-11-15 siko1056 StatusPatch Submitted Ready For Test
    2018-11-15 siko1056 Attached File- Added bug54607_QFileDlgs_native.patch, #45439
    2018-11-15 siko1056 Attached File- Added bug54607_configure_native_dlgs.patch, #45431
    2018-11-05 siko1056 StatusFixed Patch Submitted
        Open/ClosedClosed Open
        Release4.4.1 dev
        Carbon-Copy- Added -email is unavailable-
    2018-09-24 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2018-09-10 mtmiller Carbon-CopyRemoved 80942 -
    2018-09-06 rik5 Item GroupNone Feature Request
        StatusNone In Progress
        Assigned toNone ttl

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code