[Development] renaming all QWindow properties that have "window" in them

[Samuel Rødal]

On 10/19/2012 06:46 PM, Rutledge Shawn wrote:
> QWindow has properties like windowTitle, windowIcon, windowModality, windowState and so on, which are named that way to be familiar to users of QWidget.  However it causes some silliness in Qt Quick: QQuickWindow inherits QWindow, and that means it inherits those properties too (even though they have not yet been documented).  But we would like the QML API for Window to be more typical, e.g.
>
> Window {
> 	title: "the title"
> 	modality: Qt.ApplicationModal
> }
>
> QQuickWindow could of course add the extra properties, but then you would be able to access either one, because I don't know of a way to hide an inherited property.  Furthermore because inherited signals don't work in Q_PROPERTY declarations, it's not enough to just add
>
> Q_PROPERTY(Qt::WindowModality modality READ windowModality WRITE setWindowModality NOTIFY windowModalityChanged)
>
> in order to reuse the accessors and just rename the property.  There must be a new signal in the subclass too.  So then I have to add a setter to emit the signal when the property changes.  This is why it's easier to rename them in QWindow; and really the naming was redundant anyway.  If you have a QWidget, you need to be clear what kind of title is being set, because there can be an implied window; but if you have a QWindow it's already clear.
>
> So that change resulted in the following patches so far:
>
> https://codereview.qt-project.org/#change,37763
> https://codereview.qt-project.org/#change,37764
> https://codereview.qt-project.org/#change,37765
> https://codereview.qt-project.org/#change,37766
> https://codereview.qt-project.org/#change,37762
>
> and I have one for Webkit as well.  I just wondered if there are any objections before we proceed with testing and trying to integrate this, or if anyone sees something that I missed.  I will be doing further testing to make sure we get the desired result in Qt Quick.

Agreed, this makes sense from the C++ API side as well, 
window->setModality() is nicer API-wise than 
window->setWindowModality(). It's less redundant and also more 
consistent, since we don't do window->setWindowPos() to set the position 
of the window for example.

Are people in general ok with fixing API warts in new APIs like these 
while we still have the chance?

--
Samuel