[PD-dev] Fw: Re: local canvas-only pd_bind

katja katjavetter at gmail.com
Tue Mar 19 20:31:09 CET 2019


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#L764

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 at gmail.com> wrote:
>
>
>> On Mar 17, 2019, at 5:53 PM, pd-dev-request at lists.iem.at wrote:
>>
>> Date: Sun, 17 Mar 2019 17:53:32 +0100
>> From: "Christof Ressi" <christof.ressi at gmx.at
>> <mailto:christof.ressi at gmx.at>>
>> To: pd-dev <pd-dev at lists.iem.at <mailto:pd-dev at lists.iem.at>>
>> Subject: Re: [PD-dev] Fw: Re: local canvas-only pd_bind
>> Message-ID:
>> 	<trinity-747b5b71-f76b-4152-b9e3-32b84eb46d99-1552841612281 at 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/>
>
>
>
>





More information about the Pd-dev mailing list