- User Since
- Dec 12 2013, 11:11 PM (180 w, 2 d)
Thu, May 25
- Fix various crashes/glitches when reading transform orientations of old files
- Undo changes in workspaces branch and merge into this patch
- Minor cleanup and fix wrong argument list caused by merge
Wed, May 24
Planning changes. Not much of the actual implementation should change however, so it's fine to do a first review already.
Also just found a crash when reading transform orientations from old files, think it's easy to fix, JFYI.
Added a patch for moving custom transform orientations from scene to workspace level, D2687.
We were talking about moving it to screen level previously, but realized this would be too granular for users (as in - having to set it up for each screen-layout could become annoying). Having it in workspace seemed to make more sense to me.
I'm of course fine with, would of course be nice to hear what others say. I'd still prefer a clearer distinction than Properties Sidebar and Properties Editor give us, but I think this is acceptable since we didn't find a solution that gives this,
Sun, May 21
Sat, May 20
That means I need the icons as .svg now, images above are all .png or .jpg.
Fri, May 19
Thu, May 18
So, do we all agree that OUTLINER_OB_GROUP_INSTANCE and OUTLINER_OB_FORCE (ALT 4) are fine? If so I'll go ahead and commit them.
Esp. the gradual use point is pretty convincing to me. So I would be fine with the DNA_PRIVATE_* idea.
Sun, May 14
Sat, May 13
I don't really like this either. Thing is that the custom orientations never should've been stored in the scene but in the screen IMHO... I don't see why you would want to make it scene data (rBd660e293650d doesn't give any info on that either).
Fri, May 12
Wed, May 10
Mon, May 8
I think all mentioned issues are fixed now. FWIW, most issues were indeed caused by merges or recent changes. I also committed a better fix for the fullscreen window issue, we do all workspace versioning after lib-linking now.
Only thing remaining is cleanup of template_ID which I'll do separately (but so that it's ready before this goes to blender2.8).
- Fix unfreed IDProperties, caused by branch merges
- Fix crash loading pre-2.80 .blends
- Fix crash when loading .blend with multiple scenes
- Fix failing assert on undo
- Fix (harmless) error print with multiple workspaces
- Fix crash opening startup.blend as regular .blend (again)
- Fix empty default workspace configuration
- Better fix for reading fullscreens from old files
- Revert redundant workaround for buffer overflow
Sun, May 7
Feel free to commit, I'm sure if something breaks you'll be around to fix it ;)
Sat, May 6
Closing this, there isn't any useful information to work with here. Please create a new report with all requested info if you want to get an issue resolved.
I don't see why we would have to rush this too much, replacing an icon is a minor change that can be done in Bcon3 too (@Campbell Barton (campbellbarton), you agree?).
Went over the patch just really quickly again, looking almost good (didn't test latest version though).
Fri, May 5
The key-repeat issue was not the only reason for removing this Add-on:
- To my knowledge there wasn't an active maintainer at that time, which is against our rules for keeping Add-ons in the list of officially supported Add-ons.
- It only worked for the 3D View, not for other editors.
- It didn't work with most modal operators.
Ah that! Yes, this is intended: Idea was to only have the "General" workspace with the "Default" Layout in the default startup.blend, the other default workspaces could be added via the '+' button (meaning the default workspaces.blend would contain these). That way we don't waste space in the topbar with workspace-tabs that the user will never need, but we still have a number of ready-to-use workspaces bundled with Blender.
When opening pre-2.8 .blends we still convert layouts to workspaces, the only exception is the default startup.blend. (See changes in versioning_defaults.c.)
I should really write such things down in a wiki page... :S
Wed, May 3
Tue, May 2
Regarding the bugs on undo, reading of old files and such, I can recreate them, but I'm pretty sure they are caused by recent changes. I tested such simple actions regularly and I would have noticed issues like these. Will investigate.
@Lukas Toenne (lukastoenne) worked on implementing shader based hair drawing some time ago, I think it's all in the stand_nodes branch. See his Kajiya shading demo video. Maybe it's time to have a closer look on that work?
Apr 27 2017
I don't really like the way this is done. Added inline comments on some specifics, but I really think this should have been approached differently.
Also, I'd like to see an example of where this would be needed. I'd say it should never be possible to set an invalid value there in the first place. UI code should probably check that when selecting and renaming search items, and fail properly instead of allowing to set invalid values.
Apr 26 2017
Apr 21 2017
I wasn't able to recreate this (tried with GNOME 3 and LXDE) but I also only got a single GPU system to test. @Campbell Barton (campbellbarton) or @Brecht Van Lommel (brecht) would be other candidates for fixing this, maybe you can recreate it?
Apr 18 2017
Apr 16 2017
I actually started liking Properties Sidebar. It gives a nice hint to where you can find it without specifying left or right (which you can still change). And I think for everyone who has basic understanding of Blender's sub-windowing system it's obvious that this doesn't refer to the Properties Editor which can be placed everywhere.
The only thing it doesn't convey is that it's a per-editor region, but don't think that's needed really (toolshelf doesn't either).
Apr 15 2017
I think it's totally fine if an external library uses it's own code-style or naming conventions. However, Blender's calls to it should follow Blender's conventions. Especially in the case of a library that's accessed everywhere in Blender - like Gawain. We all know what Gawain is and what it does for us. For us, naming conventions may not be so important. But this code will likely see many years of aging, new devs will stumble over it, people who are familiar with the details of Gawain might move on to other, non-Blender things. So making it clear what functions and types do just by well though-out naming is crucial if you ask me.
As a matter of fact, I've been asked at some point to debug some immediate-mode replacement patches where it turned out to contain wrong usage of VertexCompType (using COMP_I32 instead of COMP_F32 or so). Reaction of the patch author was like: "How the hell should I know what this is doing, the names are just useless and there is no documentation. I just copy & pasted it!". Rephrasing from memory here, but this actually happened and I'm not exaggerating even ;)
Apr 13 2017
Apr 12 2017
Apr 11 2017
Apr 10 2017
- Support storing active render-layer per workspace.
- Add a workflow file to store custom workspaces as part of user configuration.
- Allow user to choose a workspace from this workflow file when adding a workspace.
- Bundle a default workspace configuration with Blender.
- Improve support for multi-window setups (like proposed in T50521).
- Only ensure unique layout name within workspace.
- Basic support for reading 2.8x files in pre-2.8 Blender.
- Added place holder icon.
- Of course tons of fixes, cleanups, etc.