bugGNU Octave - Bugs: bug #61172, Problems after maximize the GUI...

 
 

bug #61172: Problems after maximize the GUI with 2 monitors

Submitter:  Luiz Antonio Maccari Junior <luiz>
Submitted:  Thu 16 Sep 2021 08:31:00 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Luiz Antonio Maccari Jr. Open/Closed:  * Closed
Release:  * 7.0.90 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 14 Oct 2022 03:47:59 PM UTC, comment #58: 

Thanks for the feedback.

Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Fri 14 Oct 2022 12:27:26 PM UTC, comment #57: 

On my setup: Linux mint 20.3 with Octave 7.2.0, the problem has been corrected.

I think the bug report could be closed.

Thanks.

Luiz Antonio Maccari Junior <luiz>
Fri 14 Oct 2022 07:48:30 AM UTC, comment #56: 

Is this issue fixed?
I'm struggling to understand if "same behavior" is good, bad or neutral.

Can someone who could observe this bug before check if it still is an issue with a current build from the stable branch of Octave?

Markus Mützel <mmuetzel>
Group administrator
Fri 12 Aug 2022 08:44:49 PM UTC, comment #55: 

I have recompiled Octave, directly after the changeset mentioned in comment #53. I have not observed any regressions, the behavior on my (ubuntu linux) machine is still the same as I observed it in comment #43 and comment #32.

Hartmut <hardy>
Fri 12 Aug 2022 08:43:30 PM UTC, comment #54: 

I have recompiled Octave, directly after the changeset mentioned in comment #53. I have not observed any regressions, the behavior on my (ubuntu linux) machine is still the same as I observed it in comment #43 and comment #32.

Hartmut <hardy>
Mon 08 Aug 2022 08:01:20 PM UTC, comment #53: 

Using Qt::WindowState::WindowMaximized, the horizontal layout of the dock widgets is not preserved at startup. Using setGeometry (also in addition) leads to a frameless window. I have pushed changeset http://hg.savannah.gnu.org/hgweb/octave/rev/a44009224387 to the default branch that used setGeometry() and re-adds the title bar with the related window flag.

Reopened the bug as "Ready to test".

Torsten Lilge <ttl>
Group Member
Thu 04 Aug 2022 07:28:45 PM UTC, comment #52: 

Thanks for the hints in the code, I will make some tests. From the Qt documentation, the limitation on X11, availableGeometry() returning the total geometry, only occurs on systems with more than one monitor.

Torsten Lilge <ttl>
Group Member
Thu 04 Aug 2022 07:11:34 PM UTC, comment #51: 

To fix the issue, it can be firstly set Qt::WindowState::WindowMaximized, then compute the geometry using for example, QStyle::PM_TitleBarHeight.

The subsequent resizing of widgets will be based on total height - title bar height, and is not affected.

Just my two cents.


comment #50:

