2016-02-08 15:02 GMT+01:00 Thierry Goubier <thierry.goub...@gmail.com>:
> > > 2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: > >> >> >> 2016-02-08 10:37 GMT+01:00 stepharo <steph...@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 > >
