Smalltalk › Pharo › Pharo Smalltalk Developers

[bloc] shape size?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

69 messages Options

1234

Igor Stasenko

Re: [bloc] shape size?

On 3 April 2016 at 23:30, Thierry Goubier <[hidden email]> wrote:

Le 03/04/2016 21:58, Igor Stasenko a écrit :

On 3 April 2016 at 22:32, Thierry Goubier <[hidden email]
<mailto:[hidden email]>> wrote:

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

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

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

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

<mailto:[hidden email]
<mailto:[hidden email]>>>> 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). 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 )

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.

Regards,

Thierry

Best regards,
Igor Stasenko.

Igor Stasenko

Re: [bloc] shape size?

On 3 April 2016 at 23:41, Igor Stasenko <[hidden email]> wrote:

On 3 April 2016 at 23:30, Thierry Goubier <[hidden email]> wrote:
Le 03/04/2016 21:58, Igor Stasenko a écrit :

On 3 April 2016 at 22:32, Thierry Goubier <[hidden email]
<mailto:[hidden email]>> wrote:

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

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

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

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

<mailto:[hidden email]
<mailto:[hidden email]>>>> 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).

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)

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 )

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.

Regards,

Thierry

--
Best regards,
Igor Stasenko.

Best regards,
Igor Stasenko.

Thierry Goubier

Re: [bloc] shape size?

Le 03/04/2016 22:46, Igor Stasenko a écrit :

>
>
> On 3 April 2016 at 23:41, Igor Stasenko <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
> On 3 April 2016 at 23:30, Thierry Goubier <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Le 03/04/2016 21:58, Igor Stasenko a écrit :
>
>
>
> On 3 April 2016 at 22:32, Thierry Goubier
> <[hidden email] <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
>
> Le 03/04/2016 20:01, Igor Stasenko a écrit :
>
>
>
> On 3 April 2016 at 20:51, Thierry Goubier
> <[hidden email]
> <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>
> <mailto:[hidden email]
> <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>>> wrote:
>
> Le 03/04/2016 19:12, Igor Stasenko a écrit :
>
>
>
> On 3 April 2016 at 19:48, Thierry Goubier
> <[hidden email]
> <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>
> <mailto:[hidden email]
> <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>>
> <mailto:[hidden email]
> <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>
>
> <mailto:[hidden email]
> <mailto:[hidden email]>
> <mailto:[hidden email]
> <mailto:[hidden email]>>>>> 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

Igor Stasenko

Re: [bloc] shape size?

On 4 April 2016 at 00:18, Thierry Goubier <[hidden email]> wrote:

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.

Yes. I, of course did not made it dedicated only for text. But i guess text is only single user of it so far.

But it could be worth subclassing ScrollBar for that purpose.

Unfortunately, my cognitive capacity was not that high at that moment, in order to understand how ScrollBar is working and what needs to be done in order to adapt it to my text model. Or maybe because when i was looking at its implementation the only thing i was thinking is not to run screaming in terror.

Pick one explanation, that suits you best :)

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?

Well, for scrollbars it is just counting lines of text. For layout , it is of course, fully precise text layout & kerning yadda yadda.

Thanks,

Thierry

Best regards,
Igor Stasenko.

Thierry Goubier

Re: [bloc] shape size?

Le 03/04/2016 23:31, Igor Stasenko a écrit :

>
>
> On 4 April 2016 at 00:18, Thierry Goubier <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
> 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.
>
>
> Yes. I, of course did not made it dedicated only for text. But i guess
> text is only single user of it so far.

Ok.

> But it could be worth subclassing ScrollBar for that purpose.
>
>
> Unfortunately, my cognitive capacity was not that high at that moment,
> in order to understand how ScrollBar is working and what needs to be
> done in order to adapt it to my text model. Or maybe because when i was
> looking at its implementation the only thing i was thinking is not to
> run screaming in terror.

