some questions about bloc
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic. Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary. Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells? Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working. Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView? Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic .... Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block". And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me. About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily? I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture? nicolai
Hi Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic. Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now. Cheers, Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent. Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView? I think I don't understand bloc Cheers,
Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
On 09/08/15 21:57, Nicolai Hess wrote:
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Because the theme only provides default values (and reset to theme). Stephan
Hi Nicolai, Thanks for looking into this :) Hierarchy will be optimised. Basically EnclosedView will gone - ProtoView will be a composition, this will remove code duplication and simplify addition of new functionality. After that rounded rectangle and rectangle will be merged. So in the end hierarchy will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> BrButtonView which is simple enough. As Stephan said theme just provides default values and also skin for morph. Skin provides view and different styles for states like hovered, pressed, active, focused, disabled and others. Summarizing, with event listener any arbitrary morph can get dynamic behaviour on events, with skins any arbitrary morph can be deeply styled. Maybe it makes sense to move theme from BlProtoView to BlMorph. Cheers, Alex On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView?
I think I don't understand bloc
Cheers,
Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Nicolai,
Thanks for looking into this :) Hierarchy will be optimised. Basically EnclosedView will gone - ProtoView will be a composition, this will remove code duplication and simplify addition of new functionality. After that rounded rectangle and rectangle will be merged. So in the end hierarchy will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> BrButtonView which is simple enough.
merging EnclosedView and ProtoView: +1
As Stephan said theme just provides default values and also skin for morph.
Ok, yes that makes sense.
Skin provides view and different styles for states like hovered, pressed, active, focused, disabled and others.
Summarizing, with event listener any arbitrary morph can get dynamic
behaviour on events, with skins any arbitrary morph can be deeply styled.
Maybe it makes sense to move theme from BlProtoView to BlMorph.
Cheers, Alex On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView?
I think I don't understand bloc
Cheers,
Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
Are you interested in some feedback for brick, or is it in a too early stage? 2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Nicolai,
Thanks for looking into this :) Hierarchy will be optimised. Basically EnclosedView will gone - ProtoView will be a composition, this will remove code duplication and simplify addition of new functionality. After that rounded rectangle and rectangle will be merged. So in the end hierarchy will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> BrButtonView which is simple enough.
As Stephan said theme just provides default values and also skin for morph. Skin provides view and different styles for states like hovered, pressed, active, focused, disabled and others.
Summarizing, with event listener any arbitrary morph can get dynamic behaviour on events, with skins any arbitrary morph can be deeply styled.
Maybe it makes sense to move theme from BlProtoView to BlMorph.
Cheers, Alex On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView?
I think I don't understand bloc
Cheers,
Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
Are you interested in some feedback for brick, or is it in a too early stage?
please.
2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>>:
Hi Nicolai,
Thanks for looking into this :) Hierarchy will be optimised. Basically EnclosedView will gone - ProtoView will be a composition, this will remove code duplication and simplify addition of new functionality. After that rounded rectangle and rectangle will be merged. So in the end hierarchy will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> BrButtonView which is simple enough.
As Stephan said theme just provides default values and also skin for morph. Skin provides view and different styles for states like hovered, pressed, active, focused, disabled and others.
Summarizing, with event listener any arbitrary morph can get dynamic behaviour on events, with skins any arbitrary morph can be deeply styled.
Maybe it makes sense to move theme from BlProtoView to BlMorph.
Cheers, Alex
On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView?
I think I don't understand bloc
Cheers, Alex
On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
Yes, shoot :) On Sun, Aug 16, 2015 at 10:54 AM, stepharo <stepharo@free.fr> wrote:
Are you interested in some feedback for brick, or is it in a too early stage?
please.
2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Nicolai,
Thanks for looking into this :) Hierarchy will be optimised. Basically EnclosedView will gone - ProtoView will be a composition, this will remove code duplication and simplify addition of new functionality. After that rounded rectangle and rectangle will be merged. So in the end hierarchy will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> BrButtonView which is simple enough.
As Stephan said theme just provides default values and also skin for morph. Skin provides view and different styles for states like hovered, pressed, active, focused, disabled and others.
Summarizing, with event listener any arbitrary morph can get dynamic behaviour on events, with skins any arbitrary morph can be deeply styled.
Maybe it makes sense to move theme from BlProtoView to BlMorph.
Cheers, Alex On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView?
I think I don't understand bloc
Cheers,
Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
Feedback is always welcomed :) Still in the brick repo there are, at the moment, quite some sub-projects/experiments. We are working now on making a better description for what is already in a more advanced state. For example the logic for skin, styes and theme modules is in a good state. Cheers, Andrei On Sat, Aug 15, 2015 at 11:59 PM, Nicolai Hess <nicolaihess@web.de> wrote:
Are you interested in some feedback for brick, or is it in a too early stage?
2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Nicolai,
Thanks for looking into this :) Hierarchy will be optimised. Basically EnclosedView will gone - ProtoView will be a composition, this will remove code duplication and simplify addition of new functionality. After that rounded rectangle and rectangle will be merged. So in the end hierarchy will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> BrButtonView which is simple enough.
As Stephan said theme just provides default values and also skin for morph. Skin provides view and different styles for states like hovered, pressed, active, focused, disabled and others.
Summarizing, with event listener any arbitrary morph can get dynamic behaviour on events, with skins any arbitrary morph can be deeply styled.
Maybe it makes sense to move theme from BlProtoView to BlMorph.
Cheers, Alex On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi
Thanks for your response.
Animation was copied from other project and has nothing to do with Bloc. However, it is still there for a moment. BTW, example on the class side is still morphic.
Yes, but it only works in a bloc world
Yes, it does not make any sense to theme CircleView and ImageView, but it makes sense to theme their subclasses, like BrButtonView. Theming mechanism is not integrated in Bloc for now.
But why dont we put this into a BlThemeableView ? All subclasses of BlProtoView that want to support color or fillstyles, now have a theme property too. Why do they need a color property if the color is theme-dependent.
Btw. what is that strange hierarchy for BrButtonView: BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView A BlRectangleView, a RoundedRectangleView and a BrRectangleView?
I think I don't understand bloc
Cheers,
Alex On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess@web.de> wrote:
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells?
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily?
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
nicolai
Thanks nicolai for all these questions. Writing more tests is cool. I started and each time alain imporved Bloc :) Alain is driving somwhere in vacation with nearly no internet. Stef
BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic.
Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary.
Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells? Yes.
Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working.
I think that this is more a work in progress.
Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView?
Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic ....
I would really like to see if Viva animation could be used in Bloc. StephaneDucasse / PetitsBazars > viva Alex used it for Roassal and this is nice but we need more experience and to check if it is compatible with the design of bloc. Is this a software pattern ? I have never seen this before.
(For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block".
And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me.
About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily? yes.
I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture?
What I can tell is that I tried several times and bloc changed at that time :) Now it is ***much*** more stable so this is the time to push. Did you read a bit the documentation we started on BlocCore? So having tests would be nice. I was planning to start to port some little classes I have around the game such as ledMorph and other to see how it goes. Stef
participants (5)
-
Aliaksei Syrel -
Andrei Chis -
Nicolai Hess -
Stephan Eggermont -
stepharo