Avoid clipping data-block name in data-block menu because of library name #84188

New Issue

Julian Eisel · 2020-12-27T23:09:47+01:00

Julian Eisel commented

2020-12-27 23:09:47 +01:00

The grayed out, right aligned library .blend name in the menu can cause space problems when the data-block name and/or the library name are long. E.g. from #77929:

A few things we could do:

- Increase the menu width.
- Hide the .blend suffix.
- Hide the square brackets.
- Show the full data-block and library name in the tooltip.
- Clip the middle of the data-block name, not the end.
- Clip the library path name.
- (Dynamically enlarge the menu width based on the item name widths.)

The grayed out, right aligned library .blend name in the menu can cause space problems when the data-block name and/or the library name are long. E.g. from #77929: ![bug.jpg](https://archive.blender.org/developer/F8626313/bug.jpg) A few things we could do: * - [ ] Increase the menu width. * - [ ] Hide the `.blend` suffix. * - [ ] Hide the square brackets. * - [x] Show the full data-block and library name in the tooltip. * - [x] Clip the middle of the data-block name, not the end. * - [x] Clip the library path name. * - [ ] (Dynamically enlarge the menu width based on the item name widths.)

Julian Eisel commented

2020-12-27 23:09:47 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Julian Eisel commented

2020-12-27 23:09:47 +01:00

Added subscriber: @JulianEisel

blender-admin commented

2020-12-27 23:09:47 +01:00

#84795 was marked as duplicate of this issue

Julian Eisel commented

2020-12-27 23:11:10 +01:00

This is both a design and a To-Do task. Would be good to address this before the release, since it's a recently introduced issue.

Julian Eisel commented

2020-12-27 23:12:49 +01:00

Also note the multiple reports about this in #78012.

Julian Eisel commented

2021-01-18 11:54:30 +01:00

Added subscribers: @VanessaE, @lichtwerk

Julian Eisel commented

2021-01-25 23:16:30 +01:00

Changed how the clipping is done to fix the regression for the release, 77f73a9284.

Changed how the clipping is done to fix the regression for the release, 77f73a9284.

Ludvik Koutny commented

2021-01-27 11:59:55 +01:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2021-01-27 11:59:55 +01:00

This comment was removed by @Rawalanche

*This comment was removed by @Rawalanche*

Ludvik Koutny commented

2021-01-27 12:04:59 +01:00

Making the width datablock search popover UI element dynamic or at least much wider is the way to go. The days when the fixed width value was decided were most likely the days when 640x480 was dominant screen resolution.

Right now, the horizontal space is on modern resolutions is ridiculously underutilized (vertical too):

The current screenshot of 2.83 is still shows really poor result. I am really confused why multiple changes to the clipping and formatting of the text were done prior to increasing the width, which is the actual, proper way to address it.

It really confuses me why in the list of "A few things we could do", are the things done in the order from those which have the least useful impact to solving the problem to the ones that impact the solution the most? Once the popover has proper width, all the other, already done changes will most likely be wasted work.