> I was trying to compile it locally but did not succeed. There are a number of dependencies but I do not have time to investigate into it.
>
> But I noticed that in `main-window.cc`, http://hg.savannah.gnu.org/hgweb/octave/file/bf6376a754a4/libgui/src/main-window.cc#l1600
>
> The `availableGeometry()` method is called to obtain screen size.
>
> On *Windows*, this method `availableGeometry().height()`, returns 1042 on a 1080p screen and 2122 on a 4k screen.
>
> On *Linux*, this returns 768 on a 1366*768 screen.
>
> Noting that gnome has the option to combine window title bar with system status bar, and it is feasible to hide system status bar, see for example (just perfection extension https://extensions.gnome.org/extension/3843/just-perfection/). This setting will probably affect available screen size.
>
> On this line, http://hg.savannah.gnu.org/hgweb/octave/file/bf6376a754a4/libgui/src/main-window.cc#l1608
>
> The height is available height - 2, leads to a `full screen` result which is borderless. `MainWindow::setWindowState(Qt::WindowState::WindowMaximized)` retains window title bar height regardless of gnome settings.
>
> To reproduce, with gnome, I believe one can hide system status bar first, then lauch octave, maximize it, then exit and reopen ovtace. The behaviour shall be expected.
>
>
> comment #49:
> > I wonder if this is a flatpak peculiarity.
> > I cannot reproduce on fedora 36 with self-compiled 7.2.X.
> >
> > Dmitri.
> > --
> >

Theodore <tlcfem>
Thu 04 Aug 2022 07:02:15 PM UTC, comment #50: 

I was trying to compile it locally but did not succeed. There are a number of dependencies but I do not have time to investigate into it.

But I noticed that in `main-window.cc`, http://hg.savannah.gnu.org/hgweb/octave/file/bf6376a754a4/libgui/src/main-window.cc#l1600

The `availableGeometry()` method is called to obtain screen size.

On *Windows*, this method `availableGeometry().height()`, returns 1042 on a 1080p screen and 2122 on a 4k screen.

On *Linux*, this returns 768 on a 1366*768 screen.

Noting that gnome has the option to combine window title bar with system status bar, and it is feasible to hide system status bar, see for example (just perfection extension https://extensions.gnome.org/extension/3843/just-perfection/). This setting will probably affect available screen size.

On this line, http://hg.savannah.gnu.org/hgweb/octave/file/bf6376a754a4/libgui/src/main-window.cc#l1608

The height is available height - 2, leads to a `full screen` result which is borderless. `MainWindow::setWindowState(Qt::WindowState::WindowMaximized)` retains window title bar height regardless of gnome settings.

To reproduce, with gnome, I believe one can hide system status bar first, then lauch octave, maximize it, then exit and reopen ovtace. The behaviour shall be expected.


comment #49:

> I wonder if this is a flatpak peculiarity.
> I cannot reproduce on fedora 36 with self-compiled 7.2.X.
>
> Dmitri.
> --
>

Theodore <tlcfem>
Thu 04 Aug 2022 01:23:58 PM UTC, comment #49: 

I wonder if this is a flatpak peculiarity.
I cannot reproduce on fedora 36 with self-compiled 7.2.X.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 04 Aug 2022 01:03:48 PM UTC, comment #48: 

Yeah I forget to mention those.

I have two laptops running fedora 36, both have single internal monitor setup, not dual-monitor. The binary is installed via flatpak. Resolutions are 1080p and 720p.

The behaviour appears to be more like `MainWindow::showFullScreen()` to me. But I presume the correct behaviour shall be `MainWindow::setWindowState(Qt::WindowState::WindowMaximized);` then `MainWindow::show();`.

Theodore <tlcfem>
Thu 04 Aug 2022 12:43:43 PM UTC, comment #47: 

I have NOT succeded to reproduce such a "borderless" Octave GUI on my 2 monitor setup under linux. (Octave 7.2.0 self compiled from official tar ball, x11, gnome 3.26.8 under Ubuntu 20.04.4 LTS).

What could be different with your setup? Could you maybe give details of your monitor setup (how many, what resolutions, what arrangements next to each other)? Is the behavior reproducible on your side?

Hartmut <hardy>
Thu 04 Aug 2022 12:30:18 PM UTC, comment #46: 

I believe this problem still exists in 7.2.0. See the attached screenshot.

Running gnome 42.3 on x11.

comment #45:

> Okay to close?  Trying to wrap up bugs with fixes ahead of 7.1 release.



Theodore <tlcfem>
Tue 22 Feb 2022 07:04:57 PM UTC, comment #45: 

Okay to close?  Trying to wrap up bugs with fixes ahead of 7.1 release.

Rik <rik5>
Group administrator
Tue 15 Feb 2022 05:59:10 AM UTC, comment #44: 

@Hartmut, thanks for testing.

Torsten Lilge <ttl>
Group Member
Mon 14 Feb 2022 10:01:19 PM UTC, comment #43: 

I have just recompiled Octave's stable branch, directly after Torsten's commit in comment #40, under (Ubuntu 20.04) linux. The behavior of maximized windows with two monitor setups, as well as the horizontal separation inside the window itself, look fine to me.

I observe the very same behavior as reported in comment #32, nothing unexpected. I still perceive this as a very useful improvement over the original behavior.

Hartmut <hardy>
Mon 14 Feb 2022 09:10:35 PM UTC, comment #42: 

@Luiz Antonio, if you are not building Octave yourself, you would have to wait until the next release candidate. My previous post was rather directed to @Hartmut.

Torsten Lilge <ttl>
Group Member
Mon 14 Feb 2022 08:48:35 PM UTC, comment #41: 

How can I do the test? Could you give me the instructions?

Luiz Antonio Maccari Junior <luiz>
Mon 14 Feb 2022 07:27:56 PM UTC, comment #40: 

I recently have seen the issue on windows, which is fixed by changeset http://hg.savannah.gnu.org/hgweb/octave/rev/60e31b2666d2 now. I would appreciate if you could test the new version on linux, too, just to avoid regressions.

Torsten Lilge <ttl>
Group Member
Fri 14 Jan 2022 06:44:56 AM UTC, comment #39: 

I have pushed the second patch as cset http://hg.savannah.gnu.org/hgweb/octave/rev/6ad5bb8f6a6d

Torsten Lilge <ttl>
Group Member
Tue 11 Jan 2022 10:03:02 PM UTC, comment #38: 

I myself, as a two-monitor user, would prefer to have the GUI always start on the first screen (if closed with maximized windows last time), and not have it start in this weired full screen mode any more. This gives me at least the possibility to move the GUI window around to another position.

Hartmut <hardy>
Tue 11 Jan 2022 09:19:17 PM UTC, comment #37: 

This issue does not have a simple "last minute" solution (at least, I am not able to find one). Maybe we have to decide whether starting always on the primary screen or starting in a weird full screen mode is the less annoying isuse.

Torsten Lilge <ttl>
Group Member
Sun 09 Jan 2022 10:02:27 PM UTC, comment #36: 

@Torsten: I've freshly recompiled the official 7.0.90 sources on my Ubuntu laptop with 2 monitors. This is what I see:

  • start the Octave window on monitor 1, maximize the window, close Octave, restart Octave -> frameless fullscreen Octave GUI on monitor 1.
  • start Octave  window on monitor 2, maximize the windows, close  Octave, restart Octave -> frameless fullscreen Octave GUI on monitor 2.

Conclusion: Yes, the akward behavior from my comment #32 (fullscreen window moving from monitor 2 to 1 after Octave restart) seems really to be introduced by your patch in comment #31.

Hartmut <hardy>
Sun 09 Jan 2022 08:45:34 PM UTC, comment #35: 

@Hartmut, was this behavior different before the patch, i.e., octave restarted on monitor 2 when it was closed on monitor 2?

Torsten Lilge <ttl>
Group Member
Sun 09 Jan 2022 08:41:43 PM UTC, comment #34: 

As far as the patch from comment #31 goes on my local 3-column main GUI window setup on Windows:

  • On my Windows 10 box with 2 monitors I see no regression w.r.t. bug #59426. The vertical borders between panes remain in position.


  • The horizontal borders between vertically stacked panes in left- and right pane columns creep up a few pixels upon every restart of Octave. But this is actually better than it was: before the patch, these borders would always reset to some "preset" position much higher up.


Philip Nienhuis <philipnienhuis>
Group Member
Sun 09 Jan 2022 07:40:39 PM UTC, comment #33: 

@Hartmut, thanks for testing. I have a vague idea what might happen when octave should be restored on monitor 2 but actually is on monitor 1. I will test this during the next couple of days.

Torsten Lilge <ttl>
Group Member
Sun 09 Jan 2022 07:19:18 PM UTC, comment #32: 

I have tested Torsten's second patch (from comment #31) on my Ubuntu laptop with Octave 7.0.90. It looks good in many aspects:

  • one monitor, fullscreen GUI -> is restored OK
  • one monitor, horizontal layout -> is restored OK
  • two monitors, horizontal layout -> is restored OK.
  • two monitors, fullscreen GUI on monitor 1 -> is restored OK, i.e. I do not recognize the 1 pixel difference with my eyes.


but there is another problem now:

  • two monitors, fullscreen GUI on monitor 2 -> is also restored in an OK layout, but on monitor 1 instead of monitor 2.



Hartmut <hardy>
Sun 09 Jan 2022 01:44:41 PM UTC, comment #31: 

Please find attached a patch that solves this issue and reduces the regression of bug #59426 to a minimum (at least on my system).

On X11 systems with two monitors, the reported available screen geometry is equal to the total geometry leading to some weird full screen mode of octave. Reducing this total geometry by some pixels is enough to prevent this effect and reduces the change in the horizontal layout (bug #59426) at restart to a few or even no pixels.


(file #52633)

Torsten Lilge <ttl>
Group Member
Sun 09 Jan 2022 12:12:43 PM UTC, comment #30: 


> We could check whether there is more than one screen and omit the extra setGeometry if this is the case.


Wouldn't that cause a regression of bug #59426 on systems with multiple monitors?

I guess in that case, we'd need to decide which of those bugs is the more important one to resolve. Unless, there is a solution that'd work in both use cases...

Markus Mützel <mmuetzel>
Group administrator
Sat 08 Jan 2022 09:17:22 PM UTC, comment #29: 

I see now, that the horizontal slider isn't going back into the middle after a restart, but moves towards the middle, which is also annoying.

In the documentation of QScreen::availableGeometry (which can be used to replace the obsolete QDesktopWidget) I found the following:

> Note, on X11 this will return the true available geometry only on systems with one monitor and if window manager has set _NET_WORKAREA atom.


We could check whether there is more than one screen and omit the extra setGeometry if this is the case.

Torsten Lilge <ttl>
Group Member
Sat 08 Jan 2022 07:39:55 PM UTC, comment #28: 

I have taken Torsten's patch (from comment #27) and recompiled Octave 7.0.90 on my Ubuntu laptop. And on my two-monitor setup his patch also solves this issue for me.

But: The horizontal layout (I just moved the central separator some way to the left side) is properly conserved, when closing and re-opening the Octave GUI in a non-maximized window configuration. But when having the Octave GUI in a maximized window, then this horizontol layout is reset to default (i.e. the separator in the middle) after a restart of the  GUI.

This seems to be a (small) regression introduced by this patch. (Does this  "showMaximized" command maybe ignore the horizontal layout? Pressing the maximize button of the window decoration also ignores my horizontal layout, so this might be the expected behavior of "showMaximized".) I personally would still consider the new behavior (with Torsten's patch) better than before, for my two-monitor setup. But other people (with one  monitor and a fancy horizontal window layout) will most probably see this different.

Hartmut <hardy>
Sat 08 Jan 2022 07:11:10 PM UTC, comment #27: 

Using showMaximized () instead of setGeometry (), the horizontal layout is correctly resotored when starting maximized. Could someone with a second monitor please test if this still fixes the issue of this bug report? The patch file is attached.

(file #52631)

Torsten Lilge <ttl>
Group Member
Sat 08 Jan 2022 06:44:22 PM UTC, comment #26: 

@Markus: Good point. Actually, the horizontal layout isn't preserved with John's patch when octave starts maximized.

Torsten Lilge <ttl>
Group Member
Sat 08 Jan 2022 05:12:05 PM UTC, comment #25: 

Instead of setting the geometry, should we be calling showMaximized for the main window?

Hmm, the Qt docs for that function say

On X11, this function may not work properly with certain window managers. See the Window Geometry documentation for an explanation.

https://doc.qt.io/qt-5/qwidget.html#showMaximized

https://doc.qt.io/qt-5/application-windows.html#x11-peculiarities

John W. Eaton <jwe>
Group administrator
Sat 08 Jan 2022 04:56:40 PM UTC, comment #24: 

It looks like that code snippet was added as part of the changes for bug #59426 (issues with horizontal widget layout?).

Does that still work correctly on affected systems after jwe's patch is applied?

I haven't seen this before on any of my systems. But it might be nice to have this fixed for Octave 7 if the fix is as simple as it currently looks.

Markus Mützel <mmuetzel>
Group administrator
Sat 08 Jan 2022 04:34:19 PM UTC, comment #23: 

@John, your patch looks reasonable. setGeometry() sets the geometry excluding the frame decoration. This might be the reason why the latter was outside the screen. Still, this does not explain why the window manager does not handle the window correctly and why this only happens on a multi-screen setup. Since the removed setGeometry() looks redundant to restoring state and geometry of the main window, I vote for applying the patch.

Regarding the obsolete QApplication::desktop(): After some internet research, it seems that QGuiApplication::screens and primaryScreen is a replacement for it (https://doc.qt.io/qt-5/qguiapplication.html).


Torsten Lilge <ttl>
Group Member
Sat 08 Jan 2022 03:01:54 PM UTC, comment #22: 

I have applied John's patch from comment #21 to my Octave 7.0.90 sources and recompiled. And then this issue appears to be fixed on my Ubuntu laptop with the attached second monitor.

Hartmut <hardy>
Sat 08 Jan 2022 02:38:47 PM UTC, comment #21: 

The attached change appears to fix the problem for me.

I also note that the object returned by QApplication::desktop has been marked obsolete in current versions of Qt.  I'm not sure when that change was made so maybe we can't eliminate all uses yet but if possible, it seems we should try to transition away from using it.  However, I don't know what is supposed to replace its functionality.  The documentation says its use is strongly discouraged but doesn't point to any replacement or provide other hints about what to instead of asking QDesktopWidget for things like the geometry or screen number (things we do in the remaining 9 uses in the Octave sources).

(file #52628)

John W. Eaton <jwe>
Group administrator
Sat 08 Jan 2022 01:24:00 PM UTC, comment #20: 

I also see the problem with the following sequence of events:

  • start Octave in a two monitor configuration
  • maximize Octave's main window
  • exit Octave
  • start Octave -> no title bar
  • exit Octave
  • disconnect second monitor
  • start Octave -> main window is maximized with no title bar (?!?)


OR (fewer steps)

  • start Octave in two monitor configuration
  • maximize Octave's main window
  • exit Octave
  • disconnect second monitor
  • start Octave -> main window is maximized with no title bar (?!?)


I will also note that when Octave is in this state, the keyboard shortcuts to maximize and restore a window do not work (for me, these are the windows key + up/down arrows).  They do work when Octave is not in this strange state.  So it's as if Octave is not even properly managed by the window manager when it starts in this state.  Hmm.

John W. Eaton <jwe>
Group administrator
Sat 08 Jan 2022 11:57:35 AM UTC, comment #19: 

OK, I connected a second monitor to a laptop in a dual monitor arrangement.  If I maximize Octave and then exit then start it again, the title bar is off the screen.  The laptop also has the same up to date Debian testing version installed and is using Wayland.

If I close Octave and remove the geometry line from the [MainWindow] section of my ~/.config/octave/octave-gui.ini file, then when I restart Octave, the window is not maximized but has the default size and I am able to use the title bar.  Are we storing incorrect info in the geometry setting when Octave exits or is the geometry setting correct and Qt is doing the wrong thing with it when Octave starts in a dual monitor environment?

John W. Eaton <jwe>
Group administrator
Fri 07 Jan 2022 10:15:13 PM UTC, comment #18: 

@Torsten: This was a very good hint. Normally I work with two monitors on this laptop, the built-in monitor plus an additional external monitor. When using this tww-monitor setup I do always observe this bug. But after your question, I now tried to reproduce this bug with the external monitor disconnected. Result: The bug is gone, once I switch to a single (built-in) monitor setup. Wow. But immediatelly after re-connecting my external monitor, and re-starting the Octave GUI, the window decorations around the maximized Octave GUI are gone again, this bug quickly returns.

To your original question: When staying with the two-monitor setup, it behaves like this:

  • (A = on internal monitor, the one where the Octave GUI moves to, after executing the Octave GUI menu entry "reset windows layout to default") Start Octave GUI, move it to monitor A. (Have the window NOT maximized.) Close Octave GUI. Start Octave GUI again (it now automatically opens on monitor A, as excpected). Maximize Octave GUI. Close Octave GUI. Start Octave GUI again. It still opens on monitor A. But the window decorations have disappeard, i.e. the buggy behavior happens.
  • (B = on external monitor) Start Octave GUI, move it to monitor B. (Have the window NOT maximized.) Close Octave GUI. Start Octave GUI again (it now automatically opens on monitor B, as excpected). Maximize Octave GUI. Close Octave GUI. Start Octave GUI again. It still opens on monitor B. But the window decorations have fully disappeard, i.e. the buggy behavior happens.


Conclusion: There is no difference between the two monitors (A and B), when using a two monitor setup. But there is a difference between the one monitor setup (no bug) and my normal two monitor setup (bug happens).

Hartmut <hardy>
Fri 07 Jan 2022 09:27:05 PM UTC, comment #17: 

@Hartmut, do you always start octave on the same monitor?

Torsten Lilge <ttl>
Group Member
Fri 07 Jan 2022 08:21:02 PM UTC, comment #16: 

I obverve this on my standard laptop. It has regularly updated qt packages installed from the standard repository of Ubuntu 20.04 LTS, this is currently qt version 5.12.8 (e.g. package "qtbase5-dev" is installed in version 5.12.8+dfsg-0ubuntu2.1). I am running Gnome under x11, not wayland. If you would like to know further details, please let me know.

Hartmut <hardy>
Fri 07 Jan 2022 08:02:46 PM UTC, comment #15: 

What version of Qt?  Does the Ubuntu 20.04 system where the problem appears use Wayland?  I can't duplicate the problem with Qt 5.15.2 on a Debian system running Xwayland.

John W. Eaton <jwe>
Group administrator
Fri 07 Jan 2022 07:41:19 PM UTC, comment #14: 

This bug is still present in the current release candidate Octave 7.0.90 (using Ubuntu 20.04 LTS with Gnome under X11).

Hartmut <hardy>
Fri 05 Nov 2021 04:26:51 PM UTC, comment #13: 

This bug is still present in Octave 6.4.0.

Luiz Antonio Maccari Junior <luiz>
Thu 21 Oct 2021 04:30:54 PM UTC, comment #12: 

This bug is still present with the current release candidate Octave 6.3.90 on Ubuntu 20.04 LTS.

Hartmut <hardy>
Sat 18 Sep 2021 08:19:38 PM UTC, comment #11: 

I see the same wrong behavior of the Octave GUI after closing the maximized window. I also have the whole window "decoration" missing after the second Octave GUI start (like the screenshot in comment #10).

I use (self compiled from release tar-ball) Octave 6.3.0 on Ubuntu 20.04.3 and an X11 seesion (i.e. no wayland display server) with Gnome. It is a quite freshly installed "vanilla" Ubuntu linux.

In my setup, there are also two monitors involved, the problem happens on either of them. (The problem disappears once I remove the second monitor.) Maybe it is relevant that my two monitors have different size (meaning different numbers of pixel height) and are arranged side by side in the display settings. (This is probably a typical home office setup, a laptop plus a monitor next to it.)

I could supply more information if it is relevant.

Hartmut <hardy>
Sat 18 Sep 2021 08:03:20 PM UTC, comment #10: 

Now a better screenshot only of the screen with problems. The problem is not only the wrong size but the impossibility of resize it.




Luiz Antonio Maccari Junior <luiz>
Sat 18 Sep 2021 07:44:14 PM UTC, comment #9: 

Good point! I am also seeing some minor issues on Wayland with Qt applications. Octave's main window is slightly too high after a restart in full screen mode such that the status bar is not visible. However, everything work as expected and I can quit full screen mode.

TeXStudio, e.g., shows a too wide window when leaving full screen mode.

Torsten Lilge <ttl>
Group Member
Sat 18 Sep 2021 07:43:59 PM UTC, comment #8: 

Making another test it seems that the problem only happens with two monitors. When I remove one monitor and use only one the problem not happens anymore. However if i plug the second monitor and maximize I got the weird full screen without task bar and other commands.

I have annexed two screenshots of my two monitor setup. .


Luiz Antonio Maccari Junior <luiz>
Sat 18 Sep 2021 06:42:54 PM UTC, comment #7: 

Could it be an Xorg-vs-Wayland issue?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 18 Sep 2021 06:22:52 PM UTC, comment #6: 

Full screen mode works as expected on Debian 11 with Gnome.

Is it possible to provide screenshots of the main window states in full screen mode?

Torsten Lilge <ttl>
Group Member
Sat 18 Sep 2021 05:03:33 PM UTC, comment #5: 

It seems that bug #61183 is the same as the one reported here.

Luiz Antonio Maccari Junior <luiz>
Sat 18 Sep 2021 04:52:18 PM UTC, comment #4: 

Is bug #61183 a duplicate of this one?

Torsten Lilge <ttl>
Group Member
Sat 18 Sep 2021 02:15:30 PM UTC, comment #3: 

The same problem happens in Ubuntu 20.04 with Octave 6.3. Restoring default windows layout makes the window normal but doesn't solve the problem.

Changpu Li <lcp29>
Thu 16 Sep 2021 09:40:34 PM UTC, comment #2: 

Hello,

No. Unmaximize, move and resize appears in gray and the shortcuts do not work as well. Is impossible to do these commands after the maximization.

Thanks for your attention.

Luiz Antonio Maccari Junior <luiz>
Thu 16 Sep 2021 08:49:17 PM UTC, comment #1: 

Thanks for the report. Are you able to open the windows menu via Alt+Space and unmaximize the window via this menu?

Torsten Lilge <ttl>
Group Member
Thu 16 Sep 2021 08:31:00 PM UTC, original submission:  

I am using Linux Mint 20.2. I have build Octave 6.3 and got an unexpected behavior.

When I run the GUI for the first time everything is ok, however if I maximize the GUI and close the program. When it starts again it comes in a full screen configuration without the mint taskbar and without the buttons to unmaximize, minimize or close the program. The only way to close is with alt+f4 command. If I use the windows key the task bar appears again but the unmaximize option stay in gray.

So after maximize it is impossible to unmaximize because of the lack of the buttons on the top right. All title bar disappears. Also is impossible to grab the window and move it to other monitor.

After trying reinstall sometimes, I see that the problem is related with the file /home/luiz/.config/octave/octave-gui.ini. If  I delete it the program think that is the first time that I am running the GUI and the behaviour is normal again. Except that I can't maximize the program because is impossible to unmaximize it and problem starts again.

It seems that when I close the program maximized, it rewrite the .ini file on a wrong manner.

I have annexed two config files: file 1 is before the maximization and file 2 is after the maximization.

Luiz Antonio Maccari Junior <luiz>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52633:  bug61172_02.patch added by ttl (2KiB - text/x-patch)
file #52631:  bug61172_01.patch added by ttl (703B - text/x-patch)
file #51941:  Problem.png added by luiz (69KiB - image/png)
file #51928:  octave-gui@-@1 added by luiz (21KiB - application/octet-stream)
file #51929:  octave-gui@-@2 added by luiz (21KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by tlcfem (Updated the item)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by lcp29 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by luiz (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 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-14 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-08-08 ttl StatusFixed Ready For Test
        Open/ClosedClosed Open
    2022-08-04 rik5 Carbon-CopyRemoved 72865 -
    2022-08-04 tlcfem Attached File- Added Screenshot@from@2022-08-04@14-27-39.png, #53502
    2022-02-22 ttl StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-01-14 ttl StatusNone Ready For Test
    2022-01-09 ttl Attached File- Added bug61172_02.patch, #52633
    2022-01-08 ttl Attached File- Added bug61172_01.patch, #52631
    2022-01-08 mmuetzel Release6.3.0 7.0.90
        SummaryGUI problems on Linux Mint - Problems after maximize the GUI Problems after maximize the GUI with 2 monitors
    2022-01-08 jwe Attached File- Added main-window-maximized-diffs.txt, #52628
    2021-09-18 luiz Attached File- Added Problem.png, #51941
    2021-09-18 luiz Attached File- Added Screenshot@without@problem.png, #51939
        Attached File- Added Screenshot@with@problem.png, #51940
    2021-09-18 ttl Dependencies- bugs #61183 is dependent
    2021-09-16 luiz Attached File- Added octave-gui@-@1, #51928
        Attached File- Added octave-gui@-@2, #51929

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code