On Monday, October 29, 2012 21:57:40 Marco Martin wrote: > it seems quite sensible, > only thing i would put declared properties immediately after the id:
sounds good; note, however, that pretty much NONE of our QML does this. it's almost always id, anchors/geometry, declared properties. since that's what we've been doing rather consistently, i just kept it that way. i did spend some time considering why this happens ... and here's my guess (though it is only that): one tends to start with and also change most frequently the geometry properties (anchors, widths/heights, spacing, margins) and so those "naturally" got promoted to the top. they are also some of the most common things to find in items, so "id => geometry" is just a very common pattern. i'm ok either way, but declared properties before geometry properties means we need to alter nearly every single QML file to meet that guideline. > usually i tend to put onFooChanged immediately after the declaration of foo, > has advantages and disadvantages, but i guess is mostly gettig used to tbh, this is one habit that really bugs me. due to the mix of property definitions and blocks of code, it's very hard to get an overview of what the properties actually are. worst of all, it ends up encouraging the mix of other elements referenced by these onFoo methods in there too. running across a Timer definition mixed in with properties QML is not entirely uncommon, and i think it is probably due to this. so i'd really like to vote against mixing onFooChanged with property declaration and setting :) -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
