[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pmf-dev] [Wazaabi] Introduce dataObject attribute
2010/4/28 Hallvard Trætteberg <hal@xxxxxxxxxxx>
On 28.04.10 14.36, Olivier Moïses wrote:
'fetchValue' is not longer used, it has been replaced by a merge with
the previous getValue (which is called now 'get'). I tried to respect E4
context method signature. Tracking changes in above widgets was a case I
did not think about. that's a good point.
My version is from the PMF site. How recent is this change?
You should get the latest version from CVS (sorry, the p2 site is not
available yet :-( )
Don't know exactly, but probably more than one week. Another point, as far I understood, the public CVS is a mirror of the one I commit on, then usually, there is until 24 hours (not sure) of difference.
It would be nice to have a general way of distributing changes to a hierarchy. Sometimes you want to listen to a certain change within a subtree, sometimes you want to listen to certain changes above a subtree, etc. Perhaps it's possible to use a single EContentAdapter as an event bus and support filtering and distributing events from it?
When using the EMap, the metamodel is the same. It's only the instance class of the ContextContent that identifies it as an EMap instead of a plain Elist.
Yes it is an option, but a collection of ContextContent is an
information easily understandable to who will read the metamodel.
Yes, you're right
Or "dispose"? Perhaps names that indicate that they are a pair is better, e.g. activate/deactivate?
So to an event handler, this event will "look like" a normal UI
event (generated by the user). Sounds like a nice place to hook in
Yes, I am thinking about a 'close' like event too.
Yes, but refresh is common to every platform while dispose means deletion of platform part in SWT and nothing in Swing :-D.
Activate/deactivate are reserved in SWT and the name resolution is based on reflection.
After the previous discussion, I will probably propose an uniform naming convention like for instance: "ui:onMouse" or "swt:onMouse" or even 'urn:ui:onMouse'. If I merge property change and event, I ll need to distinguish UI events and properties (@name, $library, &books, etc...)