[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".
--
Samuel
More information about the Development
mailing list