wxSmith control support architecture

[cbexaminr]

It appears that support of any new controls within wxSmith requires the addition of C(++) code to the wxSmith code base.

true/false?

Assuming this is true, has there been any analysis done regarding the plausibility of some level of support for "drop-in" addition of controls(*)?

If known analysis has been done, what conclusions were reached regarding this?

Is there documentation somewhere that describes the current wxSmith architecture and/or implementation?

(*)whereby controls might be largely "described" by configuration data in some selected format (possibly XML), and the addition of a control for use by wxSmith, and/or a c::b wxwidgets installation, would involve dropping such configuration and accompanying (shared library?) code implementation into a known location, or asking c::b to do so based on user selection of such an item from some location.

[MortenMacFly]

It appears that support of any new controls within wxSmith requires the addition of C(++) code to the wxSmith code base.

true/false?

false, if you look at the wxs branch there are a bunch of controls added to wxSmith that do not touch the core.

Is there documentation somewhere that describes the current wxSmith architecture and/or implementation?

You can create a doxygen documentation just out of the wxSmith plugin.

(*)whereby controls might be largely "described" by configuration data in some selected format (possibly XML), and the addition of a control for use by wxSmith, and/or a c::b wxwidgets installation, would involve dropping such configuration and accompanying (shared library?) code implementation into a known location, or asking c::b to do so based on user selection of such an item from some location.

Sounds OK, but would surely require a re-write of big parts of wxSmith. I am not sure if the current implementation which requires really not much code to add a new control (which in addition is not done too often) is really harder to do. That's just my guess...