Le 03/04/2016 22:46, Igor Stasenko a écrit :
On 3 April 2016 at 23:41, Igor Stasenko <[email protected]
<mailto:[email protected]>> wrote:
On 3 April 2016 at 23:30, Thierry Goubier <[email protected]
<mailto:[email protected]>> wrote:
Le 03/04/2016 21:58, Igor Stasenko a écrit :
On 3 April 2016 at 22:32, Thierry Goubier
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
Le 03/04/2016 20:01, Igor Stasenko a écrit :
On 3 April 2016 at 20:51, Thierry Goubier
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[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]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[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).
Sounds like right way to do it. There's no point to keep
million UI
elements for million items in list, since you never render
them all at
once on the screen. So, practical approach is to create as
many UI
elements as fits on the screen, but not as many you have in
list.
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:).
Well, as Henrik pointed out, not everytime ;)
Yeah, i did similar thing in TxText - also create morph(s)
only for part
of text which is currently displayed.. and basically it is
same idea for
TxText itself: it calculates layout only for a portion of
text, the
portion that currently displayed, but never for whole text,
which can be
megabytes long.
Thus, it guarantees that overall performance are bound to
the area,
covered by UI control that displays the text, but not to
text size.
I'm interested to know how you handle scrolling then: how do you
define the step, the length and the position: relative to the
number of characters displayed / start character of the current
UI / and knowing the number of characters in the whole text, so
that you are independent of the layout?
The scroll is defined in delta in pixels. So, scrolling single line
- you scroll by top or bottom line height (depending on direction).
You wrote a dedicated scrollbar? The standard one is [0, 1.0] with a
constant step whatever the direction so it's hard to make the difference
in height between the top line or the bottom line.
But it could be worth subclassing ScrollBar for that purpose.
Or maybe i lying here.. i could be 'scroll up/down' until next/previous
line are fully visible in layout. (There's of course an edge case, when
line height is bigger than viewport height)
That edge case is complex to handle...
Scrolling page - you scroll by using height of viewport. No need to
count lines of text.
And so, i scan text forward or backward until new layout fully
covers part of text after such scrolling. And after it deleting
portion of layout that became invisible due to scrolling.
The layout has anchor point in text - a position. And then
dimensions (width and height) and offset (a delta horizontal or
vertical relative to perfect condition when a position in text
corresponds to 0,0 point in layout )
Understood for the scan forward or backward.
The only place where i needed to measure text size was to
positioning a scrollbar knob to represent its size & vertical
position approximately close to where you in text and text size. And
i really don't like that, since it requires scanning whole text..
But well... tradeoffs.. It win anyways, since i succeeded to avoid
most operations to be bound to text size. And only few left, that
you cannot avoid.
What do you scan in the text? Do you compute a complete pixel height of
the text or some approximation?
Thanks,
Thierry