:)

> Pick one explanation, that suits you best :)

I'm using the same explanation when I see some widgets. I wanted to use
a button for expand/unexpand in a tree, looked at the variants of
ButtonMorphs (and three state button morphs and...), got a headache and
just took a normal Morph with a custom handler :(

> 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?
>
>
> Well, for scrollbars it is just counting lines of text. For layout , it
> is of course, fully precise text layout & kerning yadda yadda.

Understood. Thanks again for all the explanations.

Thierry

Damien Pollet

Re: [bloc] shape size?

In reply to this post by Aliaksei Syrel

On 3 April 2016 at 12:27, Aliaksei Syrel <[hidden email]> wrote:

However, in most UI of applications (in web, mobile) it is extremely rare that clipping or event handling areas differ from drawing one (visual one - one that user sees in the end).

A counter-example that immediately comes to mind is Pharo's icon. You could imagine a minimal version of it with just the circle/wave/splash and the striped lighthouse inside (in the current icon, that has been filled with some semi-transparent whiteish gradient). The visual shape has voids (inside the circle, in between the stripes…) but the click-collision mask is basically a full disc. I'm pretty sure an early version of the icon had the same shape for rendering and click-catching, and you had to aim for the small opaque regions in it…

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Henrik Nergaard

Re: [bloc] shape size?

In reply to this post by Thierry Goubier

-----Original Message-----
From: Pharo-dev [mailto:[hidden email]] On Behalf Of Thierry Goubier
Sent: Sunday, April 3, 2016 9:52 PM
To: [hidden email]
Subject: Re: [Pharo-dev] [bloc] shape size?

Hi Henrik,

Le 03/04/2016 21:32, Henrik Nergaard a écrit :
> I changed it mostly because it was messing up the color when you did
> mouse-over (required to check the owner color to set it correctly when
> there was a selection, the code was ugly and with corner cases).

Ok.

> Encapsulating a morph with another morph just for a background color
> is kind of waste IMO. Causing unnecessary overhead for
> rendering/layout/eventHandling etc...

Rendering maybe a bit. Layout, maybe a bit. Event handling? Oh well, row morphs contents are already a tree of morphs at least 3 deep, what will be the effect of one more doing nothing?

> Mesurable? Don’t think I checked, but in the long run there is less allocations, less layout etc..

I guess that, given how FT works, it is hidden in the number of Morph creation per drawOn: :)

> I would also argue that
> ------------------
> (highligtedRowIndexes includes: rowIndex) ifTrue: [
> row selectionColor: (self owner colorForSelection:
> primarySelectionIndex = rowIndex) ].
> -----------------
> Is better than
> -----------------
>
> rowSubviews add: ((highligtedRowIndexes includes: rowIndex)
> ifTrue: [
> "IMPORTANT: I need to set owner to nil because otherwise it will trigger an
> invalidation of the owner when adding morph to selectionMorph, causing an
> infinite loop"
> self
> toSelectionRow: (row privateOwner: nil)
> primary: primarySelectionIndex = rowIndex ]
> ifFalse: [ row ]) ].
> -----------------------

<I like the game with #privateOwner: in the FT code. Tells you a lot about ownership in Morphic :)

<At the same time, your new code isn't very clear. It is written just as the setting of a theme property where in fact it is setting the row as selected.
When pointing it out, I totally agree. Will fix that ;)

> Selection could be and drawn by the container, but then again you
> would need much more code and special logic (updating the
> damageRecorder with correct rectangles when selection changes for
> example) than to just extend and specialize one morph to be a row.

<I'm doing the selection draw by container, and, honestly, there is none of the complexity you describe. Selection is a model operation anyway, so it usually <triggers a redraw (because selection may move you elsewhere, if the model so chooses); if you have some caching in place (that FT hasn't), you gain a bit upon <redraw, but nothing noticeable.

No there won't be that complexity, I was thinking of mouse-over not the selection; apologies.

