[Top][All Lists]

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

[Octave-bug-tracker] [bug #53443] Compile warning when casting QVariant

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53443] Compile warning when casting QVariant to (QWidget *)
Date: Mon, 9 Apr 2018 13:40:27 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #21, bug #53443 (project octave):

The tbar->tabData(i) format is set internally by Qt.  We have no control of
that.  I don't think Qt developers intended for there to be a programmatic set
of an index on a QMainWindow.  It would all be user-driven by clicking the
mouse on a tab, etc.  And the reason is probably because these QDockWidget
objects don't get deleted by the absence of a QTabWidget; the just get
shuffled around in terms of tabbed in a group or not tabbed in a group.  In
other words, it doesn't make sense for QMainWindow to be creating and deleting
QTabWidgets, just the tab bars because the QTabBar isn't a container class.

I've dumped the QMetaObject names of everything that is in the main GUI
window.  It is a long list, but I don't see any QTabWidget object that
corresponds to the QMainWindow-created tabs in the various areas.  (If that
were the case, *then* we could use a class that does have several functions
for identifying the widgets in the container class and select the index.  That
would be easy...but that's not the case.)  Qt must have programmed it's
QMainWindow so that it is merely using QTabBars and essentially replicates
what QTabWidget class does.  There are probably signals/slots connections
between the QTabBars--program flow we aren't privy to.

So, it seems to me the only location the information is accessible is that
tbar->tabData(i).  I thought I had a good lead on a solution, which is this
routine from the documentation:


"Returns the accessibleName of the tab at position index, or an empty string
if index is out of range."

A widget has an accessibleName:


That way, I thought we could compare the accessibleTabName list against the
accessibleName of "this" and avoid all the pointer stuff.  But the compiler
keeps telling me that accessibleTabName() is not a function of QTabBar...plus
accessibleName() returns an empty string.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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