Page MenuHome

UI: Fix long tooltip in bug reporting

Authored by Luis de Bethencourt Guimera (luisbg) on Aug 16 2019, 2:18 AM.



Avoid a neverending Python tooltip on the bug reporting menu buttons.

This was pointed out to me by @Harley Acheson (harley)
I continued his work from D5194

Here is the tooltip before the change:

And here is after:

Diff Detail

rB Blender
TEMP-URL-PRESET (branched from master)
Build Status
Buildable 4519
Build 4519: arc lint + arc unit

Event Timeline

Harley Acheson (harley) resigned from this revision.Aug 16 2019, 4:05 AM

I compiled this and it certainly works. And I am glad to not see "the Neverending tooltip".

Although I see no obvious errors here, I am also not too proficient in Python. So review is best left to someone with more experience.

This should already not be displayed by default, only when you have Python Tooltips enabled in Preferences.

Overall if you don’t like seeing ugly technical stuff in your tooltips, keep Py Tooltips off as is default.

It’s certainly bad in this case, but perhaps there are other cases where it’s useful to see the URL inside the Python tooltip?

@Campbell Barton (campbellbarton) thoughts?

It’s certainly bad in this case, but perhaps there are other cases where it’s useful to see the URL inside the Python tooltip?

There is only “this case” because his change only changes this bug reporting item, not the generic case of browser urls. This particular URL is not useful because you can’t even see the entire thing anyway. We’ve had bug reports on this just because it look so strange to have a tooltip bisect your screen.

My main point is merely that this is already not visible by default - if it were it would be much more important to remove this.

So, okay if it only affects this case, then I think it probably makes sense?

Campbell Barton (campbellbarton) abandoned this revision.EditedAug 16 2019, 8:28 AM

Prefer not to add operators just because of Python tooltips.

This could be resolved differently.

  • There could be a way to override tool-tips.
  • We could have an operator with an enum property where each item is a web-site. Each enum can have a description which will be shown in the tool-tip.
  • We could wrap text, although in this case - it will be a large paragraph still.
  • We could have some way to execute Python directly, eg:


    .. although I'm not keen on injecting Python into operators calls, especially keymaps. For this menu item it seems a reasonable trade-off, but I'm wary of the precedent it sets.

Personally would not mind this being its own operator, even without the tooltip issue.

It does more than just opening a URL, and actually gathers a bunch of system information. That it can reuse the open URL operator is more of an implementation trick.

@Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht) : Looking through this thread and I am a little confused about the process taken.

Here we have a new contributor trying to get a start and hoping for a first commit.

The way I read this we have one one senior dev saying this seems like a good idea, and a second senior saying "this could be resolved differently". So then why was the patch also "abandoned" on him? This does not seem very welcoming.

The premise that we should have operators created because of how their Python tool-tips display isn't compelling IMHO since it's a developer feature.

If we want to split out operators for other reasons, we can always do it.

I set the patch as abandoned because I think the patch is trying to solve the problem at the wrong level.

Alternative solutions are possible, these require some design, we could solve a few different ways as stated.

This is now pressing developers to come up with solutions to a problem that isn't very urgent and can even be overlooked.

@Campbell Barton (campbellbarton) - isn't compelling IMHO since it's a developer feature.

I would agree if "Python Tooltips" was just an integral part of "Developer Extras"

If we want to split out operators for other reasons, we can always do it.

There are reasons here too, so not sure why "tooltip length" is the only consideration. It seems to make sense to have a "report_bug" operator that other things could call. And it feels right to me to gather this system information at the point that the user selects that item, rather than do so whenever the menu drops down.

But I was mostly confused about the process and how that could discourage new developers starting out. When I read your earlier comment I don't think you would have considered ending it with "And therefore I am going to delete your work", but that is the effect that it had when combined with forced abandonment.

Talked with @Luis de Bethencourt Guimera (luisbg) over chat, he's interested to make web-site presets (as mentioned in first reply), meaning all standard URL's can have more useful tips too.

@Campbell Barton (campbellbarton) - Talked with @Luis de Bethencourt Guimera (luisbg) over chat, he's interested to make web-site presets...

Thanks! Really appreciate that.

Luis de Bethencourt Guimera (luisbg) edited the summary of this revision. (Show Details)EditedAug 20 2019, 1:14 AM

Avoid a neverending Python tooltip on the bug reporting menu buttons.
By creating a generic way to open preset websites that have more informative tips too.

This is indeed cleaner than my previous diff.

As @Campbell Barton (campbellbarton) suggested I also applied this generic url_open_preset to the Development Fund buttons, to show how it can be used for other URLs besides bug reporting. If you guys want I can switch more url_open buttons to this generic Operator in a followup diff.

  • Move websites and there URL's into a single list which can be dynamically extended.
  • Use URL presets for splash screen and about menu.
  • Add descriptions.
  • Correction to last commit (missed rename ADDON-BUG -> BUG_ADDON)
This revision is now accepted and ready to land.Aug 20 2019, 3:45 PM

@Campbell Barton (campbellbarton) I could've added the rest of the URLs as I offered, and the other edits as well.

Of the four patches I've sent since I tried to join the Blender developer community, this is the second one a maintainer edits and submits with himself as author.

This isn't very welcoming.

You were attributed in the commit message and the patch was linked.

Phabricator doesn't have a convenient way to set you as the author.

This change wasn't especially urgent, so while it's fine to make small improvements, we can't always justify spending time to iterate on a patch.
This is why I edited and committed.

As an alternative it could have been put on hold too.

In the future, it's probably best to talk to the people who would review your work and ask what they can use help with.

Otherwise you risk spending time on changes which are disputable or not urgent compared to other work going on at the time.

git commit --amend --author="Other Person <>" works in Phabricator.

I know the change wasn't urgent, that's why I was surprised you edited it instead of asking me to do it myself.

I will ask in the future what people need help with. This tooltips issue was sent to me by an other developer but he isn't a maintainer.

Phabricator doesn't give us a way to access your email, also changes to your name will list you as different authors (depending on where we copy/paste from).

I've seen other community members get their patch in by using their nickname instead of their email. Git doesn't have any rules about the Author line format needing a valid email.

For example:

Maybe they have automated it or are manually copy-paste it.

I have a script to apply patches from arc, so I'll look into updating it to include the original author in the formatting you've mentioned.