Re: Beginning to extend csVariantType

> An object could implement iModifiableList, and it
> would be displayed as a collapsible list. But where?

The GUI generation tool is not fully automatic, and should be used by some
higher-level tool that knows the context of the edition and would use the
generated GUI as part of its edition task.

But here as you mention it, there are several problems with the idea of
the iModifiableList. This concept can actually be useful eg for a mesh
factory, where the user would want to visualize and manipulate the list of
instances of the mesh factory. But in this case, we are still lacking some
mechanism for the creation and the deletion of the objects of the list.

There are also other data structures already present within CS that can be
useful. For example, the iObject interface can also be used to structure
objects in hierarchies, and maybe it can be useful to create an automated
tool able to build some GUI from a tree of iObject.

So maybe let's keep it simple: the iModifiable would only be used for
single modifiable objects, and the structures of those objects would be
represented with other interfaces and GUI generation tools. So let's
concentrate on the iModifiable stuff now, and we'll see later for the
structures of several iModifiable's.

> Well we shouldn't throw out the directly editable parameters anyway.

For sure. It's always good to propose several different modalities to let
the user achieve what he wants, so that he can choose the one that he
finds the most adapted to his current working context.

> Okay, I'll just add a canvas-style panel where stuff will be able to get
> rendered (perhaps I can still look at some of the editor code for
> inspiration).

A priori, you shouldn't need to render any 3D thing for your first test
application. It should probably look similar to the current 'varedittest'
application, with one panel with the GUI generated for the current active
iModifiable, and another panel with eg some buttons allowing to switch
from one iModifiable to another in order to check that the data is
persisted correctly.

Once you will have finished with this, then the next step would probably
use some 3D rendering in order to visualize the things that are edited.
But this would then be using the cseditor framework that would manage the
rendering by itself.

> Alright, but before re-making it, isn't the wxWidgets built-in slider
> any good? (wxSlider) I think there might be a good reason for it, but I
> just can't seem to see it.

A first problem with that slider is that this is really only one big
missing feature of the wxPropertyGrid library (see eg the discussion at
http://sourceforge.net/projects/wxpropgrid/forums/forum/452255/topic/2825856),
and that the best solution for everybody would be that this slider stuff
would be added directly to it. So the idea of contributing in the end this
functionality to the wxPropertyGrid library can be considered.

About the wxSlider, the current implementation does actually use it
internally, and the rendering problems that are currently present are due
to a cached image of that slider that is used when the slider is not
activated, and with the GUI events that are not propagated correctly to
the wxSlider in this case.



------------------------------------------------------------------------------
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/