2016-02-08 15:02 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:

2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

2016-02-08 10:37 GMT+01:00 stepharo <stepharo@free.fr>:
Hi guys

I should say that I'm sick (gift from my little boy) so may be this is obvious.

I'm looking at the code of Spec and I hate this code :)

widgetDo: aBlock

�� ^ self widget ifNotNil: aBlock

I do not see why widgetDo: has to test for nil
So I transformed

widgetDo: aBlock

�� ^ self widget ifNotNil: aBlock

into

widgetDo: aBlock

�� ^ aBlock cull: self widget

BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull:
I do not know how many arguments, I do not care I use cull:
cull: is slow slow and help producing messing API.

aBlock value: value: value:��

does not much better than cull:, imho. Usually, the api documentation of the block are just what you'll find in existing code, nothing else.
��

And it broke. The methodBrowser example did not work anymore and many others.
Debugger felt down....
I feel sad. Now my brain is dead so I cannot concentrate more.

Stef

This is a big problem with morphic/spec ui elements. You never know for sure
what code this
self update ---> search through all (dynamicly added) dependents and notify
will finally call.

I don't think there is any way around it. You have to decouple view(s) from model(s), and, hence have those propagation constraints by way of notifications.

Of course, a true alternative would be to use a proper propagation constraint system...
��
In this example we are about to *built* the widgets and in this run , we change a component that
will update all dependents goes back and forth between model, adapter and widget. And all
before the widget is actually accessible for the widgetDo: call.

(and, REALLY we need to clean this up. This is really bad code if we announce a textChanged announcement for
a text component, if we *initialize* an *empty textcomponent* with an *empty text*!).

In short, whatever way you look at it, this initialization difficulty is a hard problem.

Morphic makes it a bit harder than expected because a Morph can be considered as active as soon as it is created, not just when it has been opened in the world.

Here is an example:

|t|
t:=TextModel new.
t text:'hello'.
t openWithSpec.
t hasUnacceptedEdits

it shows that our text has unaccepted edits, although the text did not change. ( and there is actually no text decoration indicating this state).

I tried to follow the trace from #openWithSpec to the call that sets #hasUnacceptedEdits:true.

I don't think this is a problem of "initialization is difficult" but a problem of pluging rubric text components as widgets for spec.

The way spec-models are working and the way rubric works, just don't fit well.

(see issue
16873Adding a new Method marks current entry in SendersOf MessageBrowser as dirty

for another example. The cause is that rubric somehow changes this "hasUnacceptedEdits state" when the text actually *did not change*. And this

again is difficult to trace down. And I don't know how to fix this.

Help appreciate

��

Thierry