[android] image button.on_press() possible?

[HKLM]

Is there any way to make a button, that instead of text, display a icon or image? (That will work on android)
Im looking for a way to get a "on_press" event from a icon or image

[freakboy3742]

This is something that has come up a few times - see this issue for at least one of those discussions.

The short answer to your question is that this isn't currently possible. It's been proposed in PR #1213, but I'm still not sold on the use case.

The underlying question is why do you want this? If what you want is a button with an icon, then we don't need an image that supports on_press - we need to support icons on buttons. This is something I can definitely support - and at some level, should already be possible by using unicode in the button label.

A button is very different to an image. An image is a picture, of arbitrary size. There might be a valid use case for making the image clickable - but being able to fake a button isn't that use case.

[HKLM]

This is something that has come up a few times - see this issue for at least one of those discussions.

The short answer to your question is that this isn't currently possible. It's been proposed in PR #1213, but I'm still not sold on the use case.

The underlying question is why do you want this? If what you want is a button with an icon, then we don't need an image that supports on_press - we need to support icons on buttons. This is something I can definitely support - and at some level, should already be possible by using unicode in the button label.

A button is very different to an image. An image is a picture, of arbitrary size. There might be a valid use case for making the image clickable - but being able to fake a button isn't that use case.

I would like to have a button with a icon displayed on it. I think it would make my app visually more appealing. Right now it reminds me of a webpage from 1990's :) . For example, to display a gear icon that opens up a settings window. vs a button that says "settings"

I have a working prototype android app that can tell me if my doors are locked/unlocked, windows are up or down, I can remotely lock and unlock my truck. The app Ford has out does not tell me the status of my windows or doors or even if the alarm is active or not. Even tho I am using Ford's owns RESTful API to do this, my app can do it. I'm not a professional programmer. In fact this is my 1st time using python, I've more experience with C#. In fact I was originally trying to get this to work using Xamarin Forms. But then I came across beeware and so far it has fulfilled almost everything I want to do. I'm now at the point where I am trying to polish it up and make it nice and clean visually. For example: I have 2 buttons "Update" and "Lock". Not very elegant and boring. I have these two icons I would rather have displayed

"Update" would be

And "Lock" would be

And thus tapping on either one do the on_press() and so on. Currently there is no way to do this on android that I know of. All the widgets that use icons, with the exception of imageview, don't work on android. There is no command widget for android. I'm not asking for a major reworking of toga. I just want to know any way that this can be implemented in my app?

Android has a native ImageButton widget.
I think you guys have a great thing here. It works, I like it and think it has a lot of potential. But I don't get why there is a reluctance to be able to have a button with a icon on it or a clickable image, or even a on_press event for a imageview widget or even <a href=xxx><img></a> or what ever. I just want a icon that when clicked on, fires off a specified function.

I don't like having to beg for something.
If this is not the direction you want toga to be going, then I'm going to look for other ways to do this.

This is my app currently

This is Ford's official app that I can use to remotely lock my truck.

.

[freakboy3742]

My apologies - I think we've got some crossed wires here because of terminology.

In Toga's terminology, what you've described are icons, not images. Although it might not be obvious, there's a very important distinction here. Icons are:

• small;
• square (or at least, NxN bitmaps),
• provided by the system or the app; and
• on many platforms, a single color (although this isn't true on every system)

Images, on the other hand, are:

• Arbitrarily sized (and can be huge, requiring scaling);
• usually provided by the user;
• have arbitrary colors.

Using the "official" app as an example - the start/lock/unlock pictures are icons. The picture of the truck is an image.

As a result, the APIs that we provide for icons vs images can be very different.

What you've described - putting a "settings" or "refresh" icon on a button is (to me) an entirely reasonable use case, and one that we should definitely support. The app you're describing looks like a really solid example of where you'd use them (and, as an aside - the app itself seem amazing!). We sorta-kinda have support for this right now - in the form of using the icons that are available in Unicode (such as the Media Control symbols) - however, those aren't a great solution; I'm only suggesting them as "something that will definitely work right now" because you can treat the icons as "text labels".

What I'm "resisting" is the idea of an image button.

The reason for this is somewhat philosophical - I'm utterly sick of UI designers reinventing the wheel. Platforms have UI design guidelines for a reason, and consistency is something that aids user experience. Take the screenshot of the official app that you've provided. Based on the visual language, it's very difficult to know for certain what is and what isn't a button - because the design language is completely inconsistent. I'm guessing the big start icon is a button - they've used shadows to try and develop some sort of skeuomorphism that makes it look like a Big Button You Can Press. However, that skeuomorphism is inconsistent with the Android style guide... so that leads to things like the "24x7 assistance" pictogram. Is that a button? The design language isn't consistent with the other buttons on the screen, so how is the user meant to intuitively know it's a button. What about the "F-250 XLT F4 v" text? Is that button? Is it all a button, or just the down chevron? Who knows? The design language doesn't tell you. What about "Find a dealer"? I presume that's a button as well? What about the picture of the truck .... is that a button? Who knows?

So - Ford has built a UI that has 3 (4?) buttons... and they're all different - WHY? Now, I'll grant that in this specific case, you might say it's not that big a deal. However, I've lost count of the number of times I've seen UIs where users literally don't know that something is a button because A Designer Has Designed The App; and while it may be "pretty" (for some definition of pretty...), how the app is actually meant to function is completely opaque. I've seen users completely surprised that a specific feature or functionality is available at all, because the fact that one particular "image" was actually an interactive element wasn't obvious.

What I'm trying to do with Toga's APIs is make it easy to do the right thing - which means being consistent with the platform style guide. That means buttons look like buttons, and behave like buttons. Depending on the platform, a button has an edge indicating how big it is, some contrast to show how big the pressable area is; simple text or an icon, and maybe a little shadow to give the visual impression that it can be pushed. An image is a picture. And while, yes, you can make the picture look like some sort of button - just because you've got a hammer, doesn't mean you need to treat everything like a nail.

When someone says "I want an image button", the question I ask is "do you really want an Image button, or do you want an icon on a button"? And, in my experience, the answer is almost always icon. I'm 100% on board with supporting Icons on buttons. We don't have support for them yet, but I'm not opposed to adding them.

Internally, that might end up being implemented on Android using android.widget.ImageButton - but that's an implementation detail. Toga is an abstraction API - it doesn't expose the eccentricities of the underlying platform. iOS and macOS, for example, don't have an ImageButton - you can set an image on any button. When we expose a piece of functionality, we find an API abstraction that makes sense in general, rather than dogmatically following one specific platform API.

As for "begging" - well, I can tell you what features we have right now. I can also tell you that this is a volunteer-based Open Source project, so that addition won't happen unless someone volunteers to add it.

[HKLM]

My apologies - I think we've got some crossed wires here because of terminology.

In Toga's terminology, what you've described are icons, not images. Although it might not be obvious, there's a very important distinction here. Icons are:

• small;
• square (or at least, NxN bitmaps),
• provided by the system or the app; and
• on many platforms, a single color (although this isn't true on every system)

Images, on the other hand, are:

• Arbitrarily sized (and can be huge, requiring scaling);
• usually provided by the user;
• have arbitrary colors.

What you've described - putting a "settings" or "refresh" icon on a button is (to me) an entirely reasonable use case, and one that we should definitely support. The app you're describing looks like a really solid example of where you'd use them (and, as an aside - the app itself seem amazing!). We sorta-kinda have support for this right now - in the form of using the icons that are available in Unicode (such as the Media Control symbols) - however, those aren't a great solution; I'm only suggesting them as "something that will definitely work right now" because you can treat the icons as "text labels".

What I'm "resisting" is the idea of an image button.

Need I remind you, technically the icon widget in toga is currently not supported on android. So forgive me that I am using a .png file to display a image, "of a icon", on a button widget.

The reason for this is somewhat philosophical - I'm utterly sick of UI designers reinventing the wheel. Platforms have UI design guidelines for a reason, and consistency is something that aids user experience.

What I'm trying to do with Toga's APIs is make it easy to do the right thing - which means being consistent with the platform style guide. That means buttons look like buttons, and behave like buttons. Depending on the platform, a button has an edge indicating how big it is, some contrast to show how big the pressable area is; simple text or an icon, and maybe a little shadow to give the visual impression that it can be pushed. An image is a picture. And while, yes, you can make the picture look like some sort of button - just because you've got a hammer, doesn't mean you need to treat everything like a nail.

Why is it ok for Google to style their own default clock app for android, but you don't want us to do the same with toga? WTF?
Both have a small one color icon picture of a symbol, that when the user "presses it"/ "clicks it" it does something (Google defines a Imagebutton as "Displays a button with an image (instead of text) that can be pressed or clicked by the user."
Microsoft defines a ImageButton as "The ImageButton displays an image and responds to a tap or click that directs an application to carry out a particular task.")
If it walks like a duck, and talks like a duck, its a duck,.

When someone says "I want an image button", the question I ask is "do you really want an Image button, or do you want an icon on a button"? And, in my experience, the answer is almost always icon. I'm 100% on board with supporting Icons on buttons. We don't have support for them yet, but I'm not opposed to adding them.

As for "begging" - well, I can tell you what features we have right now. I can also tell you that this is a volunteer-based Open Source project, so that addition won't happen unless someone volunteers to add it.

While you may have a dislike for the modern style of "buttons", I personally do not like the old Windows 3.1 style of a "button". Yes I've been using computers before Microsoft windows was even invented. And I'm not the only one asking for this feature, there are a few others that have asked for the same feature. #774 #1257. It bothers me to see that your holding your own project here back. You already have this button code #1213 done for you, its all ready to be added into the main branch. But you are not merging that PR....? Why? Its like a father locking his daughter in her room for her entire adult life, because he does not like what she "might wear" if she was allowed out of the house.

Its time to let your daughter grow up

[clemsam]

There is a possibility to make an image(!) "clickable" by using code from an active pull request.
I used this PR's fork code (NOT merged!) as described in this discussion #1372, BUT:

it does NOT behave like a button (= change color on_press() ) !!!

I myself do NOT think an image on a (typically small) button to make much sense, btw:
... how about allowing ".icon" files on buttons -- ?!? [Edit: IS already "allowed" but not yet implemented.]

[freakboy3742]

The "long press" vs "right click" is one we do have an answer for - you capture the UX use case, not the specific physical action. This is one of the reasons that the handler for button is "on_press", not "on_click" - "click" implicitly suggests that a mouse will be used to perform the action.

In this specific case, something like "on_alternate_press" or "on_context_press" would make sense - something that captures the functional purpose of the action, rather than the platform specifics of the cation. This would then be implemented as a right click on windows, a Control-click on macOS, and a long press on mobile platforms - three different physical manifestations of the underlying UI concept.

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

and for linux which can be desktop or mobile? There will need to be a way to detect the platform.

[freakboy3742]

... you mean, like the tools that Toga already has (toga.platform.current_platform)? Toga doesn't consider Android to be a "Linux"; and even if it did, toga_android and toga_gtk are separate backends, so they can have different implementations.

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

I actually mean real Linux phones , like the pine phone and librem or actually any Os with a touch screen I guess. like windows in tablet mode..

[freakboy3742]

I don't know anything about the specifics of PinePhone or Librem devices to be able to comment. However, I can't see how they could be doing anything that would be incompatible with what I've already said. Either (a) there's a need for a separate toga_pine (or whatever) backend, or (b) the Gtk backend (which is the current default backend for Linux) needs to be modified to trigger on_context_press on a long touch as well as a right click. While it might be nice to be able to clearly identify Pine/Librem phones from desktop Linux, neither of these approaches would require Toga to be able to differentiate a desktop platform from a Pine/Librem phone platform.

If you're motivated to support PinePhone or Librem devices, then by all means contribute patches to that effect; but I can't say they're an especially high priority on my own personal roadmap.