Why does toga lack events for a large number of widgets other than Button?

[wanglifeng95]

In my spare time, I watched local APIs for Android, Windows, and Linux. I found that many widgets of Toga, such as Box, ImageView, Label, etc., may not have been able to add click or long press events, perhaps because Linux PyGobject is using Gtk3.0. In Gtk3.0, button can use signals to trigger events normally, but many other widgets can only be added to EventBox() to trigger events. That is, these widgets can have events,but they are no longer themselves,instead become EventBox objects. Therefore when Toga uses local APIs to add events to these widgets, it will cause problems, and ultimately, toga give up the events of those widgets, right?
But one difficulty with Python is mainly in mobile applications. If Toga's goal is to make Python apps run better on various platforms(desktops and mobile), The Desktop OS can be based on Python's built-in TKinder (which is converted to Toga code). TKinder is lightweight and stable, and it is well adapted to various system platforms on the desktop end. Then Toga can focus on the most promising intelligent mobile terminals in the future, and Toga can have a better set of code to unify the operation of various desktops and mobile platforms, and it is easier to maintain. Alternatively, Toga may follow the previous approach, and Toga's local API for Linux may be based on PYGobject GTK4.0 in the future, which is more user-friendly and allows widgets to easily add events without the need to use EventBox() to change themselves.
The above is my thoughts on Toga after studying it and the local APIs of various operaitting systems. I don't know if my ideas are appropriate. I really like Toga and hope it gets better and better.

[freakboy3742]

I'm not exactly sure I understand what the question is.

It feels like you've asking for a feature that is currently missing... but I can't work out from your description what that need actually is. It might be something to do with mouse press events... but you haven't really explained what it is that you want to do that you can't do.

If you're comparing Toga with Tkinter... I'd argue that Toga is already superior to Tkinter. Tkinter doesn't have a web widget, or a canvas widget; and it's not ever likely to be available on iOS, Android, web, or text console - features that Toga has right now. Are there things you can do in Tkinter that you can't do in Toga? Sure. But I can tell you from experience that it will be a lot easier to add missing features to Toga than to add features than it will be to add missing features to Tkinter.

If your suggestion is that Toga should be made a wrapper around GTK4 on all platforms... I guess you've never used GTK on any platform other that Linux. In my experience, GTK apps look awful on macOS, are only marginally better on Windows - and won't work on iOS, Android, web, or text console. The only one of those platforms that is even plausible as a future GTK target is web (and maybe Android). So this is a non-starter as well.

If you've got a feature request, can I ask that you actually describe the feature request, rather than theorising about potential fantasy rewrites of Toga?

[freakboy3742]

Ok so you would only differentiate and image from an Icon just by restricting its shape and size?

At least at present, there's no "built in" icons in Toga, but that's definitely something I would like to see change in time.

However, even in that eventuality, there needs to be a way to define an icon that the system doesn't provide. It's impossible for a GUI framework to provide every icon for every purpose. What does an app developer do when a new social media platform emerges, and they want to support it, but their GUI framework doesn't provide an icon representing that platform?

For the menu items I was simply making the case for the combination of an Icon and Text.

Sure - and I'm making the case that it's not "text and an icon" - it's a menu. That's a function that can be represented in an abstract way, and the way that abstract function is implemented need not be the same "text and an icon" on every platform. Compare the way that a phone renders Twitter and the way a desktop browser renders Twitter.

Let me show you a few code examples of how its done in Flutter:

Allow me to assure you that my resistance here has nothing to do with feasibility, API design, or familiarity with GUI toolkits. I'm very much aware how it can be done in many other frameworks. Completely aside from the fact that Toga is wrapper around 6 different GUI (and 1 TUI) frameworks, I've been various using GUI APIs for over 30 years at this point.

The implementation, if it were to be added to Toga, would be trivial. However, it would also undermine the design goals of Toga as a framework.

I guess you could be making specific widget for each user cases like a gallery a menu item etc .. but if you become too specific it will be limiting and much more work to maintain, no?

That's exactly the case I'm making.

Toga has explicitly stated as a design goal that we wrap abstract concepts, not specific widgets. Yes, this makes some use cases more difficult; but the benefit that comes from that is that apps are always well behaved and HIG-compliant examples of native apps. This is a design decision that has been made actively, with full awareness of the consequences.

