- User Since
- Feb 15 2014, 8:59 PM (314 w, 2 d)
I applied this on top of D6929 and I still saw the same linker errors.
Okay, I applied the patch from D6930 and got the same linker errors. I removed the build folder before compiling.
This fixes the OpenEXR and OIIO linker errors I was experiencing on Arch, but new math linker errors have appeared in the last week. https://hastebin.com/nuyicakube.txt
Sun, Feb 9
Tue, Feb 4
Wed, Jan 29
Jan 26 2020
Jan 24 2020
Use all four vars (revert previous change).
Remove extra precompiled libs vars
Jan 23 2020
It is strange that it is necessary to set BOOST_ROOT. I just tested a few more combinations of the options.
Jan 22 2020
Jan 20 2020
Jan 12 2020
Jan 8 2020
This is by design. In my discussions with @Campbell Barton (campbellbarton) during development, we decided that users rarely have more than one outliner open at a time so outliner-to-outliner syncing is not something very needed. But we decided if the need arose, it could be implemented.
Dec 3 2019
Nov 30 2019
Nov 26 2019
@David Gonzalez (Bango) during development of the outliner during the Google Summer of Code, I originally did have arrow key navigation move the active element. But because activation was tied to other events (like toggling edit mode) the behavior felt inconsistent and confusing. Although moving only selection, not active is also not ideal, it was the easiest option to implement during the summer. The code for walk navigation is all there, and once the patch I mentioned is committed, it will be an easy fix to switch arrow key navigation back to the active object.
Nov 25 2019
This is not a bug, just how the walk navigation is currently implemented. Due to other factors when activating elements, walk navigation that moves the active element caused issues. Once D5817 is reviewed and committed I intend to make walk navigation move the active element as expected.
@Philipp Oeser (lichtwerk) This is a small oversight, and those two tasks you mentioned should take care of it. If not, then it should be a simple fix otherwise.
Nov 17 2019
Nov 6 2019
@Germano Cavalcante (mano-wii) I will take a look.
Oct 28 2019
Oct 16 2019
@Stanislav Blinov (radcapricorn) I replied on that other task, but I think the problem mentioned in T70852: 2.81 Outliner: using active object as anchor for shift-selection is fragile as it may become hidden in outliner is the same here. Again, I don't think this is a bug, but I'm curious what @William Reynish (billreynish) and @Dalai Felinto (dfelinto) think about this.
This is not a bug. If the light is active, then hidden from the outliner by filtering out light objects, then there is no active object in the outliner. Therefore, trying to do a range select is impossible. In your example, both Torus.001 and Torus are selected, but making a code decision to decide which to begin the range select from would be arbitrary. That is why I decided to only do range select if an active element exists.
Oct 15 2019
@Dalai Felinto (dfelinto) when designing the range select (shift + left click) I based the behavior on file browsers I had handy. One element must remain "active" from which to extend the selection over a range. I chose to not modify the current active object. If the last selected element (with shift) became active, then a subsequent range select would start from that element. So this isn't a bug, just how the behavior was designed. This is how shift+click works in other applications, so I don't think it should be changed. (VSCode for example)
Sep 21 2019
Sep 20 2019
Sep 19 2019
I'm pretty sure this isn't a bug, as the same behavior is used if Cube is moved to collection 2 from the viewport with "M > Collection 2". If only the parent cube is moved to the second collection, the outliner draws the child with a dashed line under it, showing the relationship, but implying that the child is in a different collection
Sep 18 2019
@Dalai Felinto (dfelinto) I'm willing to look at this, and I think instancing on paste in the viewport makes sense, though I imagine a paste in the outliner would duplicate the collection on the same level as the copied collection.
Yes, I will take a look.
Sep 17 2019
Sep 16 2019
I discussed this report earlier today with the author (he messaged me on Twitter). The real issue was the use of Shift+LMB for selection in the outliner. Shift is the modifier key for doing a range select. When there is an active outliner element, range select will not activate any elements. Ctrl is the modifier for extending selection + activation (equivalent to Shift click in 3D view).
Sep 13 2019
Would we also want general functions for bone and sequence selection to tag for syncing, depsgraph, and notifiers?
Sep 2 2019
Sep 1 2019
Aug 31 2019
- Merge branch 'master' into arcpatch-D5572
- Merge branch 'master' into arcpatch-D5572
Aug 29 2019
I moved the tagging on setting view layer, scene, and workspace from the RNA. I think it would be safe now to commit this, the improvements to syncing, and tagging for outliner operations.
- Move scene, viewlayer, and workspace update tagging out of RNA
I think that using the depsgraph or notifiers would be the better route. A quick look through the code where ED_outliner_select_sync_from_ calls are made shows that the notifiers are more common than depsgraph tags (especially with bone selection).
@Dalai Felinto (dfelinto) toggling editmode isn't what is deselecting the object, it is related to selection syncing. Because the object is not selected in the outliner, synced selection deselects the object.
Aug 26 2019
Aug 25 2019
Outliner: fix select sync on sequence paste
Updated with more syncing fixes for separation, duplication, and outliner operations
Aug 24 2019
Aug 23 2019
@William Reynish (billreynish) That's fine and will work well I think.
Aug 22 2019
@William Reynish (billreynish), I think using a new icon and some reorganization would be good, then the popover could be shown in sequences view which doesn't have filtering options.
Aug 21 2019
Sorry, I meant activation of UI list data. Materials, Grease Pencil Layers, Vertex groups, etc. I am trying to see how this will work with properties syncing. If I wanted to edit a specific material, I would think clicking the material name would open the proper tab in the properties editor, with the selected material active.
@Julian Eisel (Severin) thanks for the suggestion. I will update the design to use two popovers for consistency.
Besides scenes and cameras I think that we could include activating collections in the left gutter so selecting a collection to rename or move doesn't also activate it. It would also make the active collection more clear (I remember some confusion from users about active collections).
This was fixed by 6bc6d016c5e7.
Aug 20 2019
Yes, the subversion needs a bump. Will do.