Nothing is broken here. All the float images are saving in scene linear
space by intention. Adding a way to save in different color space is in
TODO list.
On Mon, Jul 8, 2013 at 7:38 AM, Troy Sobotka wrote:
> Is there a reason that the color management transforms do not work on EXR
> files save
This layout I like if the dividers were a little Dimmer as they are now it
makes the menu too busy visually
On 8 Jul 2013 14:17, "Harley Acheson" wrote:
> Short of a big overhall, there are also simple things we can do.
>
> The following shows the current menu on the left. On the right there
> ha
Short of a big overhall, there are also simple things we can do.
The following shows the current menu on the left. On the right there
has been some margin added to the left of the icons so they are not
scrunched against the left. The separators are made a lot less invisible,
and are not extended t
Imho, "alphabetical" means not quite ideal for i18n UI display.
In fact, the current list already got well-classified if looking closely a
bit. However, if there really needs to be any goal for quick look-ups, I
think a better solution would probably be trying to "stress" the role of
icons, since
Is there a reason that the color management transforms do not work on EXR
files saves?
Seems broken.
With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
On Sun, Jul 7, 2013 at 3:53 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:
> One reason is that you can't do forward declarations of enums in
> header files [in ISO C] like you can do with structs.
I see my confusion. gcc has a non-standard extension to support forward
declarations o
One reason is that you can't do forward declarations of enums in
header files like you can do with structs. That means you have to
include header files in header files, which is generally avoided
whenever possible.
I don't think there's a good reason #defines are used instead of enums
to define th
I have uploaded the ALTERNATE patch ...
I *strongly* urge people to try both patches. Using it makes the difference
more apparent than thinking/talking about it. Set a handle-pair to "align",
then choose one handle to "free" and see the behavior difference
(summarized below).
BOTH patches fix iss
Is there any particular reason (besides legacy) that many parts of the code
still use int/#define, instead of using enums?
Even though C-compilers don't typecheck enums, there is a documentation /
readability benefit to using enums. Using enum-forward declaration avoids
any header nastiness.
For
I have been messing with "TorqueTrackTo" and "ApplyForceToTarget"
instead could I have a "rigid body IK solver" with max torques on all bones
and input "target angle" or "tracking object"
___
Bf-committers mailing list
Bf-committers@blender.org
http://li
FYI - After much deliberation about feedback on BA, I've decided to take a
different route than I did with Patch [#36029]. I am going to create a NEW
version of this spline-fix-patch which fixes the tooltips, bugs, and adds
"rotation constraint" visuals -- while leaving the current behavior
untouch
I still think this has nothing to do with the list being too large.
The order of the items on the list changes depending on whether
it pops up or down, so we can't just remember them visually by
location. And the order is non-visual so we have to do a linear
scan instead of a binary one. We have
Hi all,
Here's the notes from today's meeting in irc.freenode.net #blendercoders.
It's summertime, or everyone is busy, so it was a short meeting!
1) Blender 2.68 release status
- Meeting agrees to extend BCon4 period (bug fix only) 1 more week.
- The tracker still has too many open reports (1
It's just simpler code in makesrna.c to put them in each file. I don't
mind having them in a separate header, could be committed after the
release.
On Sun, Jul 7, 2013 at 9:37 AM, David Jeske wrote:
> When doing grep/searches tracing things from python-to-C, I sometimes have
> a lucky keyword tha
I realize that i use only a certain part of blender.
So what about trying to solve the problem of
"too big menus" generically via customization?
I know this is nothing that can be done on a weekend.
But i also believe that thinking about solutions should
not be ruled by "can be done quickly" argum
I find all new layouts proposed to be a big improvement over the current
long list that is, in my opinion, too long to scan efficiently when looking
for a window type. I'm always annoyed about myself taking 5 seconds to find
the right one in there.
These two here seem to be the best ones to me, th
I am not sure what to make of these new layouts yet, imho it's more
complicated to scan 3 columns with no description or misleading title,
than scanning through the list we have know.
So I am not convinced here yet. ;)
Am 07.07.2013 06:53, schrieb Gavin Howard:
> +1 to the last 3-column layout
When doing grep/searches tracing things from python-to-C, I sometimes have
a lucky keyword that matches something in the rna-gen "extern prototypes"
which are repeated in every rna__gen file. They look like this...
extern StructRNA RNA_BlendTexture;
Is there a reason these are generated into
18 matches
Mail list logo
