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

Samuel Rødal samuel.rodal at digia.com
Mon Oct 22 10:08:14 CEST 2012

On 10/19/2012 10:18 PM, Shawn Rutledge wrote:
> On 19 October 2012 21:56, Oswald Buddenhagen
> <oswald.buddenhagen at digia.com> wrote:
>> On Fri, Oct 19, 2012 at 04:46:01PM +0000, 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.
>> correct. http://doc.qt.digia.com/qq/qq13-apis.html#theartofnaming ,
>> "general naming rules".
>> i don't see why this shouldn't apply equally to qml. if it poses a
>> problem in a particular case, it is most likely indicative of a serious
>> API issue.

What would be indicative of a serious API issue?

I don't really expect QWindow being used in any deep inheritance 
hierarchies the way QWidget is used. Although, if QWindow is exposed to 
QML that does impose some constraints.

> So pos is bad because it's abbreviated.  And I suspect we may have
> problems with renaming windowState to state, because in QML that
> usually refers to the state-machine state (driving animated
> transitions etc.)  Should we be inconsistent and leave that one as
> windowState then?

QCursor, QWidget, QQuickItem, and QGraphicsItem use setPos(), whereas 
QTextCursor and QTextLayout use setPosition(), so we're not entirely 
consistent there.

As for "state", there's no clash in this case since the Window element 
won't be a sub-class of QQuickItem. Although it could still lead to 
confusion, so it might be worth leaving it as "windowState".


More information about the Development mailing list