[Roassal2] Events forwarding pressed modifier keys
Locked
[Roassal2] Events forwarding pressed modifier keys
 
|
Hi
I decided to propose changes to Trachel and Roassal based on discussion initiated by myself here: http://forum.world.st/Getting-whether-specific-key-is-currently-pressed-td4877401.html Main change is that all Trachel and Roassal user input events now forward which modifier keys are pressed. While I was poking TRMorph, I also tried to simplify few methods in it and fixed that TRMouseMove event had wrong position (visible on exampleMovingEdges). My goal for our DynaCASE was to be able to do more than only select elements (by clicking or doing marquee selection), but also to add more elements to current selection if shift is being held down (control would be better than shift, but control doesn't work quite right). It seems my goal was accomplished if my changes to Roassal are used: http://www.mediafire.com/watch/tbnytwaxy0nvb6c/multiselect_x264.mp4 mcz files are here: Trachel: http://www.mediafire.com/download/jpy46jrdx1u922p/Trachel-bliznjan.349.mcz Roassal: http://www.mediafire.com/download/kih8bho9273k88p/Roassal2-bliznjan.1225.mcz Jan |
|
|
Hi Jan,
Sorry for the late reply. Feb is holidays time in Chile. __Thanks you__ very much for your change. This is a great work! The video is really appealing! I have merged your version. Cheers, Alexandre > On Feb 16, 2016, at 6:49 PM, Jan Blizničenko <[hidden email]> wrote: > > Hi > > I decided to propose changes to Trachel and Roassal based on discussion > initiated by myself here: > http://forum.world.st/Getting-whether-specific-key-is-currently-pressed-td4877401.html > > Main change is that all Trachel and Roassal user input events now forward > which modifier keys are pressed. While I was poking TRMorph, I also tried to > simplify few methods in it and fixed that TRMouseMove event had wrong > position (visible on exampleMovingEdges). > > My goal for our DynaCASE was to be able to do more than only select elements > (by clicking or doing marquee selection), but also to add more elements to > current selection if shift is being held down (control would be better than > shift, but control doesn't work quite right). > It seems my goal was accomplished if my changes to Roassal are used: > http://www.mediafire.com/watch/tbnytwaxy0nvb6c/multiselect_x264.mp4 > > mcz files are here: > Trachel: > http://www.mediafire.com/download/jpy46jrdx1u922p/Trachel-bliznjan.349.mcz > Roassal: > http://www.mediafire.com/download/kih8bho9273k88p/Roassal2-bliznjan.1225.mcz > > Jan > > > > -- > View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp4877934.html > Sent from the Moose mailing list archive at Nabble.com. > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Roassal2] Events forwarding pressed modifier keys
|
|
Hi,
Thanks for merging it. There are two things (and they both would take your time I'm afraid) I'd like to discuss about that. First is that I'd like to ask for giving me permission to push into Roassal and Trachel repositories. Second thing, which requires more time and text from my side, is following problem with that "TRMouseMove event had wrong position (visible on exampleMovingEdges)". Thing is, some TREvent events have their position just directly taken from MorphicEvent, but some events have them translated using something like trachelEvent position: trachelCanvas camera fromPixelToSpace: morphicEvent position which is the same translation as TREvent>>#positionFromCamera does. So in some subclasses of TREventthere is this translation already made and saved into "position" from the beginning and therefore calling positionFromCamera on them does not make any sense because it would do the same translation twice (TRKeyDown, TRMouseClick, TRDoubleClick, TRMouseWheel and now also TRMouseMove), but some of them have their original position, so to get their translated position, one HAS to use that positionFromCamera (TRMouseDragEnd, TRMouseDragStart, TRMouseDragging, TRMouseEnter, TRMouseLeave and originally also TRMouseMove). The initial translation happens (or doesn't) in TRMorph methods beginning with "tr...", like "trMouseMove:". trMouseMove originally did not do this translation, but mentioned exampleMovingEdges didn't do this translation either, so it had wrong position. I added this translation into TRMorph, so TRMouseMove>>#position is now already translated, but now, when I look at it again, I am not sure if I should have done that because it could break other users, not sure what should be changed there. Maybe that example, maybe the TRMorph>>#trMouseMove: like I did, or maybe it should be unified and all events should already have this position translated and TREvent>>#positionFromCamera should be removed, or none events should be already translated and users of these events should use this TREvent>>#positionFromCamera in some cases, I don't know. Simplest way would be to just change that example and most uniform way would be probably to have all TREvents their position already translated and TREvent>>#positionFromCamera removed, but it would mean that all users of TRMouseMove, TRMouseDragStart, TRMouseDragEnd, TRMouseDragging, TRMouseEnter and TRMouseLeave would need to adapt. Changing any of this in TR/RT classes would be matter of few seconds-minutes for me, but this is more of a desing choice. I hope the information I wanted to tell could be decrypted out of that text :) Jan
|
|
|
I have seen you did a major rewrite. I did not go in detail over your change.
We should always be able to get the position of the mouse in pixel (0 @ 0 is the top left of the morph), and in the space (subject to the camera). I do not understand the reason of changing all the users of the TREvent classes. Can you give examples? Alexandre > On Feb 26, 2016, at 8:12 AM, Jan Blizničenko <[hidden email]> wrote: > > Hi, > > Thanks for merging it. > There are two things (and they both would take your time I'm afraid) I'd > like to discuss about that. > > First is that I'd like to ask for giving me permission to push into Roassal > and Trachel repositories. > > Second thing, which requires more time and text from my side, is following > problem with that "TRMouseMove event had wrong position (visible on > exampleMovingEdges)". > Thing is, some TREvent events have their position just directly taken from > MorphicEvent, but some events have them translated using something like > trachelEvent position: trachelCanvas camera fromPixelToSpace: morphicEvent > position > which is the same translation as TREvent>>#positionFromCamera does. > So in some subclasses of TREventthere is this translation already made and > saved into "position" from the beginning and therefore calling > positionFromCamera on them does not make any sense because it would do the > same translation twice (TRKeyDown, TRMouseClick, TRDoubleClick, TRMouseWheel > and now also TRMouseMove), but some of them have their original position, so > to get their translated position, one HAS to use that positionFromCamera > (TRMouseDragEnd, TRMouseDragStart, TRMouseDragging, TRMouseEnter, > TRMouseLeave and originally also TRMouseMove). The initial translation > happens (or doesn't) in TRMorph methods beginning with "tr...", like > "trMouseMove:". > trMouseMove originally did not do this translation, but mentioned > exampleMovingEdges didn't do this translation either, so it had wrong > position. I added this translation into TRMorph, so TRMouseMove>>#position > is now already translated, but now, when I look at it again, I am not sure > if I should have done that because it could break other users, not sure what > should be changed there. Maybe that example, maybe the > TRMorph>>#trMouseMove: like I did, or maybe it should be unified and all > events should already have this position translated and > TREvent>>#positionFromCamera should be removed, or none events should be > already translated and users of these events should use this > TREvent>>#positionFromCamera in some cases, I don't know. Simplest way would > be to just change that example and most uniform way would be probably to > have all TREvents their position already translated and > TREvent>>#positionFromCamera removed, but it would mean that all users of > TRMouseMove, TRMouseDragStart, TRMouseDragEnd, TRMouseDragging, TRMouseEnter > and TRMouseLeave would need to adapt. Changing any of this in TR/RT classes > would be matter of few seconds-minutes for me, but this is more of a desing > choice. I hope the information I wanted to tell could be decrypted out of > that text :) > > Jan > > > abergel wrote >> Hi Jan, >> >> Sorry for the late reply. Feb is holidays time in Chile. >> >> __Thanks you__ very much for your change. This is a great work! >> >> The video is really appealing! >> I have merged your version. >> >> Cheers, >> Alexandre >> >>> On Feb 16, 2016, at 6:49 PM, Jan Blizničenko < > >> bliznjan@.cvut > >> > wrote: >>> >>> Hi >>> >>> I decided to propose changes to Trachel and Roassal based on discussion >>> initiated by myself here: >>> http://forum.world.st/Getting-whether-specific-key-is-currently-pressed-td4877401.html >>> >>> Main change is that all Trachel and Roassal user input events now forward >>> which modifier keys are pressed. While I was poking TRMorph, I also tried >>> to >>> simplify few methods in it and fixed that TRMouseMove event had wrong >>> position (visible on exampleMovingEdges). >>> >>> My goal for our DynaCASE was to be able to do more than only select >>> elements >>> (by clicking or doing marquee selection), but also to add more elements >>> to >>> current selection if shift is being held down (control would be better >>> than >>> shift, but control doesn't work quite right). >>> It seems my goal was accomplished if my changes to Roassal are used: >>> http://www.mediafire.com/watch/tbnytwaxy0nvb6c/multiselect_x264.mp4 >>> >>> mcz files are here: >>> Trachel: >>> http://www.mediafire.com/download/jpy46jrdx1u922p/Trachel-bliznjan.349.mcz >>> Roassal: >>> http://www.mediafire.com/download/kih8bho9273k88p/Roassal2-bliznjan.1225.mcz >>> >>> Jan >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp4877934.html >>> Sent from the Moose mailing list archive at Nabble.com. >>> _______________________________________________ >>> Moose-dev mailing list >>> > >> Moose-dev@.unibe > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list > >> Moose-dev@.unibe > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp4877934p4880960.html > Sent from the Moose mailing list archive at Nabble.com. > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Roassal2] Events forwarding pressed modifier keys
|
|
I'll answer that in the very end of following pretty long post to explain it better :)
For example is you run following code: ---------------------------- |view box block| view := RTView new. box := RTBox element. box @ RTDraggable. view add: box; open. Transcript open. block := [ :event | Transcript show: ('position: ', event position asString, ', translated: ', event positionFromCamera asString); cr ]. view when: TRMouseEnter do: block. view when: TRMouseLeftClick do: block. ---------------------------- Entering the little box and clicking on it result in different outputs (I mean too different). TRMouseEnter>>#position is position in morph and TRMouseEnter#>>positionFromCamera is position from camera center, but TRMouseLeftClick>>#position is position from camera center and TRMouseLeftClick#>>positionFromCamera is nonsense, so there is no way to get position in morph. It was exactly like that already before I rewritten structure of those methods, I changed it only for TRMouseMove, but that change has to be reverted (in TRMorph>>#trMouseMove: remove line "trEvent position: (trachelCanvas camera fromPixelToSpace: trEvent position)." ). So that's why I'm talking about it - same method on same original position provided by MorphicEvent (and also "real" position as user sees on screen) results in different positions in TREvent subclasses. All TREvent users already know about this difference, so for TRMouseLeftClick they call just "event position" but for TRMouseEnter they call "event positionFromCamera" to get exactly same thing. If this was unified (#position was always position in morph and #positionFromCamera was always position from camera center), they would need to unify these calls too. Jan
|
|
|
Wait… The script you provided does not seem to behave as it should.
Pressing the mouse left button does not trigger the block. And exiting the element trigger the callback. That is odd. I use: Roassal2-PeterUhnak.1235 Trachel-AlexandreBergel.352 Can you reproduce what I am describing? Alexandre > On Feb 26, 2016, at 11:50 AM, Jan Blizničenko <[hidden email]> wrote: > > I'll answer that in the very end of following pretty long post to explain it > better :) > > For example is you run following code: > ---------------------------- > |view box block| > view := RTView new. > box := RTBox element. > box @ RTDraggable. > view > add: box; > open. > Transcript open. > block := [ :event | Transcript show: ('position: ', event position asString, > ', translated: ', event positionFromCamera asString); cr ]. > view when: TRMouseEnter do: block. > view when: TRMouseLeftClick do: block. > ---------------------------- > > Entering the little box and clicking on it result in different outputs (I > mean too different). TRMouseEnter>>#position is position in morph and > TRMouseEnter#>>positionFromCamera is position from camera center, but > TRMouseLeftClick>>#position is position from camera center and > TRMouseLeftClick#>>positionFromCamera is nonsense, so there is no way to get > position in morph. It was exactly like that already before I rewritten > structure of those methods, I changed it only for TRMouseMove, but that > change has to be reverted (in TRMorph>>#trMouseMove: remove line "trEvent > position: (trachelCanvas camera fromPixelToSpace: trEvent position)." ). So > that's why I'm talking about it - same method on same original position > provided by MorphicEvent (and also "real" position as user sees on screen) > results in different positions in TREvent subclasses. All TREvent users > already know about this difference, so for TRMouseLeftClick they call just > "event position" but for TRMouseEnter they call "event positionFromCamera" > to get exactly same thing. If this was unified (#position was always > position in morph and #positionFromCamera was always position from camera > center), they would need to unify these calls too. > > Jan > > > abergel wrote >> I have seen you did a major rewrite. I did not go in detail over your >> change. >> We should always be able to get the position of the mouse in pixel (0 @ 0 >> is the top left of the morph), and in the space (subject to the camera). >> >> I do not understand the reason of changing all the users of the TREvent >> classes. Can you give examples? >> >> Alexandre >> >> >>> On Feb 26, 2016, at 8:12 AM, Jan Blizničenko < > >> bliznjan@.cvut > >> > wrote: >>> >>> Hi, >>> >>> Thanks for merging it. >>> There are two things (and they both would take your time I'm afraid) I'd >>> like to discuss about that. >>> >>> First is that I'd like to ask for giving me permission to push into >>> Roassal >>> and Trachel repositories. >>> >>> Second thing, which requires more time and text from my side, is >>> following >>> problem with that "TRMouseMove event had wrong position (visible on >>> exampleMovingEdges)". >>> Thing is, some TREvent events have their position just directly taken >>> from >>> MorphicEvent, but some events have them translated using something like >>> trachelEvent position: trachelCanvas camera fromPixelToSpace: >>> morphicEvent >>> position >>> which is the same translation as TREvent>>#positionFromCamera does. >>> So in some subclasses of TREventthere is this translation already made >>> and >>> saved into "position" from the beginning and therefore calling >>> positionFromCamera on them does not make any sense because it would do >>> the >>> same translation twice (TRKeyDown, TRMouseClick, TRDoubleClick, >>> TRMouseWheel >>> and now also TRMouseMove), but some of them have their original position, >>> so >>> to get their translated position, one HAS to use that positionFromCamera >>> (TRMouseDragEnd, TRMouseDragStart, TRMouseDragging, TRMouseEnter, >>> TRMouseLeave and originally also TRMouseMove). The initial translation >>> happens (or doesn't) in TRMorph methods beginning with "tr...", like >>> "trMouseMove:". >>> trMouseMove originally did not do this translation, but mentioned >>> exampleMovingEdges didn't do this translation either, so it had wrong >>> position. I added this translation into TRMorph, so >>> TRMouseMove>>#position >>> is now already translated, but now, when I look at it again, I am not >>> sure >>> if I should have done that because it could break other users, not sure >>> what >>> should be changed there. Maybe that example, maybe the >>> TRMorph>>#trMouseMove: like I did, or maybe it should be unified and all >>> events should already have this position translated and >>> TREvent>>#positionFromCamera should be removed, or none events should be >>> already translated and users of these events should use this >>> TREvent>>#positionFromCamera in some cases, I don't know. Simplest way >>> would >>> be to just change that example and most uniform way would be probably to >>> have all TREvents their position already translated and >>> TREvent>>#positionFromCamera removed, but it would mean that all users of >>> TRMouseMove, TRMouseDragStart, TRMouseDragEnd, TRMouseDragging, >>> TRMouseEnter >>> and TRMouseLeave would need to adapt. Changing any of this in TR/RT >>> classes >>> would be matter of few seconds-minutes for me, but this is more of a >>> desing >>> choice. I hope the information I wanted to tell could be decrypted out of >>> that text :) >>> >>> Jan >>> >>> >>> abergel wrote >>>> Hi Jan, >>>> >>>> Sorry for the late reply. Feb is holidays time in Chile. >>>> >>>> __Thanks you__ very much for your change. This is a great work! >>>> >>>> The video is really appealing! >>>> I have merged your version. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>>> On Feb 16, 2016, at 6:49 PM, Jan Blizničenko < >>> >>>> bliznjan@.cvut >>> >>>> > wrote: >>>>> >>>>> Hi >>>>> >>>>> I decided to propose changes to Trachel and Roassal based on discussion >>>>> initiated by myself here: >>>>> http://forum.world.st/Getting-whether-specific-key-is-currently-pressed-td4877401.html >>>>> >>>>> Main change is that all Trachel and Roassal user input events now >>>>> forward >>>>> which modifier keys are pressed. While I was poking TRMorph, I also >>>>> tried >>>>> to >>>>> simplify few methods in it and fixed that TRMouseMove event had wrong >>>>> position (visible on exampleMovingEdges). >>>>> >>>>> My goal for our DynaCASE was to be able to do more than only select >>>>> elements >>>>> (by clicking or doing marquee selection), but also to add more elements >>>>> to >>>>> current selection if shift is being held down (control would be better >>>>> than >>>>> shift, but control doesn't work quite right). >>>>> It seems my goal was accomplished if my changes to Roassal are used: >>>>> http://www.mediafire.com/watch/tbnytwaxy0nvb6c/multiselect_x264.mp4 >>>>> >>>>> mcz files are here: >>>>> Trachel: >>>>> http://www.mediafire.com/download/jpy46jrdx1u922p/Trachel-bliznjan.349.mcz >>>>> Roassal: >>>>> http://www.mediafire.com/download/kih8bho9273k88p/Roassal2-bliznjan.1225.mcz >>>>> >>>>> Jan >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp4877934.html >>>>> Sent from the Moose mailing list archive at Nabble.com. >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> >>> >>>> Moose-dev@.unibe >>> >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>> >>>> Moose-dev@.unibe >>> >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp4877934p4880960.html >>> Sent from the Moose mailing list archive at Nabble.com. >>> _______________________________________________ >>> Moose-dev mailing list >>> > >> Moose-dev@.unibe > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list > >> Moose-dev@.unibe > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp4877934p4881029.html > Sent from the Moose mailing list archive at Nabble.com. > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Roassal2] Events forwarding pressed modifier keys
|
|
Well, now that's wierd. With fresh image 50614, loaded Roassal 1235 and Trachel 352, it triggers when I click anywhere on canvas (inside or outside the box), when I enter the box and when I leave the box.
I tried also Roassal 1232 and Trachel 351 (prior to my changes) and also image 50493 (preSpur) and it behaves exactly the same. Question is whether even that is right. No matter what (it's not related), in TRMorph>>#trMouseMove: there should be removed the line "trEvent position: (trachelCanvas camera fromPixelToSpace: trEvent position)." because it changes behavior of more things than I wanted. Jan
|
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |