Prior to rB3b8a14a3c072 it was not possible to change the rotation in the Adjust Last Operation HUD at all.
Now if you touch the rotation, it changes back to WORLD, because this rotation happens in world space anyways.

here sdf is the new folder, it has some highlight that resembles that of a hover (T73679). it should have been like that of T73217, alternating dark and light. release is selected, i.e. using up/down arrow to traverse the list.

@Andrzej Ambroz (jendrzych) some work for you.

Committed this in the menu rBd95dbd1f4f1c: UI: add kerning menu for 3D text editing since this is mostly a way to expose the key shortcuts, adjusting kerning with menu items isn't that handy.

In fact, with nothing indicating on the interface that the hotkey * changes between no expression and expression mode, it is very difficult for the user to find out.
Changing the behavior to use with expression by default would not be the best solution since users are used to, for example, changing the signal just by pressing -
And I'm also not sure if the * hotkey is the best choice.

@Alessio Monti di Sopra (a.monti)) ah, didn't notice this, corrected rB661b01825f811e949feae5ade8170efe09a716c2, which adds the slash in fsmenu_insert_entry instead of making all callers add it.

@Campbell Barton (campbellbarton) thanks for looking into it!

Go ahead, fire away!
Thanks for the help 🙂
I actually wanted some info regarding the issues related to the font. I'll try to come up with something.

• Packed image from library can't be saved: "name" [lib]
• Image can't be saved, select a different file format: "name"
• Multiple saved images use identical path: path
• Image can't be saved, no valid file path: "name" [path]

Committed rB48816d462eedc254d439608431fde78d74f2f518 with the following changes:

In D6934#164828, @Yevgeny Makarov (jenkm) wrote:

The uiItemL_ returns a pointer.

In any case, regardless of how it will be implemented internally, it is convenient to have a uiItemL_select() wrapper to make it easy to use. That's exactly what's done in this patch.

uiItem functions do not return uiBut* pointers, they're meant to abstract away individual buttons.

Damn, that does look quite nice!

I am also getting this problem. The build on 2/2/20 theme worked fine. Then when I updated to build 2/14/20 it was lighter. I'm on windows 8 with AMD Radeon HD 7310 integrated graphics card. The computer is air gapped and nothing else was installed or changed. To get headers close to the same darkness I have to set it to a hex #0f0f0f or RGB 0.059

• modified ED_get_xdg_user_dirs() to directly insert the menu entry and renamed it to fsmenu_add_linux_dir()

@Debuk (Debuk) That would be nice. Thank you.

@Brecht Van Lommel (brecht) - What's poor here is the name UI_SELECT_DRAW, it could be renamed to UI_TEXT_HIGHLIGHT to make more clear what it does.

In D6934#164788, @ThinkingPolygons (ThinkingPolygons) wrote:

I would if I knew how.

In D6934#164786, @Harley Acheson (harley) wrote:

Why not test the patch and find out for yourself?

You can add an uiItemL_ex function with an extra const bool highlight argument. This can then be extended as needed.

@ThinkingPolygons (ThinkingPolygons) wrote:
This is overkill IMHO.
Will this white color be themeable?
What if my dialog box is light/white, the text will be unreadable?
If I can't change that white color, that's not good.

Image %s can't be saved automatically, must use a different file format
"%s" is read-only. Select a different image format

This is overkill IMHO.
Will this white color be themeable?
What if my dialog box is light/white, the text will be unreadable?

@Arvind R (r-arvind) - I am actually planning to apply for GSOC this summer , maybe I can take this up as my task

Although could we get the same result by adding a new uiBut.flag instead? As in follow the pattern of UI_BUT_REDALERT (UI_interface.h) as there is also a similar UI_BUT_INACTIVE too. LIke "UI_BUT_TEXTHI" or similar. then check for that in interface_widgets.c widget_state() and set the text color to use TH_TEXT_HI.

What you have to do here is add quotes to image names. It'll definitely be an improvement.

I guess the UI_SELECT_DRAW flag is just for these purposes.

This looks better and allows better separation between header and text paragraph. But I'm not sure if we consider this somewhat abuse of the selected state - seems a bit like a hack?

@Campbell Barton (campbellbarton) Any suggestions about my proposal to take this up for GSOC?

@William Reynish (billreynish)

• 'writable' is a word I would prefer not to use. I find the previous error message clearer, with more straight forward wording
• 'Cannot save %s with invalid path: . 'With invalid path' I think is not so clear. What is meant is that the images can't be saved because there is no valid file path. Again previous description was more straight forward.

One of the changes to me seems good: Multiple saved images use identical path: %s is indeed clearer than the original text.

I don't know if the updates are really clearer. Overall I think it's less clear.

Image %s can't be saved automatically, must use a different file format
You must change %s to a writable image format

Hi guys, any chance this gets patched in for the 2.83 final release? Thanks, hope it's not too much work to get that resolved

@Marcelo Mutzbauer (1xundoredo) are you interested in updating this patch? There's also support for dynamic operator descriptions now (see wmOperatorType.get_description), so you could get the tooltip with the shortcut hint to work. Not sure if we still want that design wise though, many things changed here in 2.8.

