Smalltalk › Frameworks & Tools › Moose

Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Peter Uhnak

Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

Hi Alex,

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.

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.

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

On another note:

I added methods for moving to RTLayoutTranslator for all sides, so you can probably move it to Roassal if it looks ok to you.

Thanks,

Peter

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

> 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.

> On another note:
> I added methods for moving to RTLayoutTranslator for all sides, so you can probably move it to Roassal if it looks ok to you.

Yes yes yes!

It is all in!

This is an excellent contribution!

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Peter Uhnak

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

On Fri, Jul 24, 2015 at 3:41 PM, Alexandre Bergel <[hidden email]> 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.

Okey... I will resolve it on my side if it will annoy me long enough.

> 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.

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.

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Peter Uhnak

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

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 <[hidden email]> wrote:

On Fri, Jul 24, 2015 at 3:41 PM, Alexandre Bergel <[hidden email]> 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.

Okey... I will resolve it on my side if it will annoy me long enough.

> 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.

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.

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

In reply to this post by Peter Uhnak

> 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.)

Oh yes, you’re right.
Well… Let’s see if someone complain. This is not a big deal.

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

In reply to this post by Peter Uhnak

I have included the Resizable from DynaCASE-Roassal2-PeterUhnak.156. The class DCTRAnnouncingOverseer does not exist then. All seems to work well.
(as you said, I have also included missing classes).
I have taken the latest roassal in a fresh image and all seems good.

Apparently your changes are not in the DynaCASE-Roassal2 package in the roassalcontrib repo right?

Alexandre

> On Jul 26, 2015, at 12:04 AM, Peter Uhnák <[hidden email]> wrote:
>
> 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 <[hidden email]> wrote:
> On Fri, Jul 24, 2015 at 3:41 PM, Alexandre Bergel <[hidden email]> 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.
>
> Okey... I will resolve it on my side if it will annoy me long enough.
>
>
> > 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.
>
> 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.
>
>
> 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
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Peter Uhnak

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

On Sun, Jul 26, 2015 at 9:41 AM, Alexandre Bergel <[hidden email]> wrote:

I have included the Resizable from DynaCASE-Roassal2-PeterUhnak.156. The class DCTRAnnouncingOverseer does not exist then. All seems to work well.
(as you said, I have also included missing classes).
I have taken the latest roassal in a fresh image and all seems good.

Apparently your changes are not in the DynaCASE-Roassal2 package in the roassalcontrib repo right?

This is odd, it's definitely there.

I downloaded Roassal and peteruhnak/roassal-contrib into a fresh image and it is there.

When you run DCRTResizable class>>example you should see this

(there have been changes compared to what's in Roassal - namely it's lazy loaded and resize deselection will occur if you click on any other element, whether resizable or not)

Name of the respective commits in roassal-contrib is

DynaCASE-Roassal2-PeterUhnak.161

and

DynaCASE-Trachel-PeterUhnak.54

Peter

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

Ah okay! I see. My mistake.

I did a few renames:
DCRTRectangle -> RTResizableRectangle
DCTRAnnouncingOverseer -> TRAnnouncingOverseer now part of Trachel

I have move DCTRResizeCanceled into Trachel under the name TRResizeCanceled
However, why TRResizeCanceled does belongs to Trachel? Shouldn’t it be in Roassal itself? It is created only by Roassal classes I see.

By the way, do you want me to save your Dynacase package without the classes I have migrated in Roassal and Trachel? Does this help?

Thanks for your improvements!

Cheers,
Alexandre

> On Jul 26, 2015, at 11:34 AM, Peter Uhnák <[hidden email]> wrote:
>
>
>
> On Sun, Jul 26, 2015 at 9:41 AM, Alexandre Bergel <[hidden email]> wrote:
> I have included the Resizable from DynaCASE-Roassal2-PeterUhnak.156. The class DCTRAnnouncingOverseer does not exist then. All seems to work well.
> (as you said, I have also included missing classes).
> I have taken the latest roassal in a fresh image and all seems good.
>
> Apparently your changes are not in the DynaCASE-Roassal2 package in the roassalcontrib repo right?
>
> This is odd, it's definitely there.
> I downloaded Roassal and peteruhnak/roassal-contrib into a fresh image and it is there.
>
> When you run DCRTResizable class>>example you should see this
> <2015-07-26_11:31:26.png>
> (there have been changes compared to what's in Roassal - namely it's lazy loaded and resize deselection will occur if you click on any other element, whether resizable or not)
>
> Name of the respective commits in roassal-contrib is
> DynaCASE-Roassal2-PeterUhnak.161
> and
> DynaCASE-Trachel-PeterUhnak.54
>
> Peter
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Peter Uhnak

Re: Roassal TRDrag events should be conditioned by TRMouseEnter and RTLayoutTranslator

I have move DCTRResizeCanceled into Trachel under the name TRResizeCanceled

However, why TRResizeCanceled does belongs to Trachel? Shouldn’t it be in Roassal itself? It is created only by Roassal classes I see.

I don't know.

Originally it was in Roassal, however that was the only Roassal-level event. So I moved it to Trachel and is now subclass of TRShapeEvent, because it also carries the shape of the clicked element.

But events are confusing for me... because I am still attaching Trachel events to Roassal elements...

el when: TRMouseClick do: [ :event | ... ]

So there's no clear separation anyway.

By the way, do you want me to save your Dynacase package without the classes I have migrated in Roassal and Trachel? Does this help?

No need to do that. I have to change it in my code first before I can remove it.

Peter

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev