Contextmenu location

[hotNipi]

Oh of course. But the values for bbox will be in which order then?

[dceejay]

left bottom right top (where 0 0 is top left ) - as those are the two most used corners to attach a sub menu to...

[hotNipi]

@dceejay

left bottom right top

So the element.getBoundingClientRect() then and not the element.getBBox()

[dceejay]

Well for the button you want to attach to the corners of that and not the text inside

[Steve-Mcl]

Dave, are you referring to the context menu location here?

Typically (at least in windows, chrome & other systems that support context menus) context menus popup with the TOP LEFT corner aligned to the mouse coordinates (i.e. aligning top left to pageX, pageY).

that said, the bounding box info is very useful if (for example) you don't like that behaviour (or want a emulate a drop-down/menu off a button type behaviour)

(Apologies if I am misunderstanding your point)

[dceejay]

See this discussion / wrinkle Contextmenu location
If you click a button you want the submenu tree to grow from that. Not some random point you click on.

[greenembrace]

Hi @Steve-Mcl, sorry different time zones. Yes click does work, but I was having difficulties with it (3-5 clicks before recognition) on a 400mm screen I use as my may house control console. So I thought if I also used touchstart I might increase my hit rate. It's my partner who gets more frustrated than me... i'm trying not to put them off using the system. I will try increasing the target area.

thanks

[Steve-Mcl]

Understand. @BartButenaers or I will fix the lack of coordinates in touch events before next release.

[BartButenaers]

I will do that very soon. Just need to finish a couple of things for other users.

[BartButenaers]

@Steve-Mcl

No need for any legacy flags as far as I can see Bart

Hey Steve (@Steve-Mcl),
Finally a little bit of time to fix this. But ...
The output message of the button widget and state-trail are currently nicely aligned, but our SVG node output message (when a shape is being clicked) looks completely different:

Not sure how I can align our output message to both other nodes, without breaking existing flows?
All suggestions are welcome!

[dceejay]

Just add them as well - your existing use will (or should) just ignore the "new" high level event property.
(and you can always migrate/deprecate over time)

[BartButenaers]

@dceejay

deprecate over time

Thanks Dave!
Indeed then I will add to the docs that this field is obsolete, and will be removed in the future ...

[BartButenaers]

Finally found some time to implement this on our "panzoom" branch on Github (which will become our version 2.0). This is the output message when an SVG element is clicked:

As you can see we have an extra set of coordinates (SvgX and SvgY), which are not available in the other 2 nodes above. These represent the coordinates inside the SVG coordinate system.

Wanted to solve this without breaking change, but unfortunately we already used the msg.event field in the past to send the type of event (e.g. "click"). Cannot solve that. And since we have now a breaking change anyway, I have also remove our msg.position and msg.coordinates also. Have added this to our 2.0 migration guide:

[BartButenaers]

I have now also added a drawing to the readme page to explain the different coordinate systems:

Because I'm afraid that otherwise users might get lost ...

[BartButenaers]

I'm almost finished with the 2.0.0 release of the SVG node, but now I need to have a look at the contextmenu node (because they are quite related to each other).

Currently there are two ways to specify the location in the contextmenu node:

1. Fixed coordinates:

   

2. Via the input message:

   

   Via input message means we get the location from (hardcoded) msg.position.x and msg.position.y, because the Svg node 1.x.x did use that message field.

But SVG node 2.0.0 will send the coordinates in msg.event.x and msg.event.y. To avoid everybody having to add Change nodes (between the SVG and Contextmenu node), the input x and y message fields should be customizable in the ContextMenu node.

Now I'm wondering whether I should remove the 'position' dropdown in the ContextMenu node and instead use two typedInput fields (for x and y), where you can select type 'msg' or 'number' (the latter one is for fixed coordinates):

Does this make sense?

[Paul-Reed]

Hey Bart, will the event.bbox array remain unchanged?

[BartButenaers]

Yes the SVG node output message will contain the event (incl. bbox) like we discussed above. The only problem is that the SVG node 2.0.0 sends all that info in msg.event (instead of msg.position), but currently the ContextMenu node still expects the data to arrive in the input message field msg.position.

So I don't want the ContextMenu node to keep getting his data hardcoded from msg.position. Would like that you can specify in the contextmenu node in which msg field the data will arrive...