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 [image: Inline images 1] A bit longer answer would require to read the following document https://drafts.csswg.org/css-transforms/#interpolation-of-transforms <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! [image: Inline images 1] 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.ht ml
-- www.tudorgirba.com www.feenk.com
"Sometimes the best solution is not the best solution."
