In Read Etexts I had to deal with backwards compatibility because I wanted to support text to speech for those that had speech-dispatcher installed without making it impossible to use the Activity until speech-dispatcher was a standard part of Sugar. I check for the existence of a python package by trying to import it and catching an exception when the import fails. Later Aleksey created a version of Read Etexts that supported both speech-dispatcher and his new espeak gstreamer plugin, which I merged into the mainline. He created two versions of the speech code and imported one or the other depending on what python package was available for import. You might be able to do something of the kind with these toolbars. Create a sort of compatibility version of the code that could be included with Activities, but which would only be used if the genuine article could not be imported. That would mean putting the new toolbar code in a different place from the current stuff. Activity authors would need to write code to import one or the other.
I think what Aleksey came up with is an elegant solution to the problem. I agree that as an Activity author I want my stuff to be used by the largest audience possible, and that means targeting .82 for the foreseeable future. James Simmons >> As an Activity author, this is what breaks my heart. 99.5% or more of >> our users will be unable to get the benefits of new Activity releases. >> That's real tough psychology, and very de-motivating for volunteer >> authors. > > Yeah, that's a hard one to get around. We've had these designs since > the first release of Sugar, but there just wasn't time or resources to > make it happen. On a positive note, these new designs were developed > based directly on feedback from kids and teachers, and address a > number of issues that they found frustrating or confusing. Based on > the enthusiastic responses to the designs among all of you as well, I > think we're onto something good. > > I wish I had some suggestions on how to avoid the backwards > compatibility problem, though... > > Eben > > > ------------------------------ > > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > > End of Sugar-devel Digest, Vol 9, Issue 72 > ****************************************** > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel