I´m not sure understand good all message, Stephane. I believe the integration is easy from CLFramework to Pharo and reverse and really don´t need changes:
The mechanism than widgets launch events is the same of system, the trigger mechanism. I only encapsulate that basic functionality on a TCLPublishEvents trait, for send rich event arguments in some cases, and force the handler of event is always of two parameters, the sender of event and the information of event, but the functionality for launch the events is the same of system. In some types of control usability I implemented news widgets: listview, button, treeview, statusbar, grid, splitterpanel and tablepanel. The others widgets be Polymorphs sons. Really a widget in CLFramework is a normal morph implementing the trait TCLControl, for only basic properties (#location, #style ,#tabIndex, #text ..... ). Exists others traits: TCLCollectionControl for list type widgets, TCLContainerControl for panels, TCLObservableCollectionListener for controls than need listen a ObservableCollection instance etc The reason of that news widgets is the velocity, clean methods interface and inexistence like basic and huge needed grid. Really Pharo has been repeat updated and I didn´t have problems. I believe than unique dependence of Pharo is Polymorph. The unique problem I have in last step is the imposibility of save on a external file the preferences. In Pharo 1.1 that works. I did use that functionality for my Deployment tool mechanism. Clean the system and remove useless code from system is a great idea, but in GUI I believe Pharo needs some enhancements: ·Another more fast way for render the morphs, the GUI still slow compared another languages. ·Posibility of open independent windows (integrate ffenestri on Core??). ·Embed a pharo world on a browser for have the same application on the desktop or the web, ala Silverlight (something I did see lasts days). ·Basic widgets like a good and fast grid (not like my shit grid) for upset, group, filter and edit data. I believe the difference in some cases for create enterprise applications or not create will be widgets like that. ·Bindings implementation on widgets ala WPF/XAML. The link of widget value and data model must be with bindings mechanism, not with simple events. ·A GUI designer. I believe the Morphic designer is the good way. I wait understood the question. Regards. -- View this message in context: http://forum.world.st/Binding-data-to-controls-widgets-in-CLFramework-tp3337252p3337451.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
