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