QML style guide

[Dmitry Ashkadov]

30.10.2012 13:15, Aaron J. Seigo пишет:
> On Tuesday, October 30, 2012 12:25:14 Dmitry Ashkadov wrote:
>> First of all, it a good idea!
> :)
>
>> 1. I think you should explain why you have chosen  such style instead of
>> another one. Your decision should be justified.
> this is the death of style guides. for many style decisions there is no
> justification that can be made; it is simply a matter of custom and personal
> taste. tabs vs spaces is the classic example.
I think you are wrong. Any decision has its justification. Fox example, 
if you use spaces it may be due to old code.

>
>> Some JS can be an adjunct to QML file and cannot be used
>> outside of this QML file. Such JS can provide stuff for only one QML. To
> should each QML file go into its own directory?
>
> contents/main/main.qml
> contents/main/main.js
> contents/itemdelegate/delegate.qml
> contents/itemdelegate/delegate.js
No, no, no.

contents/ui/main.qml
contents/ui/main.js
contents/ui/delegate.qml
contents/ui/delegate.js
contents/code/statelesslib.js

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


>> 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?

>> 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 
in separate file). It may be used from many QML files. Such item must 
never set its geometry but very often such it declares its own 
properties. And these public properties should, I think, go after id 
property immediately, then should be declared public functions, signals 
and then its implementation: subitems, states, etc.


2. Some item is an implementation of parent item (it usually should be 
in the same QML file). In this case geometry properties usually defined 
and there should be no declaration of properties (may be exceptions)

For example:

Button.qml: // separate component, use case: developer who want use 
Button searches public interface (properties, functions, signals)

Button {
     property string text

     function setText()
     {
     }

     signal ...

     // usually geometry properties isn't defined
     // but if it's really need they are part of implementation of 
button and should be defined here
}


main.qml:

Item {
     // Button is used for implementation, use case: developer tries to 
understand implementation of parent item
     Button {
         anchors.fill: parent
         text: "blablabla"

         // property bool state // this property should not be declared, 
it should be declared in Button.qml
     }
}