ipyevents icon indicating copy to clipboard operation
ipyevents copied to clipboard

Consider returning normalized coordinates

Open mwcraig opened this issue 7 years ago • 6 comments
trafficstars

Would need to decide whether these are normalized in the current view of the widget or normalized in the "natural" coordinates of the widget, if any.

mwcraig avatar Dec 23 '17 20:12 mwcraig

Do you mean generalizing what you currently do for image widgets? ie, for each click, we would get the dimensions of the widget and return where the click was as a fraction of the total size?

pbugnion avatar Jan 01 '18 07:01 pbugnion

I hadn't thought about it that way, but yes. I think the only question really is whether the size of the widget includes the border and padding (if any) or not. For images, those are excluded because they aren't part of the image....so I suppose for consistency's sake they should also be excluded for others too.

The original suggestion was made at the end here:

Also, I'd think normalize versions (between 0 and 1) would be useful.

@maartenbreddels -- were you thinking normalized versions of all of the coordinates returned?

mwcraig avatar Jan 01 '18 16:01 mwcraig

For reference, the coordinates currently returned are:

Location of the mouse event

These attributes are standard properties of HTML mouse events.

  • screenX, screenY: Coordinates of the event relative to the user's whole screen.
  • clientX, clientY and x, y: Coordinates of the event relateive to the visible part of the web page in the browser.
  • pageX, pageY: Coordinates of the event relative to the top of the page currently being displayed.
  • offsetX, offsetY: Offset of this DOM element relative to its parents.
  • relativeX, relativeY: The location of the mouse relative to the current element (i.e. widget). This emulates the functionality of the layerX/Y attributes implemented in many browsers but not part of any standard.

Additional location for some types of widgets

  • arrayX, arrayY: Position of the mouse event in the underlying data object. For example, a click on an Image widget returns as arrayX and arrayY the coordinates of the click in the image. This location should be regarded as the approximate location the user intended given the difficulty of clicking accurately at the pixel level.

For widgets (like Label) for which there is no underlying array object these properties are not returned.

mwcraig avatar Jan 01 '18 17:01 mwcraig

Normalized would be nice, since there may be a scale associated to the image that does not correspond to pixels. And you never know the try image size in the browser right?

maartenbreddels avatar Jan 03 '18 20:01 maartenbreddels

Normalized would be nice

Just to be clear, you mean one normalized coordinate pair, or do you mean normalized versions of each of the x,y coordinates listed above? (screen, client, page, etc).

My leaning would be to provide normalized coordinates only for things like an image that have an intrinsic size).

mwcraig avatar Jan 03 '18 21:01 mwcraig

And you never know the try image size in the browser right?

The only in-browser image size I really trust is the naturalWidth/naturalHeight. My understanding is that the <img width/height> properties are completely meaningless...

mwcraig avatar Jan 03 '18 21:01 mwcraig