Hi, 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 On Thu, May 5, 2016 at 1:18 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 04/05/2016 19:18, Stephan Eggermont a écrit :
On 04/05/16 18:18, stepharo wrote:
Can you open bug entries with such points?
18164 Put drag-and-drop behaviour in one object
18165 ComposableModel: aboutText seems to be in the wrong place
18166 Where should focus change keystrokes be handled?
For this one there was an debate about the following point: why Spec needs to reimplement the focus change keystroke implemented by Morphic?
Thierry
Stephan
