Le 03/04/2016 20:01, Igor Stasenko a écrit :


On 3 April 2016 at 20:51, Thierry Goubier <[email protected]
<mailto:[email protected]>> wrote:

    Le 03/04/2016 19:12, Igor Stasenko a écrit :



        On 3 April 2016 at 19:48, Thierry Goubier
        <[email protected] <mailto:[email protected]>
        <mailto:[email protected]
        <mailto:[email protected]>>> wrote:

             Le 03/04/2016 17:33, stepharo a écrit :

                 If you want to change clicking behaviour you need to
        override
                 one single
                 method.


                              Everything you wrote with unreadable amount of
                     characters is
                              for nothing.

                          I see clearly point of Igor. And for me it
        feels very
                     logical.
                          With such design you can lively change
        clipping area and
                          interaction area for any morph (element) on
        screen.


                     In short, i see only two cases where indeed, morph
        requires
                     a nothing
                     of shapes to define:
                       - clipping region(s)
                       - ui interaction region(s)

                     but for drawing? nooooo... really? who cares what
        you draw
                     there?
                     draw anything, in any possible way you see fit..
        compose,
                     decompose,
                     recombine, blend and mix.. that's the whole purpose of
                     drawing and be
                     artistic and be able to express yourself in any
        possible way
                     you want :)
                     Why nailing and formalizing things that are tend to
        be hardly
                     formalizable and more than that, unnecessary.
                     That's my main concern about current design.


                 I agree.
                 I do not see why people are forced to create a submorph
        just to
                 change
                 the rendering.
                 If you want to change it dynamically you can for
        example pass a
                 different shape.


             I don't see the problem with subclassing a morph.

        Me neither. But do you confusing subclassing and submorph
        compositing?


    Let me return you the question then: do you do a composition of
    submorphs if you're trying to get a different drawOn:?

Who, me? No. Maybe i was just misunderstood your reply.
Because what i was tried to demonstrate in previous post(s) that there's
simply no easy way to expose all possible drawing operations via
composition of morphs (or composition of any other kind of elements),
unless, of course you will lift full feature set of Athens to the level
of composition..
As result you will get a full feature set that Athens provides, plus
extra complexity.
Sounds like thing to do, no? :)

Agreed :)

    Oh, ok, that's true FastTable does it for the selection... changing
    background color by encapsulating a row in another Morph with the
    right background color.

Well, i don't know what is FastTable beast are.. so i cannot comment on
this one.

I think FastTable is something you should have a look at. Esteban did something really interesting there.

In FT, Submorphs are only created when they are about to be displayed: Pharo can easily create hundreds of morphs on every redraw cycle. So FT performance is O(k) where k is the number of rows to display on screen (typical k is ~25), and is O(1) regarding the length of the list (almost: there is a point, for very large tree-like structures, where just iterating over the structure becomes the main performance limitation: see FTTree).

A FTTableContainerMorph recreates all its submorphs on every drawOn:. I've played with different variants (do not recreate all submorphs, for example) but you don't see any performance difference (on the time needed for a drawOn:).

Regards,

Thierry

Reply via email to