Add support for tooltip

[s-h-a-d-o-w]

At least on Windows, it is standard for tray icons to have tooltips. Hence, I added an option to set one. (If the user doesn't want that, he can set NULL or an empty string)

I am only able to implement the Windows part though (I realize the check for TRAY_WINAPI isn't really necessary because on the other platforms it simply wouldn't do anything... I merely put it there for emphasis) and don't know what the common behavior on Linux distros and macOS is.

[jslegendre]

I can say macOS definitely does not have tooltips for menu bar icons and Linux is (as usual) a mixed bag. Some do, some don't. It will also depend which desktop environment is being used. That being said, I would classify this feature as "Windows only" and therefore should not be part of a cross-platform library.

[s-h-a-d-o-w]

I find that an odd conclusion - any cross-platform library should only offer the lowest common denominator.
Reminds me of the cross-platform design philosophy of the 1990s - when software developed using such tools was always inferior because the UX simply wasn't adequate on any given platform.

[jslegendre]

I can see what you are saying. There are always going to be some sacrifices when using cross-platform utilities such as this. Usually x-platform applications have a single code base for the functionality and all UI/platform specific features are built on top of that for each platform.

Maybe setting a default tooltip such as the executable name would be a good middle-ground solution.

[s-h-a-d-o-w]

I appreciate that. 👍
But... did you by any chance miss the part where I wrote that I made it optional? (If none is supplied then none will be shown)
Because I feel that it should be up to whoever is using this library whether they want to have a tool tip or not, even on Windows. It's not a question about dictating anything but providing the option and of course documenting that the feature is only available on platforms X & Y.

The thing about building on top - well... the problem with UI is that the "top" is in a sense the bottom. In that - the user code provides the generic data structure (in this case tray_menu) and then the library does the platform-specific stuff, depending on what is supported. I've seen this done many times and that way, you don't have to sacrifice anything. The user just has to be made aware of what they can do on a given platform.

[jslegendre]

I agree with you that you don't HAVE to sacrifice anything. A developer can implement as many features as they want. I think in this case it is a question of expectancy. Lets say a dev builds an app using Tray on Windows and decides to put some information about the process in the tooltip for users to have a quick look whenever they need to, then builds on macOS and there is no tooltip. Thus needing to re-write certain parts specifically for macOS/*nix to show an additional menu item for that information.

Granted, this wouldn't be difficult but it wouldn't be "expected behavior". Starting down a road where some platforms have some features that others don't seems outside the scope of this project as it is not presented as a complete UI library.

Really though, we can lay out our POVs until we are dead but at the end of the day it isn't up to us. It is up to the owner(s) of the project to decide the road ahead.

[s-h-a-d-o-w]

That's true. You seemed to speak with authority in your first post ("therefore should not be..."), so I assumed that you are an owner. 😄