A Toga interactive plotting facility?

[paolofranzetti]

I am a python software developer working to astronomical data analysis software.

I recently discovered Beeware and Toga and I think they could be extremely useful for the astronomical (and, in general, scientific) community.

However what is really missing is an interactive plotting library. Interactive plots are widely used during scientific analysis and this kind of widget could give a boost to Toga usage in this context.

I think that starting from the toga.Canvas widget it could be quite easy to develop a plotting Toga module which implements an API similar to the matplotlib one but with the addiction of interactivity.

As a test I even wrote a brief script that plots a galactic spectrum and zooms into it using the mouse; just a few lines of code.

So here is the big question; are the "toga managers" interested in this idea ?

[freakboy3742]

Are we interested in the general concept? Sure! It sounds like an interesting use case for Toga; and I agree that science visualisation could be a really good use case for Toga.

However, does this feature need to be part of Toga itself? Almost certainly not. A charting library is the sort of feature that could happily live as a third-party library, imported by those projects that need it, using the basic widgets provided by Toga.

As evidence of this - we've already got toga-chart. That's a matplotlib backend, backed by Toga's canvas widget.

It doesn't currently implement of the interactive features of matplotlib, but that's entirely because we haven't been focussing on that widget specifically. If someone wanted to add support for interactive charts to toga-chart, I'd gladly look at any contributions; and if supporting interactivity in charts required additional to the base functionality of Canvas, I'd be happy to consider those changes as well.

[freakboy3742]

That said - Toga is a cross platform framework, and the APIs that are implemented need to keep that in mind. The action handler for a button is "press", not "click" - because if you're on a phone, you don't "click" anything. So - if you want to support mouse wheel scrolling, you'll need to propose an abstraction that makes sense on platforms that don't have a mouse wheel - like phones, and laptops with a trackpad.

A part from the naming, I thought to propose this useful feature (at least for me) because I saw the existence of the on_alt_* ones; also these handlers do not make sense on phones (as it is stated by "This event is not supported on Android or iOS."). Conversely, on laptops with a trackpad scrolling is a standard gesture.

There's a difference between "not implemented" and "can't be implemented". The intention for on_alt_ is that we'd likely do something like "long press" as the "alt" press on mobile. We haven't implemented that feature, but we know how it would be implemented, and the terminology doesn't require "right_click" (which betrays a specific, right-handed mouse implementation).

Scrolling is a standard gesture on trackpads - but we need to be clear about how "normal" UI scrolling interacts with gestures. If you put a canvas inside a scroll window... where does the "scroll" gesture go?

[paolofranzetti]

There's a difference between "not implemented" and "can't be implemented". The intention for on_alt_ is that we'd likely do something like "long press" as the "alt" press on mobile. We haven't implemented that feature, but we know how it would be implemented, and the terminology doesn't require "right_click" (which betrays a specific, right-handed mouse implementation).

My fault, I did not understood that "not supported" stands for "not implemented"

Scrolling is a standard gesture on trackpads - but we need to be clear about how "normal" UI scrolling interacts with gestures. If you put a canvas inside a scroll window... where does the "scroll" gesture go?

I think that in the case you described the "scroll" gesture should go in the canvas when the mouse in inside it and in the window otherwise.

Anyway I do not want to further discuss you development choices; the project is yours, the decisions are yours.

Just allow a kind advice from an old developer (my "first" python was 1.6). It is great that your framework is natively cross platform; but limiting its functionalities for the only reason to be "fully" cross platform may be counterproductive for its wide diffusion; many science groups develop python GUI applications that no one will ever use on a phone or a tablet.

[freakboy3742]

Scrolling is a standard gesture on trackpads - but we need to be clear about how "normal" UI scrolling interacts with gestures. If you put a canvas inside a scroll window... where does the "scroll" gesture go?

I think that in the case you described the "scroll" gesture should go in the canvas when the mouse in inside it and in the window otherwise.

I'm not sure I see how that works. How do you scroll the canvas itself in this case without literally reimplementing the scrolling behavior that ScrollContainer provides (including, but not limited to, actual scroll bars)?

Just allow a kind advice from an old developer (my "first" python was 1.6).

Mine too. Don't let my username fool you - I'm a nearing-greybeard who has been at this for a while :-)

It is great that your framework is natively cross platform; but limiting its functionalities for the only reason to be "fully" cross platform may be counterproductive for its wide diffusion; many science groups develop python GUI applications that no one will ever use on a phone or a tablet.

Sure - and there are features that we explicitly don't support on mobile for this reason. However, if you don't keep issues like "how will we implement this on mobile" in mind, you end up painting yourself into corner. I'm totally willing to accept "This isn't supported on mobile" as an answer - if there's a reasonable reason why that is the answer.

[paolofranzetti]

I think that in the case you described the "scroll" gesture should go in the canvas when the mouse in inside it and in the window otherwise.

I'm not sure I see how that works. How do you scroll the canvas itself in this case without literally reimplementing the scrolling behavior that ScrollContainer provides (including, but not limited to, actual scroll bars)?

I agree that I do not want to reimplement the scrolling behavior of the ScrollContainer. Here I am thinking of use cases when you want to link the scroll event to a different action. An example is a canvas containing a plot where you want to use the mouse wheel to zoom in and out the plot itself; this is a "quite standard" and appreciated behavior of many, if not all, scientific plotting facilities.

[freakboy3742]

I don't disagree that it is "quite standard". What I'm highlighting is that there is an interaction with existing scrolling behavior, and that discrepancy/overlap is something that needs to be resolved as part of any design/implementation.

Accomodating zoom in/out would be reasonably straightforward for macOS and mobile platforms, because multi-touch "pinch to zoom" has no ambiguity or overlap, and isn't currently being handled. However, I don't have enough experience with scroll wheel handling on Linux/Windows to comment on whether attaching the scroll wheel to the zoom action on canvas would result in unexpected behavior in any ScrollContainer wrapped around the canvas.