Strange approach to properties

Wilk

Hi all.

I'm working on a small collection of functions that allow to serialize/deserialize Objects in/from XML. And I found out a fact that astonished me a lot: some properties of QWidget are actually not properties, and some of them are kinda useless, 'cause they can only be read.

For example, windowFlags is mentioned as property in docs, however it is not, that can be seen in sources, where windowFlags is declared with QDOC_PROPERTY.

Another example is fullScreen property of the same QWidget class. This property can only be read, but not set.

Thus I can not understand, why all those properties was not implemented as full properties with set and get methods so that it could be used as any other property? I believe that there was some reason for that, however I can not understand it.

Does anyone know that reason?

SGaist

Hi,

Because not all properties makes sense to be read/write. You can have for example a property representing the state of a piece of hardware. The hardware being the controller of the state, it wouldn't make sense for a library user to be able to set that state.

Wilk

@SGaist Well, you are right, not all properties make sense to read and write. But I think, that property like fullScreen is one of those, that one may want to write. Well, I want to write it)

mrjj

@Wilk
well that is what
http://doc.qt.io/qt-5/qwindow.html#setWindowState
is for :)

Wilk

@mrjj, I know about all other ways to make window fullscreen or set another window state. I'm talking about inability to make all those funny things with use of property system. Basically I'm veeery lazy, so I prefer to write a single piece of code that does everything instead of creating different code for handling different approaches to setting window state.

Wilk

For example, if everything is property, I can do the following:

Serialize object state with a single call:

QDomNode serializedObjectProperties = serialize (
	this,
	QObjectSerialization::TAG_OBJECT_NAME);

serializedObjectProperties will be XML DOM element with tag name that's the same as object name stored in objectName property.
2. Save serialized object state in XML file like this:

 <SomeWidget minimumHeight="0" toolTipDuration="-1" modal="false" focus="false" windowOpacity="1" styleSheet="" objectName="SomeWidget" autoFillBackground="true" windowModified="false" maximized="false" toolTip="" inputMethodHints="0" minimumWidth="0" isActiveWindow="false" height="1024" y="51" width="1280" accessibleDescription="" windowTitle="" enabled="true" font="MS Shell Dlg 2,8.25,-1,5,50,0,0,0,0,0" windowModality="0" statusTip="" contextMenuPolicy="1" fullScreen="true" accessibleName="" maximumWidth="16777215" visible="true" x="-1280" updatesEnabled="true" maximumHeight="16777215" mouseTracking="true" layoutDirection="0" windowFilePath="" focusPolicy="0" whatsThis="" acceptDrops="false" windowIconText="" minimized="false">
        <property name="childrenRect">
          <QRect y="0" width="0" x="0" height="0"/>
        </property>
        <property name="geometry">
          <QRect y="51" width="1280" x="-1280" height="1024"/>
        </property>
        <property name="normalGeometry">
          <QRect y="358" width="640" x="-1050" height="480"/>
        </property>
        <property name="frameGeometry">
          <QRect y="51" width="1280" x="-1280" height="1024"/>
        </property>
        <property name="rect">
          <QRect y="0" width="1280" x="0" height="1024"/>
        </property>
      </SomeWidget>

Restore full object state with a single call:

deserialize (
	window,
	serializedObjectProperties);

I find it usefull as soon as I don't need to wary about anything as long as object state if fully described with it's properties.

mrjj

Well, i understand.
show() and hide() are not properties either so
I guess they designed fullscreen to be a case of showíng and
not a property. We are all lazy: )
I just wish c++ had serialization system as default :)

Wilk

@mrjj
With QObject properties serialization becomes realy easy. Well, some things in my implementation may be wrong or, you know, ugly, but for now it works quite fine. I think I'll put it on GitHub as soon as it will be ready enough.

mrjj

@Wilk
sounds cool. other will like to see such library.
Thank you

Wilk

@mrjj
You inspired me so I've commited my work on GitHub. The implementation is not good enough for production, I guess, and it's not packed as appropriate library, but it still may be usefull. As soon as I'll find time for it I'll try to make it a real library.

mrjj

@Wilk
Checked a few files. seems good quality.
Thank you.

Wilk

@mrjj Thanks)