I've been looking for a way to get rid of the shadow behind the nodes backdrop, or at least control the opacity of it, will this patch allow me to do that? @Ellwood Zwovic (gandalf3)

@ThinkingPolygons (ThinkingPolygons) This change only applies to node based editors

• UI param rename and version dependency

Parameter name was changed in user preferences from "Grid depth" to "Grid levels",
description was changed from "Makes grid chunks more profound" to "Amount of grid lines displayed in the background",
added grid_levels to do_versions_theme

Abandoning this. Code would have to be redone for 2.8 changes and there's no consensus on the design. Plus, we may rework the visual language of the node editor as a whole for the everything nodes project.

Does this affect the movie clip editor? I guess nah, but the graph/dopesheet view there has a very strong hardcoded grid that could benefit from something like this. 🤔

In T74157#879972, @Demeter Dzadik (Mets) wrote:

I can think of cases when I'd rather not have to bother adding my operator to a menu just to make it searchable, particularly when developing the addon mainly for myself or my friends or my team, or when the addon is a single operator that doesn't really belong anywhere in the UI, etc.

Just going through some old patches.

This needs a change in do_versions_theme to ensure existing preferences do not load with grid levels 0. Something like:

Some of those sound like symptoms, not the root cause.

LGTM now

In D6826#164313, @Harley Acheson (harley) wrote:

I think the function name "ED_get_xdg_user_dirs" has the plurality wrong and should be "ED_get_xdg_user_dir"
But personally I wouldn't do above, but would instead call it something like "fsmenu_add_linux_dir" and add arguments for "struct FSMenu *fsmenu", "const char *name", and "const int icon" and add the item to the menu in there.

@Demeter Dzadik (Mets) The root issues are:

I can think of cases when I'd rather not have to bother adding my operator to a menu just to make it searchable, particularly when developing the addon mainly for myself or my friends or my team, or when the addon is a single operator that doesn't really belong anywhere in the UI, etc. Is there really no other way to allow us to set shortcuts from the search menu? How come? Are we sure we're fixing the root of the problem here?

Yes, at a certain point it is better to grey out.

@TheRedWaxPolice (TheRedWaxPolice) Python operators can add themselves to a menu fairly easily.

Regarding criticism along the lines of "Shouldn't it always be on by default?" and "Who asked for this?", I think adding more options is nearly always a good idea, particularily for accessibility purposes.

yeah it's intel cpu, the thing is I don't know how to reproduce it now :( I selected selarate object and bone from armature of another object and parented it (ctrl+p)
I reloaded backup file and I tried the same thing and it didn't broke bones selection, aparently there is another condition which is causing this

Sorry, I must have misread something.

If we ever get filtering it would be nice to then allow the inclusion of extra reports. I *think* we can, right now, start blender with command-line arguments that then log more detailed reports, including things like simple item selection. But they only go to the console. So we might be able to enable that same behavior within Info Editor.

• Added grid options to preferences
• Revert "Fixed grid visibility for Texture Node Editor"
• Revert "UI: Node space grid visibility"
• Changed parameter UI text and description

Okay, that is pretty sweet!

Excellent. Thank you.

I say you (plural) that when I want to bear near an object, the aplication doesn't alow me and when I want put application's view on the buildings, not it allow me. How can I solve it?

It's most likely a different issue. If you think you found a bug, best to create a new report with example .blend file and all requested system information.
https://developer.blender.org/maniphest/task/edit/form/1/

I mean Intel CPU

In T65138#879416, @Patryk Sawicki (yetanotherblenderuser) wrote:

I just got that problem in 2.82
I have windows 10 and GTX 1060.
Tbh I don't know how I ended up witht his but right now in pose mode I can select bones only with lasso or clircle selection tool.
Previouysly it worked with any tool.

Thanks for the detailed report. I can indeed reproduce this.

Moving grid settings to Preferences -> Theme. It will be possible to adjust grid levels (so far it looks better than initial idea).

(was passing by :p)

Hi! Please note that it's just a change proposition :D
I thought about placing it in theme setting but it didn't feel suitable because in every other editor the grid visibility is placed directly in the editor space. In theme it is possible to change node editor backgrounds for easy differentiation. For example in compositor view I don't really mind grid since backdrop usually covers whole view including grid, as for node view it makes whole view darker and introduces a lot of noise during panning around, especially in editing grouped nodes, possibly causing dizziness.

• Fixed grid visibility for Texture Node Editor

@Peter Fog (tintwotin) No need for report if you are not fixing bug, just improving interface

This seems more like a theme option? It's not clear to me why you'd want to hide this per editor?

This report was linked to a patch, which cleaned up the polls giving the impression of a broken sidebar. It also exposed the mentioned meta strip functions. In the VSE chat I posted a suggestion on how to make the Meta Strip range more clear and with your line of code the "Return" button could be implemented. So all of these things could be solved, but I'll leave it up to you guys.
The patch: https://developer.blender.org/D6913

There are a couple of bugs/unfinished implementation of the Meta Strips in the Sequencer:

Always report one bug per report.

I think the function name "ED_get_xdg_user_dirs" has the plurality wrong and should be "ED_get_xdg_user_dir"

@Evan Wilson (EAW) - @Harley Acheson (harley) Is this the type of bug you said to watch for in D6370?

I just got that problem in 2.82