On Mar 17, 2019, at 5:53 PM, pd-dev-request@lists.iem.at wrote:
Date: Sun, 17 Mar 2019 17:53:32 +0100 From: "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> To: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> Subject: Re: [PD-dev] Fw: Re: local canvas-only pd_bind Message-ID: trinity-747b5b71-f76b-4152-b9e3-32b84eb46d99-1552841612281@3c-app-gmx-bs56
Content-Type: text/plain; charset=UTF-8
But, no mouseup unfortunately.
on mousedown, the widget could assign itself to a "grab" variable, and a mouseup event sends a message to the object who has the current grab.
Basically yes. I've implemented a similar strategy in a "poor man's UIKit" for my lua environment ala Apple's UIKit: https://github.com/danomatika/loaf-ingredients/tree/master/hui https://github.com/danomatika/loaf-ingredients/tree/master/hui
The lowest (sub)view that received the mouse down becomes the active subview and receives the eventual mouse up, no matter where it may occur. Mouse position is scaled to match the coordinates of the (sub)view.
another question: if we choose to go with a widget, can we just add this functionality to [cnv] ? after all, it can be made invisible by setting the visible width and height to 0.
It might be good to design this in such a way that it can be used within the other UIs and possible externals. Again, UIKit's approach to this is nice in that you only have to think about what';s going on within you're view as mouse events are only propagated down when the mouse is over and interstices with the lowest (sub)view.
In any case, this is getting more complicated that my original intention (simple [mouse] analogy to [key]), however I am familiar with some of the approaches and we could mock up a test proposal. If this can be done in a no-to-complicated manner, it's a win for everyone.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Regardless of how mouse events are best exposed to the user (via widget or message-to-canvas method), there seems to be consensus that whoever got the most recent mousedown should receive the following mouseup. In a single-touch configuration that is obvious, analogous to a monophonic midi keyboard. It is different for multi-touch, but we're happy with single touch mouse data, right? (in 2019...).
Since I focused mostly on the widget approach, that is where I can best perceive opportunities, albeit not in detail yet. In the mousepad code that is now online for discussion, you can see how the object sets up communication channels with fixed names for the purpose of communicating with the properties abstraction:
https://github.com/katjav/pd-mouse-trial/blob/master/mousepad/mousepad.c#L76...
The base symbol for send and receive name is the pointer to object, converted to hex. Rather similar to how all GUIs identify in their messages for Tk. The pointer is unique by definition. So it is pretty safe to use in send/receive names, in particular because a message to a deleted receiver won't crash anything. It seems to works well for the properties abstraction who gets the base symbol passed as an argument during its instantiation. The abstraction is loaded in a way similar to a help patch but the symbol argument helps it to respond to the proper object.
The same fixed symbol might be used to request mouseup from a global mouseup-dispatcher. The object sends its receive name to the dispatcher after receiving a mousedown, which only one widget at a time can receive. The mouseup dispatcher only has to remember the last receiver name, and at mouseup time send a message to it. Of course it is important that objects comply to the rule, that is, sending their name only after getting the mousedown.
What do you think, is it realistic? Is this just another description of what is already proposed? At least a global-mouseup-to-local-receiver method like this seems less invasive than adapting the widgetbehavior infrastructure for data that only one or a few classes would use.
Katja
On 3/17/19, Dan Wilcox danomatika@gmail.com wrote:
On Mar 17, 2019, at 5:53 PM, pd-dev-request@lists.iem.at wrote:
Date: Sun, 17 Mar 2019 17:53:32 +0100 From: "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> To: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> Subject: Re: [PD-dev] Fw: Re: local canvas-only pd_bind Message-ID: trinity-747b5b71-f76b-4152-b9e3-32b84eb46d99-1552841612281@3c-app-gmx-bs56
Content-Type: text/plain; charset=UTF-8
But, no mouseup unfortunately.
on mousedown, the widget could assign itself to a "grab" variable, and a mouseup event sends a message to the object who has the current grab.
Basically yes. I've implemented a similar strategy in a "poor man's UIKit" for my lua environment ala Apple's UIKit: https://github.com/danomatika/loaf-ingredients/tree/master/hui https://github.com/danomatika/loaf-ingredients/tree/master/hui
The lowest (sub)view that received the mouse down becomes the active subview and receives the eventual mouse up, no matter where it may occur. Mouse position is scaled to match the coordinates of the (sub)view.
another question: if we choose to go with a widget, can we just add this functionality to [cnv] ? after all, it can be made invisible by setting the visible width and height to 0.
It might be good to design this in such a way that it can be used within the other UIs and possible externals. Again, UIKit's approach to this is nice in that you only have to think about what';s going on within you're view as mouse events are only propagated down when the mouse is over and interstices with the lowest (sub)view.
In any case, this is getting more complicated that my original intention (simple [mouse] analogy to [key]), however I am familiar with some of the approaches and we could mock up a test proposal. If this can be done in a no-to-complicated manner, it's a win for everyone.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-
Dan Wilcox -
katja