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-td4…
>>>>
>>>> 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-tp48…
>>>> 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-tp48…
>> 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-tp48…
Sent from the Moose mailing list archive at
Nabble.com.