- User Since
- Dec 12 2013, 11:11 PM (175 w, 4 d)
Fri, Apr 21
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?
Tue, Apr 18
Sun, Apr 16
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).
Sat, Apr 15
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 ("What is COMP_F32"?), 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 ;)
Thu, Apr 13
Wed, Apr 12
Tue, Apr 11
Mon, Apr 10
- 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 compatibility support for reading 2.8 files in pre-2.8 Blender.
- Added place holder icon.
- Of course tons of fixes, cleanups, etc.
Sun, Apr 9
Just to name some use-cases:
It's common to save .blends for sharing with a text editor opened, with a text giving all kinds of information about usage of the .blend file. I think that's a pretty useful trick that would be nice to keep working.
Also, when working in the motion tracker, opening a .blend file that contains some 3D scene should move you to a working enviornment setup for the 3D scene, users wouldn't want to stay in the motion tracking environment.
Sat, Apr 8
Fri, Apr 7
Without this, bones use matrix from last redraw, even if transform has changed since then. You have to look closely but there is some noticeable jumping of a few pixels when changing drag direction. Of course calling BKE_pose_where_is on every redraw while dragging isn't really nice either, since it's called again when drawing the bone itself (I guess). Can't avoid this without changes elsewhere in code I'm afraid, but shouldn't be hard to do. Maybe add flags for dirty matrices, or make transform system handles matrix updates at the right moment.
Note that we agreed on committing this first and porting changes from transform-manipulators branch soon.
So seems we have some misunderstanding here, I re-wrote transform_manipulator.c in the transform-manipulators branch. I'm sure we talked about that one before on IRC, but either my brain is fooling me or I wasn't clear enough. In any case, this is a pretty stupid situation, sorry if I've caused confusion and redundant work :/
We now have both dna_workspace_types.h and DNA_workspace_types.h (CMake still uses former one I guess).
I intentionally used a lowercase prefix to mark the file as local header btw. Don't have a strong preference on it though, just thought it would be reasonable.
Thu, Apr 6
Wed, Apr 5
Tue, Apr 4
Hrm... IIRC @Joshua Leung (aligorith) - who is the module owner of most of the code you touched - strongly prefers to keep declarations at the top of blocks and not mixed with actual code. I personally agree with this style, it makes it easy to spot where a variable is defined, without having to search it throughout the block.
Sat, Apr 1
Thu, Mar 30
Wed, Mar 29
Tue, Mar 28
Mon, Mar 27
Mar 25 2017
Mar 24 2017
Just to make that clear: When talking about adding more information to tooltips I'm not talking about giving such in-depth descriptions like the manual. They should give all the essential information, the manual can go much broader than that (add screenshots, put tools/options into context, etc). Don't recall if we talked about this explicitly, but I think that's what other UI workshop attendees had in mind too.
I can think of two ways to solve this:
- Always use the first set of edges that form the same horizontal/vertical coordinates as the one dragged from - In your example this would be the screen boundary on the right.
- Allow gradually increasing join size edge by edge - In your example this would look something like this:
Initial layout: +---+---+---+ | | | | | 1 +-+-+-+-+ | | | | | +---+-+---+-+ Mouse release after dragging over first vertical edge: +-----+-+---+ | | | | | 1 +-+-+-+ | | | | +-----+---+-+ Mouse release after dragging over next vertical edge: +-------+---+ | | | | 1 +-+-+ | | | | +-------+-+-+ ...
Implementation-wise, the join operator will need to keep track of more than just two areas, and will need to find areas by different means than just finding the area under the cursor. Also, the code that draws the join overlay will need to be restructured.
I definitely wouldn't mind a refactor of the area joining code, it's really hard to understand whats going on in it, far from self-explaining. Guess the main reasons for that are bad variable names and cryptic integer and character values instead of enums/defines.
Feel free to give it a go, otherwise I will ;)
Mar 23 2017
Great to see this tackled!
I also don't really agree with @Aaron Carlisle (Blendify) here, I find this much more intuitive than what we have currently.
Functionality wise I'd say it's fine to put this into the 2.8 branch as it overlaps with quite some other (planned) 2.8 UI changes. Note that there might be some conflicts when porting the patch to the blender2.8 branch.
Mar 18 2017
Great! Just quickly compiled & tested it, and it's working just fine.
I don't think we should use separate files for every tooltip though, I'd prefer having JSON/XML/Python files for each module (mesh ops/props, screen ops/props, render ops/props, ...). IMHO that would be totally fine for users as well, it can be made really simple and self-explaining. Changing them won't be a common thing anyway, this is more meant to make it easier for people to do these changes and submit them for master inclusion.
On IRC we concluded that using this will be the exception, however thinking about it some more, I realize we actually should make heavy use of this. It could be a great way to improve our tooltips based on the new guidelines. And everybody could help doing it, not just devs ;)
Already discussed this with @Clément Foucault (fclem), we need a shader with clipping plane support here. I did this in the transform-manipulators branch already, see rBc5c2c3be9815670b.
We can also just wait until the new transform manipulators are ready to get merged into master (eventually!) which will fix this issue anyway. However it's not much work to fix this particular issue.
Mar 17 2017
Committed rB2977a8cd2176 to 2.8 branch.
- Update patch for blender2.8
- Use new immediate mode work-alike drawing
- Remove testing code
Mar 16 2017
Grrr... seems like auto-closing is failing... Closed by commit rB7eecc2e1c43ba.