@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.

Played with this for a bit to see where it stands. Found some issues that need to be looked into. Quickly going over RNA, DNA and UI changes, I didn't see anything obviously wrong.

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.

@Kévin Dietrich (kevindietrich) (or @Fabio Russo (ruesp83) even), is there interest in reviving this?

Campbell made some fair points about this, and they still hold up. Also, with 2.8 we have the ability to create popovers, which are more suited for this kind of option dialog.

Just going through some old patches.

On Linux, I got multiple build errors, so I had to do some changes. With these changes I also didn't need to use an absolute patch for the Ghost includes:

Thanks to the DNA defaults, this is finally solved in principle. We still need to add DNA defaults to more data structures, but that is something we can do during regular development.

So is this actually solved in the refactor? This was a big issue for some artists here, so better to double check it doesn't get lost.

In T73978#875548, @Yevgeny Makarov (jenkm) wrote:

It works in 2.80, for example, 'knife' cursor becomes large, but does not work in 2.83 (macOS).

This is expected. The cursors were updated, but on macOS they don't respect the Large Cursors. Think that's because we'd have to provide the cursors with 4x the size then too (double pixel size due to Retina + Large Cursors).

@William Reynish (billreynish) will be in Amsterdam end of this week, we (the UI-team) will look into a decision for this design then.
Pablo and I discussed this further in the Blender chat a while ago. He was fine with pausing work on this patch for a bit, which is why there weren't any updates since then. I'll make sure that he can continue on this soon.

The cursors don't change anymore based on the mode, but based on the selected tool. The default OS cursors are not upscaled, only our custom ones.

Could not reproduce this either, so I guess this is indeed macOS only.

Classifying this as bug for now, because the code doesn't seem to do this intentionally from what I can see. The viewport team can re-classify if they disagree.

In the IC keymap this uses the X key now instead. This works fine for me.
So guess this can be closed as resolved. Thanks for the report either way.

In D6400#163063, @Brecht Van Lommel (brecht) wrote:

It could work for multiple editors with some heuristic to find corresponding editors, but I'm not sure it's worth it.

Yeah, it's probably fine to have it for 3D Views only to start with. If this appears useful for other editor types too, we can always add it to more.

I fixed a related bug, see rB9b243b9a53ca.

I think this is fine as fix in principle. I'd still like to hear from @Campbell Barton (campbellbarton) though if we should indeed fix this on this level, i.e. not expecting Python scripts to override the context.

This report does not contain all the requested information, which is required for us to investigate the issue.

Yes, but the function could return two colors, uchar *r_text_color and uchar *r_line_color.

As mentioned, this feature is only available in the 3D View. In other editors it's not implemented.

The feature idea is really useful. We agreed on adding some way to sync editor data during early 2.8 days, see https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Shared_Editor_View.

Closing this quick hack, the feature was implemented by @Alessio Monti di Sopra (a.monti) and made its way into master.

@Michael Soluyanov (crantisz) we usually close reports after a week without reply if information/action was requested. You've just submitted some patches, so I'll assume this was just an oversight and leave it at a friendly poke for now.
What was requested is that you try to remove any additional data from the .blend file that is not needed to reproduce the issue. Remove all irrelevant workspaces, windows, cameras etc. That may be hugely helpful to pinpoint the issue.

Guess this is fine. Am almost ready to accept this.

Quite some things have changed here during 2.8. I've tried recreating this and wasn't able to, so I assume this is fixed.

So this seems to be an issue of the OS or of the accessibility app, not something on our end.
Closing this report for now. If Apple says otherwise, so if they say we should actually fix something in Blender, we can re-open the report.

I don't see the weights either when opening the file, but I think that's fine since the Comb tool is active.
However if I select the weight tool, they show up once I start painting. Interestingly, if I enable the tool settings region (3D View → View → Tool Settings), the weight drawing is toggled immediately when switching the tool.

I was not able to reproduce this issue either, but steps to reproduce it are not clear.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Thanks for the report. This seems like a graphic driver issue. Please double-check if the drivers are up to date and the hardware meets Blender's requirements: https://www.blender.org/download/requirements

I do think these limits should exist, why would you want to keep scrolling out of camera bounds? This perspective is meant to show what the camera sees, not to navigate the viewport.
Also note that moving the view behaves glitchy without this limits and continuous grab enabled.

Okay, I think it's time to close this. We can reopen if there are more things to be discussed.

Let me add: I chose the name ED_region_tag_redraw_editor_overlays() over ED_region_tag_redraw_gizmos() because due to the way we currently draw, we can not redraw-gizmos without also redrawing other editor overlays. Namely annotations which are drawn in-between 3D and 2D gizmos.

The animation team has not accepted this patch yet.

Partial review, found some things to address, but nothing too serious.

What's up with this task? Guess it can be closed since we have T63726 now?

Most of the points here were addressed. The separate drawing thread idea isn't implemented yet, but that's a project that can be done as a part of regular VR development.

This is a bit of an awkward situation. We can't just change the RNA definition, because that would be an API breaking change. I'd expect that many add-ons and scripts use these properties. One thing we could do is making the tooltip text more general, so that it doesn't describe a specific enabled/disabled state. But I personally find it hard to come up with a good description that follows our usual tooltip language, am open for proposals though :)

Code-wise, this is fine with me. I guess if Sybren accepts this now, we can commit.

The way these things are mapped is a historical decision that would be very hard to change now. I think it is indeed an issue of the right-handed, Z-up coordinate system. Any change here would have major impacts, even if they were easy to do. So this is not just a visual issue, it's the definition of our coordinate system that causes this inconsistency.

So this appears to be a limitation in the selection syncing design, not like something that's supposed to work but is broken. So will set mark this as known issue, as mentioned improvements are being worked on.

Although I can't recreate this easily with my current setup, I'd consider such issues as quite likely. It's definitely more than just a visual glitch, so will consider this a bug.

I've recently checked on this briefly to see where the issue is coming from, but I didn't see anything suspicious. My first guess was that the grid overlaps the axes, so that you'd get the color mixed. But even disabling the grid didn't seem to fix this.