[Pharo-dev] [bloc] shape size?
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
> one single
> Everything you wrote with unreadable amount of
> characters is
> for nothing.
> I see clearly point of Igor. And for me it
> feels very
> With such design you can lively change
> clipping area and
> interaction area for any morph (element) on
> In short, i see only two cases where indeed, morph
> a nothing
> of shapes to define:
> - clipping region(s)
> - ui interaction region(s)
> but for drawing? nooooo... really? who cares what
> you draw
> draw anything, in any possible way you see fit..
> 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
> 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
> 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? :)
> 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:).
More information about the Pharo-dev