nfiedler (N)
antony (A)
joellam (JL)
jtulach (JT)
david kaspar (DK)
milos kleint (MK)


JT: Let's go thru open questions
DK: rename of a method - let's introduce new method and leave there the old one
MK: I want to deprecate the method and remove it for 6.0
JT: general question of backward compatibility
DK: there was release551 branch and I tried to make it compatible
N: enterprise pack will work only with release551, not with 6.0, we can change the code
DK: I want to keep the library stable, but I will do the last incompatible renames now

A: Issue about documentation changes
DK: I have added new docs
A: Ok.

JL: Adding support for ActionMap 
DK: The library does not support it at all
JL: I want to assign ActionMap to Widget, 
DK: ActionMap is unsorted
JL: We already have action and we need to rewrite them for widgets
MK: need conversion javax.swing.Action <-> Widget actions
DK: If you have patch then ok.
JT: Can we leave it for future? If possible to add it in future let's leave it for future. Now you have 5min to discuss with Joel.
JL: Convertor is ok, probably. 
DK: Factory method that takes an ActionMap and creates Widget action, 
MK: Oposite. 
JL: But I'd like to have the first. ActionMap is standard. 
DK: wraper around ActionMap to create Widget action, keypress and popup menu creation (TCR)
MK: in swing the actions are processed from inside out, but in the library this is different,
    scene is asked first, widgets later, not documented
DK: scene delegates to children.
MK: Should be documented.


DK: Some of the examples could be moved to automated tests
JT: Yes, please.

JT: Y09 - Move to non-public package

JT: Y10 - VMD - separate package?
JL: I am using this package.
DK: There could be additional module for VMD package. You would need to add dependency.
JL: Maybe rename VMD. 
JT: Invent acronym, keep the package name and classes untouched for sake of backward compatibility
MK: change javadoc to not say "VMD plugin" - if we keep the vmd in name, invent acronym.
MK: who decides how it is going to look? mobility, that would not be really compatible.
DK: if there are new looks, I always keep backward compatibility and add an option.
JL: let mobility modify behaviour of these settings
JL: we would like more things public, non-final, etc.
DK: that makes maintainance hard when evolving the API, this way I am sure that nobody can override these methods
DK: propose some API changes, I can make changes, but then I will be ready for them
JL: How we will find out that mobility is making a change in its look and feel
DK: In future there will be UI changes, will be announced on mailing list user@graph.netbeans.org
JT: use API_REVIEW_FAST, you'll get api-changes@netbeans.org
DK: Ok.
JL: Will U use UI review?
DK: Yes, in future. 
MK: With VMD: keep status quo, improve javadoc

JL(all): Great use of the library 2.0!, excellent job, David.


Accepted with TCR, integrate for M8.