call for cleaning ideas around Spec

On 05/05/16 00:23, Stephan Eggermont wrote:
Announcers are not designed to handle 0 or 1 subscriptions.
If we want that, we need to fix them

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?

Talking to Latsabben on Slack, first step:

Name:
SLICE-Issue-18167-NewValueHolder-classvalue-should-use-rawValue-StephanEggermont.1
Author: StephanEggermont
Time: 5 May 2016, 11:55:36.083109 am
UUID: d89767d0-5d9d-40b8-ad67-5887b22a338f
Ancestors:
Dependencies: NewValueHolder-StephanEggermont.34

Do not send announcements when you know there can't be any subscriptions

Le 04/05/2016 19:18, Stephan Eggermont a écrit :
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
>
>
>

With Peter we cleaned some subscription for enabled that were register
twice.

https://pharo.fogbugz.com/f/cases/18175/Cleaned-up-code-duplication-in-initialization


Stef and Peter



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

Le 4/5/16 à 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

We were looking and I proposed to

AbstractWidgetModel
     ButtonModel
     CheckboxModel
     DragDropModel
         TabModel
         TreeModel
         ListModel
>
> 18165 ComposableModel: aboutText seems to be in the wrong place

peter check and this is ok because like that a composable model can do
the same as for title
just declare aboutText and the window grab it.
>
> 18166 Where should focus change keystrokes be handled?
>
> Stephan
>
>
>

Le 4/5/16 à 21:26, Glenn Cavarlé a écrit :
> stepharo wrote
>> cleaning Spec API.
> +10 !
> just general remarks i have about Spec:
Glenn send code :)
>
> 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, ...
It is the second Spec should be like MVP


> Maybe, extending the SpecLayout's responsibility should be one idea to
> handle the full "presentation" part, like the role played by markup
> languages.

Yes this is one idea
> I'm not saying I want to transform Spec to XML :), but its role is basically
> the same.

Indeed
> The existing separation between the widget declarations (instance side) and
> the widgets composition (class side) seem confusing to me.

Totally.
If you look in Deprecator (sorry bad name)
you will see a new ButtonPresenter API and tests
We moved all the Model adaption code into the Adapter. The goal is to
remove
the Adapter at runtime but for now we need better widgets.
> 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...
Yes but we also need much better widgets. Because they need to

     - accept blocks or provide correct APIs to be able to refresh
     - for example we got problem because we want to be able to open a
button then change its label and the label
     should reflected.

>
> 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...
Reuse of interaction.
>
> But it is maybe a bit off topic -> "cleaning Spec API".
Let us start by the beginning

Le 5/5/16 à 00:15, Stephan Eggermont a écrit :
> 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?
I will let peter explained.
We did an experience by trying to remove the valueHolder is
ButtonPresenter but it led to refresh problem
when we want to update the widget. Because when you change the label of
your model you want that the widget
get notified and (without ghving the adapter at runtime in the middle).
But the state of PluggableButtonMorph
is too bad to express that the way we want.

Stef

>
> Stephan
>
>
>
>

Hi stefan

Should we apply that for all the announcements?
Do you write tests for this?
Stef

On 07-05-16 22:04, Peter Uhnák wrote:
> We question whether this belongs to AbstractWidgetModel, as only  > three (TreeModel, ListModel, and TabModel (iirc)) benefit from it in
 > any way.

ContainerModel, DropListModel, ImageModel, LabelModel, MenuModel,
TextModel and WindowModel.

So no.

> for example keep the messages, but delegate the behavior.

That is what I was thinking about. As soon as you define drag or drop
behavior, instantiate a DragDropSpec.

> 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).

Where would you like to define application style default overrides
then? People ask about this all the time, and the reason it's used so
little is because our implementation in the widgets is so bad:
very inconsistent naming and default styles ignoring overridden values

Stephan

On 08-05-16 10:01, stepharo wrote:
> Should we apply that for all the announcements?
> Do you write tests for this?
We should be very clear about when we're setting things up,
and when we expect announcements to start being sent.

The NewValueHolder class method should be safe.

Stephan

On 08-05-16 09:59, stepharo wrote:
> > We did an experience by trying to remove the valueHolder is >
ButtonPresenter but it led to refresh problem when we want to update >
the widget.

If we want to have such fine-grained change propagation with a
NewValueHolder for each widgetproperty, we need a much more lightweight
announcement proces.
NewValueHolder initializes a boolean lock and an Announcer. The
announcer initializes a SubscriptionRegistry. The subscriptionregistry
initializes a Semaphore and an IdentitySet. An identityset initializes
with a tally and a size of 5. If we know most valueholders never need to
propagate a change, and most of the others only to one subscriber,  we
should introduce some null/one objects.

Alternatively, we could propagate change at the widget level instead of
the property.

Stephan

On 08-05-16 17:13, Peter Uhnák wrote:
> Can you give me an example of how would you use it with LabelModel?

Not a good one.

I've seen it used as a droptarget for a directory,
where the corresponding textfield provided the file name.

Stephan

On 08-05-16 17:19, Peter Uhnák wrote:
> We should have metrics for this… otherwise seeing what's the actual
> impact is a guesswork.
> Most ValueHolders will have at least (and usually) one subscriber —
> the adapter
Most have 0

1741 NewValueHolders, 911 with 0, 801 with 1

NewValueHolder allInstances select: [ :each | (each instVarNamed:
#announcer) numberOfSubscriptions = 1 ]

Stephan

On 08-05-16 18:34, Peter Uhnák wrote:
> If the difference is 10% maybe the word "most" isn't appropriate, but
> you are looking at system, not Spec.

There is exactly one user of NewValueHolder outside Spec
> Most widgets will instantiate the value holder and then immediately
> subscribe to it (either directly in #initialize, or in
> #registerEvents), at least for ValueHolders that propagate changes to
> Morphic.
Most properties in a user interface are optional. We need to design for that
> Regardless of that I said _will_, because that's the idea behind the
> new Adapters, currently in the image only TabModel/MorphicTabAdapter
> use it.
What is the impact of that on debugability?

Stephan