Interface for "Text" objects (bge)

This patch creates an interface for ["Text"] properties in Font objects.

Interface:
http://www.pasteall.org/pic/show.php?id=23785

Simple test file:
http://www.pasteall.org/blend/10616

Code Explanation:
---------------
(1) it adds a toggle to add/remove a "Text" gameproperty.
 - internally this property is just another game property (so we can find it within the game.properties lookup).
 - the property itself has no 'value', the interface shows the content of ob.data.body instead (why? because gameproperties are per object, while the text is per data).

(2) at BGE converter time it sets the current value of the object.data.body to the ["Text"] property.

(3) if you change object.text (bge text property) it automatically convert ["Text"] to a CStringValue.
*** that means if the original property was a CIntegerValue, it will be converted to CStringValue forever ***

* the only to do I can think of is to add a warning at doversion time if user has ["Text"] property for a Font object *

[Moguri, 2012-01-03 09:30:34]

One of the main reasons for adding a dictionary interface to KX_GameObject (and
thus it's children) was to keep "user" properties separate than "api"
properties. This way the two don't cause conflicts. This patch introduces a
possible conflict. The underlying issue is that you want logic bricks to access
a KX_FontObject property. Is this how we want to solve the problem?

There is, however, a bit of a precedent for muddling with user properties
("text" for bitmap fonts and some life/timebomb property for addObject).

I'm not saying this patch is bad; this is just something to think about before
moving forward.

[z0r, 2012-01-03 10:37:59]

On 2012/01/03 09:30:34, Moguri wrote:
> One of the main reasons for adding a dictionary interface to KX_GameObject
(and
> thus it's children) was to keep "user" properties separate than "api"
> properties.

I remember this happening, and at the time I was glad - but since then, I have
gone to a lot of effort to get this feature back. Most of my current game and
middleware relies on the ability to subclass KX_GameObject and friends. By doing
so, I can add and remove attributes, and I do it a lot.

Still I find it useful to have the game properties separate: they are input
parameters, and things that I intend logic bricks to access. So on some levels I
think it makes sense for this to be accessible through a property. I'm still not
sure whether restricting this to a property called Text is the best way to go,
but none of the options have seemed perfect, and I am at least comfortable with
this one.

:)

btw, another example of magical user properties are unform inputs to shaders.

[dfelinto, 2012-01-03 19:53:28]

>The underlying issue is that you want logic bricks to access a KX_FontObject
property.
Yup.

>Is this how we want to solve the problem?
What is your suggestion?
I have a feeling that the problem arises from the combination of ob.text and
ob["Text'']. Getting rid of ob.text may solve that (originally I proposed to
have ["Text"] to ALL font objects, automatically, but then we (Campbell and I)
thought that it would be more clear to the user if it was something he could
create/delete (also code-wise this avoids a lot of problems)


This is a hard API design issue. But, as Alex said, this may be the least bad
option.