[Pharo-dev] [bloc] shape size?

Thierry Goubier thierry.goubier at gmail.com
Sun Apr 3 15:32:17 EDT 2016


Le 03/04/2016 20:01, Igor Stasenko a écrit :
>
>
> On 3 April 2016 at 20:51, Thierry Goubier <thierry.goubier at gmail.com
> <mailto:thierry.goubier at gmail.com>> wrote:
>
>     Le 03/04/2016 19:12, Igor Stasenko a écrit :
>
>
>
>         On 3 April 2016 at 19:48, Thierry Goubier
>         <thierry.goubier at gmail.com <mailto:thierry.goubier at gmail.com>
>         <mailto:thierry.goubier at gmail.com
>         <mailto:thierry.goubier at gmail.com>>> 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



More information about the Pharo-dev mailing list