bugGNU Octave - Bugs: bug #59426, Horizontal widget positions not...

 
 

bug #59426: Horizontal widget positions not persistent with Qt5.15

Submitter:  Lars Kindermann <larskindermann>
Submitted:  Sat 07 Nov 2020 08:46:59 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  ttl
Originator Name:  Open/Closed:  * Closed
Release:  * 6.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 20 Mar 2021 10:31:33 AM UTC, comment #60: 

I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/6448a10a642a to stable.

Closing this report. We can reopen it whenever problems with restoring the layout are showing up.

Torsten Lilge <ttl>
Group Member
Fri 19 Mar 2021 04:13:56 PM UTC, comment #59: 

Very good news, thanks for testing. I will test with a pre-5.15 of Qt and push the patch to stable in case there will be another stable release before 7.1.0.

Torsten Lilge <ttl>
Group Member
Fri 19 Mar 2021 01:27:09 PM UTC, comment #58: 

Works also on Windows (w. qt 5.15.2) w. dev Octave, as expected.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 17 Mar 2021 07:10:07 PM UTC, comment #57: 

The patch works on Debian 11, too.

Lars Kindermann <larskindermann>
Wed 17 Mar 2021 06:34:57 PM UTC, comment #56: 

Sorry, Philip, just saw your posts right now. The patch cleanly applies to the default branch.

Torsten Lilge <ttl>
Group Member
Wed 17 Mar 2021 05:53:12 PM UTC, comment #55: 

Never mind, I just tried the patch with dev Octave on Linux (Mageia-8 w. Qt 5.15.2), and the patch works - that is, for my favorite window pane layout.

Later on (maybe weekend) I'll try with Windows but I have no reason to expect it'll work differently there.

So, good work, Torsten!

Philip Nienhuis <philipnienhuis>
Group Member
Wed 17 Mar 2021 08:15:14 AM UTC, comment #54: 

Is it exclusively meant for stable? or could it work on dev Octave as well?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 16 Mar 2021 09:36:42 PM UTC, comment #53: 

Please find attached a patch for the stable branch that fixes the issue for me on Debian, Qt 5.15. The approach is to reset the window layout to its default position and then restore the previous state and geometry. I can fully explain why this is more robust, but the default layout was always reliably restored after restart and only certain changes in the layout triggered the issue.


(file #51080)

Torsten Lilge <ttl>
Group Member
Sun 14 Mar 2021 01:14:47 PM UTC, comment #52: 

6.2.0 just made it into the Debian 11 repository. As Qt libs there are 15.5, the problem now is "mainstream". Just testet on a vanilla debian 11 install.

Lars Kindermann <larskindermann>
Sun 14 Mar 2021 09:38:58 AM UTC, comment #51: 

After testing again on my Debian system I can confirm that restoring correct horizontal widget positions works well with Qt5.13 but fails with Qt5.15.

With the latter, I have made the following observation: After resetting the window layout to the default one, you can change the position of the left console widget border or other borders and those will be correctly restored at next start. But certain actions seem to trigger the issue, like, e.g. tabbing two of the widget on the left.

Torsten Lilge <ttl>
Group Member
Sun 14 Mar 2021 09:16:22 AM UTC, comment #50: 

@Philip: I'm not sure you did anything wrong this time. It might be more likely that building from a tree with mixed Qt versions "incidentally" worked for you in prior tests. (Maybe dependent on the order in which you compiled and installed the different versions.)
All that this probably means is that we should take the results of your prior tests with a grain of salt because we can't be sure which parts of Qt were picked up from which version during compilation.

Markus Mützel <mmuetzel>
Group administrator
Sat 13 Mar 2021 06:22:11 PM UTC, comment #49: 

[OT]
It's mostly important for me as I don't have up-to-date fast HW, crossbuilding take quite some time and once booted in linux, working from home on my company's network while building Octave is suboptimal - I need to keep that time minimized. Also I don't mind experimenting a bit - some distraction from working from home is quite welcome in these covid-19 times :-)

