[Top][All Lists]

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

[Octave-bug-tracker] [bug #53537] main_window::focus_changed() routine s

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53537] main_window::focus_changed() routine should be improved
Date: Tue, 3 Apr 2018 02:18:14 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0

Follow-up Comment #7, bug #53537 (project octave):

@Torsten:  What are your thoughts on the following test in focus_changed()?

  // catch focus changes and determine the active dock widget
  void main_window::focus_changed (QWidget *, QWidget *new_widget)
    // If there is no new widget (e.g., when pressing <alt> and the global
    // menu gets active, we can return immediately
    if (! new_widget)

I'm looking at the drag-and-drop outside the main window and why that isn't
always creating a top-level window.  (Recall, the drag and drop is where the
newly-floated window can't immediately be turned to a top-level window while
dragging.  Otherwise there is a seg fault.)  This is the one thing in Bug
#53276 patch that doesn't seem to work consistently now.

I've found that when I let go of the mouse, focus_changed() does in fact get
called, but sometimes the new_widget argument is nullptr because there is
nothing on the dropped window to be focused.  Stated differently, the
currently focused widget loses focus, but there is nothing to acquire the new
focus.  This explains the rare and seemingly random behavior of sometimes a
dragged, floated window doesn't become toplevel.

Does it seem that restriction should be dropped and the routine always
continue on so that the currently in-focus octave_dock_widget can be
un-highlighted because it lost focus even if there is no new focused widget?

There is another approach that I can take in Bug #53276 which is to
temporarily install an event filter that will recognize a *mouse-release*
event and then convert the window to a toplevel.  Then once it is toplevel,
change the event filter back to the previous filter.  That way we wouldn't be
relying on focus change to initiate that toplevel conversion.  Instead, we
know there has to be a button release if the window is in drag state.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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