GLMBrick whats next?
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 - 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 nicolai
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
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 <stepharo@free.fr> 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"
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 <tudor@tudorgirba.com> 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 <stepharo@free.fr> 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"
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 <tudor@tudorgirba.com> 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 <tudor@tudorgirba.com> 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 <stepharo@free.fr> 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"
Thank you for this explanation 2014-12-31 23:47 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:
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 <tudor@tudorgirba.com> 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 <tudor@tudorgirba.com> 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 <stepharo@free.fr> 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"
2015-01-06 10:55 GMT+01:00 Nicolai Hess <nicolaihess@web.de>:
Thank you for this explanation
2014-12-31 23:47 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:
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 <tudor@tudorgirba.com> 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 <tudor@tudorgirba.com> 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 <stepharo@free.fr> 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
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 :) 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. No morphs are used at all (except Rubric of course). All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. 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. 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. I could say that we collected quite some experience building it. Now I would like to enumerate features of UI framework we used to solve encountered problems. - Local bound coordinates. Nothing to say more here :) It's somehow obvious to have. - Detects graph of Bricks that should be invalidated when Brick triggers invalidation. So there is no need to invalidate the whole graph. - For example if Brick fills parent it means that it doesn't depend on children (simple and most common situation). So if any child triggers invalidation there is no need to invalidate parent as it doesn't depend on them. The same works in reversed way. - Build graph separately for each dimension: width and height. If only height of Brick was changed and children depend only on width, there is no need to invalidate them => x2 faster. - Invalidate resizing and re layouting separately. If there is no need to reposition bricks when size changes we just skip it. - Link subbricks in a DoubleLinked list. So subbrickAfter and subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates over the whole submorphs collection of the owner finds index if current morph and then returns submorphs at: index +/-1. submorphAfter is used when morphic tries to detect which morph should take focus. Take a look at: Morph>>nextMorphWantingFocus. It iterates over owner's subbricks and for each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening a window with a lot of submorphs takes so many time, especially system browser for big classes. - Native support of *paddings* with css-like syntax: padding: anArrayOrInteger paddingTop: anInteger
paddingRight: anInteger paddingBottom: anInteger paddingLeft: anInteger
padding: 10. "top, right, bottom, left padding are 10px" padding: #(10 20). "top, bottom padding 10px. left, right padding 20px" padding: #(10 20 30). "top 10px. left, right 20px. bottom 30px" padding: #(10 20 30 40). "top 10px, right 20px, bottom 30px, left 40px" - Native support of *margins* with css-like syntax: margin: anArrayOrInteger marginTop: anInteger
marginRight: anInteger marginBottom: anInteger marginLeft: anInteger
Have the same syntax as padding. - Native support of dynamic *minHeight, minWidth, maxHeight, maxWidth* minWidth: anIntegerOrBlock "actually any object that implements brickValue:"
maxHeight: anIntegerOrBlock
minHeight: [ : brick | brick label width * 2 ]. minHeight: 200. maxWidth: [ self height / 2 ]. maxWidth: 100. - Native support of *z-index*, so we don't rely on subbricks' order any more if one brick should be drawn above/below others. Works the same as css one. zIndex: 2. "default value is 1" - Native support of *floating *bricks. Floating bricks don't influence on any other neighbour bricks in layout. floating: aSymbol floating: #right. "top right brick's corner matches top right parent's corner + corresponding paddings and margins" floating: #center. "will be in the center of the parent and doesn't care about other subbricks" Example use case is scroll bar in spotter - it has floating: #right and zIndex: 2 so it appears above all list elements. (+ some margins to make it fancy). - Native support of horizontal and vertical *aligning*. hAlign: aSymbol vAlign: aSymbol hAlign: #right. vAlign: #center. - Horizontal and vertical *shrinking* to fit children. It is possible to have in one brick two subbricks where one shrink wraps and other fills parent. hShrinkWrap.
vShrinkWrap.
- Horizontal and vertical *filling* with support of percents and min/max height/width. If in brick one child shrink wraps width (or have static width) and other fills 100% of parent's width, filling one will take only available space left by shrinking (or static) brick. hSpaceFill: aFloat - fills aFloat percents of parent's width
hSpaceFill. - alias for 100 percents. vSpaceFill: aFloat - fills aFloat percents of parent's height vSpaceFill. - alias for 100 percents.
- Transparent *border* styling with possibility to separately configure each side. borderWidth: anArrayOrInteger.
borderColor: anArrayOrColor
The same syntax as used for paddings/margins - Native support of smooth gradient *box-shadows* with rounded corners: shadowColor: aColor.
shadowWidth: anInteger.
- Layout events such as: onLayouted - "called when brick was completely resized and layouted in its
parent"
onChildrenLayouted - "called when all children are completely resized and
layouted"
Use case: implementing flexible and responsive UI. Used in GLMLabelBrick to shrink text and add '...' when it doesn't fit in parent. Example is tab labels in Playground. Morphic version of tabs shrinks text and change ui of the tab during drawing. WAT? - Application dependent themes. To make app work perfect all UI elements should have the same style. In case of spotter, item preview is created outside of spotter and there is no way using existing morph theme mechanism to customize its look&feel especially for spotter, because widgets always refer to global UITheme. Brick extends theming mechanism and allows to extend existing themes specifically for needed application and it will be applied to the whole tree of subbricks. For example spotter can completely change theme in runtime to dark (without even closing it). "in context of SpotterMorph" self themer: GTSpotterBrickDarkThemer new. (or
just replace first line in initialize)
Even having white theme chosen in settings. (all rubric fields become dark too). - What we really want to have in Bloc is an easy way to detect that user clicked outside of specific morph. What do you want with brick ? A new framework or just an "implementation
detail" for spotter? It is *really* important to clarify this.
Now it becomes more stable, api changes less and less. We already have quite a number of tests for layouting logic and documentation for basic widgets. What we want from brick... I think we want to have a way to build fast and cheap unique and complex UIs. While it will fit our needs in GT Team we will use it. 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. Of course it would be great to cooperate to make Bloc release sooner. Some time ago I tried to port Brick on top of Bloc saving all business logic untouched and only changing events from morphic ones to bloc and FormCanvas to AthensCanvas. It was rather successful. I will be happy if it would be possible to do everything or almost everything mentioned above in Bloc. I think we will never (but who knows) announce Brick as separate project. In our minds it is just useful helper library. Thanks for reading :) Cheers, Alex
Thanks for this reply, Alex. Doru On Mon, Mar 23, 2015 at 8:54 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
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 :)
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. No morphs are used at all (except Rubric of course). All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. 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. 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.
I could say that we collected quite some experience building it. Now I would like to enumerate features of UI framework we used to solve encountered problems.
- Local bound coordinates.
Nothing to say more here :) It's somehow obvious to have.
- Detects graph of Bricks that should be invalidated when Brick triggers invalidation. So there is no need to invalidate the whole graph. - For example if Brick fills parent it means that it doesn't depend on children (simple and most common situation). So if any child triggers invalidation there is no need to invalidate parent as it doesn't depend on them. The same works in reversed way. - Build graph separately for each dimension: width and height. If only height of Brick was changed and children depend only on width, there is no need to invalidate them => x2 faster. - Invalidate resizing and re layouting separately. If there is no need to reposition bricks when size changes we just skip it.
- Link subbricks in a DoubleLinked list. So subbrickAfter and subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates over the whole submorphs collection of the owner finds index if current morph and then returns submorphs at: index +/-1. submorphAfter is used when morphic tries to detect which morph should take focus. Take a look at: Morph>>nextMorphWantingFocus. It iterates over owner's subbricks and for each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening a window with a lot of submorphs takes so many time, especially system browser for big classes.
- Native support of *paddings* with css-like syntax:
padding: anArrayOrInteger
paddingTop: anInteger
paddingRight: anInteger paddingBottom: anInteger paddingLeft: anInteger
padding: 10. "top, right, bottom, left padding are 10px"
padding: #(10 20). "top, bottom padding 10px. left, right padding 20px"
padding: #(10 20 30). "top 10px. left, right 20px. bottom 30px"
padding: #(10 20 30 40). "top 10px, right 20px, bottom 30px, left 40px"
- Native support of *margins* with css-like syntax:
margin: anArrayOrInteger
marginTop: anInteger
marginRight: anInteger marginBottom: anInteger marginLeft: anInteger
Have the same syntax as padding.
- Native support of dynamic *minHeight, minWidth, maxHeight, maxWidth*
minWidth: anIntegerOrBlock "actually any object that implements
brickValue:" maxHeight: anIntegerOrBlock
minHeight: [ : brick | brick label width * 2 ].
minHeight: 200.
maxWidth: [ self height / 2 ].
maxWidth: 100.
- Native support of *z-index*, so we don't rely on subbricks' order any more if one brick should be drawn above/below others. Works the same as css one.
zIndex: 2. "default value is 1"
- Native support of *floating *bricks. Floating bricks don't influence on any other neighbour bricks in layout.
floating: aSymbol
floating: #right. "top right brick's corner matches top right parent's corner + corresponding paddings and margins"
floating: #center. "will be in the center of the parent and doesn't care about other subbricks"
Example use case is scroll bar in spotter - it has floating: #right and zIndex: 2 so it appears above all list elements. (+ some margins to make it fancy).
- Native support of horizontal and vertical *aligning*.
hAlign: aSymbol
vAlign: aSymbol
hAlign: #right.
vAlign: #center.
- Horizontal and vertical *shrinking* to fit children. It is possible to have in one brick two subbricks where one shrink wraps and other fills parent.
hShrinkWrap.
vShrinkWrap.
- Horizontal and vertical *filling* with support of percents and min/max height/width. If in brick one child shrink wraps width (or have static width) and other fills 100% of parent's width, filling one will take only available space left by shrinking (or static) brick.
hSpaceFill: aFloat - fills aFloat percents of parent's width
hSpaceFill. - alias for 100 percents. vSpaceFill: aFloat - fills aFloat percents of parent's height vSpaceFill. - alias for 100 percents.
- Transparent *border* styling with possibility to separately configure each side.
borderWidth: anArrayOrInteger.
borderColor: anArrayOrColor
The same syntax as used for paddings/margins
- Native support of smooth gradient *box-shadows* with rounded corners:
shadowColor: aColor.
shadowWidth: anInteger.
- Layout events such as:
onLayouted - "called when brick was completely resized and layouted in
its parent"
onChildrenLayouted - "called when all children are completely resized and
layouted"
Use case: implementing flexible and responsive UI. Used in GLMLabelBrick to shrink text and add '...' when it doesn't fit in parent. Example is tab labels in Playground. Morphic version of tabs shrinks text and change ui of the tab during drawing. WAT?
- Application dependent themes. To make app work perfect all UI elements should have the same style. In case of spotter, item preview is created outside of spotter and there is no way using existing morph theme mechanism to customize its look&feel especially for spotter, because widgets always refer to global UITheme. Brick extends theming mechanism and allows to extend existing themes specifically for needed application and it will be applied to the whole tree of subbricks. For example spotter can completely change theme in runtime to dark (without even closing it).
"in context of SpotterMorph" self themer: GTSpotterBrickDarkThemer new.
(or just replace first line in initialize)
Even having white theme chosen in settings. (all rubric fields become dark too).
- What we really want to have in Bloc is an easy way to detect that user clicked outside of specific morph.
What do you want with brick ? A new framework or just an "implementation
detail" for spotter? It is *really* important to clarify this.
Now it becomes more stable, api changes less and less. We already have quite a number of tests for layouting logic and documentation for basic widgets. What we want from brick... I think we want to have a way to build fast and cheap unique and complex UIs. While it will fit our needs in GT Team we will use it. 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. Of course it would be great to cooperate to make Bloc release sooner.
Some time ago I tried to port Brick on top of Bloc saving all business logic untouched and only changing events from morphic ones to bloc and FormCanvas to AthensCanvas. It was rather successful. I will be happy if it would be possible to do everything or almost everything mentioned above in Bloc. I think we will never (but who knows) announce Brick as separate project. In our minds it is just useful helper library.
Thanks for reading :)
Cheers, Alex
-- www.tudorgirba.com "Every thing has its own flow"
thanks a lot for these explanations. yep! very promising :) I would love to see all these improvements implemented in Bloc.
Le 23 mars 2015 à 20:54, Aliaksei Syrel <alex.syrel@gmail.com> a écrit :
What we really want to have in Bloc is an easy way to detect that user clicked outside of specific morph. I will investigate this
Cheers Alain
Hi Aliaksei, this is a good and interesting read, especially the feedback on making it fast (solution to some performance problems in Morphic). However, I have the feeling that the css inspired layout syntax is a step backward on what is/was Morphic (which is using other morphs to constrain and adjust layout in the same way as TeX/LaTeX instead of adding padding, align). Was that syntax choosen because layouting with filler Morphs is considered too slow or too complex to be understandable? Regards, Thierry Le 23/03/2015 20:54, Aliaksei Syrel a écrit :
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 :)
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. No morphs are used at all (except Rubric of course). All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from original Morph only Canvas (without drawing) and MorphicEvents. 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. 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.
I could say that we collected quite some experience building it. Now I would like to enumerate features of UI framework we used to solve encountered problems.
* Local bound coordinates.
Nothing to say more here :) It's somehow obvious to have.
* Detects graph of Bricks that should be invalidated when Brick triggers invalidation. So there is no need to invalidate the whole graph. o For example if Brick fills parent it means that it doesn't depend on children (simple and most common situation). So if any child triggers invalidation there is no need to invalidate parent as it doesn't depend on them. The same works in reversed way. o Build graph separately for each dimension: width and height. If only height of Brick was changed and children depend only on width, there is no need to invalidate them => x2 faster. o Invalidate resizing and re layouting separately. If there is no need to reposition bricks when size changes we just skip it.
* Link subbricks in a DoubleLinked list. So subbrickAfter and subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates over the whole submorphs collection of the owner finds index if current morph and then returns submorphs at: index +/-1. submorphAfter is used when morphic tries to detect which morph should take focus. Take a look at: Morph>>nextMorphWantingFocus. It iterates over owner's subbricks and for each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening a window with a lot of submorphs takes so many time, especially system browser for big classes.
* Native support of /paddings/ with css-like syntax:
padding: anArrayOrInteger
paddingTop: anInteger paddingRight: anInteger paddingBottom: anInteger paddingLeft: anInteger
padding: 10. "top, right, bottom, left padding are 10px"
padding: #(10 20). "top, bottom padding 10px. left, right padding 20px"
padding: #(10 20 30). "top 10px. left, right 20px. bottom 30px"
padding: #(10 20 30 40). "top 10px, right 20px, bottom 30px, left 40px"
* Native support of /margins/ with css-like syntax:
margin: anArrayOrInteger
marginTop: anInteger marginRight: anInteger marginBottom: anInteger marginLeft: anInteger
Have the same syntax as padding.
* Native support of dynamic /minHeight, minWidth, maxHeight, maxWidth/
minWidth: anIntegerOrBlock "actually any object that implements brickValue:" maxHeight: anIntegerOrBlock
minHeight: [ : brick | brick label width * 2 ].
minHeight: 200.
maxWidth: [ self height / 2 ].
maxWidth: 100.
* Native support of /z-index/, so we don't rely on subbricks' order any more if one brick should be drawn above/below others. Works the same as css one.
zIndex: 2. "default value is 1"
* Native support of /floating /bricks. Floating bricks don't influence on any other neighbour bricks in layout.
floating: aSymbol
floating: #right. "top right brick's corner matches top right parent's corner + corresponding paddings and margins"
floating: #center. "will be in the center of the parent and doesn't care about other subbricks"
Example use case is scroll bar in spotter - it has floating: #right and zIndex: 2 so it appears above all list elements. (+ some margins to make it fancy).
* Native support of horizontal and vertical /aligning/.
hAlign: aSymbol
vAlign: aSymbol
hAlign: #right.
vAlign: #center.
* Horizontal and vertical /shrinking/ to fit children. It is possible to have in one brick two subbricks where one shrink wraps and other fills parent.
hShrinkWrap. vShrinkWrap.
* Horizontal and vertical /filling/ with support of percents and min/max height/width. If in brick one child shrink wraps width (or have static width) and other fills 100% of parent's width, filling one will take only available space left by shrinking (or static) brick.
hSpaceFill: aFloat - fills aFloat percents of parent's width hSpaceFill. - alias for 100 percents. vSpaceFill: aFloat - fills aFloat percents of parent's height vSpaceFill. - alias for 100 percents.
* Transparent /border/ styling with possibility to separately configure each side.
borderWidth: anArrayOrInteger. borderColor: anArrayOrColor
The same syntax as used for paddings/margins
* Native support of smooth gradient /box-shadows/ with rounded corners:
shadowColor: aColor. shadowWidth: anInteger.
* Layout events such as:
onLayouted - "called when brick was completely resized and layouted in its parent"
onChildrenLayouted - "called when all children are completely resized and layouted"
Use case: implementing flexible and responsive UI. Used in GLMLabelBrick to shrink text and add '...' when it doesn't fit in parent. Example is tab labels in Playground. Morphic version of tabs shrinks text and change ui of the tab during drawing. WAT?
* Application dependent themes. To make app work perfect all UI elements should have the same style. In case of spotter, item preview is created outside of spotter and there is no way using existing morph theme mechanism to customize its look&feel especially for spotter, because widgets always refer to global UITheme. Brick extends theming mechanism and allows to extend existing themes specifically for needed application and it will be applied to the whole tree of subbricks. For example spotter can completely change theme in runtime to dark (without even closing it).
"in context of SpotterMorph" self themer: GTSpotterBrickDarkThemer new. (or just replace first line in initialize)
Even having white theme chosen in settings. (all rubric fields become dark too).
* What we really want to have in Bloc is an easy way to detect that user clicked outside of specific morph.
What do you want with brick ? A new framework or just an "implementation detail" for spotter? It is *really* important to clarify this.
Now it becomes more stable, api changes less and less. We already have quite a number of tests for layouting logic and documentation for basic widgets. What we want from brick... I think we want to have a way to build fast and cheap unique and complex UIs. While it will fit our needs in GT Team we will use it. 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. Of course it would be great to cooperate to make Bloc release sooner.
Some time ago I tried to port Brick on top of Bloc saving all business logic untouched and only changing events from morphic ones to bloc and FormCanvas to AthensCanvas. It was rather successful. I will be happy if it would be possible to do everything or almost everything mentioned above in Bloc. I think we will never (but who knows) announce Brick as separate project. In our minds it is just useful helper library.
Thanks for reading :)
Cheers, Alex
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@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
Hi Nicolai, I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :) 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 <nicolaihess@web.de> wrote:
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@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 "Every thing has its own flow"
On 24 Mar 2015, at 12:37, Tudor Girba <tudor@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 <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@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"
2015-03-24 12:37 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
not the implementation, the uncertainty of its purpose - a GT private implementation / a public framework.
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.
I did not say "discard GT" . Brick is in the image, but I don't want to have it in the core image *as another UI-library* next to what we already have - without cleaning that up. You know the questions on the mailing list about what framework to use for creating an application:pure Morphic/Polymorph/Spec/Glamour, and yes I am sure people will come and ask "hey how can I create such cool looking application like spotter". It is already difficult for new people to step in, and get an idea how to work in pharo, or find information about the different frameworks. Nicolai
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, I think I might have misunderstood your mail :). Tthe intention behind Brick is not to be a separate framework but an internal tool for GT. At least not now, and at least not before we investigate how we get to the end goal of having a vectorial canvas (hence Bloc). Is this satisfying? Cheers, Doru On Tue, Mar 24, 2015 at 1:44 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-03-24 12:37 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
not the implementation, the uncertainty of its purpose - a GT private implementation / a public framework.
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.
I did not say "discard GT" . Brick is in the image, but I don't want to have it in the core image *as another UI-library* next to what we already have - without cleaning that up.
You know the questions on the mailing list about what framework to use for creating an application:pure Morphic/Polymorph/Spec/Glamour, and yes I am sure people will come and ask "hey how can I create such cool looking application like spotter". It is already difficult for new people to step in, and get an idea how to work in pharo, or find information about the different frameworks.
Nicolai
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
2015-03-24 13:54 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
I think I might have misunderstood your mail :).
Tthe intention behind Brick is not to be a separate framework but an internal tool for GT. At least not now, and at least not before we investigate how we get to the end goal of having a vectorial canvas (hence Bloc). Is this satisfying?
Yes, thank you!
Cheers, Doru
On Tue, Mar 24, 2015 at 1:44 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-03-24 12:37 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
not the implementation, the uncertainty of its purpose - a GT private implementation / a public framework.
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.
I did not say "discard GT" . Brick is in the image, but I don't want to have it in the core image *as another UI-library* next to what we already have - without cleaning that up.
You know the questions on the mailing list about what framework to use for creating an application:pure Morphic/Polymorph/Spec/Glamour, and yes I am sure people will come and ask "hey how can I create such cool looking application like spotter". It is already difficult for new people to step in, and get an idea how to work in pharo, or find information about the different frameworks.
Nicolai
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
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.
I did not say "discard GT" . Brick is in the image, but I don't want to have it in the core image *as another UI-library* next to what we already have - without cleaning that up.
Yes I understand the feel. This is why I'm juggling between Bloc and improving Morphic slowly too slowly. But cleaning is tedious.
You know the questions on the mailing list about what framework to use for creating an application:pure Morphic/Polymorph/Spec/Glamour, and yes I am sure people will come and ask "hey how can I create such cool looking application like spotter". It is already difficult for new people to step in, and get an idea how to work in pharo, or find information about the different frameworks.
I agree I would like to remove some :)
Nicolai
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
And well⦠I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support⦠well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be âold stuffâ and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric⦠but it cannot be used right now (or better: It cannot replace none of the previous yet) So⦠which one to use? We, the board, have something clear and some other not so clear yet, for example: - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. So well⦠yes this is a mess. Yes we are aware. No we donât know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects⦠this is my recommendation: - Do not use âdirectâ Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon) And of course, I would help with fixes and reports on everything :) cheers, Esteban
On 24 Mar 2015, at 12:37, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
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 <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@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"
Hi Esteban, 2015-03-24 13:56 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
And well... I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal:
- we have Morphic, and it's upcoming replace, Brick (but Brick is not in the image, so the pain there is less)
I suspect you mean Bloc, not Brick there, no? Now I'm lost ;) Thierry
On 24 Mar 2015, at 14:23, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Esteban,
2015-03-24 13:56 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: And well⦠I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal:
- we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less)
I suspect you mean Bloc, not Brick there, no? Now I'm lost ;)
oops! yes, Bloc :P
Thierry
There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc. The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too. On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
And well⦠I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal:
- we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support⦠well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be âold stuffâ and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric⦠but it cannot be used right now (or better: It cannot replace none of the previous yet)
So⦠which one to use? We, the board, have something clear and some other not so clear yet, for example:
- we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel.
So well⦠yes this is a mess. Yes we are aware. No we donât know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects⦠this is my recommendation:
- Do not use âdirectâ Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon)
And of course, I would help with fixes and reports on everything :)
cheers, Esteban
On 24 Mar 2015, at 12:37, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
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 <nicolaihess@web.de> wrote:
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@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
"Every thing has its own flow"
On 24 Mar 2015, at 14:29, kilon alios <kilon.alios@gmail.com> wrote:
There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas.
The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc.
if you read my mail, you will notice that I said BOTH are on the table (and we are actually moving oon both): - Bloc is the redesign - In the mean time we WORK and ENCOURAGE others to work on improve it. but Morphic it self has several fundamental flaws that cannot be fixed and thatâs why in the long, very long way, needs to be replaced.
I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc.
Glamour is very mature and Iâve used it serval times⦠and in theory Brick will be compatible with Glamour (mostly) so even if developers deprecate one for the other you will be able to use your code (mostly).
The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too.
First, Athens is not a replace for Morphic, is a replace for the canvas in which morphs are drawn. So is not Morphic or Athens⦠is "Morph using DisplayPlugin" or "Morphic using Athens". But anyway, how can Athens be so slow? Why? Can you share some info? Most probably is because you are doing double work: you draw with Athens, but you convert it to a Form to display it (and a Form is a Morph using DisplayPlugin). I can ensure you that if you use Athens directly with SDL2 (an example I can share with you anytime) it is orders of magnitude faster⦠Esteban
On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: And well⦠I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal:
- we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support⦠well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be âold stuffâ and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric⦠but it cannot be used right now (or better: It cannot replace none of the previous yet)
So⦠which one to use? We, the board, have something clear and some other not so clear yet, for example:
- we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel.
So well⦠yes this is a mess. Yes we are aware. No we donât know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects⦠this is my recommendation:
- Do not use âdirectâ Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon)
And of course, I would help with fixes and reports on everything :)
cheers, Esteban
On 24 Mar 2015, at 12:37, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
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 <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@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"
2015-03-24 15:16 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 24 Mar 2015, at 14:29, kilon alios <kilon.alios@gmail.com> wrote:
There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas.
The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc.
if you read my mail, you will notice that I said BOTH are on the table (and we are actually moving oon both): - Bloc is the redesign - In the mean time we WORK and ENCOURAGE others to work on improve it.
but Morphic it self has several fundamental flaws that cannot be fixed and that's why in the long, very long way, needs to be replaced.
One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. Thierry
Hello Thierry,
Le 24 mars 2015 à 15:24, Thierry Goubier <thierry.goubier@gmail.com> a écrit :
One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :(
why do you think so ? Cheers Alain
You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you.
Still, I will miss the demise of Morphic.
Thierry
Hi, On Tue, Mar 24, 2015 at 3:24 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-03-24 15:16 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 24 Mar 2015, at 14:29, kilon alios <kilon.alios@gmail.com> wrote:
There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas.
The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc.
if you read my mail, you will notice that I said BOTH are on the table (and we are actually moving oon both): - Bloc is the redesign - In the mean time we WORK and ENCOURAGE others to work on improve it.
but Morphic it self has several fundamental flaws that cannot be fixed and thatâs why in the long, very long way, needs to be replaced.
One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :(
You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you.
Still, I will miss the demise of Morphic.
I think I do not understand this point. Why do you say that the future solution will be less than Morphic? Doru
Thierry
-- www.tudorgirba.com "Every thing has its own flow"
Hi, 2015-03-24 15:27 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
I think I do not understand this point. Why do you say that the future
solution will be less than Morphic?
Because we're driving it with uses which are less than Morphic requirements were. Because you don't need Morphic power to do GT tools; it justs gets in the way: slow, over-engineered for that use case. As a consequence, you end up with Rubricks: dedicated, ad-hoc solution which is a far better match for its use case. That Rubricks proudly present its Z layering where Morphic was / is probably the easiest toolkit ever to do layering of arbitrary widgets on top of another? (*) Thierry (*) Even if we're not doing it(**). (**) Well, I did. Nobody's interested, so what ?
Doru
Thierry
-- www.tudorgirba.com
"Every thing has its own flow"
One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :(
you mean less messy Surely. I think that you did not look at Bloc because we have already a lot there and much nicer.
You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you.
Still, I will miss the demise of Morphic.
Thierry
Hello Esteban,
Most probably is because you are doing double work: you draw with Athens, but you convert it to a Form to display it (and a Form is a Morph using DisplayPlugin). I can ensure you that if you use Athens directly with SDL2 (an example I can share with you anytime) it is orders of magnitude fasterâ¦
please share :) I would like to learn how to use SDL2. Thanks Cheers Alain
Esteban
Hello all, I think you should consider what is mature and what is in the image now. now we have Spec with Morphic, Morphic without Spec as an alternative, GT Tool framework (with Brick), Glamour. Regarding text editing we have Rubric. My fault, someone (sorry I donât remember who) proposed to work on its integration (PluggableTextMorph replacement). As an answer, I said that I wouldnât do it because of TxText. TxText is really cool but not fully integrated. Thus, maybe it was a mistake to not replace PluggableTextMorph with Rubric. And now yes, as a fork of PluggableTextMorph, Rubric brings a lot of code duplication. I guess we will have to live with that for a while. Cheers Alain
Le 24 mars 2015 à 14:29, kilon alios <kilon.alios@gmail.com> a écrit :
There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas.
The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc.
I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc.
The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too.
On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: And well⦠I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal:
- we have Morphic, and itâs upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support⦠well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be âold stuffâ and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric⦠but it cannot be used right now (or better: It cannot replace none of the previous yet)
So⦠which one to use? We, the board, have something clear and some other not so clear yet, for example:
- we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel.
So well⦠yes this is a mess. Yes we are aware. No we donât know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects⦠this is my recommendation:
- Do not use âdirectâ Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon)
And of course, I would help with fixes and reports on everything :)
cheers, Esteban
On 24 Mar 2015, at 12:37, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi Nicolai,
I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :)
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 <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@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"
On Mar 24, 2015, at 10:29, kilon alios <kilon.alios@gmail.com> wrote:
[Spec] does not support custom made GUIs which is what I want
Thatâs simply not true. Spec supports the embedding of whatever Morph you want inside your GUI. So you can easily mix and match your custom components with all the standard Spec components. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Tudor Girba-2 wrote
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.
Given that, now I /really/ feel it would be beneficial to have the talks recorded because otherwise you increase your work exponentially by excluding the bulk of the community from the conversation. You will have to try and convey all the decisions and rationales over what... the lists? AFAICT many Morphic replacements have failed primarily due to lack of community buy in. Let's finally break that trend! ----- Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
There is only one talk about Bloc. The rest is like a sprint. Doru On Tue, Mar 24, 2015 at 2:41 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
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.
Given that, now I /really/ feel it would be beneficial to have the talks recorded because otherwise you increase your work exponentially by excluding the bulk of the community from the conversation. You will have to try and convey all the decisions and rationales over what... the lists? AFAICT many Morphic replacements have failed primarily due to lack of community buy in. Let's finally break that trend!
----- Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
Hello Sean, As Iâve already said, Iâm currently working on a documentation on Bloc. Iâve stopped adding new things into it (well only examples and bug fixes) It is far from being finished and polished https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc <https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc> have a look at BlocCore.pillar please, be patient, I canât work full time on it, unfortunately Cheers Alain
Le 24 mars 2015 à 14:41, Sean P. DeNigris <sean@clipperadams.com> a écrit :
Tudor Girba-2 wrote
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.
Given that, now I /really/ feel it would be beneficial to have the talks recorded because otherwise you increase your work exponentially by excluding the bulk of the community from the conversation. You will have to try and convey all the decisions and rationales over what... the lists? AFAICT many Morphic replacements have failed primarily due to lack of community buy in. Let's finally break that trend!
----- Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (10)
-
Alain Plantec -
Aliaksei Syrel -
Esteban Lorenzano -
Johan Fabry -
kilon alios -
Nicolai Hess -
Sean P. DeNigris -
stepharo -
Thierry Goubier -
Tudor Girba