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 <[email protected]> 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 <[email protected]>: > >> 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" <[email protected]> wrote: >> >>> >>> >>> 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <[email protected]>: >>> >>>> 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" <[email protected]> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >
