Re: Beginning to extend csVariantType

Hi Andrei,

> csArray
> -------
> I think it should simply represent a collapsable set of various other
> properties (like how a Vector/Color can be expanded to edit various
> components, only generic)

Maybe we can use additional interfaces to define specific structures of
iModifiable objects.

For example for a list, we would define an additional interface
iModifiableList like this:

struct iModifiableList : public virtual iBase
{
   size_t Push (iModifiable* modifiable);
   bool Insert (size_t index, iModifiable* modifiable);
   size_t GetCount () const;
   size_t GetIndex (iModifiable* modifiable) const;
   bool Delete (size_t index);
   bool Delete (iModifiable* modifiable);
}

And an object willing to be structured like a list would implement that
interface.

Similarily, we can define interfaces for a process:

struct iModifiableProcess : public virtual iBase
{
   iModifiable* GetInput ();
   iModifiable* GetOutput ();
}

And for a tree node:

struct iModifiableNode : public virtual iBase
{
   void SetParent (iModifiable* parent);
   iModifiable* GetParent ();

   void SetChild (size_t index, iModifiable* child);
   iModifiable* GetChild (size_t index);
   size_t GetChildrenCount () const;
   void RemoveChild (size_t index);
}

> iBase
> -----
> Maybe represent it as a drop-down menu of various other elements in the
> scene? (obviously populated based on its contraints, if any are present)

An iBase should be constrained by a iModifiableConstraintEnum that will
let you build a combo box holding all the possible values. A callback
mechanism should also be added to the iModifiableConstraintEnum in order
to be able to update the enum list.

If the iBase has no constraint, then you simply don't display it in the GUI.

> keyVal
> ------
> A key-value pair. Should these things be editable on their own, or only
> as part of a keyValList?

A iModifiable is already some sort of more generic key-value structure,
associating a csStringID to a csVariant. Therefore, we may not need an
additional variant type for iKeyValuePair.

And a key-value list can be represented either by a single iModifiable or
by a iModifiableList, therefore we may not need additional structures for
both KeyVal's and KeyValList's

> matrix3
> -------
> So we'll basically going to need an efficient way to edit 3x3 matrices.
> Could a simple text field where all 9 values get entered suffice? Maybe
> a two-level collapse section to expand into rows, then cells?

A matrix 3 can be represented eg by three rows with 3 text fields. But I
doubt that this can be really helpful for any 'normal' human being to try
to edit directly those values, therefore such a GUI tool wouldn't be that
helpful.

But if we consider that matrix3 will only be used for rotations, then we
can use another representation. Euler angles are probably the only ones
that can be really manageable by a human being, although they suffer from
several problems such as gimbal lock. Maybe use them and put the three
values for the Euler angles in three text fields on the same line, or
separated by a ';'. And internally, the Euler angles are converted into a
csMatrix3.

Mmm, actually, maybe we can remove the 'matrix3' type, and only use
quaternions.

> transform
> ---------
> see matrix3

You can represent it by two rows: one with the Euler angles, the other
with the offset. And internally, you convert it to a csTransform.

Or: we remove the 'transform' variant type, and we let the user having to
define two parameters for the rotation and the offset. Probably better.

In all cases, transforms and rotation matrices can be accompanied in the
editor by another GUI tool based eg on a mouse interaction (Jorrit has
already some code for that in AresEd). The user would therefore be able to
manipulate either directly the explicit values or through a mouse
interaction.

> After this, another problem seems to arise: After working with the graph
> nodes' properties and the GUI generation, what will the next step be,
> considering that csEditor is currently getting scrapped?

You don't need the cseditor to test the iModifiable. Your test application
should be self-contained, implementing by itself some instances of a
iModifiable that are interesting for the purpose of the test application.

I'm still working on the cseditor although I'm very busy with other things
these days. Hopefully I will have finished in a few days, by the same time
that you finished the iModifiable stuff.

And there are much probably still a lot of work that can be done on the
iModifiable before that: adding all types, adding lists, adding callback
mechanisms, adding translations, etc.

> The float slider gets reset when it loses focus (through the selection
> of another button). It also still gets rendered when the property panel
> it's in collapses. Should I attempt to study its code and fix these bugs?

Yes, there are several issues with the slider that I've never talked
about, sorry about that:
- The code has been taken from some other project which was GPL. You
should therefore rewrite the whole code and you don't unfortunately have
the right to cut & paste a single line from the original code (otherwise
we need to put your code in GPL too).
- There is the issue you mention with the focus. It is not clear how this
problem can be solved.
- Side note: the slider is not only for float's, it should manage int's too.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/