>>> Also, note, that you need only one instance of such tree in image .
>>> You don't have to build this tree over and over again for each browser
>>> window on screen :)
>> In a way, yes.
>> But then OB would basically do what the system itself should do, namely modeling
>> packages. I would rather invest in a genuine package model in the system itself than
>> let OB build its own persistent package model. A browser should by definition browse
>> an existing model and not primarily create, maintain, and make persistently
>> accessible a system's model. This would be like a shadow model to what the system
>> otherwise uses, Sounds odd to me, although from a performance point of view it would
>> make sense.
> Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to
> model different data structures and they relations. Should we expect
> from squeak/pharo to use same model? I think no.
> So, even if some day we will have categories as first class objects in
> system, you still will need to map them to own objects.
yes, but that won't be problematic in terms of performance anymore when we can rely
on an efficient package model. The traditional system browser not showing packages
(no matter whether based on OB or the old Browser class) does not need to use caching
or even provide its own persistent shadow system model. Instead it just provides a
view on the system model, as it should be.
Because what the browser does is really simple: It traverses a tree from packages (or
class cats in case of the system browser) down to methods. There shouldn't be a huge
overhead if the system model provides efficient access to the entities and its
sub-entities (eg. transitions from packages to class cats, to classes, to extended
The next version (Polymorph-Widgets-gvc.45) will support adaptive layout
insets for buttons in the Watery2 theme dependent upon the corners that are
rounded. For square buttons this will save 8 pixels horizontally per button.
I'll put on SqueakSource once enough other changes are made to Polymorph to
justify the effort of releasing ;-)
>> Space to sides of the buttons?? Perhaps unrelated, but I have been
>> thinking of something similar while poking at Damien's recent dev image.
> Because Watery2 has more-rounded-than-usual buttons some extra space is
> required to avoid the text/morph apearing outside the button image.