today with Stef we spent some time going through Spec.
But first to address some points
In AbstractWidgetModel we have
dragEnabled dropEnabled dragTransformationBlock wantDropBlock acceptDropBlock transferBlock��
That needs to be one instance variable dealing with drag and drop.
We question whether this belongs to AbstractWidgetModel, as only three (TreeModel, ListModel, and TabModel (iirc)) benefit from it in any way.
One option would be to have an intermediate subclass so we can move at least some of it, like this
�����
As for separating into a separate instance variable��� I agree from design perspective��� however
having directly available methods is very user-friendly when you are configuring it, because you can use a cascade.
^ TreeModel new
roots: #(a b c d);
childrenBlock: [:it | it = #c��
ifTrue: [ {1. 2. 3} ]
ifFalse: [ {} ]];
dragEnabled: true;
dropEnabled: true.
Which is quite nice.
Without it you would have to do
(tm := TreeModel new)
roots :#(..);
childrenBlock: [ :it | ... ].
tm dragAndDrop dragEnabled: true.
tm dragAndDrop dropEnabled: true.
There are different ways how to have it separate and provide and nice-ish API, for example keep the messages, but delegate the behavior.
Or provide a configuration block. This is for example used when you are configuring a MenuModel/MenuGroup/MenuItem.
^ TreeModel new
roots: #(...);
childrenBlock: [ :it | ... ];
dragAndDrop: [ :dnd |
dnd
dragEnabled: true;
dropEnabled: true
]
The same questions also applies to Styles (color, borderColor, borderWidth). Which I would prefer to remove altogether (it's not really used, and I question whether whether it even belongs to Spec side).
If we want to keep it, then separating it would be a nice idea (I've started, slice in Pharo60Inbox)
ComposableModel: aboutText seems to be in the wrong place.
That is a WindowModel property, and we seem to need some kind of
mechanism to propagate property access in the widget hierarchy.
I though so too at first, however this is very same as #title. In fact having directly in ComposableModel is very convenient.
MyFormEditor>>title
^ 'Form Editor'
MyFormEditor>>aboutText
^ 'Neither #aboutText, nor #title is actually used by MyFormEditor, but by WindowModel, but it makes for nicer API'
ComposableModel: keyStrokesForNextFocusHolder keyStrokesForPreviousFocusHolder I'm pretty sure I do not want
focus switch to be an individual widget concern
Take a look at http://smalltalkhub.com/#!/~StephaneDucasse/Deprecator
We started cleaning up the API a bit. The idea is to start from Spec side, figure out what we need and then adapt adaptor��� and not try to reimplement Morphic.
Right now only ButtonModel (ButtonPresenter) is done, but without shortcuts. We would like to introduce some common/uniform behavior for this instead of each Widget redoing it in a chaos.
And some more cleanup sits in Pharo60Inbox...
Peter