[Octave-bug-tracker] [bug #53046] Variable Editor: feature request to make multiple tables visible at once.

[Dan Sebald]

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

OK... :-)

Attached is a patch to use a QMainWindow model for the variable editor. 
Shrinking down the central widget to nothing makes for a very versatile
collection of panels with the look-and-feel of the main GUI window and all the
similar features.

Not too much description required--lots of diff hunks the bulk of which is
moving things around--but I'll add a follow up list of comments.  Aside from
lengthy debugging and finding an ancillary-related crash bug that I thought
was part of what I was changing:

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

the big snag here was the tool-bar stealing active window and focus when it
came time to doing an action.  I first looked for a way to have QToolButtons
not change active window, but I just don't think Qt can control that.  In
order for a button to activate and receive events, the underlying window
system has to make it's window active.  So, then I tried ways to get around
that and return focus to the variable widget that had focus when the buttons
were hovered.  Half of that was no trouble, but restoring focus just before
the action was tricky.  In principle, it's easy with simple child objects

HoverToolButton (derived from QToolButton)
ReturnFocusToolButton (derived form HoverTOolButton)
ReturnFocusMenu (derived from QMenu)

and eventFilters with a few conditionals.  The problem is that the telling
widget to activateWindow() isn't something synchronous with Qt's signal/slot
or event system.  Checking the active window and focus object immediately
after that call doesn't indicate the object that was just activated.  So, that
was a bit of a race.  However, I think I finally found a useful function at
the QApplication level.  A comment in the code explains it:


  variable_dock_widget *tofocus = findChild<variable_dock_widget >
(m_hovered_focus_vname);
  if (tofocus != nullptr)
     {
      // Note that this may be platform and window system dependent.
      // On a particular Linux system, activateWindow() alone didn't
      // immediately set the active window and there was a race
      // between the window focus and action signal.  Setting the
      // active window via the QApplication route did work.
      QApplication::setActiveWindow(tofocus->window());
      tofocus->activateWindow ();
      tofocus->setFocus (Qt::OtherFocusReason);
     }


If this shows signs of trouble on some OS's then there is a simply solution
which is to add the QString name of the variable to the broadcast rather than
check focus.  But I didn't want to go to that immediately and pass extra data
around until necessary.  I'd rather simulate the appearance that focus hasn't
changed when pressing a tool button...and if there is someone who has a better
idea of how to do this more directly or with event filtering at the toplevel
window (I attempted this a bit to no avail), I'm open to that.  Like I said,
though, I think the windowing system sort of governs the possible options.

(file #43286)
    _______________________________________________________

Additional Item Attachment:

File name: octave-multipanel_variable_editor-djs2018feb13.patch Size:92 KB


    _______________________________________________________

Reply to this item at:

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

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