As I wrote I find the current dependency system in mxe-octave quite robust. I've backed out to earlier Qt versions before w/o a 'make uninstall' and then it did work for several weeks - last time I must have forgotten some step, or -equally well possible- borked it in some other, unrelated way.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 13 Mar 2021 05:54:24 PM UTC, comment #48: 

Philip wrote:

"So I was thinking more about say, having a package-to-be-uninstalled extracted by mxe-octave, maybe have it patched if patch files exist, and then in the tmp-<package> subdir run 'make uninstall', followed by deleting the installed-packages/ entry. Something along those lines."

I don't think we can count on packages to have working "make uninstall" targets.  But we could try to keep a list of files installed for each package and add a step to remove them before building and installing the package again.  We could also keep the actual installed files in a separate archive so they could be quickly reinstalled after a "make clean" if there have been no changes in the package or its dependencies.  But that starts to look like a package management system...

John W. Eaton <jwe>
Group administrator
Sat 13 Mar 2021 04:55:30 PM UTC, comment #47: 

Works OK with Qt back to 5.14.2.

Yesterday I upgraded one of my Linux boxes to Mageia 8, which includes Qt 5.15.2, and guess what: now the problem exists there :-(

[OT]
No discussion about mxe-octave's intended purpose. But as it stands it's remarkably flexible. In the past I have fiddled quite a bit with mxe-octave, it has many unexpected "potentials".

In my perception package managers work primarily for compiled/prebuilt packages, a situation where dependencies are vital and fairly fragile. mxe-octave however works with source packages, implying dependencies should be resolved more easily & the build process is more robust.
The dependencies in the various .mk files seem to be reasonably complete, AFAICS 'make <target>' picks up changed packages and dependencies as it should. E.g., just delete a basic building block entry in installed-packages/, type 'make zipdist' and watch the dependency build circus unfold.

So I was thinking more about say, having a package-to-be-uninstalled extracted by mxe-octave, maybe have it patched if patch files exist, and then in the tmp-<package> subdir run 'make uninstall', followed by deleting the installed-packages/ entry. Something along those lines.
Undoubtedly there'll be snags to be sorted out; no reason to not try to get it working.
BTW, thinking of it, a step I mentioned above (deleting the pertinent installed-packages/ entries) might be exactly what I forgot last time. But I'm unsure if that was the fatal blow.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 13 Mar 2021 10:31:43 AM UTC, comment #46: 

Back on topic: Is the widget position restored correctly with your latest build?

Markus Mützel <mmuetzel>
Group administrator
Fri 12 Mar 2021 12:32:12 PM UTC, comment #45: 

OT: IIUC, MXE Octave was never thought to manage different versions of the same package. It's designed to easily allow (cross-)building of a set of packages without depending too much on any tools or dependencies installed on the build system. And does a good job at that task.
It doesn't have a package manager. So once a package was built and installed there is no (standard) way of uninstalling that package. It doesn't include any rules for the various upgrade and downgrade scenarios (and I'd say that would be out of scope for such a project).
Some version changes might work "accidentally" (because all files from the installation of the previous version are overwritten). But there's no guarantee for that.
Adding a package manager to MXE Octave would be a huge undertaking (speaking of time and energy). That would basically require a re-design of how MXE Octave is working at the moment.

Markus Mützel <mmuetzel>
Group administrator
Fri 12 Mar 2021 11:35:04 AM UTC, comment #44: 

@Markus:
you were right, after make clean (that I typed too quickly) an overnight build produced an mxe-octave build w/o errors. So that issue of comment #39 has been solved.
<rant>
I could as well have started a completely new mxe-octave, everything got built again. There must be a more elegant way to change versions of dependencies w/o rebuilding the lot. I simply don't have fast HW, and apart from that I find it a waste of time, energy and e.g., CO2 emissions for rebuilding things (non-dependers on Qt) that need not be rebuilt in the first place.
</rant>

That build now yields 3 new FAILs: a FAIL/REGRESSION in pathdef.m, FAIL in help.cc-tst and FAIL in bug38691.cc-tst.
Plus the spreadsheet tests (spsh_test.m) in the io package now fail for the oct interface.
I'll look into those later.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 11 Mar 2021 07:13:52 PM UTC, comment #43: 

'make clean' isn't a handy solution for this use case is it.
It wipes all built files, including configure. A bit overdone if all you want to do is clean up just one library + dependers - and make should take care of the latter.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 11 Mar 2021 04:03:55 PM UTC, comment #42: 

It looks like you are building in a tree where some parts of Qt5.15 have been replaced by Qt5.14. That is bound to cause problems.
Did you run `make clean` after you backed out these changesets?

Markus Mützel <mmuetzel>
Group administrator
Thu 11 Mar 2021 03:47:11 PM UTC, comment #41: 


/home/philip/devel/octdev/mxe/mxe_64w_20210309D/tmp-default-octave/octave-7.0.0/libgui/src/documentation.cc: In constructor 'octave::documentation::documentation(QWidget*, octave::base_qobject&)':
/home/philip/devel/octdev/mxe/mxe_64w_20210309D/tmp-default-octave/octave-7.0.0/libgui/src/documentation.cc:241:37: error: 'documentActivated' is not a member of 'QHelpIndexWidget'
  241 |                  &QHelpIndexWidget::documentActivated,
      |                                     ^~~~~~~~~~~~~~~~~
make[4]: *** [Makefile:18210: libgui/src/libgui_src_la-documentation.lo] Error 1
make[4]: *** Waiting for unfinished jobs....


I had a correct mxe-octave build tree and then backed out two csets for Qt updates:
15.15.0->5.15.0 (5589 (38be0ef93ce3) Update qt5 to v5.15.2 …)
-and-
5.14.2->5.15.0 (5586 (19a6cd0f2f60) Restore Qt 5.15 for development)

Did I forget one somewhere?
Earlier on I reverted to 5.14.2 using another cset but that didn't apply anymore.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 10 Mar 2021 09:20:27 PM UTC, comment #40: 

Philip, which build errors are exactly showing up with Qt 5.14.2? The bookmark feature should not require Qt 5.15. I can build dev octave with Q 5.13 without problems.

Torsten Lilge <ttl>
Group Member
Wed 10 Mar 2021 08:47:51 PM UTC, comment #39: 

Motivated by issues with bug #55727 I had to start a fresh mxe-octave build tree and now the problem of this bug report is back with dev octave.

:-(

But the "old" mxe-otave tree was on Qt 5.14.2, the new one still on Qt 5.15.2. I backed out the pertinent Qt-base updates but then I got build errors related to cset http://hg.savannah.gnu.org/hgweb/octave/rev/b92614cfdfed (bug #54938 - bookmarks in documentation; apparently some Qt library is needed that isn't in 5.14.2 or so).

The released 6.2.0 (from ftp.gnu.org) works fine w.r.t. the issue here.
It surely is an interesting bug ...

Philip Nienhuis <philipnienhuis>
Group Member
Tue 09 Mar 2021 11:12:59 PM UTC, comment #38: 

@Philip: You said the problem was resolved on dev, but valid on 6.1.1.  Is it still valid on the stable branch (6.2.X)?

Rik <rik5>
Group administrator
Sat 20 Feb 2021 11:56:19 PM UTC, comment #37: 

For me, after a big number of updates for dev octave and mxe-octave, this problem seems solved for dev octave.
It might be that there was also a mix-up on my side, the new build I reported about in comment #28 may still have been one with Qt-5.15 rather than Qt-5.14. I can't reconstruct it now, the relevant files/shortcuts have been overwritten.

However, for 6.1.1. it is still valid.

As 7.0.0 now keeps its layout between sessions, but starting 7.0.0 after exiting 6.1.1 gives a shifted right border, I suspect in 6.1.1 the layout info in the octave-gui.ini file is somehow misread or misinterpreted.
I suppose it saves its layout properly, but the fact that after each restart the right command pane border moves ever more to the right (not just the first two times as I wrote in comment #23) seems to support this guess.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Feb 2021 09:35:57 PM UTC, comment #36: 

Looks like a similar problem had been reported a long time ago as a QT Bug:

QTBUG-25954: Central widgets gets centered after restoring QMainWindow state and geometry

https://bugreports.qt.io/browse/QTBUG-25954

Any relation to the current problem?

Lars Kindermann <larskindermann>
Sun 14 Feb 2021 07:01:39 PM UTC, comment #35: 

For me it does not depend on tabs, any two widgets, one left one right will not remember the horizontal position of the division. If the whole window is big, nealy covering the whole screen, the partition is in the middle, when small, it appears more to the left.

Lars Kindermann <larskindermann>
Sun 14 Feb 2021 02:59:41 PM UTC, comment #34: 

In my case, yes: Command pane & Documentation pane.

I tried with doc pane not visible => no difference.
Same with doc pane undocked => no difference.
So at least with tabbed panes in the center column this seems a dead end.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 13 Feb 2021 09:23:17 PM UTC, comment #33: 

Maybe, I found something. In the cases where the horizontal widget is not preserved, are there tabbed widget involved?

Torsten Lilge <ttl>
Group Member
Sat 13 Feb 2021 08:28:15 PM UTC, comment #32: 

The behavior strongly depends on the window layout. In certain layouts, I can now reproduce the bug with Qt 5.15, too. Specifically, I can reliably reproduce the issue when I have three widgets tabbed left and the command widget is located right. In this configuration, Octave always starts with the border between the widgets in the middle of the main window.

Torsten Lilge <ttl>
Group Member
Wed 10 Feb 2021 09:33:02 PM UTC, comment #31: 

I see no change to the behaviour initially reported in this bug, the horizontal position of the widget division is still not restored (in Debian testing).

Both stable and dev are affected, along with the version currently in the Debian bullseye repository. (version 6.1.1~hg.2021.01.26)

Lars Kindermann <larskindermann>
Wed 10 Feb 2021 07:27:18 PM UTC, comment #30: 

Yeah I can add that I see this only on Windows.
On Linux it works fine - but Qt may be a bit older there (Mageia-7.1).

Philip Nienhuis <philipnienhuis>
Group Member
Wed 10 Feb 2021 09:50:59 AM UTC, comment #29: 

Agree to the both of you Torsten and Philip 😉

On my Linux daily use system (comment #17) the bug is still fixed for Octave 6.2.0.  On a plain test MS Windows system the nightly octave-2021-02-05-00-31-w64-installer.exe installed and after purging the config locations (comment #28) the old small "drag move to rearrange the horizontal widget positions" is still necessary, the positions are not remembered.  I don't know what makes qt "forgetting" it 😓

Kai Torben Ohlhus <siko1056>
Group Member
Wed 10 Feb 2021 08:40:13 AM UTC, comment #28: 

I tried restarting 6.1.1 four times in a row = no luck.
Right command window border has still moved to the right after each restart (each restart a little less if I don't move the border back)

Renamed octave-gui.ini I %APPDATA%\Local\Roaming\Octave & re-made my favorite UI layout ==> no luck.
(BTW I see no different subdirs for each release differences like there is in %USERPROFILE%\.config)

Started a new mxe-octave build tree with Qt-5.14.2 to build 7.0.0, (didn't install it but ran it from the dist/octave..../ subdir on my Linux drive) ==> again no luck.

Of course it can be due to local circumstances but I wouldn't know how to pinpoint the relevant ones down.
Maybe caused by command windows in the center column of a three pane columns layout? (see comment #14)?

If you think that it's probably due to my local setup and it's otherwise sufficiently fixed it's all-right with me.
Kai's comment #17 seems to indicate he's seen it a lot longer than I did with more Octave versions; we didn't see many other complaints apart from Lars % Dmitri so it doesn't seem to be a widely occurring issue.
It still feels a bit itchy.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 09 Feb 2021 09:27:54 PM UTC, comment #27: 

There might be interference between 5.x and 6.x but after the second start of the same version this should have converged to a "steady state".

Torsten Lilge <ttl>
Group Member
Tue 09 Feb 2021 12:51:47 PM UTC, comment #26: 

With a 6.1.1 nightly (octave-6.1.1_2021-02-05-00-40-w64-64.7z) I see the same issue, both at home & at work.
I have several other Octave installations (5.2.0, 6.1.0, two 7.0.0), could those interfere through the settings file(s)?

I had no chance yet to crossbuild with Qt 5.14; hopefully tonight.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 08 Feb 2021 09:11:09 PM UTC, comment #25: 

My issues are in Octave-7.0.0. I don't use 6.1, but I can try a nightly if you wish to check if that behaves better.

Sure I can try with downgrading Qt to 5.14 (essentially starting a new mxe-octave build tree).
I suppose my issues don't block a new Octave-6.x release. I just posted here as the issue also affects dev Octave.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 08 Feb 2021 09:38:59 AM UTC, comment #24: 

Can we consider this as fixed "well enough" for shipping Octave 6.2 with Qt 5.15?
Or do the remaining issues require a downgrade to Qt 5.14 again?

@Philip: Does the issue you are seeing disappear if you downgrade Qt to 5.14 in MXE Octave?

Markus Mützel <mmuetzel>
Group administrator
Tue 05 Jan 2021 10:13:29 PM UTC, comment #23: 

What I also see is that after resetting the terminal width to my liking, upon the first two restarts of Octave the right terminal border moves more to the right each time.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 10 Dec 2020 10:08:58 AM UTC, comment #22: 

FTR, just to be sure I rebuilt dev Octave without the Property Inspector patch #9953, wiped all GUI settings, but the issue here remains.

It almost seems as it's just the right terminal pane border that has issues. Upon restarting Octave I only need to move that border back into place and then the layout look like it was before exiting Octave.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Dec 2020 07:41:36 PM UTC, comment #21: 

@Torsten, thanks for your patience.

By "reset" you mean throw away all GUI settings, start over and recreate my favorite layout?
I already did something similar, i.e., starting Octave anew by removing qt-settings, and the problem is still there.
(FTR I do have the latest patch from patch #9993 in my build. It's GUI behavior isn't perfect. But I'm unsure this is the culprit. An earlier build without it behaved the same.)

At issue there is that 7.0.0 also tries to read qt-settings from the "old" 6.1.0 / 5.2.0 location (%USERPROFILE%/.config/octave) if it can't find the one in %USERPROFILE%/Appdata/Roaming/octave - that is, I have to conclude so as removing qt-settings from only Appdata wasn't enough to reset Octave to a pristine condition; I also had to rename qt-settings in .config/octave/.

Anyway, do you imply that besides qt-settings also the other gui files in .config/ or Appdata/config need to be reset?

OK, I hit "Reset default Window Layout" and saw the following:

  • Moving the left terminal border to the right works and survives an Octave restart.
  • There's no easy way to move any pane inside the main window such that the number of columns of panes in the GUI (see pic comment #14) is enlarged, in any case not by shifting the Terminal pane around.
  • After I got it together to recreate the "3-column" layout shown in comment #14, the position of the right Terminal pane didn't survive a restart. See attached pic, essentially similar to the one comment #14 (but now with proper font size)": upper before restarting Octave, lower after restart.




Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Dec 2020 05:46:34 PM UTC, comment #20: 

It does not relate to a bug. For code maintenance, jwe fixed the parent widgets when creating some gui objects. The terminal uses some signal connections with the main window which where now tried to establish with the terminal dock widget instead of the main window.

When your build include the patches for this bug report, the horizontal position should be restored correctly. Could you please try to reset the layout with the related menu action?

There are several occasions where settings are written immediately to the settings file.

Torsten Lilge <ttl>
Group Member
Mon 07 Dec 2020 11:39:02 AM UTC, comment #19: 

@Torsten:
cset http://hg.savannah.gnu.org/hgweb/octave/rev/27dc4dae6826 only worked partly. Which bug does it relate to?
AFAIU this bug is precisely what I also see on Windows but only on dev Octave, not 6.1.0.

The background color & font of the terminal widget is OK now, but its position (or that of the file browser & history pane to the right of it) isn't remembered.
Intriguingly a build from Nov 22 that didn't behave (see comment #14) now behaves correctly. I'd almost conclude that the qt-settings file was clobbered.

FWIW, I monitored the appdata/.octave/qt-settings file (in Windows) and noted that also when Octave starts it gets overwritten (date/time changes).
I'd expect Octave just reads it then and only overwrites it when Octave exits. But admittedly I have no idea how the settings mechanism actually works.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Dec 2020 08:11:24 AM UTC, comment #18: 

@Torsten:
Thanks. Unfortunately that cset came just too late :-)  (my box has been building overnight). OK, I'll try again.

@Kai:
For me this problem only appeared quite recently, between Nov. 9 and Nov. 21 (on those dates I've made Windows builds).
On Linux (where I build the required dist files) I didn't see it.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Dec 2020 07:34:52 AM UTC, comment #17: 

Thanks Torsten✌️😊✌️ One of your recent changes must have fixed it for me on Linux (OpenSUSE 15.2, qt 5.12.7).

The first times in a while that I open the GUI and I don't have to drag the widgets like Philip had to do as well.  For me this was also broken in Octave 5 and I think there was a bug report about it, but I don't find it.

Kai Torben Ohlhus <siko1056>
Group Member
Sun 06 Dec 2020 08:45:31 PM UTC, comment #16: 

@Philip, I hope that the issues you are seeing are fixed with cset http://hg.savannah.gnu.org/hgweb/octave/rev/27dc4dae6826 (and mainly unrelated to this bug).

Torsten Lilge <ttl>
Group Member
Sun 06 Dec 2020 07:08:21 PM UTC, comment #15: 

In the default branch, the command window settings are currently ignored due to a change to the parent of the terminal implementation. I am working on a patch.

Torsten Lilge <ttl>
Group Member
Sun 06 Dec 2020 07:01:07 PM UTC, comment #14: 

Maybe related:

On Windows I see similar things, see attached pic of a crossbuild from Nov 9 (top) and one from Nov 22 (below):
the workspace pane is much wider; the command pane background setting (yellowish) is ignored; and the command line font is significantly smaller. Making the latter bigger helps but then the history pane font gets unreasonably large as well.

Looks like the qt-settings file was reorganized?

I've not tried the patch from comment #13 yet, I'll see if I can build tonight, or I might try a nightly tomorrow.



Philip Nienhuis <philipnienhuis>
Group Member
Sun 06 Dec 2020 01:22:13 PM UTC, comment #13: 

I have pushed cset http://hg.savannah.gnu.org/hgweb/octave/rev/5d7a651bf0bb to stable. The changeset at least  makes resetting to default layout and restoring previous layout more robust. I can not completely rule out that there are scenarios where restoring the previous layout still does not work correctly.

Torsten Lilge <ttl>
Group Member
Sat 05 Dec 2020 11:19:46 PM UTC, comment #12: 

I see the problem on fedora 33 with qt5.15.2

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 29 Nov 2020 10:57:16 PM UTC, comment #11: 

On Debian testing a minor update of qt (5.15.1-4) was just rolled out, but the problem persists.

Lars Kindermann <larskindermann>
Tue 24 Nov 2020 06:27:14 AM UTC, comment #10: 

The issue is back here, too. I am not sure what happened, maybe I mixed up my different builds (stable, default, Qt 5.13/5.15) during the tests.

Torsten Lilge <ttl>
Group Member
Mon 23 Nov 2020 06:41:44 AM UTC, comment #9: 

Xfce

Lars Kindermann <larskindermann>
Mon 23 Nov 2020 05:51:38 AM UTC, comment #8: 

Lars, which desktop environment are you using on your Debian system?

Torsten Lilge <ttl>
Group Member
Sun 22 Nov 2020 10:52:55 PM UTC, comment #7: 

The patch does not work for me. The horizontal position is still not restored.

Lars Kindermann <larskindermann>
Sun 22 Nov 2020 05:04:33 PM UTC, comment #6: 
Torsten Lilge <ttl>
Group Member
Sat 21 Nov 2020 06:29:30 PM UTC, comment #5: 

I can confirm this with a build using Qt 5.15.1 on Debian.

This effect also happens for older Qt versions, but only when octave gui is maximized. The fix for this one is quite easy but does not fix the new issue with Qt 5.15.1.

Torsten Lilge <ttl>
Group Member
Tue 10 Nov 2020 04:41:45 PM UTC, comment #4: 

Problem also appeared in Octave 5.2 which used to work fine so far. So it is probably an upstream problem.

It seems to be introduced by updating the Qt libs to 5.15.1. on Debian testing a few days ago.

Lars Kindermann <larskindermann>
Sat 07 Nov 2020 10:50:26 AM UTC, comment #3: 

Floating windows remember their positions after restart.

Lars Kindermann <larskindermann>
Sat 07 Nov 2020 10:38:02 AM UTC, comment #2: 

Can be reliably demonstrated on the standard layout after deleting all config files. Just move the vertical division to the left or right, close octave and restart: The x-positions of the docked widgets are reset to default while y-positions are correctly remembered.

Btw: I'm running Debian testing (bullseye) and there have been updates of qt libs recently.

Lars Kindermann <larskindermann>
Sat 07 Nov 2020 09:14:42 AM UTC, comment #1: 

Thanks for the report. Is there a specific window layout in order to reliably reproduce the issue? Do you mean the horizontal layout of docked widgets or the horizontal position of floating widgets?

Torsten Lilge <ttl>
Group Member
Sat 07 Nov 2020 08:46:59 AM UTC, original submission:  

The horizontal positions of the widgets in the GUI are not remembererd between sessions any more.

Clearing all config files does not help. Happens both in stable and dev.

Lars Kindermann <larskindermann>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51080:  bug59426_01.patch added by ttl (3KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by larskindermann (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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-03-20 ttl StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2021-03-16 ttl Attached File- Added bug59426_01.patch, #51080
        StatusIn Progress Patch Submitted
        Release6.1.0 6.2.0
    2021-03-14 philipnienhuis Carbon-Copy- Added philipnienhuis
    2021-03-14 mmuetzel StatusReady For Test In Progress
        Operating SystemGNU/Linux Any
        SummaryHorizontal widget positons not persistent Horizontal widget positions not persistent with Qt5.15
    2021-03-11 rik5 Carbon-CopyRemoved 72865 -
    2020-12-29 ttl Dependencies- bugs #59780 is dependent
    2020-12-07 philipnienhuis Attached File- Added bug59426_Windows_#2.png, #50421
    2020-12-06 philipnienhuis Attached File- Added bug59426_Windows.png, #50411
    2020-12-06 ttl Assigned toNone ttl
    2020-12-06 ttl Release6.0.92 6.1.0
    2020-11-22 ttl StatusConfirmed Ready For Test
    2020-11-21 ttl StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code