Add tooltip attribute to description widgets #1864

[piyushrungta25]

for #1864

[jasongrout]

How would we disable the tooltip if we didn't want it to show up?

[piyushrungta25]

As far as I understand, it couldn't be disabled completely previously also since it always defaults to the description. Not specifying the tooltip or setting it to an empty string will result in closest behavior.

[jasongrout]

Thanks! One design comment about disabling the tooltip if we'd like. Setting the tooltip to '' seems natural to disable it - perhaps None should be the default, which means take it from the description?

I agree that this change is strictly better than what we have (we can't turn off tooltips right now either).

[jasongrout]

Also, can we call it description_tooltip? An arbitrary control might have other places where tooltips make sense, so scoping the name to where it is used makes sense, even if it is a bit long. We do have precedence for a name like that, in that the style has a description_width attribute.

[piyushrungta25]

Thanks for the feedback.

Setting the tooltip to '' seems natural to disable it - perhaps None should be the default, which means take it from the description?

Just so that I understand correctly, the new behavior should be,

• tooltip = None, use description
• tooltip = '' , disable tooltip

with None as the default value.

[jasongrout]

Does that make sense to you as a user? It's a bit awkward that we use "None" as a default value, but it is a convention. The way I see it, if you have a string, set the tooltip to that (including ''). If you have None, do the default behavior.

[maartenbreddels]

I think it makes sense, looks great (from mobile phone)

…

On Thu, 10 May 2018, 22:54 Jason Grout, ***@***.***> wrote: Does that make sense to you as a user? It's a bit awkward that we use "None" as a default value, but it is a convention. The way I see it, if you have a string, set the tooltip to that (including ''). If you have None, do the default behavior. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2070 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABryPRE7wN_4mCRb_L0sXqRDxTxf0j3hks5txKkIgaJpZM4T6SkB> .

[piyushrungta25]

That does make sense. I made the discussed changes.

[jasongrout]

Thanks. We'll need to update the spec to have this trait, then I think we are good to merge. I'll look at this hopefully tomorrow.

[jasongrout]

@SylvainCorlay - what are your thoughts about the model change here? In particular, the attribute can be either null or a string - does that make things difficult for xwidgets?

[SylvainCorlay]

Hey @jasongrout thanks for the heads up.

The model changes are fine with me. We handle optional widget attributes very well in xwidgets.

For example, in the layout widget, we do:

XPROPERTY(xtl::xoptional<std::string>, derived_type, align_items, {}, XEITHER_OPTIONAL("flex-start", "flex-end", "center", "baseline", "stretch", "inherit", "inital", "unset"));

[jasongrout]

Great, then I'm okay with merging this for the beta.

[jasongrout]

Thanks @piyushrungta25 for pushing this through!