- User Since
- Dec 12 2013, 11:11 PM (166 w, 5 d)
Mon, Feb 20
I don't think such changes should be done for 2.79 instead of 2.80. Especially stuff like changing shortcuts and design guidelines. From a user POV these may not be trivial.
Also, when changing guidelines we should make sure there's wide agreement and then do it once and for all (more or less). We must not change any guidelines, just to change them again after a few releases.
Thu, Feb 16
Mon, Feb 13
Can easily recreate this using steps mentioned by @Vuk Gardašević (lijenstina).
Sun, Feb 12
Indeed, there isn't a need to show the tool name in most cases, a short, general description would be enough, followed by a more detailed description. Kind of like we do currently already. E.g.
Also, I realize "tool name" is the wrong term, we're actually talking about the name of the entity a button represents (can be an operator, property or a enum-property value).
Well, this is not a solution. The opengl32.dll is made for testing purposes, it runs GPU computations on the CPU, bypassing the driver. You'll notice Blender runs extremely slow with it.
However, this does tell us that this is indeed a graphics driver issue. Nothing that can be fixed on Blender's side.
Sat, Feb 11
What are the plans with this considering the new layers/collections work? Is this patch still valid after all?
Fri, Feb 10
The patch seems to be created the wrong way around, the new code should be the one highlighted in green on the right-hand side. Other than that and a few commented things, I think this is ready to go. UI-wise I'm mostly fine with the changes.
From a quick glance, patch looks good, just the usual minor nitpickings :)
This is not really my area, so resigning my self from reviewers.
Looks almost good to me, just 2 minor remarks.
Also requesting changes since consensus is that current patch isn't really the way to go.
You can use RNA_def_property_flag(prop, PROP_CONTEXT_UPDATE); to get bContext passed to the property _update function. I think that would be okay as a solution for this corner case. Alternatively, we could place a button (icon only?) next to the Scripts text field to reload scripts manually. But indeed, an automatic approach would be preferable.
TBH I find the behavior of .active utterly confusing, I much prefer using .enabled. A button should either be disabled or enabled, not some state in-between.
Thu, Feb 9
Will have a look at that, but as a rather low-priority one (everything still works, just a visual issue).
Empty report, closing.
Wed, Feb 8
Tue, Feb 7
Mon, Feb 6
Sun, Feb 5
Fri, Feb 3
Actually, this only partially reverts rB1ad842d432cc, the commit title/description should make that clear. Also, in future please add some info on why you reverted it ;) I guess you're more used to working with SVN, so not sure if you're aware of it, but the Git history is a quite important tool for regular Blender development. Putting some effort into writing meaningful commit descriptions is definitely worth it an much appreciated!
Mon, Jan 30
Fri, Jan 27
None of these, I was just pointing out that the entry point to all Blender documentation currently is https://wiki.blender.org/, and in future with the new docs infrastructure it would be https://docs.blender.org/. Both sites can stay as they are now, just saying ;)
Thu, Jan 26
@Bastien Montagne (mont29), my point is simply that docs.blender.org/api/ is far too vague and may be misleading. We do have many APIs, it doesn't matter if they're internal/private or external. The thing is, one person clicking on docs.blender.org/api/ might expect to see an API documentation for C/C++ plugins, another one might expect to see the documentation of the internal APIs and another one might expect it to show the Python API documentation.
The URLs and sitemap structure should make it clear what kind of APIs and corresponding docs are available.
Tue, Jan 24
I'm absolutely against adding a PROP_VALUE_CLEAR RNA property flag if there's no 'real' need for it. Thing is we just split the flags apart so we get some free bits again eventually (rB440d104279811). We have to be quite strict to not end up with zero free bits within a short time again.
A more acceptable approach would be having this as option to UILayout.prop. Something like layout.prop(..., show_value_clear=True). It would be limited to text buttons for now, but that would be okay-ish.
However, even for that I'd like to see a use-case where it would make sense to have this. Cause I don't see a point in exposing options that aren't really needed. That's also why I didn't do it in the first place. I wanted to see if script authors would want to use it before adding it.
There's T50521 now for further design discussion. The points regarding workspace sharing and multi-window setups might influence how we'll be saving data to files. So if we want to avoid breaking files created with blender2.8, we should probably hold off with the merge until questions are answered and needed changes done.
The questions regarding workspace sharing and multi-window setups are the only ones that are a bit urgent, because they might have quite some influence on D2451. So I'd really appreciate feedback on those.
Jan 23 2017
In general it's useful to add some screenshots when proposing visual changes ;)
Sorry guyzz for letting you wait that long! (tm) Real live dared to take all my attention.
Jan 22 2017
- Fix compile error and warning in release builds
- Fix and compile time option for workspace object-mode
- Merge branch 'blender2.8' into workspaces
In general I'm a big fan of gathering all our services on more centralized places, making it easier to find and access them. So big +1 for the idea of bringing all the docs to a unified docs.blender.org domain.
This is caused by rBda026249abbe058.
Jan 21 2017
I guess someone who's familiar with the 2.8 changes should do a master->blender2.8 merge before merging this. Not only for this patch, but as a general practice now that blender2.8 and master started to differ quite a bit. Just to ensure merge conflicts in other areas are handled by people who are at least a bit familiar with them.
Jan 20 2017
Jan 17 2017
There is a difference between the revert commit (rB6ecab6dd8e48d56#b0cb2c8e) and the reverted one (rB5aa19be91263a24#b0cb2c8e) in anim_channels_defines.c, and there's also changes in rB4b99958ca12642.
So fixing this is probably just a matter of correctly undoing these changes so code matches master again.
Jan 16 2017
This task is mainly about why buttons in toolbars may align text differently than buttons anywhere else in Blender. I don't see why this should be the case. Also reported in T41592.