Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: cbexaminr on May 03, 2011, 04:59:42 am

Title: wxSmith control support architecture
Post by: cbexaminr on May 03, 2011, 04:59:42 am
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.
Title: Re: wxSmith control support architecture
Post by: MortenMacFly on May 03, 2011, 06:32:12 am
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...