Added ToolTip.ShowOnDisabled and ToolTip.ServiceEnabled

[TomEdwardsEnscape]

ToolTipService now processes raw mouse input, to allow tooltips on disabled controls. It is also now possible to disable the service entirely, to allow users to write their own logic for hiding and showing tooltips without interference from Avalonia.

What is the current behavior?

Tooltip behaviour is currently linked to pointer events on the host control. These events are not raised at all if the control is disabled, so tooltips cannot be automatically opened on the control. It is also not possible to block a tooltip on an enabled control from opening automatically.

How was the solution implemented

ToolTipService now subscribes to the InputManager.Process event. I could have had TopLevel pass the events directly to ToolTipService and avoid this dependency, but that would mean that tooltip processing would not occur until either after InputManager.PostProcess or before InputManager.PreProcess, both of which seem wrong.

In order to support this subscription in unit tests, where multiple applications are constructed, ToolTipService is disposable. This is not relevant to real-world applications because normally only one instance can exist in a given process.

Breaking changes

None

Obsoletions / Deprecations

None

Fixed issues

Fixes #3847

[TomEdwardsEnscape]

The ApiCompat tool is complaining that three hit test methods no longer exist. I'm not sure how to fix that, because they do. I have added overloads which take an optional bool parameter, but the original method signature is still there, now defined like this:

public static IInputElement? InputHitTest(this IInputElement element, Point p) => InputHitTest(element, p, true);

[Takoooooo]

@TomEdwardsEnscape Since you've extended the API you probably need to re-run the APICompat. Usually it will run automatically when you build the project but you may run it manually also https://github.com/AvaloniaUI/Avalonia/wiki/ApiCompat---Diffs

[grokys]

LGTM in general though I think the disabling of the feature where the tooltip is hidden on pointer down was unintentional?

[MrJul]

Nitpicking about naming: shouldn't these properties be IsShownOnDisabled and IsServiceEnabled?

ShowOnDisabled really looks like a method name, and Is is usually used as a boolean prefix, even if we have exceptions (yes, I'm looking at you, Focusable.)

[TomEdwardsEnscape]

Nitpicking about naming: shouldn't these properties be IsShownOnDisabled and IsServiceEnabled?

The names are carried over from WPF, but have drifted a little because they really ought be properties of ToolTipService, but in Avalonia that is a private class.

WPF has these:

• ToolTipService.ShowOnDisabled
• ToolTipService.IsEnabled

I don't know if it makes sense to follow the "IsState" pattern here because neither of these are really properties of the target object. They are configuring how the the service behaves when processing the target object.

But, I've not got any strong opinions here.

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0046647-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0046655-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[grokys]

LGTM now. I think the naming makes sense, though I'll leave this open for a few days to get any further feedback in that area (it's Easter holidays anyway).

[MrJul]

Regarding the naming, note that in .NET 4.8 there's also ToolTip.ShowsToolTipOnKeyboard, using the third person.
My preference would be ShowsOnDisabled for consistency, but either is fine.

ServiceEnabled on the other hand really feels like it misses that Is prefix, imo (like in WPF). And since there's no ToolTipService, it's hard to know what exactly "Service" refers to here. Ideally the property should be IsEnabled but that already exists, as you mentioned. What about ToolTip.IsToolTipEnabled?

No blockers here for me, just discussing, I know naming is hard :)

[TomEdwardsEnscape]

What if ToolTip service were public and exposed same property names as WPF?

It would look like this pseudocode:

public static class ToolTipService
{
    ShowOnDisabledProperty
    IsEnabledProperty

    internal class Impl : IToolTipService { }
}

[TomEdwardsEnscape]

@grokys @MrJul

[maxkatz6]

Adding ToolTipService would be a bit confusing, when we already have some WPF ToolTipService members kept in ToolTip instead.