g_object_data vs struct fields

[Jani Monoses]

> Different ways to achieve the same thing. If you need a lot of data one 
> struct to contain everything is more efficient than storing them 
> separately as object data.

good I'll use the struct as it is good old C and more legible and clear
than object_set, especially when you don't know what the latter does ;)

> I had something like that initially, but I removed it, since it doesn't 
> add any functionality that is not otherwise available. So, a plugin 
> writer can basically do whatever he prefers ;-)

It indeed doesn't add functionality but IMHO (after working on two 
plugins) makes the panel/plugin interface clearer and gives less rope
to plugin writers which is good. Because there will always be the 
question why can it be done in two slightly different ways and whether
one is more appropriate. Rigth now the API which is defined by the 
signals is 'loose' because you can seemingly pass any argument as a last 
param. This is good when done by glib but within an API layered over it 
it is confusing.
A recomandation - because this can not be enforced precisely because the 
signals permit it - would be to only use the plugin object in construct 
and pass to all the objects static signals just the private struct as 
the last param.

This way plugins code would be more consistent.

Maybe hearing opinions of other plugin porters too on this issue would 
be good? Besides you or Brian ;)

Jani