QML style guide

[Aaron J. Seigo]

On Tuesday, October 30, 2012 14:14:05 Dmitry Ashkadov wrote:
> 30.10.2012 13:15, Aaron J. Seigo пишет:
> > On Tuesday, October 30, 2012 12:25:14 Dmitry Ashkadov wrote:

> We see that main.qml and main.js, delegate.qml and delegate.js may be
> considered in pairs. main.qml cannot exist without main.js. At the same
> time there is  statelesslib.js that may be shared between main.qml and
> delegate.qml

these are unimportant distinctions. when i see a .js file included, i want to 
be able to know exactly where it is without having to go through a heuristic:

* is it only used in this qml file?
* is it named the same as this qml file?
* is it generic / stateless?

all i want to be able to do is see a .js include and know instantly that it 
will be in code/

and my point about plasmate still stands, btw.

> >> 5. Vim:
> >>> The {{{ and }}} are just for the sakes of vim's automatic folding.
> >> 
> >> Do we all use vim? I think no. So, we must never force developers use
> >> vim.
> > 
> > i mostly agree :) i don't think this forces anyone to use vim, but i would
> > like to see a solution that works with katepart before adding it to the
> > style guide.
> 
> Do you want force developers use kate?

of course not :)

but i'd like to make the lives of people who use kate, vim, etc. easier if 
possible. if we have to chose between "no one benefits from code folding" or 
"some people get to benefit", we should pick "some people" every single time. 
"some" is better than "none". 

this does not prevent you from using any editor you wish -> you might not get 
the cute little bonus of code folding, but otherwise it's the same as it is 
right now already.

> >> 6.
> >> 
> >>> 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.
> >> 
> >> Let them be unchanged until somebody want to do it. Old code will always
> >> stop you to make new code better. Refuse new code made in old style.
> > 
> > so your vote is to live with it being inconsistent for now, and in new
> > code
> > put geometry properties with the other inhereted properties, correct?
> 
> Current code may be unchanged for now.
> 
> I see 2 branches:
> 
> 1. Developer can implement some item as a separate component (it must be
...
> 2. Some item is an implementation of parent item (it usually should be

this has nothing to do with parent-vs-child geometry setting. rather, when 
geometry properties are set, where do they appear in that block? what you are 
discussing is a separate topic, one that should go into a "best practices" 
section (and i agree with you that setting it in the parent is usually better 
than in the child)

what we're discussing is:

Item {
    id: foo
    anchors.fill: parent
    signal foo
    property bar: true
    inheritedProperty: false
}

vs

Item {
    id: foo
    signal foo
    property bar: true
    anchors.fill: parent
    inheritedProperty: false
}

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121030/dfb8a133/attachment-0001.sig>