2015-01-06 10:55 GMT+01:00 Nicolai Hess <[email protected]>: > Thank you for this explanation > > 2014-12-31 23:47 GMT+01:00 Aliaksei Syrel <[email protected]>: > >> Bloc has a big future, for sure! I hope it will move Pharo to a very new >> level! As Doru said, Brick was born out of necessity. More exactly because >> of text resizing in Inspector. By default, if one wants to clip/resize text >> in tabs she uses clippingBounds. And clippingBounds is called during... >> what would it be?...during drawing! For example *TabExample open. *So >> morphic (in some cases) calculates geometry of submorphs during drawing. >> And very first version of Brick was build to shrink/clip tabs with content >> during layouting and not during drawing :) Simple like that. >> >> Cheers, >> Alex >> >> On Wed, Dec 31, 2014 at 10:13 PM, Tudor Girba <[email protected]> >> wrote: >> >>> Of course, I meant to say that Brick is the incremental solution, not >>> Bloc :) >>> >>> Doru >>> >>> On Wed, Dec 31, 2014 at 2:08 PM, Tudor Girba <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> Brick was born out of necessity. It is a thin layer on top of basic >>>> Morphic that is supposed to coexist with Morphic but not be bound by >>>> various problems Morphic has (such as the layout). Alex Syrel built it >>>> primarily for performance reasons and it was critical to make GTSpotter >>>> work. In the meantime, also the pager interface of GTInspector is using it >>>> as well. Currently, Brick is able to draw itself on Athens. >>>> >>>> About the relation with Bloc: we definitely do not want to end up with >>>> two solutions. Building Brick was a great learning experience. Bloc >>>> followed a rewrite from scratch approach, while Bloc is more incremental >>>> (it subclasses Morph) but it works in production. As both are able to work >>>> with Athens and both have local coordinates, I think it's a great >>>> opportunity to learn from both and find the one path that will be >>>> integrated in Pharo. Alex will be at the PharoDays and if Alain is >>>> available, he will work with Alain. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Wed, Dec 31, 2014 at 12:30 PM, stepharo <[email protected]> wrote: >>>> >>>>> >>>>> Le 31/12/14 11:58, Nicolai Hess a écrit : >>>>> >>>>>> I took a look at GLMBrick and I am wondering what is the intent: >>>>>> >>>>>> - a temporary solution until this functions/behavior are included in >>>>>> Morphic >>>>>> >>>>> would be nice. >>>>> >>>>>> - a layer on top of morphic without the intent to do this in Morphic >>>>>> any time. >>>>>> - a temporary solution until this functions/behaviors are implemented >>>>>> with bloc >>>>>> >>>>> >>>>> I hope the third but we will need more people participating to Bloc. >>>>> >>>>> I should continue to work on the documentation.... but it takes time. >>>>> >>>>>> >>>>>> nicolai >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >
I would like to raise the question again. Brick is not a thin layer anymore. Looks more like a new framework (still, based on Morphic but "hiding" its origin). Spotter highly depends on this. There are some efforts to make spotter a central tool. And make it visible and discoverable for new users. It may be advertised as one of the hot feature of the new release. What do you want with brick ? A new framework or just an "implementation detail" for spotter? It is *really* important to clarify this. nicolai
