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:  In Progress Assigned to:  Torsten <ttl>
Originator Name:  Open/Closed:  Open
Release:  4.4.1 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)

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:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -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 4 latest changes.

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