- User Since
- Dec 12 2013, 11:11 PM (253 w, 2 d)
Sep 4 2018
Aug 27 2018
Aug 24 2018
Jul 6 2018
Jul 3 2018
Jul 2 2018
Jun 30 2018
Jun 29 2018
Arrrg, no! Pasted wrong commit hash... This was in fact caused by rB7ffe838473a7f0b4a, not ca8f787349dcdf5.
Jun 28 2018
Jun 20 2018
I think the best way to go about this is what we agreed on during the 2.8 UI workshop:
Since we plan to introduce the global top bar, we can also repurpose the Info Editor. It would be the expanded, much more detailed version of the status bar. Our place for all kinds of statistics and logs.
The Info Editor could contain:
- Notification logs (log of last displayed warnings, errors and hints)
- Information about currently open .blend file
- Log of executed operators
- Detailed information about on-going jobs
- Diverse statistics (memory, polygon count, object count, ...)
- Hardware/Driver information (maybe system-info.txt can be integrated a bit nicer here?)
Jun 8 2018
Jun 4 2018
The way things work right now is totally intentional. Only code that actually deals with area geometry (ScrEdges and ScrVerts) should use ScrArea.vn. The bounds of ScrArea.totrct and the ScrArea.vn vertices are not supposed to match. Doing so would reduce the space between editors:
I'm a bit skeptical about using the number keys for mode changing too. When changing a mode, users also typically change the task they are doing (object mode is an exception). That is exactly what workspaces should handle though - each workspace would have it's own mode set, e.g. the "Animation" workspace would be in pose mode, the "Retopo" workspace would be in edit mode with necessary tools, add-ons and viewport settings loaded. See T55246 & T53389.
So in the big picture, the workspace mode and multi-object editing would mean users switch modes far less frequent. Instead they would change workspaces. They'd probably still regularly toggle between Object Mode and the workspace mode.
May 25 2018
Improvements to BLI_str_format_bytes:
- Rename to BLI_str_format_byte_unit
- Use long long int as argument, not double. Floating point byte-count doesn't make much sense, it's only needed for internal purposes.
- Strip trailing zeroes.
- Support passing negative values - not sure if that's useful even, but simple to support.
- Improve test coverage, esp. for corner-cases.
- General cleanup (codestyle, naming, comments, etc.)
Stumbled over this today and made some changes (updating patch in a minute). Should be ready to go now.
This is most likely a graphics driver failure, you can try if updating your driver fixes the issue.
May 24 2018
It should definitely be possible to hide it by dragging its edge - just like the lower part of the top-bar.
May 23 2018
Not sure if there are currently specific rules for triaging Code Quest reports, but guess it's reasonable to tag this as high priority.
Same happens in Text Editor and Console (note, you have to draw over main region, not over the header). This is caused by rB6e40b2de7ae81653f.
Another way to reproduce this is by using --debug-memory and joining any areas.
May 22 2018
This fixes the issue:
May 18 2018
For the records, this is pretty high on my priority list. I'm planning to look into it asap. Unfortunatly that may only be after the weekend though.
May 13 2018
Why would we move those settings into the top-bar? It's nice to have all tool-settings in a single place, however some of the mentioned settings are merely 3D View settings. And the ones that are shared across multiple editor types usually vary depending on the editor type. E.g.:
From discussions during the code quest, I thought the consensus was to keep them in the editors they belong to, but to properly make them per editor type (so that enabling snapping in the 3D View wouldn't also enable it in the Node Editor for example).
May 12 2018
May 8 2018
I actually agree on what @Linus Wiklander (wiklander) said, I'd also prefer keeping the Render Size Percentage at 50% to force people into discovering it ;)
May 7 2018
May 6 2018
May 2 2018
Hmm, I'd say screen-verts must never have a negative coordinate, if so there's probably a bug. So the assert seems to be right. Would still have to check details though.
Apr 30 2018
Thanks a lot! I did work on a patch taking the same direction as yours, just didn't get around to finish it. Glad it's fixed now!
Apr 26 2018
Apr 24 2018
Huuuuge thumbs up for the general proposal! I've been very worried about the complexity of the new layer/collection system; this addresses my concerns just fine and is in fact quite similar to what I had in mind.
No more linking, instead you define you're hierarchy once and define a sub-set of it for each layer -- so much yes!
Apr 23 2018
Apr 22 2018
Also, RegionEmbossSide is unused now and should be removed.
This is removing region emboss, but in the commit message you speak about area emboss. So either you removed the wrong emboss or used the wrong term :) What was your intention?
Hey and happy lekker Sunday! ;)
Apr 21 2018
I think this depends a bit on how we want to handle scrolling in the top-bar. If we don't want any scrolling and instead do things like moving tabs into a '...' menu if there are to many to display, the second solution sounds better. If we want to make sections scrollable option one should be the way to go.