Making the width datablock search popover UI element dynamic or at least much wider is the way to go. The days when the fixed width value was decided were most likely the days when 640x480 was dominant screen resolution. Right now, the horizontal space is on modern resolutions is ridiculously underutilized (vertical too): ![image.png](https://archive.blender.org/developer/F9600292/image.png) The current screenshot of 2.83 is still shows really poor result. I am really confused why multiple changes to the clipping and formatting of the text were done **prior** to increasing the width, which is the actual, proper way to address it. It really confuses me why in the list of "A few things we could do", are the things done in the order from those which have the least useful impact to solving the problem to the ones that impact the solution the most? Once the popover has proper width, all the other, already done changes will most likely be wasted work.

Vanessa Dannenberg commented

2021-01-27 13:01:32 +01:00

While I agree that increasing the popover's size is the proper first-step to a solution, I note the width of your image suggest (vaguely) that you're using a widescreen monitor. I'd like to remind folks that some of us old pharts ;-) still use 4:3 screens, so please don't go overboard.

Ludvik Koutny commented

2021-01-27 14:34:57 +01:00

In #84188#1101742, @VanessaE wrote:
While I agree that increasing the popover's size is the proper first-step to a solution, I note the width of your image suggest (vaguely) that you're using a widescreen monitor. I'd like to remind folks that some of us old pharts ;-) still use 4:3 screens, so please don't go overboard.

Well, obviously the width would be defined as a fraction of the horizontal screen resolution, rather than fixed size (which is where the current implementation fails). So I'd expect it to have for example about 960 pixels max width on 1280 pixels wide screen, and so on. On the other hand, you are sort of right. This is Blender, so I expect it to first be implemented wrong (bigger but fixed width) and then stay there the wrong way for 2-3 years before someone fed up decides to fix it again.

> In #84188#1101742, @VanessaE wrote: > While I agree that increasing the popover's size is the proper first-step to a solution, I note the width of your image suggest (vaguely) that you're using a widescreen monitor. I'd like to remind folks that some of us old pharts ;-) still use 4:3 screens, so please don't go overboard. Well, obviously the width would be defined as a fraction of the horizontal screen resolution, rather than fixed size (which is where the current implementation fails). So I'd expect it to have for example about 960 pixels max width on 1280 pixels wide screen, and so on. On the other hand, you are sort of right. This is Blender, so I expect it to first be implemented wrong (bigger but fixed width) and then stay there the wrong way for 2-3 years before someone fed up decides to fix it again.

Julian Eisel commented

2021-01-27 17:05:11 +01:00

In #84188#1101681, @Rawalanche wrote:
Making the width datablock search popover UI element dynamic or at least much wider is the way to go.

A few things to be said here:

Dynamically deciding the width to fit all items would require possibly hundreds of string width calculations, which aren't entirely cheap. This may be unreasonably performance intensive.
We could make an educated guess based on the number of characters. But even there, clipping might be likely. It would also have to consider multi-byte characters, not sure if this can be done well & cheap.
We could use the size of the biggest visible item (10 max currently). But jumps in menus size are odd, jumps in the position of names are even worse.
What about the menus showing previews in a grid? The text width will likely still be limited to roughly the preview size and require clipping, no matter the solution for other cases.
Simply increasing the menu size results in situations like this: Smaller increases also look odd and also only slightly improve things. Maybe positioning the menu differently can help. But even when increasing the size, sooner or later there will be cases where names are too long to fit.
Point is, it's not as simple as changing the width. It's not something I could do easily.

The changes I've done don't need much design discussion and will likely be needed anyway. The tooltip is a reliable way to display all un-clipped text in all cases (even with previews), plus the full library path. Also, the clipping changes can easily be considered a regression fix and be committed to the 2.92 beta.

> In #84188#1101681, @Rawalanche wrote: > Making the width datablock search popover UI element dynamic or at least much wider is the way to go. A few things to be said here: * Dynamically deciding the width to fit all items would require possibly hundreds of string width calculations, which aren't entirely cheap. This may be unreasonably performance intensive. * We could make an educated guess based on the number of characters. But even there, clipping might be likely. It would also have to consider multi-byte characters, not sure if this can be done well & cheap. * We could use the size of the biggest visible item (10 max currently). But jumps in menus size are odd, jumps in the position of names are even worse. * What about the menus showing previews in a grid? The text width will likely still be limited to roughly the preview size and require clipping, no matter the solution for other cases. * Simply increasing the menu size results in situations like this: ![Screenshot 2021-01-27 at 17.01.03.png](https://archive.blender.org/developer/F9600856/Screenshot_2021-01-27_at_17.01.03.png) Smaller increases also look odd and also only slightly improve things. Maybe positioning the menu differently can help. But even when increasing the size, sooner or later there will be cases where names are too long to fit. Point is, it's not as simple as changing the width. It's not something I could do easily. The changes I've done don't need much design discussion and will likely be needed anyway. The tooltip is a reliable way to display all un-clipped text in all cases (even with previews), plus the full library path. Also, the clipping changes can easily be considered a regression fix and be committed to the 2.92 beta.

Vanessa Dannenberg commented

2021-01-27 17:15:15 +01:00

Maybe add a toggle somewhere to completely hide the linked filename?

Ludvik Koutny commented

2021-01-27 22:43:48 +01:00

In #84188#1101989, @JulianEisel wrote:

In #84188#1101681, @Rawalanche wrote:
Making the width datablock search popover UI element dynamic or at least much wider is the way to go.

A few things to be said here:

Dynamically deciding the width to fit all items would require possibly hundreds of string width calculations, which aren't entirely cheap. This may be unreasonably performance intensive.

We could make an educated guess based on the number of characters. But even there, clipping might be likely. It would also have to consider multi-byte characters, not sure if this can be done well & cheap.

We could use the size of the biggest visible item (10 max currently). But jumps in menus size are odd, jumps in the position of names are even worse.

What about the menus showing previews in a grid? The text width will likely still be limited to roughly the preview size and require clipping, no matter the solution for other cases.

Simply increasing the menu size results in situations like this: Smaller increases also look odd and also only slightly improve things. Maybe positioning the menu differently can help. But even when increasing the size, sooner or later there will be cases where names are too long to fit.
Point is, it's not as simple as changing the width. It's not something I could do easily.

The changes I've done don't need much design discussion and will likely be needed anyway. The tooltip is a reliable way to display all un-clipped text in all cases (even with previews), plus the full library path. Also, the clipping changes can easily be considered a regression fix and be committed to the 2.92 beta.

The thing is, in the current state, there's already string clipping calculation going on. Those strings clipped by ... at the end or in the middle of the name. At this point, you are already processing all the strings if their rendered text exceeds some dimension. So all you really need to know is what is the horizontal dimension of the longest string in the popover list, and expand the popover up to x% of the current Blender window width. If the horizontal dimension of the rendered text of the longest string would exceed the specified x percent of the Blender window width, then it'd make sense to clip those strings, only those strings which exceed it. So in the end there should not be much performance hit, since some performance should be saved by not having to process and clip so many strings.

Given the wonky Blender architecture at some places, it's pretty much safe to assume that by the time user had so many materials in one .blend file that just processing their strings in the datablock popover list would have any noticeable impact on performance, the user would have way, way worse performance issues due to other factors related to material data management.

> In #84188#1101989, @JulianEisel wrote: >> In #84188#1101681, @Rawalanche wrote: >> Making the width datablock search popover UI element dynamic or at least much wider is the way to go. > A few things to be said here: > * Dynamically deciding the width to fit all items would require possibly hundreds of string width calculations, which aren't entirely cheap. This may be unreasonably performance intensive. > * We could make an educated guess based on the number of characters. But even there, clipping might be likely. It would also have to consider multi-byte characters, not sure if this can be done well & cheap. > * We could use the size of the biggest visible item (10 max currently). But jumps in menus size are odd, jumps in the position of names are even worse. > * What about the menus showing previews in a grid? The text width will likely still be limited to roughly the preview size and require clipping, no matter the solution for other cases. > * Simply increasing the menu size results in situations like this: ![Screenshot 2021-01-27 at 17.01.03.png](https://archive.blender.org/developer/F9600856/Screenshot_2021-01-27_at_17.01.03.png) Smaller increases also look odd and also only slightly improve things. Maybe positioning the menu differently can help. But even when increasing the size, sooner or later there will be cases where names are too long to fit. > Point is, it's not as simple as changing the width. It's not something I could do easily. > > The changes I've done don't need much design discussion and will likely be needed anyway. The tooltip is a reliable way to display all un-clipped text in all cases (even with previews), plus the full library path. Also, the clipping changes can easily be considered a regression fix and be committed to the 2.92 beta. The thing is, in the current state, there's already string clipping calculation going on. Those strings clipped by ... at the end or in the middle of the name. At this point, you are already processing all the strings if their rendered text exceeds some dimension. So all you really need to know is what is the horizontal dimension of the longest string in the popover list, and expand the popover up to x% of the current Blender window width. If the horizontal dimension of the rendered text of the longest string would exceed the specified x percent of the Blender window width, then it'd make sense to clip those strings, only those strings which exceed it. So in the end there should not be much performance hit, since some performance should be saved by not having to process and clip so many strings. Given the wonky Blender architecture at some places, it's pretty much safe to assume that by the time user had so many materials in one .blend file that just processing their strings in the datablock popover list would have any noticeable impact on performance, the user would have way, way worse performance issues due to other factors related to material data management.

Julian Eisel commented

2021-01-28 01:26:45 +01:00

In #84188#1101993, @VanessaE wrote:
Maybe add a toggle somewhere to completely hide the linked filename?

If such a toggle is needed it would just be a workaround for lazy design work. Plus, it's not just about the library name, the data-block name itself can be wider than the available width.

In #84188#1102211, @Rawalanche wrote:
The thing is, in the current state, there's already string clipping calculation going on. Those strings clipped by ... at the end or in the middle of the name. At this point, you are already processing all the strings if their rendered text exceeds some dimension.

Only the strings visible on screen get clipped. So we only process 10 strings (or 20 with the library name) per redraw currently.

So all you really need to know is what is the horizontal dimension of the longest string in the popover list, and expand the popover up to x% of the current Blender window width.

That is what I explained in the 3rd bullet point. But as I said there such a solution would lead to sudden jumps while scrolling. Not too good of a solution IMO.

> In #84188#1101993, @VanessaE wrote: > Maybe add a toggle somewhere to completely hide the linked filename? If such a toggle is needed it would just be a workaround for lazy design work. Plus, it's not just about the library name, the data-block name itself can be wider than the available width. > In #84188#1102211, @Rawalanche wrote: > The thing is, in the current state, there's already string clipping calculation going on. Those strings clipped by ... at the end or in the middle of the name. At this point, you are already processing all the strings if their rendered text exceeds some dimension. Only the strings visible on screen get clipped. So we only process 10 strings (or 20 with the library name) per redraw currently. > So all you really need to know is what is the horizontal dimension of the longest string in the popover list, and expand the popover up to x% of the current Blender window width. That is what I explained in the 3rd bullet point. But as I said there such a solution would lead to sudden jumps while scrolling. Not too good of a solution IMO.

Ludvik Koutny commented

2021-01-28 10:24:31 +01:00

In #84188#1102263, @JulianEisel wrote:

In #84188#1101993, @VanessaE wrote:
Maybe add a toggle somewhere to completely hide the linked filename?

If such a toggle is needed it would just be a workaround for lazy design work. Plus, it's not just about the library name, the data-block name itself can be wider than the available width.

In #84188#1102211, @Rawalanche wrote:
The thing is, in the current state, there's already string clipping calculation going on. Those strings clipped by ... at the end or in the middle of the name. At this point, you are already processing all the strings if their rendered text exceeds some dimension.

Only the strings visible on screen get clipped. So we only process 10 strings (or 20 with the library name) per redraw currently.

So all you really need to know is what is the horizontal dimension of the longest string in the popover list, and expand the popover up to x% of the current Blender window width.

That is what I explained in the 3rd bullet point. But as I said there such a solution would lead to sudden jumps while scrolling. Not too good of a solution IMO.

I meant iterating over strings of all the materials, not just the visible ones. As I said, by the time user has so many materials in their .blend file that iterating over their names would have any noticeable impact on performance, there would be much, much bigger performance issues somewhere else, most likely depsgraph related.

Also, there are so many ways to tackle it. For example storing integer of name length with each material, which is only updated during material creation and upon material name change. Then it'd become a matter of just iterating one array of integers, finding the highest one and setting the width according to that.

But I don't see inside that mess, so of course it doesn't make much sense debating implementation details. My overall point is that this is a trivial problem to solve, so there's no need to pretend like it's a difficult one.

> In #84188#1102263, @JulianEisel wrote: >> In #84188#1101993, @VanessaE wrote: >> Maybe add a toggle somewhere to completely hide the linked filename? > If such a toggle is needed it would just be a workaround for lazy design work. Plus, it's not just about the library name, the data-block name itself can be wider than the available width. > >> In #84188#1102211, @Rawalanche wrote: >> The thing is, in the current state, there's already string clipping calculation going on. Those strings clipped by ... at the end or in the middle of the name. At this point, you are already processing all the strings if their rendered text exceeds some dimension. > Only the strings visible on screen get clipped. So we only process 10 strings (or 20 with the library name) per redraw currently. >> So all you really need to know is what is the horizontal dimension of the longest string in the popover list, and expand the popover up to x% of the current Blender window width. > That is what I explained in the 3rd bullet point. But as I said there such a solution would lead to sudden jumps while scrolling. Not too good of a solution IMO. I meant iterating over strings of all the materials, not just the visible ones. As I said, by the time user has so many materials in their .blend file that iterating over their names would have any noticeable impact on performance, there would be much, much bigger performance issues somewhere else, most likely depsgraph related. Also, there are so many ways to tackle it. For example storing integer of name length with each material, which is only updated during material creation and upon material name change. Then it'd become a matter of just iterating one array of integers, finding the highest one and setting the width according to that. But I don't see inside that mess, so of course it doesn't make much sense debating implementation details. My overall point is that this is a trivial problem to solve, so there's no need to pretend like it's a difficult one.

Eugene Du commented

2021-02-04 10:43:26 +01:00

Added subscriber: @APEC

Eugene Du commented

2021-02-04 10:43:26 +01:00

In #84188#1101681, @Rawalanche wrote:
Making the width datablock search popover UI element dynamic

Yes, finally some one say it.
It's a very nice solution match width to the longest name in the list.
I'm very suffering with this clipping names.

Popover is dynamic so why 'datablock' can't be?
And I found that material name have characters limit...so it can be limits for dynamic width.

> In #84188#1101681, @Rawalanche wrote: > Making the width datablock search popover UI element dynamic Yes, finally some one say it. It's a very nice solution match width to the longest name in the list. I'm very suffering with this clipping names. ![clipping name.png](https://archive.blender.org/developer/F9624846/clipping_name.png) Popover is dynamic so why 'datablock' can't be? And I found that material name have characters limit...so it can be limits for dynamic width.

Frederick Desimpel commented

2023-01-28 20:07:08 +01:00

Added subscriber: @FDesimpel

Frederick Desimpel commented

2023-01-28 20:07:08 +01:00

In #84188#1101989, @JulianEisel wrote:
Dynamically deciding the width to fit all items would require possibly hundreds of string width calculations, which aren't entirely cheap

You would only need to recalculate this when a name string is added / the longest one shortened/lengthened ? just keeping one variable like longest_name_char_count or something ( per type of name ) . If mono-spaced, recalculating is then just comparing with char_count of currently edited name / lib name and adjust accordingly. Also beneficial for non-monospaced fonts, only calculate the longest effective string length upfront when the names change. You could even use some heuristics on what characters used trigger a recalc.

Maybe even calculate the effective longest string length per char key hit / backspace / copy-paste / select and delete, etc... ( with current widths per char given text size/font/etc, those would trigger a full recalc) dunno the variable names but say longest_name_str_width...

It seems to me choosing from a drop down is done more often then (re)naming or changing text size / font.

This not only happens with names with library references by the way. If a strategy to fix this is found to work well, it could be applied to all the name drop downs.

> In #84188#1101989, @JulianEisel wrote: > Dynamically deciding the width to fit all items would require possibly hundreds of string width calculations, which aren't entirely cheap You would only need to recalculate this when a name string is added / the longest one shortened/lengthened ? just keeping one variable like *longest_name_char_count* or something ( per type of name ) . If mono-spaced, recalculating is then just comparing with char_count of currently edited name / lib name and adjust accordingly. Also beneficial for non-monospaced fonts, only calculate the longest effective string length upfront when the names change. You could even use some heuristics on what characters used trigger a recalc. Maybe even calculate the effective longest string length per char key hit / backspace / copy-paste / select and delete, etc... ( with current widths per char given text size/font/etc, those would trigger a full recalc) dunno the variable names but say longest_name_str_width... It seems to me choosing from a drop down is done more often then (re)naming or changing text size / font. This not only happens with names with library references by the way. If a strategy to fix this is found to work well, it could be applied to all the name drop downs.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Avoid clipping data-block name in data-block menu because of library name #84188