call for cleaning ideas around Spec

Hi guys


this afternoon we will have a meeting with Peter and others to talk
about cleaning Spec API.

If you want/can join let us know

else we can organise another skype.

if you have ideas let us know too.

Stef

We are thinking that we would like to rename ComposableModel into Presenter

to convey its role into the MVC triad.

What do the spec users think?

Stef


Le 4/5/16 à 08:19, stepharo a écrit :

On 04/05/16 15:24, stepharo wrote:
> We are thinking that we would like to rename ComposableModel into Presenter
>
> to convey its role into the MVC triad.
>
> What do the spec users think?

There are too many Models. A clear distinction between DomainModel
and ViewModel is needed. Please explain when a ViewController should
be a Presenter. Where is the boundary between MVC and MVP?

Stephan

On 04/05/16 13:43, Peter Uhnák wrote:
>>
>> by a factor of at least 2,5x compared to pure Morphic (I've seen a 5x).
>>
>
> This doesn't mean anything. Can you please provide concrete numbers (what
> you experience) and what is your expected target? Because I do not have
> such problematic experience.

Thierry develops on a machine that is somewhat slower than those most
Pharo users develop on: a Celeron 2955U machine. For Pharo I'd hope to
be able to reasonably do development on a Raspberry Pi2.

He is very aware of Morphic performance issues, so that factor 2.5 is
not the layout processing, as that is the same for Morphic and Spec.

We could add some Spec performance tests to jenkins/travis to see when
we have regressions.

Stephan

On 04/05/16 08:19, stepharo wrote:
> Hi guys
>
>
> this afternoon we will have a meeting with Peter and others to talk
> about cleaning Spec API.

In AbstractWidgetModel we have
dragEnabled dropEnabled dragTransformationBlock wantDropBlock
acceptDropBlock transferBlock

That needs to be one instance variable dealing with drag and drop.

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.

ComposableModel: keyStrokesForNextFocusHolder
keyStrokesForPreviousFocusHolder I'm pretty sure I do not want
focus switch to be an individual widget concern

Stephan

On 04/05/16 16:10, Denis Kudriashov wrote:
I know. But that is not what Spec does.

Stephan

First we should clean it, then we speed it up.


Stef


Le 4/5/16 à 15:45, Stephan Eggermont a écrit :

I would rename composableModel into Presenters.

Stef


Le 4/5/16 à 16:58, Stephan Eggermont a écrit :

***Thanks*** Stephan

this is the kind of things we should start fixing!!!

I want more :).

Can you open bug entries with such points?


Stef


Le 4/5/16 à 16:03, 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?

Stephan

stepharo wrote

cleaning Spec API.

+10 !
just general remarks i have about Spec:

I think the role of Spec may be clarified.
If Spec is just an UI builder we may remove the "overengineering" and we need another framework that provides someting like MVC, MVP, MVVM or ...
If Spec intent to be an "app" framework, it is too confused now, and yes, it needs a clear separation between the presentation, the presentation logic, the domain logic, ...

Maybe, extending the SpecLayout's responsibility should be one idea to handle the full "presentation" part, like the role played by markup languages.
I'm not saying I want to transform Spec to XML :), but its role is basically the same.
The existing separation between the widget declarations (instance side) and the widgets composition (class side) seem confusing to me.

And we need also a clearest way to bind domain models to widgets.
Using #whenSomethingChangedDo:aBlock everywhere make code a bit hard to read and to debug, if not completly ugly in complex UI...

For me, the first goal of an UIBuilder (graphical or programmatic) is to ease the presentation and to ease the two-way data-binding with domain data/logic.
If the ease-of-use of Spec is not more obvious compared to the underlying widget libraries (Morph / Bloc soon maybe...), it will be difficult to convince people to use it in future developments...

But it is maybe a bit off topic -> "cleaning Spec API".

Cheers,
Glenn.

On 04/05/16 08:19, stepharo wrote:
> if you have ideas let us know too.

Why does every NewValueHolder have its own announcer?
And is initializing all those unused valueHolders in initialize
of Spec presentation classes not slow?

Stephan

On 05/05/16 00:15, Stephan Eggermont wrote:
 > On 04/05/16 08:19, stepharo wrote:
 >> if you have ideas let us know too.
 >
 > Why does every NewValueHolder have its own announcer?
 > And is initializing all those unused valueHolders in initialize
 > of Spec presentation classes not slow?

Just a 50721 image I'm working in on SpecGenerator with 20 open windows:

NewValueHolder allInstances size
4872

(NewValueHolder allInstances select: [ :each | (each instVarNamed:
#announcer) numberOfSubscriptions = 0 ])size
2566