There is another reason for moving it into the container, but that reason is not public.
Ah, Yes; even/odd color difference per row.

> I would much rather prefer one specialized morph doing its thing, than encapsulate it.

I think the FTTableRowMorph has other duties anyway, so giving him that additional role is fine.

Regards,

Thierry

> Best regards,
> Henrik
>
> -----Original Message-----
> From: Pharo-dev [mailto:[hidden email]] On Behalf
> Of Thierry Goubier
> Sent: Sunday, April 3, 2016 8:58 PM
> To: Pharo Development List <[hidden email]>
> Subject: Re: [Pharo-dev] [bloc] shape size?
>
> Le 03/04/2016 20:00, Henrik Nergaard a écrit :
>>
>>> Let me return you the question then: do you do a composition of
>>> submorphs if you're trying to get a different drawOn:?
>>
>>> 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.
>>
>> Did, not anymore.
>>
>> FTTableRowMorph>>#selectionColor:
>
> Had to check the following code to be sure:
>
> (highligtedRowIndexes includes: rowIndex) ifTrue: [
> row selectionColor: (self owner colorForSelection:
> primarySelectionIndex = rowIndex) ].
>
> Was there a measurable inpact when changing that?
>
> Because I have now three ways of doing this, and all of them have trade-offs. For example the one above suppose that row items are a specific kind of Morph, i.e. FTTableRowMorph; one could do without a dedicated Morph subclass for rows and display the selection as a transparent colored rectangle over the row; this is what I do.
>
> Thierry
>

Best regards,
Henrik

Stephan Eggermont-3

Re: [bloc] shape size?

In reply to this post by Igor Stasenko

On 03-04-16 21:58, Igor Stasenko wrote:
> 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.

Which, if I understand it correctly, works fine for code editing,
but does not cover the needs of high-quality typesetting like we
might want in pillar rendering or advanced word processing.
Systems like TeX, Framemaker and InDesign need to recompute
layout back to the beginning of a hard page/column break, like a
new chapter, and page numbering requires whole document
recomputation, as references to page numbers in the text get a
new width. Most documents have enough spacing margin that
the recomputation does not propagate so far as to have a user
noticable impact. I used Framemaker version from version 5,
and that was able to do so with acceptable speed in 1995.
20 years of CPU improvements should allow us to do the same
in Smalltalk

Stephan

Igor Stasenko

Re: [bloc] shape size?

On 4 April 2016 at 10:47, Stephan Eggermont <[hidden email]> wrote:

On 03-04-16 21:58, Igor Stasenko wrote:

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.

Which, if I understand it correctly, works fine for code editing,
but does not cover the needs of high-quality typesetting like we
might want in pillar rendering or advanced word processing.
Systems like TeX, Framemaker and InDesign need to recompute
layout back to the beginning of a hard page/column break, like a
new chapter, and page numbering requires whole document
recomputation, as references to page numbers in the text get a
new width. Most documents have enough spacing margin that
the recomputation does not propagate so far as to have a user
noticable impact. I used Framemaker version from version 5,
and that was able to do so with acceptable speed in 1995.
20 years of CPU improvements should allow us to do the same
in Smalltalk

Well, the changes to text and amount of (re)computations they triggering was out of the scope of our discussion. Yes, indeed this is possible to do with acceptable speed.

But in addition to that, TxText was never thought as a base for full-fledged word processing. There's no model for paper-press era things, like page numbers, chapters, columns etc.

Its primary focus is to support displaying text in our UI and overcome shortcomings of old model.

Since most of text is source code and for code editing, not a surprise that most features was prioritized accordingly around that fact.

Frankly i don't think we need to focus on making yet another all-doing, all-knowing word processor. First, it is huge investment of workforce and time, and second - it is investment with no return or infinitelysmall marginal return.

Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.

Stephan

Best regards,
Igor Stasenko.

1234