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