bugGNU Octave - Bugs: bug #53409, Variable Editor QDockWidget panels...

 
 

bug #53409: Variable Editor QDockWidget panels not movable in KDE / Plasma Qt 4.4.8.7

Submitted by:  Dan Sebald <sebald>
Submitted on:  Wed 21 Mar 2018 08:36:05 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Tue 03 Apr 2018 03:35:19 AM UTC, comment #36: 

OK, thanks.  To be clear (since the original title is a bit off target, this really is more general than Variable Editor), in the main GUI window you are unable to move docked widgets around freely as well as the Variable Editor?

I'm using Mint KDE/Plasma here as well.  Do you have the same Qt build:

Installed Version         Latest Version
5.6.1-2build1~~xenial     5.6.1-2build1~~xenial

?

Dan Sebald <sebald>
Mon 02 Apr 2018 10:27:48 PM UTC, comment #35: 

@Dan: I applied your patch here: http://hg.savannah.gnu.org/hgweb/octave/rev/2b8442c890d8.  I expect if we have more problems we will hear about it.  Two variable editor windows, when they are docked, are not re-orderable for me with 5.6.1 even with this patch.  But, I'm willing to live with that.

Rik <rik5>
Project Administrator
Mon 02 Apr 2018 08:07:56 PM UTC, comment #34: 

@Rik: Attached is a refreshed patch that should now be the priority now that

http://hg.savannah.gnu.org/hgweb/octave/rev/36f17567ffa1

is applied.  This is the March 23 version.  I think it is the best that can be done, as I suspect we're going to get bug reports in any situation.  Give it a try on KDE/Plasma on the stable branch.  If it works for you, great.  If not, as you suggested I think we just apply it an move forward.  I've added a comment in the NEWS file about this bug in hopes that some builders/users might realize they could have a problem.

