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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com.
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@fit.cvut.cz 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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com.
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@fit.cvut.cz 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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com.
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 bliznjan@fit.cvut.cz 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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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
abergel wrote
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 <
bliznjan@.cvut
> 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-td48...
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-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com. _______________________________________________ Moose-dev mailing list
Moose-dev@.unibe
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@.unibe
-- View this message in context: http://forum.world.st/Roassal2-Events-forwarding-pressed-modifier-keys-tp487... Sent from the Moose mailing list archive at Nabble.com.
-
Alexandre Bergel -
Jan Blizničenko