bugGNU Octave - Bugs: bug #53893, Rearranging widgets in the...

 
 

bug #53893: Rearranging widgets in the variable editor switches to another workspace

Submitted by:  Torsten <ttl>
Submitted on:  Sun 13 May 2018 06:02:42 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
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)

Thu 31 May 2018 05:50:06 PM UTC, comment #24:

Thanks for the patch, I have pushed it with changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/b529e3e1393d

Closing the report.

Torsten <ttl>
Project Member
Mon 28 May 2018 08:47:32 PM UTC, comment #23:

That's good. Consider going with that then. I think that amounts to a Ubuntu Unity bug of a back-to-back change in floating, i.e.:

That shouldn't cause a problem. Whether it is Qt or the window manager that is responsible, I don't know and I'm not too concerned with that bug. Instead, it's QTBUG-44813; once that one is fixed, all the inelegant flickering and so on goes away along with the work-around.

Dan Sebald <sebald>
Mon 28 May 2018 08:23:32 PM UTC, comment #22:

The issue seems to be fixed with the patch, at least I was not able to reproduce it anymore. In some case of rearranging variable widgets, I am also seeing some flickering.

Torsten <ttl>
Project Member
Sun 27 May 2018 07:29:40 PM UTC, comment #21:

The changeset needs a window activation and focus to make it consistent with existing behavior. Minor addition attached.

(file #44233)

Dan Sebald <sebald>
Sun 27 May 2018 06:46:47 PM UTC, comment #20:

@Torsten, attached is a changeset I would try if I were to install Ubuntu. Let me know if this fixes the loss-of-focus issue. The difference here is that it queues an unfloat and then after that unfloat occurs queues the float. The effect is the same, but on my system (and it is no surprise) this causes the floated widget to appear momentarily, creating a bad flash. I've tried to lessen the flash effect by first hiding and then showing after the refloat is done. That improves things, but still every once in a while I see the floated paint occur. This behavior explains why you see the loss of focus occasionally rather than consistently. I suspect the exact sequence of floating and unfloating is somewhat window manager dependent. That is, Qt asks the window manager to do something, but whether the window manager does the action immediately or gets around to it is another question. It could well be that various mouse events, etc. come at different times out of sequence with relation to the float and unfloat behavior. Anyway, if the attached patch fixes things for you, I'd say it is a Ubuntu Unity bug.

(file #44232)

Dan Sebald <sebald>
Sun 27 May 2018 06:01:33 PM UTC, comment #19:

Dan wrote: "and it will eventually come out because it is conditionally included in compilation."

BTW, would you (or some other developer) already be registered with Qt's discussion board? It would be nice for someone to put a watch on this bug:

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

I'm sure that big will eventually get fixed as Qt 5.4.0/1 becomes the norm. Once it is fixed, all one need do is place the version number in place of:

and recompile.

Dan Sebald <sebald>
Sun 27 May 2018 05:53:03 PM UTC, comment #18:

On the matter of disabling the floating of individual V.E. variable panels, I see your point. Ultimately if that is what happens I'm fine with it. I think from the Qt perspective it's simply a matter of whether the user likes the fact these child QDockWidgets disappear when the QMainWindow goes out of focus. (Octave's complex method of changing floated main GUI octave_dock_widgets avoids this question.) I've seen plenty of comments on the web about Qt programmers/users who dislike that behavior.

At the same time, I think at this stage I'm more inclined to just let all the Qt features exist for the time being--the double-click float, drag float, the sub-panels disappear--and get some user feedback for one or two releases. Even if they are a bit buggy, and I think we are past the difficult spots now. If a person doesn't like some bug (like this one), then they just won't use that feature. They may report a bug, but disabling Qt features from the start is effectively the same as the user not using some buggy feature.

In addition, the V.E. float/unfloat allows one really nice feature, which is the maximize button that enlarges the variable sub-panel to full screen.

So, I'd say to not disable things too soon and just leave them for now. This project doesn't have a formal process of putting together design requirements up front then following with verification and validation. Instead the approach has always been more organic evolution than anything else. After a year or two, there will have been plenty of comments about how the V.E. and its subpanels should behave--by both users and developers. No consensus I'm sure, but enough feedback to decide on some reasonable compromise. At this point though, I'm sure few have used the V.E.

The one direction I'm a little wary of is that folks will want the V.E. subpanels to be floated with decorations just like the main GUI octave_dock_widgets. That is, V.E. windows should be very analogous to Figure windows. Doable, but that would make for a really bloated bunch of windows in the task bar to keep track of. I realize there is KDE's feature of grouping similar windows under one application, but I've found I don't like that much because the order in which KDE lists these grouped windows doesn't make sense to me. (Mint has this nice feature where it allows one to drag the icons in the task bar to whatever location s/he wants.) Maybe if there were multiple KDE groups: one for octave_dock_widgets and the main GUI, one for Figures, and one for Variables.

Dan Sebald <sebald>
Sun 27 May 2018 05:26:25 PM UTC, comment #17:

OK, caught between the devil and the deep blue sea with another Qt issue then. I don't understand this bug, and I'm wondering if it is Unity related, just like we saw issues with KDE Oxygen. Here's the event processing, it's pretty straightforward:

-verbatim-
bool
variable_dock_widget::event (QEvent *event)
{
// low-level check of whether docked-widget became a window via
// via drag-and-drop
if (event->type () == QEvent::MouseButtonPress)
m_waiting_for_mouse_move = false;
if (event->type () == QEvent::MouseMove && m_waiting_for_mouse_move)
{
m_waiting_for_mouse_move = false;
m_waiting_for_mouse_button_release = true;
}
if (event->type () == QEvent::MouseButtonRelease && m_waiting_for_mouse_button_release)
{
m_waiting_for_mouse_button_release = false;
bool retval = QDockWidget::event (event);
if (isFloating ())
emit queue_unfloat_float ();
return retval;
}

return QDockWidget::event (event);
}
-verbatim-

It's basically a little state machine that watches for the user to move the mouse and release the button. This happens just after the widget is floated (and the diff file I sent last time changed things so this state machine isn't initiated). If a mouse button press comes along before the button release, the state is reset. Similarly, in variable_dock_widget::toplevel_change(), if the widget is redocked the state is reset. I suppose there are a couple other situations where the state could be reset for good measure.

I'm sure there is nothing in Qt documentation specifying exactly what sequence of events happens with a toplevel-change. So, I can understand there being a bug in whether the widget ends up floating or not floating.

On the other hand, I can't figure out why this would have any influence on the focus leaving for another application. So, what happens if the state machine complete's its sequence? The following routine is queued:

setFloating() is a Qt method, so it should be robust in whatever window manager it is working in. Could doing this back-to-back setFloating() be a bug in Unity? If so, a solution might then be to issue the "setFloating(false)" and then queue another slot that does the "setFloating(true)". (The same technique I've used quite often to avoid similar issues.)

Torsten, I'm attaching a changeset that more thoroughly resets that state machine, as I suggested above. It may not fix anything, but give it a try and see if it avoids the issue. If you like, you may want to apply this patch in any case; it's more thorough, I guess, and it will eventually come out because it is conditionally included in compilation.

Otherwise, maybe the best thing is for me to install Ubuntu Unity here on some hard drive. (Exactly what version are you using?) It would mean discarding Kubuntu KDE Plasma, but KDE isn't something I use and I doubt I will look at that Plasma Oxygen issue again, so no big deal. It's just the process of installing all the libraries again to make Octave build on Ubuntu Unity that takes time.

(file #44231)

Dan Sebald <sebald>
Sun 27 May 2018 07:52:49 AM UTC, comment #16:

Dan, thanks for digging that deep.

Actually, the patch fixes the issue!

Regarding the issue with the floating widgets when VE itself becomes floating, what about disabling floatable variable widgets? Would this decrease the usability of the VE? The VE itself can be made floating and full screen.

Torsten <ttl>
Project Member
Sun 27 May 2018 06:19:48 AM UTC, comment #15:

@Torsten: The only thing I can think of to try is disabling that work-around for Qt bug

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

I'm attaching a diff file that effectively disables the work-around. Could you please apply that and see if it makes things better on Ubuntu Unity?

I don't see why this should have an influence, but it's worth a try from an investigative standpoint.

(file #44225)

Dan Sebald <sebald>
Sun 27 May 2018 04:23:26 AM UTC, comment #14:

Well, what I said in Comment #13 should really be disregarded. The way that I put the GUI into that state was by switching between Fusion and Oxygen in the system Widget style setting. Making the switch (either to Fusion or to Oxygen) causes this odd behavior where floating a V.E. subpanel makes it disappear. Let's not worry about what happens to Qt with system level changes and assume that the user must relaunch the application after making such a change. Relaunching corrects the issue.

The one issue I see still is that if a variable panel of the *docked) V.E. is floated, and then the V.E. itself is floated, the association between the floated variable and the V.E. is lost. Instead the associated goes to the GUI main window. That is, only when the GUI main window has focus does the variable sub-panel appear. Docking then undocking the variable subpanel fixes that association.

In KDE Plasma I've added three workspaces but see no bad effects as you describe. I've even moved the Variable Editor to another workspace. Typing "openvar x" will switch to the workspace where the V.E. exists.

I'll keep thinking...

Dan Sebald <sebald>
Sun 27 May 2018 02:52:16 AM UTC, comment #13:

I haven't been able to replicate that on KDE Plasma, but there is certainly some strangeness associated with that V.E. action. Sometimes a floated variable panel will disappear, then reappear with a particular minimize/maximize sequence. I even managed to get the attached result when trying to redock a floated V.E. panel, i.e., the same variable showing as docked within the V.E. and floating as undocked.

(file #44224)

Dan Sebald <sebald>
Sun 20 May 2018 05:22:26 PM UTC, comment #12:

Maybe I should add that all octave windows stay on the old workspace while the window manager switches to another workspace.

Torsten <ttl>
Project Member
Sun 20 May 2018 06:56:18 AM UTC, comment #11:

OK, very helpful, thanks. I'll think of how this can come about. (Even to a different workspace? Wow, that is strange.)

Dan Sebald <sebald>
Sat 19 May 2018 08:59:44 AM UTC, comment #10:

From my tests so far, I can see the follwoing:

  • The effect only happens when VE is floating
  • It happens (but not always) when a variable widget is dragged to a new location inside the VE window
  • It does not happpen when a widget is undocked or redocked, where it is not important whether this is done via dragging or by the related buttons
  • Having a widget made floating and docked again, this widget can be rearranged without initiating this effect in the following!

When the effect shows up, the window manager does not only give focus to another application but even switches to another workspaces (I generally have 4 workspaces configured).

Torsten <ttl>
Project Member
Sat 19 May 2018 08:39:47 AM UTC, comment #9:

OK, fixing that bug clears things up a bit.

It's just the variables windows (which are variable_dock_widget, not octave dock widget) for which this happens. Can you narrow it down further? For example, does this only happen when dragging the variable sub panel to a different location? Only dragging the variable sub-panel outside the Variable Editor? How about if you press the undock button? Pressing the redock button.

My suspicion is that this has to do with the work-around for

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

Recall, the solution for the above is to force any "floated-by-dragging" QDockWidget to redock and undock again directly. I'm wondering if on your system perhaps the focus leaves the Variable Editor in one of those steps based upon the window-manager rules.

Dan Sebald <sebald>
Sat 19 May 2018 08:14:50 AM UTC, comment #8:

Still seeing my window manager sometimes moving to another workspace when rearranging the variable dock widget within the variable editor. This does not happen when rearranging main dock widgets.

Torsten <ttl>
Project Member
Wed 16 May 2018 08:33:54 PM UTC, comment #7:

OK, works here, thanks. Now what is the original bug? I'm rearranging the Main GUI's octave_dock_widgets and the Variable Editor's label_dock_widgets and I don't see anything unusual. (I'm on Mint/Cinnamon.)

Dan Sebald <sebald>
Wed 16 May 2018 07:57:58 PM UTC, comment #6:

The issue with missing highlighting when docking (and sometimes undocking) should be fixed with changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/9b67c2294129

Torsten <ttl>
Project Member
Mon 14 May 2018 09:42:40 AM UTC, comment #5:

@Torsten: The place that the "non-highlight-title-from-window-to-widget" begins with this changeset:

I think the issue is the following:

It could well be that at the moment that make_widget() is called the window/widget is in a transitory state where it isn't visible. I'm not sure. Anyway, it is probably a good idea to fix that issue first, and then address the original bug report.

Dan Sebald <sebald>
Sun 13 May 2018 08:40:40 PM UTC, comment #4:

It's the patch in Bug #53600, but as noted there, that patch doesn't seem to fix the issue described in Comment #3.

Dan Sebald <sebald>
Sun 13 May 2018 07:57:32 PM UTC, comment #3:

Oh, I see. Well, I don't observe that here, but I do notice that rearranging the octave_dock_widgets by mouse drag causes a lot of redrawing as the window dynamically drags into place. That is, there is some flashing of the window title as the window shrinks into place as though focus is bouncing back and forth with each redraw.

What I can say is that if I undock an octave_dock_widget and then redock, the title is not highlighted. One has to click the mouse in a different octave_dock_widget and then click the recently docked widget to get the highlight (focus) back. But wasn't that fixed somewhere recently?

Dan Sebald <sebald>
Sun 13 May 2018 07:26:09 PM UTC, comment #2:

The effect does not happen when un/docking a widget, regardless whether via buttons or via drag & drop. It only happens when changing the location of a docked widget within the main window.

Torsten <ttl>
Project Member
Sun 13 May 2018 07:04:25 PM UTC, comment #1:

This doesn't happen Mint/Cinnamon (related to Ubuntu). My guess would be that this has to do with the code added in

to address that Qt bug, QTBUG-44813. That Qt bug has specifically to do with floating by mouse-drag. What happens if--rather than drag and rearrange--you float a subpanel by clicking the "undock button" in the header and then redock the widget using the same button? Does focus come back to the Variable Editor?

Dan Sebald <sebald>
Sun 13 May 2018 06:02:42 PM UTC, original submission:

This happens on Ubuntu Unity 16.04 LTS: Whenever I rearrange the dock widgets in the variable editor, the window manager switches to another workspace. This happens when the VE is docked and is floating but with different "target workspaces".

Torsten <ttl>
Project Member

 

(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 sebald (Posted a comment)
  • -email is unavailable- added by ttl (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-05-31 ttl StatusNone => Fixed
        Open/ClosedOpen => Closed
    2018-05-27 sebald Attached File- => Added octave-queue_secondary_float_in_unfloat_float_process-djs2018may28.patch, #44233
    2018-05-27 sebald Attached File- => Added octave-queue_secondary_float_in_unfloat_float_process-djs2018may27.patch, #44232
    2018-05-27 sebald Attached File- => Added octave-more_thorough_variable_editor_state_reset-djs2018may27.txt, #44231
    2018-05-27 sebald Attached File- => Added temp_disable_unfloat_float-djs2018may26.diff, #44225
    2018-05-27 sebald Attached File- => Added variable_editor_strangeness_Screenshot_20180526_212035.png, #44224

    Back to the top


    Powered by Savane 3.3