(file #43774)

Dan Sebald <sebald>
Sun 01 Apr 2018 09:39:21 PM UTC, comment #33: 

Re: comment #30 (It would be nice to fix Bug #53392 on stable or default)

If this patch should fix something in the upcoming 4.4, it has to be applied on stable.

Torsten Lilge <ttl>
Project Member
Sun 01 Apr 2018 04:51:51 PM UTC, comment #32: 

@Philip: 5.6.2 should still be affected by this.

Yes, the patches are spread about.  That is why I'm pointing out Bug #53392 is ready to go, in hopes of getting something rolling again.  The reason for the multiple patches is that I think we have a general philosophy of making changesets atomic in the sense they address one bug and not, say, a dozen bugs in one fell swoop.  That makes for better "tracking" in the sense that when it comes time to address down-stream peculiarities that always seem to exist across multiple p;atforms, the users can point to more granular changesets and say, it's changeset abc123 where things stopped working for me.  It also makes for easier review (provided of course there are the resources to do such review in light of the avalanche of bugs).

Dan Sebald <sebald>
Sun 01 Apr 2018 02:27:42 PM UTC, comment #31: 

@Dan:
re comment #29: my Mageia-6 box' Qt is now at 5.6.2

BTW I lost track a little bit on what patches to apply (in what order); many of your Qt fixes seem scattered over various bug reports. I guess that is because all of those bugs seem or are somehow related.
The only one I have applied  yet is the one that fixes bug #53392 (file #43650 from comment 13 there)

Philip Nienhuis <philipnienhuis>
Project Member
Sun 01 Apr 2018 09:09:14 AM UTC, comment #30: 

I'm working in Plasma/KDE right now.  My package manager indicates the following

Installed Version         Latest Version
5.6.1-2build1~~xenial     5.6.1-2build1~~xenial

For me, the March 23 patch

https://savannah.gnu.org/bugs/download.php?file_id=43640

works the best.  This is the one that uses

+#else
+        setDockNestingEnabled (true);
+#endif

Without the nesting, the octave_dock_widgets will move if they are added to a tab view, but they will not move to a different location on their own.

There is a drag-and-drop bug (Bug #53392) that has a simple patch that should really be applied before testing the bug fix here.  Perhaps you are mistaking that drag-and-drop bug as this bug.  (It makes the whole panel window a blue shade and hangs for a while.)  It would be nice to fix Bug #53392 on stable or default.  It's been hampering testing for other bugs.

Dan Sebald <sebald>
Fri 23 Mar 2018 11:13:40 PM UTC, comment #29: 

"I would still think most Ubuntu 16.04 desktop users are going to be using Unity and not pulling in these backports, so they will remain on Qt 5.5.1."

Most likely, yes.  But it would still be nice to have some work-around because surely bug reports will come this way.  It turns out Philip is using Qt 5.6.1, so that might be another tester ( see Bug #53392 ).  In any case, I think sometime next week I'll have to move those KDE 5.6.1 packages onto my KDE drive and see if there is anything that can be done.

Dan Sebald <sebald>
Fri 23 Mar 2018 11:08:40 PM UTC, comment #28: 

I don't appear to have any backport enabled in /etc/apt.  My guess is that Mint itself is doing the substitution.

But I can upgrade out of this in about 2 months time, and I mostly use the CLI anyways.  This is not a showstopper for me.  We should commit whatever changes will help users for Qt since that seems to work.

Rik <rik5>
Project Administrator
Fri 23 Mar 2018 10:56:08 PM UTC, comment #27: 

I see. The "~xenialoverlay1" packages are backports from the Kubuntu team backports PPA, not part of the mainline Ubuntu release.

The Mint installer must enable some additional PPA repositories to pull in new versions of the KDE desktop, or maybe this was a configuration you added.

So Dan, if you need another test case, what you need is someone with Ubuntu 16.04 or Mint 18 with the Kubuntu backports PPA enabled and the Qt packages installed from there.

I would still think most Ubuntu 16.04 desktop users are going to be using Unity and not pulling in these backports, so they will remain on Qt 5.5.1.

Mike Miller <mtmiller>
Project Administrator
Fri 23 Mar 2018 10:46:17 PM UTC, comment #26: 

@Mike: I'm running Mint 18.1 which is based on Ubuntu 16.04, but the Mint releases 18.0, 18.1, 18.2, 18.3 are all based on 16.04.  They substitute some packages in/out I believe.  In any case, here is a sampling of dpkg -l | grep libqt5

ii  libqt5gui5:amd64                                5.6.1+dfsg-3ubuntu1~xenialoverlay1~4+fix1                amd64        Qt 5 GUI module
ii  libqt5help5:amd64                               5.6.1-2build1~~xenialoverlay1~1                          amd64        Qt 5 help module
ii  libqt5libqgtk2:amd64                            5.6.1+dfsg-3ubuntu1~xenialoverlay1~4+fix1                amd64        Qt 5 GTK2 platform theme
ii  libqt5multimedia5:amd64                         5.6.1-2ubuntu1~xenialoverlay1~1                          amd64        Qt 5 Multimedia module

Rik <rik5>
Project Administrator
Fri 23 Mar 2018 10:43:09 PM UTC, comment #25: 

So here is the Ubuntu information to the best of my knowledge

  • Ubuntu 16.04 long-term support has Qt 5.5.1, no bug. People will be using this Ubuntu release for years to come, and Mint is also based on this release.
  • Ubuntu 16.10 had Qt 5.6.1, this version of Ubuntu is no longer supported, no one should be on it now
  • Ubuntu 17.04 had Qt 5.7.1, this version of Ubuntu is no longer supported, no one should be on it now
  • Ubuntu 17.10 has Qt 5.9.1, this is the current short-term release that will be unsupported in a few months
  • Ubuntu 18.04 will have Qt 5.9.1, this is the next long-term support release that people will probably be using until 2022

Rik - is it possible you upgraded to Ubuntu 16.10 and forgot to keep upgrading to 17.04 and 17.10?

Mike Miller <mtmiller>
Project Administrator
Fri 23 Mar 2018 10:37:55 PM UTC, comment #24: 

The bug doesn't exist in 5.5.1.  It was introduced in 5.6.1 and fixed in 5.7.1.  That much we know.  It's as though the bug existed long ago, was fixed, then reintroduced when developers did some work with multi-screens.  Just a guess.

Dan Sebald <sebald>
Fri 23 Mar 2018 10:28:46 PM UTC, comment #23: 

Rik - how do you have Qt 5.6.1 on Ubuntu 16.04? I don't use KDE, and I'm only looking at the Ubuntu repository on the web right now, but as far as I can tell Ubuntu 16.04 is Qt 5.5.1, not 5.6.1.

Dan's Mint 18 should be equivalent to Ubuntu 16.04 packages, both Qt 5.5.1.

If the patch fixes things for Qt 5.5.1 users, and Qt 5.9 isn't affected, then all Ubuntu and Mint users should be covered.

Mike Miller <mtmiller>
Project Administrator
Fri 23 Mar 2018 10:20:22 PM UTC, comment #22: 

Same thing.  The variable just snap back.  Maybe it is unfixable for users with Qt in the specific window mentioned?  It's a shame because 16.04LTS is going to be around still for a while.

Rik <rik5>
Project Administrator
Fri 23 Mar 2018 10:07:54 PM UTC, comment #21: 

Does this patch improve anything?

(file #43655)

Dan Sebald <sebald>
Fri 23 Mar 2018 09:57:34 PM UTC, comment #20: 

Actually, I can't determine any rhyme or reason for the ordering.  But, I do know that I can't drag and drop them into the positions I want.

Rik <rik5>
Project Administrator
Fri 23 Mar 2018 09:51:39 PM UTC, comment #19: 

Unfortunately, things still don't work for me.  With the patch applied from comment #12 the variables always snap back to the orientation that was created when the Variable Editor was initialized.  I also tried commenting out setDockNestingEnabled but also no luck.

Finally, this may be more relevant.  The variables seem to be displayed in alphabetical order, ALWAYS.  It is not just order of initialization.

x = 1, y = 2; z = 3;
openvar z
openvar y
openvar x

The windows are now ordered x,y,z and although I can drag them around they snap back to alphabetical order when I drop them.

Rik <rik5>
Project Administrator
Fri 23 Mar 2018 09:26:39 PM UTC, comment #18: 

I think Rik needs to test because he's the one person I know that has Qt 5.6.1 on a working KDE machine.  The patch is basically trying to find something usable on Rik's setup without tossing away to many option settings.

Dan Sebald <sebald>
Fri 23 Mar 2018 09:16:03 PM UTC, comment #17: 

So, is the most recent patch OK to apply, or is there something else we should do?

John W. Eaton <jwe>
Project Administrator
Fri 23 Mar 2018 09:14:36 PM UTC, comment #16: 

D'oh.  Disregard my last comment.  I apparently hid the dicussion accidentally and didn't realize it.

John W. Eaton <jwe>
Project Administrator
Fri 23 Mar 2018 09:13:36 PM UTC, comment #15: 

Is there any explanation about this bug?  Was it discussed elsewhere?  If so, let's add a link here.

John W. Eaton <jwe>
Project Administrator
Fri 23 Mar 2018 04:16:59 PM UTC, comment #14: 

Mint is based on Ubuntu LTS. Ubuntu 16.04 LTS froze two years ago on Qt 5.5.1. Qt 5.6 is marked as LTS by the Qt project, but wasn't released until March 2016, too late to get into Ubuntu's LTS.

The upcoming Ubuntu 18.04 LTS will have Qt 5.9.4, so that's what Ubuntu and Mint users will have for the next two years. Qt 5.9 is marked as an LTS release by the Qt project.

Mike Miller <mtmiller>
Project Administrator
Fri 23 Mar 2018 04:09:00 PM UTC, comment #13: 

BTW, on Mint/Cinnamon, the Qt version is 5.5.1 which is outside that range 5.6.1 through 5.7.0.  This is the version I used for development, before the KDE issues arose.  Perhaps Mint/Cinnamon developers were aware of this bug and held off upgrading Qt past the 5.6.1 (although, they could have gone with 5.6.0 if that were the case).

Dan Sebald <sebald>
Fri 23 Mar 2018 07:59:00 AM UTC, comment #12: 

I'm attaching a new version of this, one that places some pre-processor conditionals on the use of setDockOptions().  Hopefully, for versions 5.6.1 through 5.7.0 not using setDockOption() will prevent the non-movable docked widgets.  (The non-movable floated windows is a different bug report.)  There looks to be a unique function for controlling nesting, so I put that in there even though I'm not sure whether it too causes an issue.  My thinking is that perhaps it won't hurt the movable widgets the way that setDockOption() does:

    m_main->setParent (this);
// See Octave bug #53409 and https://bugreports.qt.io/browse/QTBUG-55357
#if (QT_VERSION < 0x050601) || (QT_VERSION >= 0x050701)
    m_main->setDockOptions (QMainWindow::AnimatedDocks |
                            QMainWindow::AllowNestedDocks |
                            QMainWindow::VerticalTabs);
#else
    m_main->setDockNestingEnabled (true);
#endif

If you still don't get movable widgets, try commenting out the setDockNestingEnabled().

Note that I only eliminated the range 5.6.1 through 5.7.0 because I'm thinking that the use of QMainWindow::AnimatedDocks will correct the 4.4.8 version issue.  Works here.  More generally?  Not sure.

(file #43640)

Dan Sebald <sebald>
Fri 23 Mar 2018 12:19:24 AM UTC, comment #11: 

Sure 'nough.  That Qt bug report says "doesn't work after changing dock options", and I've commented out the following line that changes the dock options

    m_main->setParent (this);
//    m_main->setDockOptions (QMainWindow::AllowNestedDocks |
//                            QMainWindow::VerticalTabs);

recompiled and now the widgets relocate.

The nested docks (provides more flexibility in moving things around as opposed to just the outside perimeter of the central) and vertical tabs were suggested by JWE.  We could pre-process comment this line out for now until a future date, or let the problem exist for Qt 5.6.1 through 5.7.0 users.

Dan Sebald <sebald>
Fri 23 Mar 2018 12:04:50 AM UTC, comment #10: 

It figures.  I know Mint is going to produce a version on top of the new Ubuntu LTS release soon (~next 2 months).  I might upgrade at that point and see if it is fixed.

Rik <rik5>
Project Administrator
Fri 23 Mar 2018 12:02:11 AM UTC, comment #9: 

I wonder if this is bad luck.  The following Qt bug report

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

indicates exactly what I'm seeing (4.4.8) and what you are seeing.  It indicates that the bug is in Qt 5.6.1 and 5.7.0, but then has been fixed since 5.7.1.

I've been experimenting here, trying to get around this and I can't figure anything out.  If I choose

    page->setFeatures (QDockWidget::NoDockWidgetFeatures);

there is a change in behavior in the sense that no longer can I drag the QDockWidget around.  They are static and immutable.  So Qt is reacting to the settings in a sane way, but just not letting that final drop take place.

I'm guessing this bug might have crept in because of multi-screen support.

Anyway, we might have to find someone with KDE and Qt 5.5.x series or 5.7.1 series.  This Mint KDE/Plasma version has Qt 5, but it too is 5.6.1.

I suspect the best solution is still to use QMainWindow::AnimatedDocks, as in the patch I attached previously since it seems to fix the old 4.4.x series in a reasonable way.

Dan Sebald <sebald>
Thu 22 Mar 2018 09:33:07 PM UTC, comment #8: 

Yes, I think that bug is fixed, after quite a few tries:

https://savannah.gnu.org/bugs/?53276#comment54

Regarding this bug, I notice that there is in fact a QToolBar added prior to the setDockOptions.  (Setting the options is supposed to come before anything is added.)  I'll see if that makes a difference this evening.  (I have to switch my system over to KDE on a different hard drive.)

Dan Sebald <sebald>
Thu 22 Mar 2018 09:27:55 PM UTC, comment #7: 

Also, I should note that if I use <Alt>+<Left Click> then I can move even the main Variable Editor window.

Rik <rik5>
Project Administrator
Thu 22 Mar 2018 09:24:56 PM UTC, comment #6: 

Yes, KDE/Plasma.

There is an outstanding bug about KDE undocked windows not being moveable, which is the case for me if I undock the main Variable Editor window.  What is then weird, but useable, is that undocking individual variables from the Variable Editor window makes those particular windows movable.

Rik <rik5>
Project Administrator
Thu 22 Mar 2018 09:12:30 PM UTC, comment #5: 

KDE/Plasma?  How about the main GUI window; can those be moved and repositioned?

Dan Sebald <sebald>
Thu 22 Mar 2018 09:03:08 PM UTC, comment #4: 

I tried the patch, but it doesn't work for me.  The different variables are moveable, but when I let go they spring back to their original positions (order in which they were opened).

I used

x = magic (3)
y = [1:3]
openvar x
openvar y
## Try and move y widget above x widget

This is with the development version of Octave and Qt 5.6.1.

Rik <rik5>
Project Administrator
Thu 22 Mar 2018 07:19:01 PM UTC, comment #3: 

I meant rearrange within the QMainWindow as widgets.  It's the common behavior of QDockWidget::DockWidgetMovable not active, when the mouse-title-click-drag moves things around, but let go of the mouse button and it snaps back to the original location.  This looks like something particular the Qt version noted.  Newer versions work fine.  I can't think of any reason this shouldn't work (turn off QMainWindow::AnimatedDocks for the main GUI window and there too the octave_docK_widget objects are locked in their locations).

Dan Sebald <sebald>
Thu 22 Mar 2018 06:13:37 PM UTC, comment #2: 

When you say you cannot move them, do you mean when they are undocked?  Or are you trying to re-arrange multiple VE windows that are all docked?

Rik <rik5>
Project Administrator
Thu 22 Mar 2018 02:06:51 AM UTC, comment #1: 

Here's a short changeset.  Turning on QMainWindow::AnimatedDocks appears to fix this.  Looks like an old Qt bug to me.  It could possibly have something to do with the point at which the setDockOptions is done.  (It is supposed to be before any QDockWidgets are added because the settings are passive, but as I see it nothing is added until variable_editor::edit_variable() is called.)  I also changed a line having to do with restricted layout locations.  Not sure that is needed or even applies when the QMainWindow::AllowNestedDocks is active.

(file #43620)

Dan Sebald <sebald>
Wed 21 Mar 2018 08:36:05 PM UTC, original submission:  

I'm finding in testing on Mint KDE/Plasma that the Variable Editor panels can't be moved, as though the QDockWidget::DockWidgetMovable feature parameter is not set.  But this is supposed to be on by default (and I forced the default settings, to confirm the behavior still exists).

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-02 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed
    2018-04-02 sebald Attached File- => Added octave-movable_widgets_qt_version_dependent-djs2018apr02.patch, #43774
    2018-03-23 sebald Attached File- => Added octave-ve_movable_widgets_qt_version_dependent-djs2018mar24.patch, #43655
    2018-03-23 sebald Attached File- => Added octave-ve_movable_widgets_qt_version_dependent-djs2018mar23.patch, #43640
    2018-03-22 rik5 Item GroupUnexpected Error => Feature Request
    2018-03-22 sebald Attached File- => Added octave-ve_movable_widgets_old_qt4-djs2018mar21.patch, #43620

    Back to the top


    Powered by Savane 3.5