As many of you already know, we are hoping to push out a 1.0 release
this Spring. I would like to solicit feedback on our to do page for 1.0
. I would like you all to consider issues in this order of priority
for tasks that must be completed before a 1.0 release,
- Stabilize the API so that people can develop against the Avogadro
- Stabilize the ABI , i.e. no new virtuals, no new non-static data
- Big interface changes - will break documentation efforts.
- Staying as close to KDE library policy in our libs as possible .
There are a few things I need to work on. I was planning on renaming all
private headers to header_p.h to signify that they are private and
should not be exported/are not part of our API. Any classes that should
be exported should be included in the header list and their declaration
preceded by A_EXPORT, which ensures the right thing is done on various
I have been doing some work with a GLSL painter and will be making some
changes to the Painter (and derived) class. I will also be adding some
stub virtual functions intended for future use. Remember, only exported
classes/symbols that form part of our API/ABI need this attention. That
means that none of the plugins are affected, but the Plugin, Engine,
Tool, Color and Extension classes are for example. Also derived classes
where we extensively call the base class such as Primitive, Painter,
I would like to prioritize all work that needs to be completed before we
freeze our API/ABI. Large interface changes, such as the changes Geoff
has planned for the tools, will also need to be completed before 1.0. I
am most of the way through porting Kalzium to use the latest Avogadro
library, along with finishing off the Kompound application. These should
both exercise our API a little to ensure it copes well with being used
as a library. I will try to add Kompound to the playground KDE repo as
soon as I can so others can take a look at that too.
Any other thoughts as we push toward the release of 1.0? I think we are
in good shape, although there are a few things I would like to figure
out before committing to some parts of our API/ABI.