octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53392] [GUI] Octave crashes when moving Docum


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53392] [GUI] Octave crashes when moving Documentation pane within GUI onto another pane
Date: Wed, 21 Mar 2018 20:29:34 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0

Follow-up Comment #12, bug #53392 (project octave):

OK, took a while, but I found the exact change that makes a difference in the
patch from Bug #53276.  I added just the following change hunk to the tip:


diff -r ecb5688b875f libgui/src/octave-dock-widget.cc
--- a/libgui/src/octave-dock-widget.cc  Mon Mar 19 14:38:04 2018 -0700
+++ b/libgui/src/octave-dock-widget.cc  Wed Mar 21 19:13:42 2018 -0500
@@ -203,9 +203,13 @@
     if (dock)
       {
         settings->setValue ("MainWindow/windowState", m_parent->saveState
());
+        // Stay window, otherwise will bounce back to window by default
because
+        // there is no layout information for this widget in the saved
settings.
+        setParent (m_parent, Qt::Window);
         m_parent->addDockWidget (Qt::TopDockWidgetArea, this);
         // recover old window states, hide and re-show new added widget
         m_parent->restoreState (settings->value
("MainWindow/windowState").toByteArray ());
+        setFloating (false);
         focus ();
         QApplication::setActiveWindow (this);
         m_title_widget->setToolTip ("");


As I noted previously, this process has to be fairly precise.  

I should note that the system this is failing on uses KDE/Plasma with what
looks like a fairly old version of Qt, 4.4.8.7.  In fact, it looks kind of
like a Qt bug to me.

The change above is not a hunk of code executed right before the crash. 
Instead it is executed right after startup and then not again until the user
does the drag-and-drop.  However, it is setting up the state of the
QDockWidget in an incorrect way.  (Still, Qt shouldn't crash--produce a
strange result sure--but crash at the point it comes time to convert to
tabified?)  When a QDockWidget is dragged, it immediately becomes a floating
window (hence the tricky aspect of Bug #53276).  So, it's state is floating
but I suspect the internal float variable is out of sync because of the way
make_window() is done.

That's why the first thing I did in approaching the changes of Bug #53276 was
to get rid of m_floating.  That was a second state variable, only opening
confusion with the internal isFloating() state variable.  I'd rather just rely
on the one variable as the true state and fix any bugs around that.

Anyway, how to fix this?  My preference might be to just go forward with the
patch from #53276 (or something really close).  Or if you think you want to do
this small change here first, that's fine.  This bug is in Octave 4.2 release,
but hopefully is only happening with Qt 4.4.8.  I believe there is another bug
which could be Qt (old) and that is the lack of animated docks:

https://savannah.gnu.org/bugs/?53409

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53392>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]