26 Jul
2015
26 Jul
'15
12:04 a.m.
And one more thing...
RTResizable is _NOT_ alone; it needs three (I think) more classes --
DCRTRectangle (which is terrible useless name), DCTRResizeCanceled, and
newly DCTRAnnouncingOverseer; which were not copied, so in pure roassal it
will not work at all.
(It worked for you, because you had peteruhnak/roassal-contrib package
loaded in the image).
I've made new updates to the classes, but if you really want to include it
in Roassal I feel its quite heavy duty solution, but it's up to you. (Just
make sure to test it in pure roassal so all classes that are needed are
present).
I wanted to write for it tests, but my ci.inria job can't run roassal tests
anyway (because of missing cairo) so I didn't bother; sorry.
Thanks,
Peter
On Fri, Jul 24, 2015 at 4:23 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
On Fri, Jul 24, 2015 at 3:41 PM, Alexandre Bergel
<alexandre.bergel(a)me.com
Okey... I will resolve it on my side if it will annoy me long enough.
This was meant just for demonstration, because it's not complete yet ---
for example if you click on unrelated element (that doesn't have
RTResizable) it will not deselect it, and more. So the implementation will
still change... but if the current state is enough for you, then whatever.
I also assume that there is no way to intercept "all" clicks? I guess
TRMorph might now.
wrote:
I think
that TRDrag* events should require that you are over the
dragged element with your
mouse, because now the behavior is that if the
mouse gets outside the element, drag events are still being fired. But
maybe I should fix this on my side.
All these event business is hard to get right. However, with Roassal3 (on
top of Bloc) this will all be much easier since BlMorph will be behind each
Roassal element. I therefore expect the morph to handle events in a much
better way than TRShape.
To better illustrate my point look at this
https://www.youtube.com/watch?v=4rHdiwGdr4s
When the mouse is completely out of the element
the resizing is still
occurring (because the drag event is still being applied),
and then compare
it to the behavior of resizing Playground -- there it happens only where it
makes sense.
Yes, it makes sense.
I haven't found any applicable example
directly in Roassal, but you can
look into my
smalltalkhub peteruhnak/roassal-contrib repo
(same as we used before
for moving stuff from dynacase)
at DCRTResizable>>example
Yes, this is an excellent example! I have also seen that you need to
connect the element to the view: if one click on the view, then the you
want to remove the handle. Bloc will offer this feature.
The previous class RTResizeable has been renamed
as RTSimpleResizable and
the class DCRTResizable is now called RTResizable. I have saved the package
with DynaCASE-Roassal2-AlexandreBergel.157.
Just a note, your previous class was called RTResizEable, with an extra
"e", so if someone used it it will break now. But I don't know if Pharo
has
deprecation mechanism for classes. (The proper spelling is without the
extra "e" - resizable.)
Peter