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 <[email protected] <mailto:[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]
    <mailto:[email protected]>> wrote:



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








Reply via email to