(FWIW - this is also part of the reason why the name of the framework is Toga.

As for being "more work to maintain" - you're neglecting the role of third-party contributions to this space. In the long term, I'd consider it a failure if there isn't an ecosystem of useful, complex, third-party widgets encompassing interesting use cases. I'd also consider it a failure if the best of those don't find their way into Toga's core once they've proven robust and of general interest.

For that matter, if someone really wants a "clickable image", they could implement it right now as a third party widget. It wouldn't even be that much work. All I'm saying is that I'm not going to merge it into Toga as an official widget.

[l-o-u-i-s-g]

ok so is the confusion simply a poor choice of word "button" from my part? as this implies a more specific widget with a single purpose? But do you agree that Toga needs a way for developers to create other clickable widgets without the need to create code for each platforms, IOS, osX, android, linux etc? Correct me if I'm wrong but I believe that right now if I wanted to make a gallery widget or a menu_item widget I would need to write a version for each platforms?

[freakboy3742]

You're correct that to build a gallery widget at present you would currently need to write multiple platform-specific implementations.

I don't agree that Toga necessarily needs a way to create "clickable widgets". Toga's API intentionally doesn't expose a set of drawing primitives. It's a set of high level end-user use cases. That's deliberate, because it gives the backend implementations the flexibility to find the most appropriate representation of each high level use case. It also means we don't get into the weeds of trying to find cross-platform abstractions of low level concepts, which has plenty of potential to result in bad UX of apps when misused or abused, and results in slightly worse app performance (because every abstraction, by definition, introduces complexity).

Does this make it harder to implement a "gallery" widget? Yes. However - it also means we don't end up with Toga apps in the wild that have bad UX. From a broad project perspective - I'm willing to accept the compromise of having less features in the short term if it means the public interface for the features we do have are well designed, and yield a good cross-platform, HIG-compliant user experience.

Would it be nice to have primitives to make writing new widgets easier? Possibly. However, as a data point - almost without exception, every request for "clickable images" has been a request for one of 4 things:

1. "Pretty buttons", because "I don't like the macOS/GTK/Windows style of buttons".
2. "Buttons so I an implement a tab bar on mobile"
3. A image gallery
4. A high level app navigation control

(1) is just plain wrong, and I will die on this hill. Consistency of UI elements within the OS is a feature. It aids usability. Apps that decide they know better and restyle key UI elements annoy me beyond words, and I'm not going to support violating UI guidelines. If you don't agree with this design decision, you are looking for a different GUI toolkit. My immediate suggestion would be Kivy, because it's the diametric opposite of Toga's design - no widget adheres to the platform HIG, because they're all being drawn from primitives.

(2) is actually a request for an OptionContainer widget. If the amount of effort that had been spent furiously arguing for "clickable images" to support this use case, had instead been directed towards implementing OptionContainer on Android, we'd have it by now. The good news is that this widget exists on desktop platforms, and it's on our roadmap to implement towards the end of the year.

(3) and (4) are reasonable use cases, and I would like to see them both resolved. A "clickable image" would be, at best, a bandaid solution.

I'd much rather spend the effort fixing the actual problems and functionality gaps, rather than compromise the design of the entire framework to support a couple of use cases.

[l-o-u-i-s-g]

After reflection I think you are going against your own philosophy. You state that your goal is to stay as close to the feel of the native apps. Native apps do have buttons with images/icons and labels. By suggesting that instead we create other objects like galleries and menu items etc.. you are moving away from the native way of doing things. For example If one simply wanted a logout button with his picture and a label he now has to create a logout widget where all he really needed was a button. In the end all these extra widgets that you suggest we create will end up being just a button in the native codes.

[freakboy3742]

I assure you that I'm not being inconsistent. You're missing the point.

Providing wrappers around primitives is not "moving closer to the native way of doing things". It's objectively less native. Consider a widget like DetailedList. Using your approach, we would/could build a widget from images, labels, and scrollbars. That's not what Toga does. It wraps NSTableView on macOS, and UITableViewController on iOS, and GTK.ListBox on GTK - each of which provides a rich, fully native representation of the DetailedList concept. And on each platform, the implementation is slightly different, because the local platform expectations are different. On macOS, you use right click context menus to active functionality. On iOS, you use swipe left/right. Rinse and repeat for a dozen subtle differences between widgets on every platform. Toga's approach yields a user experience that is consistent with native expectations on every platform.

There isn't currently a Gallery widget. I am saying that I'd rather see a single, well-built gallery widget that uses native API features and GUI conventions than a dozen individual attempts at cobbling together a Gallery from a collection of "clickable image" widgets. I want to see a native representation. And, to that end, I'm encouraging that outcome by not providing primitives like "on_click handlers on image".

Are there examples where the desired functionality might ultimately be implemented by an on_click handler on an image? Possibly. Does that mean that there is a need for a clickable image widget? No. It means there are high level use cases that haven't been captured yet.