Is it possible to obtain information on the position of the mouse on an image?

[airylp]

I need to get the cursor position on an image when clicking on it, is this possible or will it be possible?

[Jacalz]

It is possible to do so already. You will want to create your own widget that wraps a canvas.Image and implements the desktop.Hoverable interface.

I think the code in https://github.com/fyne-io/fyne-x/pull/37/files#diff-e536d84af5d11e2b5f531ba5331c16afcf112baa5c55e451067fadaefc2d74ae likely should serve as a good example. The example is a utility meant to extend other canvas objects but you should be able to remove the function parameters and make it return a canvas.Image in the call to widget.NewSimpleRenderer(). I mean to use it as a good example for implementing the interface mostly as well as using the widget.NewSimpleRenderer() function.

[redmoon1945]

thx very much my friend, it works !!! Now this being said, I would have expected a much more simple process to get some events instead of "wrapping" every time each widget in this wrapper. Why not for example just registering listeners to the widget (common in other GUI framework). Wouldn't it be much better ?

[andydotxyz]

Our design is intended to be simpler than other GUI toolkits - to do this we must make common usage trivial but support more complex things through extension.
Our principle is to have a behaviour based API in the core widget library - in this case "position of mouse over an image" isn't really a behaviour so we don't include that in core.
Another reason to use extension rather than event placeholders to wire up is the huge difference between many of the devices we support. We muse use many abstractions to make this possible - and exposing all layers of these possible events would make a terrible API experience.

That said, if one of our widgets missed a common usage then we would try and add that to the core API.

[redmoon1945]

understood. The seek of "simplicity" is something I also strongly support and I congrat the devs to establish it as a design principle :-) Now, on the statement "we must make common usage trivial but support more complex things through extension.", the question is : what is "common usage", how is it evaluated ? This is a tough question. In my 40 years of development (I have worked with so many GUI toolkits...), I have found this is quite difficult to establish with objectivity, as it strongly depends on our own experience of software development and the readings we do.

I would like to suggest (and ready to exchange with the devs about it) that tracking mouse position over an image is indeed a core functionality, a quite common requirement actually. I have seen it many times in the projects I have worked on. I cannot prove that mathematically, it is based on experience only (so subjective). As I understand it, Fyne dedicates "widgets" to components that have interactions with the user (defined as user providing data / giving instructions to the component, although for Label, we have an interesting case here since there is no interaction whatsoever :-) So maybe the concept is no so well defined after all...). And with that in mind, you are also probably correct to reject Image as a widget, since the user does not provide data to it. However, I would argue that there is a third class of components, for which user (or actually the application) is interested to receive events from system ("observable" components ?). It can be mouse events ("mouseable"), tap events ("tappable"), created and destroyed events, resize event, etc. Image fall in this category.

With that in mind, if we accept the idea that receiving these events for an image is core functionality, I would propose that they get added to Image. I personally like the "register" pattern, because it is simple, solid and help to not clutter the "constructor" : Image.SetOnMouseIn, Image.UnsetOnMouseIn , etc.

Thanks to take the time to discuss these ideas with me, all the best !

[andydotxyz]

What you propose is simply not how our design is set up. You need to understand the difference between basic events and the higher level user intent/behaviour. A button has "OnTapped" because a button has a tapped intent that is important for a button. A list has "OnSelected" as tapping creates a selection.

The events for mouse, keyboard, tapped etc are all lower level. It is a widget developers job to wire events and visuals together to convey user interaction and the actions they instigate.

Widgets don't, and shouldn't, propagate low level events through their API - this diminishes the carefully crafted behaviour oriented APIs.

[Jacalz]

I don’t think the discussion is relevant to the original question any more. If there is more to discuss, please open a new discussion instead