bugGNU Octave - Bugs: bug #54607, Native (KDE) open/save dialogs are...

 
 

bug #54607: Native (KDE) open/save dialogs are not used

Submitted by:  avlas <kupiqu>
Submitted on:  Fri 31 Aug 2018 05:46:41 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  Torsten <ttl>
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 17 Nov 2018 09:46:52 AM UTC, comment #50:

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

Kai Torben Ohlhus <siko1056>
Project 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 <ttl>
Project MemberIn charge of this item.
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>
Project 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>
Project 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 <ttl>
Project MemberIn charge of this item.
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>
Project 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>
Project 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 <ttl>
Project MemberIn charge of this item.
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
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>
Project 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 <ttl>
Project MemberIn charge of this item.
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>
Project Administrator
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>
Project Administrator
Wed 14 Nov 2018 03:55:26 PM UTC, comment #36:

Have you tried removing all of Octave's Qt settings

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>
Project 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>
Project 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>
Project 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 <ttl>
Project MemberIn charge of this item.
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>
Project 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.

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

Rik <rik5>
Project 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>
Project 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>
Project 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>
Project 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 <ttl>
Project MemberIn charge of this item.
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 <ttl>
Project MemberIn charge of this item.
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 <ttl>
Project MemberIn charge of this item.
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 <ttl>
Project MemberIn charge of this item.
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>
Project Member
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 <ttl>
Project MemberIn charge of this item.
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>
Project Member
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 <ttl>
Project MemberIn charge of this item.
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 <ttl>
Project MemberIn charge of this item.
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 <ttl>
Project MemberIn charge of this item.
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 <ttl>
Project MemberIn charge of this item.
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>
Project 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 <ttl>
Project MemberIn charge of this item.
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>
Project Administrator
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>
Project 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>
Project Administrator
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:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.3