[Interest] Where are the USER properties of Qt-provided QObjects documented?

K. Frank kfrank29.c at gmail.com
Thu Jun 28 17:09:16 CEST 2012


Hi Bo and André!

On Thu, Jun 28, 2012 at 3:41 AM, André Somers <andre at familiesomers.nl> wrote:
> Op 28-6-2012 9:02, Bo Thorsen schreef:
>> Den 28-06-2012 08:55, Andre Somers skrev:
>>> Op 28-6-2012 8:21, Andreas Pakulat schreef:
>>>> Hi,
>>>>
>>>> Am Donnerstag, 28. Juni 2012 schrieb Bo Thorsen :
>>>>
>>>>      Hi Frank,
>>>>
>>>>      Den 28-06-2012 06:40, K. Frank skrev:
>>>>      >  Where in the documentation (not the source code) can I find out
>>>>      which
>>>>      >  of the properties of a standard Qt QObject class is the designated
>>>>      >  USER property?
>>>>
>>>>      You can't find this, and it doesn't matter. You might be able to
>>>>      find it
>>>>      using the QMetaObject introspection, but I guess this is only for
>>>>      designer or something like it. I've never used this property.
>>>> ...
>>>>      What do you need this for?

Well, it's not that important, but here's how the question came about
for me:

I'm using a custom delegate to create and editor for a QTableView.
(See my earlier thread,
http://lists.qt-project.org/pipermail/interest/2012-June/002775.html.)

Editors don't have their own specific interface -- they're just QWidgets.
(QAbstractItemDelegate::QWidget *createEditor (..))

How does the default version of

   void QAbstractItemDelegate::setModelData ( QWidget * editor,
      QAbstractItemModel * model, const QModelIndex & index ) const

know which data in the QWidget is to be copied into the model?  It's
the USER property.

So somebody (like me) who wants to use a QComboBox as the editor
provided by a custom delegate has to experiment (or read the source
code) in order to know whether he needs to override setModelData, as
well as createEditor.

>>>> ...
> ...
> I don't think these flags are implementation
> details that don't need to be documented. The problem with them not
> being documented is, that we also cannot rely on them being stable even
> if we do find out what the flags are.

Yes, I agree with this.

Let's say I use a QComboBox as an editor provided by a custom
delegate (and I don't override setModelData).  Then the data that
gets copied from my QCombox into my model is the QComboBox's
curentIndex (its USER property).  Let's say that this is exactly
what I want.

If we take the attitude that the lack of documentation of which
property is the USER property means that this is not part of the
official public interface of the class and is a mere implementation
detail that can be changed willy-nilly in the future, then a new
version of Qt would be allowed to break my (beautiful) code.

The USER property feels like part of a QObject's public interface
and therefore ought to be documented (and stable).

>> That's why I asked OP what he wanted to use it for, since I think he's
>> going in a wrong direction and there is some other way to achieve
>> whatever it is he is doing.

Well, it may be the wrong direction, but it's the direction that Qt has
elected to go with its delegate / editor framework.

> I do agree that it would be good to get some more insight into what the
> OP wants to achieve.

Well the summary (detailed in my earlier thread, linked to above) is that
I want to use a QComboBox to edit a QString-valued column in a
QTableView.

> ...

It seems that the take-away is that which property is the USER
property isn't documented (in the standard documentation).

Even if the USER property in a less commonly used feature of Qt,
I would argue that it's still part of the public interface of QObject
classes.  (Not in the c++-purist sense of "public interface" since
c++ doesn't have a property system, but still ...)  So it ought to
be specified in the class documentation.

> André

Thanks for everyone's comments.

Cheers to all!


K. Frank



More information about the Interest mailing list