--===============3057050140417851176== Content-Type: multipart/alternative; boundary="===============3415025569892003792==" --===============3415025569892003792== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Aug. 12, 2012, 10:41 a.m., Christoph Feck wrote: > > As I understand it, the notify system is for attributes, where the obje= ct changes the value _itself_ (e.g. in response to user interaction), as op= posed to where the application changed the value. > > = > > In that light, an imagePathChanged() would not make sense, because the = path cannot change, except if the application changes it. > > = > > What am I missing? > = > Marco Martin wrote: > the notify signal, should be for all properties that can change run t= ime, no matter who is changing it (and of course the object itself is able = to know in any way when the property changes to be able to reliably signal = it). > = > the use case is property binding: if you have many classes that are b= inded to a property, you want all of them immediately automatically updated= with the new property value. > = > an example that doesn't necessary make sense per se but exemplifies, = 3 instances of Text {text: framesvgItem.imagePath} should always have the"r= ight" text Erm, what I actually had been missing is the fact, that this commit is for = QML bindings, not for the actual FrameSvg class in kdelibs/plasma... Sorry = for the noise. - Christoph ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105987/#review17265 ----------------------------------------------------------- On Aug. 11, 2012, 10:39 p.m., Luis Gabriel Lima wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105987/ > ----------------------------------------------------------- > = > (Updated Aug. 11, 2012, 10:39 p.m.) > = > = > Review request for Plasma and Marco Martin. > = > = > Description > ------- > = > When we are using a QML element, we should be able to keep track of its p= roperty changes. > = > = > Diffs > ----- > = > plasma/declarativeimports/core/framesvgitem.h 7baf0cf = > plasma/declarativeimports/core/framesvgitem.cpp 02c9d19 = > = > Diff: http://git.reviewboard.kde.org/r/105987/diff/ > = > = > Testing > ------- > = > = > Thanks, > = > Luis Gabriel Lima > = > --===============3415025569892003792== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/105987/ |
On August 12th, 2012, 10:41 a.m., Christoph= Feck wrote:
As I unde= rstand it, the notify system is for attributes, where the object changes th= e value _itself_ (e.g. in response to user interaction), as opposed to wher= e the application changed the value. In that light, an imagePathChanged() would not make sense, because the path= cannot change, except if the application changes it. What am I missing?On August 12th, 2012, 10:58 a.m., Marco Martin wrote:
the notif= y signal, should be for all properties that can change run time, no matter = who is changing it (and of course the object itself is able to know in any = way when the property changes to be able to reliably signal it). the use case is property binding: if you have many classes that are binded = to a property, you want all of them immediately automatically updated with = the new property value. an example that doesn't necessary make sense per se but exemplifies, 3 = instances of Text {text: framesvgItem.imagePath} should always have the&quo= t;right" text
Erm, what I= actually had been missing is the fact, that this commit is for QML binding= s, not for the actual FrameSvg class in kdelibs/plasma... Sorry for the noi= se.
- Christoph
On August 11th, 2012, 10:39 p.m., Luis Gabriel Lima wrote:
Review request for Plasma and Marco Martin.
By Luis Gabriel Lima.
Updated Aug. 11, 2012, 10:39 p.m. Descripti= on
Diffs=
|