2016-03-31 10:51 GMT+02:00 Tudor Girba <[email protected]>:

> Hi Nicolai,
>
> Thank you for the feedback. Just, please let’s adopt a different tone.
>
> Cheers,
> Doru
>
>
>

I am not sure what is wrong with my tone.
I did not choose a random external library and starting to criticize it.
This is a core component. And

"Because it is there just for spotter and will be deleted ASAP.

We know that it is bad. Normal fix requires too many changes."
is not an excuse for badly debuggable code.
I don't like to have quick-dirty-throwaway-hacks in the core.
There is a real demand for debugging this code.
The attached screenshot shows a common issue with inspector panes.
The available space would suffice for all tabs (secodn window) but the
default
size shnrinks nearly all tabs (first window).

The normal way to understand and trying to fix this issue, is to put some
"self halt" at some point for the layout processing.But this does not work
here
because *all* exceptions are catched.
And changing the code to actually execute the exception won't work either,
becuase this
will throw all other (previously cachted) exceptions (what is wrong with
initializing the font property properly or
checking for ZeroDivide?)
And this is frustrating.
And I hope no one sees and adopts this code, just because it is the way our
own
core tools are built.

BTW, your LazyTabGroupMorph class is another bad example. It subclasses
TabGroupMorph, it
calls super initialize,
removes all created and added morphs from its super class and
recreates and replaces them with its own.

nicolai

Reply via email to