[Bf-taskforce25] data api proposal

[Campbell Barton]

hey Matt, your right about bitflags having to turn other bitflags off.
If its in the same struct member this is fairly easy. can have an
argument that will negate some flags before setting the new value.
would be needed for halo/billboard and 2d/3d nurbs for instance.

- If there not in the same member this is trickier, can you think of
any cases of this? - possibly need to parse some callback that un-sets
the other values, worst case the autogenerator has to have some way to
parse a string of C code to compile that does whatever we need. cant
be that pretty but hope it wont happen too much.

As for grouping and subtypes, could we just use some simple delimiter?
object groups could be "physics.softbody", "drawtype.color",
"raytrace.reflect".. etc then the UI can group, python docs too.

soft/hard limit thing I see more as a user interface issue, the api
will only constrain to hard limits but if we want some function that
returns soft limits for the UI that can be added later. (not first
implimentation). personally Im not interested in having user defined
per prop defaults or soft limits. at least until we have something
working, of if Matt wants to add this in later it could be ok.

On Tue, Sep 30, 2008 at 9:33 AM, Matt Ebb <matt at mke3.net> wrote:
> Hi, just a couple of notes on things I've seen, I hope I'm not looking
> at this on the wrong level
>
> On Tue, Sep 30, 2008 at 3:47 AM, Brecht Van Lommel <brecht at blender.org> wrote:
>
>> The default value, that is something I didn't include in the proposal
>> indeed. If we want a function to reset to the default we'll need it.
>> Would be good if we could avoid duplicating them from all the add_*
>> functions in blenkernel/, but should be possible I think.
>
> If this is the case, it would also be very nice to make possible the
> capability for users to be able to define their own default settings.
> It's something I've often wished for when doing the same sequence of
> clicks over and over again when I add an object, or set up a particle
> system, or whatever.
>
>> This is the intention, bitflags should be exposed as booleans. The
>> integer type would be used for just that, integer numbers.
>
> This may be a non-issue, but it just made me think, will there be any
> implications to changing these data types further down the track? For
> example I've seen in a few places in Blender where unfortunately a
> bitflag has been used, not really as a genuine true/false boolean
> value, but as a switch between two options. Then later down the line
> you realise that you want a third option as well, would this cause any
> concerns (other than just rewriting the functions that use it)?
>
>
> And on the topic of limits - I saw some mention on the issue of hard
> and soft limits. This is something that currently causes a bit of
> grief in Blender, there are hardcoded arbitrary limits everywhere. If
> I understand the proposal, this would be really great, to have a
> 'hard' limit that's the absolute maximum it can possibly me (for some
> things, that max stored by that datatype), and a soft limit that gets
> displayed in the UI. It would be great to have functions to be able to
> update that soft limit - i.e. in Shake, if you have a slider from 0.0
> - 1.0 and you type in 5.0, the slider then changes to show a range
> between 0.0 - 5.0.
>
>
> But yeah, so far so good! Sounds very interesting indeed, I need to
> get around to finishing up a doc I started writing ages ago, but
> that's on a higher level than the discussions now.
>
> cheers
>
> Matt
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>



-- 
- Campbell