Tooltip Guidelines #50283
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#50283
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tooltip Guidelines
As part of the 2.8 UI workshop, we agreed on having tooltip guidelines to ensure useful and high quality tooltips: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Tooltips
An initial guideline page can be found here https://wiki.blender.org/index.php/Dev:Doc/Projects/UI/Tooltip_Guidelines. This task should be used to discuss and finalize it.
Once the page is finalized, we'll ask all contributors to follow it strictly.
Changed status to: 'Open'
Added subscriber: @JulianEisel
Added subscriber: @BrendonMurphy
hi, great initiative, some small changes & comments:
(Description is better than just the name & really no need for both, the button or menu is already the name) EDIT: with the exception of Icon Only ui elements
Indeed, example of this will be in booltools addon release within a few days.
Tooltip Line 1: Please select 2 or more mesh objects
Tooltip Line 2: Boolean Operation to join the mesh (Union)
there should also be a character limit applied, some tool tips can get incredibly long
+1
These guidelines will also apply to addons.
I also have a concern with Pie Menus & Tooltips, they get in the way of the menus and are quite distracting, maybe we need an option to disable tooltips for pie menus? Tooltips are useful, just in this case they do really get in the way.
Added subscriber: @GaiaClary
Would it be possible to have 2 tool tips for each item?
description = "contains information when the item is operable."
disablehint = "contains information when the item is disabled."
When disablehint is not defined, then description is used
And of course the naming is just a placeholder for something better :)
Indeed, there isn't a need to show the tool name in most cases, a short, general description would be enough, followed by a more detailed description. Kind of like we do currently already. E.g.
Also, I realize "tool name" is the wrong term, we're actually talking about the name of the entity a button represents (can be an operator, property or a enum-property value).
It's a bit tricky to solve that. What we could do is make tooltips follow the radial layout. Meaning for a button at the left, the tooltip would appear on its left side (if enough space is available), for a button at the top, the tooltip would appear above it, etc.
The info on why a button is disabled (and how to fix that?) should always be additional info, when showing it, the normal button description should still be visible.
Since
6f8060450
, we can already return a string in RNA_editable
callbacks containing info on why the button is disabled. Operators can also store such strings throughCTX_wm_operator_poll_msg_set
. These strings are then displayed in tooltips.So these approaches allow context-sensitive usage and thus are a bit more dynamic than just storing a fixed description for an item for the case that it's disabled. I think that's the right direction to go, for Python we should do something similar.
Added subscriber: @DuarteRamos
Added subscriber: @tiles
Icon only buttons would need the tool name too.
Added subscriber: @Blendify
For 2.8 I purpose that by default we disable developer information in tooltips. This will make the tooltips look simpler and also follows the proposal of "no code snippets" What will also help tooltips is the adjust the styling a little. For example, a while ago @PawelLyczkowski-1 made this mockup but it got lost:
Added subscriber: @PawelLyczkowski-1
Added subscriber: @Arruda23
Hi guys. I'm trying to do an addon that will show an specific brush in an animated gif tooltip. This is what I have so far
Do you think this could be useful for the new users? I'm just doing for increase my knowledge in Python and Blender API, but you guys think it would be any helpful to have in the software?
Added subscriber: @WilliamReynish
@Arruda23: would it be useful? Yes. Some other apps do this kind of thing. Should we include this by default? Not sure.
There’s an aversion to adding too much data in the Blender binary, although I think it might be nice.
Related question is, how deep should that concept go? Just for brushes? All active tools? Any tooltip?
Added subscriber: @JulienKaspar
@WilliamReynish
I was also thinking about this for a while and I definitely believe that adding images or even animated images would be very helpful for specific options that are hard to explain with text only.
Concepts like the "sculpt plane orientation" for example are not understood by most users since it's an aspect to a brush that is invisible to the user.
But I wouldn't add extra images to the vast majority of tooltips.
Added subscriber: @Constantina32
Hello again. I've been developing the addon I just mentioned above and I finished. I had a lot of struggles with blender addon structure and native methods such as modal, execute, poll, etc. but that's because I'm noob at programming and I also learned a lot. Here is how it looks like now:
I want to say that I did this focusing on new users experience but it is not very useful since the new user would have to install the addon and activate it to use. But I want to leave this work as an idea if the developers want to implement it natively into the software, since I used third party libraries to do so (I think this made things even more complicated).
This is the project link if anyone wants to check it out.
Closed as duplicate of #76261