@Jacques Lucke (JacquesLucke), @Brecht Van Lommel (brecht): ideas?

Getting this, too (happening when you add the same workspace type you are in [and only if this contains a timeline])

@Sergey Sharybin (sergey): you did the recent fix, mind checking?

• bring back unneccessary removal

Testfile [including image sequence]:

This is reproducable with any image sequence mapped to ParticleSettings influence [no update on framechange there]
Checking...

Cannot reproduce with an Intuos 4 on linux

This is resolved in 2.8

second part is also resolved in 2.8 [bevel weights also showing in vertex select mode], so this can be closed...

Nice idea :), not sure how to proceed with this though, I guess it would be better to post this to BA or rightclickselect or https://devtalk.blender.org/ first?
(Or possibly do a diff here? https://developer.blender.org/differential/diff/create/).

Confirmed, checking...

Confirmed (but on low prio - since you can still see this is related to IndentationError), can check later...

Can confirm.

Also cannot reproduce here in 2.79 (as well as 2.8).
And since this is confirmed to work in 2.8, I assume this can be closed [there are many things fixed in 2.8 which dont get a backport back to 2.79...]

Will close this [unless @Brecht Van Lommel (brecht) or @Campbell Barton (campbellbarton) have objections?]

I think there might be a general mathematical issue doing non-uniform scaling after rotation (as this cant be decomposed back)?
This has always been the case in blender (and other software, too) [at least as far as I can remember], I assume this is not considered a bug, checking though...

This was an intentional change, it is now ctrl+RMB, see rB1e8b007d50f76362bb4067800bc1c12c9f87b1c6

Renders fine though with F12, so seems to be a viewport drawing issue...
@Clément Foucault (fclem): does this ring a bell?

This is also true for other object types without data being drawn on the screen [meshes,surfaces,armatures,...], and a single point in a curve wont draw anything...
Lasso also works, also works if you display all origins:

I guess this is related to the discussion in D3869 (also see https://blenderartists.org/t/x-mirror-behavior-in-2-8-poll-and-opinions/)
So there seems to be an advantage of having this per mesh not just as a tool option... (at least for mesh editing, I assume this goes hand in hand with weightpainting as well though...)

Not sure I understand correctly:

• Is this still an issue with a fresh build?

This is also the case in 2.79 and while could be improved [I see the point where this gets confusing], I think there are just two settings that have an effect on weightpaint being mirrored: the mesh option plus the paint option, if either one is active, mirroring will take place...

Yes, this was an intentional change (see rB1e8b007d50f76362bb4067800bc1c12c9f87b1c6)

Hi Manuel!

@Campbell Barton (campbellbarton) : mind checking?

@Clément Foucault (fclem): any reason we a drawing this with testing Z?

Can confirm this result in better results for the file in T53581.
Note though there was F1442978 already in the bugreport [which does the same thing - and additionally claims to improve performance (havent checked this though...)]

Can confirm.

Glad to hear, closing then...

Looks like the (camera) origin is actually correctly scaling with the setting, drawing the camera however fails [stays in original position].
For meshes, this is similar: the selection outline will not scale with the setting the actual polysoup will...
Guess this is CoW-related?
(also getting assert BLI_assert failed: /blender/source/blender/blenkernel/intern/cachefile.c:103, BKE_cachefile_reader_free(), at 'cache_file->id.tag & LIB_TAG_COPIED_ON_WRITE' exiting blender after importing...)

The thing is that newly created geometry weights will always be interpolated from adjacent geometryand will end up in neighboring vertex groups.

Happens here if you do it from the User Preferences "burger" menu [Save Preferences button is gone then and exiting after seems to save preferences -- even though Auto Save Preferences was disabled prior]

What @Hanna Murad (DiamondGlitter) said, remove the Car body from the View Lock, then Center cursor and view all and Center view to cursor should behave as expected...

Think this has the same underlying cause as T59244.
So I guess this would - as well - not be considered a bug, but a TODO, will add this to T63726...

I am getting this, too. It is happening when you have Auto Save Preferences disabled, which is indeed dangerous I think...
Without checking code, this might be because Auto Save Preferences gets enabled due to Load Factory Settings? And thus then it the gets saved?

I assume this is drawing code [not sure though], @Clément Foucault (fclem): dose this ring a bell?

Backtrace is a bit misleading [since this is reproducable without animation_nodes enabled], but can confirm, checking...
Deleting from the UI has a valid Lattice->editlatt in lattice_undosys_poll / editlatt_object_from_context whereas doing this from python doesnt...

Generally: please only report one issue per bugreport (otherwise it is hard to keep track multiple issues)

@Bastien Montagne (mont29): have an opinion?

Thx for getting back, this sounds very much like T61474.
(issue there seems to be that hardware acceleration gets wonky using gizmos -- and seems to be less of an issue when other GPU accelerated apps run next to blender)

note: it might be good to pass an option to CustomData_bmesh_copy_data to controll whether this is done or not (since this called from multiple places)

• Revert "Fix T65357: wrong facemap indices after applying a boolean modifier"
• set customdata to default for layers present in dest but not source in 'CustomData_bmesh_copy_data'

Some findings:

In D5003#114191, @Brecht Van Lommel (brecht) wrote:

I think there is a deeper issue here, booleans should not have to do anything specifically for facemaps.
BM_mesh_bm_from_me seems to be using CD_CALLOC, using CD_DEFAULT instead may help?

Just to make sure I understand correctly:

Can confirm that above patch enforces an update.

Not sure if this could be considered a bug.

Not sure I understand correctly.

This should be fixed by rBAd79fa2c042e34e1639030b06ff762673a0a68803.

This is a popover (which draws a panel).
Same is true for the following:

If this is solved with default (factory) settings, I guess this can be closed, thx for getting back.
Feeld free to comment again if issues persist...

adding a layer "by hand" with CD_DEFAULT (initializes data correctly to -1) seems to do the trick, not sure though if this should/could be handled in a more generic way?

Confirmed, checking...

Can confirm, while polling (PE_poll, pe_get_current), psys->edit is NULL