Hi,
Why is that an issue in Rubric?
Because I can reproduce it only in Rubric :)
Rubric is great and it's a pleasure to use it!
I'm just curious if there is a possible quick fix. I guess, I have an idea why it could happen (because rubric for styling uses it's own background thread and doesn't absolutely takes care if during styling in its inner threads text changes) but I'm not sure if I can find time in the very nearest future to fix it, or at least try.
Why do not ensuring in spotter that only one thread at a time can modify the text editor?
That is the most interesting part. In spotter I can guarantee that at any time always maximal only one thread have access to UI elements. But I can't guarantee that this thread is UI one. It is important. I build some widgets completely in background and then pass them to UI thread to be added in the World. By convention in Spotter only UI thread can add and modify widgets in the world. If widget not in the world it can be modified by any thread, but only one.
I tried to reproduce the issue, so there is a synthetic examples: (huge numbers to increase probability of exception)
It works for text edit morph:
|morph random|
morph��:= TextMorphForEditView new.
morph��openInWindow extent: 400@400.
random := Random seed: 1337.��
[ 1 to: 1337 do:
[ :i |��morph��contents: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
The same doesn't work for rubric:
|rubric random|
rubric := RubScrolledTextMorph new beForSmalltalkCode.
rubric openInWindow extent: 400@400.
random := Random seed: 1337.
[ 1 to: 1337 do:��
[ :i | rubric updateTextWith: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
��
Why do not ensuring in spotter that only one thread at a time can modify the text editor?
yes, if no solution is found I will always create rubric morphs in UI thread
Thanks for answers��
��