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.sy...@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" <nicolaih...@web.de> wrote: > >> >> >> 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.sy...@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" <nicolaih...@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 >>>> >>>> >>>> >>>> >>>> >>>> >>
