> On 24 Mar 2015, at 12:37, Tudor Girba <tu...@tudorgirba.com> wrote: > > Hi Nicolai, > > I am surprised by your conclusion that the current Brick implementation > disqualifies it from being part of the Core :)
it was not that what disqualifies it. It is the “we will not announce it” part :) I mean: if it is not a separated framework then is not appropriate to use it for other stuff outside its intended purpose (doing GTTools). Esteban > > Let's recap. > > Brick was created to support GT. We wanted GT in the image, hence Brick is in > the image as part of Glamour. In the meantime, Brick has grown and it's now > an almost standalone framework, but it is not yet advisable to use it apps > because it will likely change more. > > As Alex says, we do not want to have two competing new projects running in > parallel (Brick and Bloc) and fragmenting the effort even more. That is why, > for Pharo 5 we want to invest in Bloc. The interesting thing is that while > Bloc starts from scratch, Brick already works and has quite some high level > widgets and logic built in. Brick is already going in the same direction > expected by Bloc, so we will likely have the opportunity of moving Brick on > top of Bloc (Alex already did an experiment in this direction). > > Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern > where Alain Plantec will join us to look into how to approach this problem > concretely. > > All in all, you should see Brick as a pragmatic intermediary step towards > removing Morph. I agree that it can be better (what cannot be), but I > disagree we should discard GT because of it. > > Cheers, > Doru > > > On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess <nicolaih...@web.de > <mailto:nicolaih...@web.de>> wrote: > > > 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.sy...@gmail.com > <mailto:alex.sy...@gmail.com>>: > Hi, > > Sorry if my reply will be too long, but I tried to summarise our experience > with Morphic/Brick and give some useful feedback or even provide ideas. Who > wants will read :) > > Hi, > thank you, this is a really great source of information, and it would be > heplful > to have this kind of write up somewhere else (not in the mailinglist). > But I did not question why we may need brick or why it is done. > My question was, what are the feature plans, is it just an experiment that > can vanish, so it is better to not use it for the core tools. Or is it meant > to be > THE new framework we should gain our focus on. > > > Brick is not a thin layer anymore. > It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born > out of need. Spotter is completely built using Brick and Rubric. > > This is something I don't understand. As we integrated GT-Tools into the > image, Rubric > slipped in as it is need by GT. I asked what is the background, what are the > feature plans > and complained about the undocumented core classes, that makes it difficult > to see > what changed compared to the old text classes. Alain said he doesn't plan to > do further > work on Rubric. > So, WHY don't we replace and migrate the existing classes now and clean it > up. It takes so > much resources to maintain both. Every theme change, every change on > shortcuts/menus/keymapping, the athens drawing, all has to be double checked > - It is so exhausting. > > > No morphs are used at all (except Rubric of course). > > Well, all Bricks ARE morphs, they share the same state and api. > > All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from > original Morph only Canvas (without drawing) and MorphicEvents. > > If so, the clean/better way would be to extract those part into a > "ProtoMorph" or a "PlainMorph". > and subclass from that once for Brick and again for Morphs. > Now we have Bricks, that are looking like a Morph, but aren't used to be one, > and probable doesn't even work if they are used as Morphs. > (Sure this is true for other Morphsubclasses as well, but that does not means > it doesn't hurt if we do more of this). > > Everything else was rewritten from scratch. During some period of time Brick > was able to render itself on Athens canvas, but we dropped it because of Font > issues in athens. > There are even more issues for Athens, and they don't vanish magically. There > are some issues > on fogbugz just waiting for some feedback, preferable from people intending > to use Athens. > > Spotter is not the only tool written using Brick, GLMPager - a pane pager in > GT-Inspector, GT-Playground and GT-Debugger is also completely done using > Brick. Almost all tab labels and tab selector in GT tools are Bricks. > > > ... > > > We really would like to move all tools to Bloc as soon as possible, but we > just need something right now that works and can be used in current version. > > But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is > needed to push > this into the release. > > I think we will never (but who knows) announce Brick as separate project. In > our minds it is just useful helper library. > > For me, this just disqualifies Brick from being used in the core image. > > > I see that many things in the GToolkit are better than the old one > (theming/layouting/delegate behavior in sub(classes/bricks). Great, it makes > fun to work with it,extending the inspector or Spotter search. > > But I don't understand why this is pushed that way and on top of the old > system/classes instead of cleaning that up. > > > nicolai > > > Thanks for reading :) > > Cheers, > Alex > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"
