Hi Sean,

lBasicExamples
- #exampleShapes, select the yellow shape with red border -> inspector ->
Transformations Tab -> Click on Composition -> "ShouldNotImplement:
#multiplyOn: should not have been implemented in BlCompositeTransformation"

I don't understand how you guys find these kind of bugs :D

Fixed, thanks!

- In BlLinearLayoutExamples class>>#exampleVerticalLeftCenterRightRTL

��- the yellow sub-element does not appear at all. Maybe it should do a `c
vertical exact: 100.` like its siblings?��

This is a bug of the default extent of the element and its geometry. Element had default extent of 50@50 while geometry 1@1. Recently we added a smarter change recording mechanism that collects all extent/position changes within a frame and then merges them together in order to produce a single notification event. Since in that example we request element's size to be (50@50) there will be effectively no change in extent, so no event is produced and geometry does not adapt itself to match element's size => geometry's extent stays 1@1 and only a tiny yellow dot is rendered :)

Wrote a test and changed default element size to be (0@0).

- All BlAnimationExamples lead to deprecation warnings and DNU's, but *do��not even attempt* #exampleBallsAnim or face endlessly multplying debugger��windows!

Indeed :) A short answer is that it is expected, taking into account a class comment :D

A bit longer answer would require to read the following document��https://drafts.csswg.org/css-transforms/#interpolation-of-transforms��to get an idea of what is going on.

The point is that animating transformations like translation, scale or rotation is very non trivial. It requires us to decompose a resulting transformation matrix, interpolate decomposed values at animation time "t" and finally recompose it back as matrix :)

The only missing piece left is interpolation of matrix decomposition, so we are not far away from having animation examples work again.

Below is a screenshot of a composite transformation consisting of translations separated by scale and applied rotation on top of all. Note that resulting translation is not (20, 20) as one would think, instead it depends on scale and rotation which causes the initial problem. Also, one can see that "scaling" matrix components on the main matrix diagonal are not equal to (2, 2) because of rotation...

However, once done we will have a powerful transformation library!

BlTextEditElement class>>#exampleText
�� - insert some characters and then press [delete] -> "Error: Illegal
sub-sequence end index: 44"
�� - There is aBlSelectionHandler, but I can't seem to select any of the
text

Aha, I forgot about it, thanks! At this point��BlTextEditElement is only used internally by Moldable Editor so I will probably move it away from Bloc.��

Thanks for the feedback :)

Cheers,

Alex

On 24 October 2017 at 11:01, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

Indeed, instance variables is what we are mainly concerned with as well. We keep on trimming, but it still feels like too many variables.

Cheers,
Doru

> On Oct 24, 2017, at 8:59 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
>
>
>
> 2017-10-24 2:04 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:
> Tudor Girba-2 wrote
> > Thanks for the feedback!
>
> But of course! Thanks for pushing Bloc :) IMHO a clean low-level graphics
> framework is the linchpin to unleash a tremendous amount of creativity in
> the Pharo community. I have several dream projects that I placed on
> long-term hold after getting stuck in Morphic quicksand :/
>
>
> Tudor Girba-2 wrote
> >> - How would one do e.g. a ticking clock in Bloc? The only possibly
> >> relevant
> >> example I see is BlAnimatedCursor. Is that a typical usage? One thing
> >> that
> >> I'm not sure how to translate to a BlElement is that the cursor seems to
> >> be
> >> responsible for starting and stopping the animation via #activateOn:,
> >> which
> >> doesn't exist for an element. How would one prevent an element's
> >> animation
> >> from continuing to run after a space was closed?
> > What do you mean?
>
> I guess I mean what is the Bloc version of #step that would enable us to do
> e.g. Squeak's mouse-eyes-tracking-the-cursor or Lively Kernel's clock:
> <http://forum.world.st/file/t128965/Chromium5.png>
>
>
> Tudor Girba-2 wrote
> >> - BlElement has 278 instance-side methods. A frequent battle cry against
> >> Morphic was the bloated Morph class with 899. Definitely an improvement,
> >> but
> >> are we "there yet��?
> > What do you mean?
>
> Is there a consensus on a maximum number of instance-side methods before a
> class becomes impossible to understand, and if so where does BlElement fall
> on that scale?
>
>
>
>
> I dont think this number alone is a problem. As long as the "responsibility" of this
> class is well structured.
> A problem with the Morph class is, that it acts as many things at once.
> A structured container, a model, a view, a graphical object, a widget base ...
>
> About BlElement, I am more afraid about the number of instance variables
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."