Yes, i actually want to do that.
I'm trying to understand the reason of such a plan? Is it because like that the clients of existing rendering do not have to be touched?
I plan to inject the new methods into a Morph
Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas
which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol.
I don't want to repeat a balloon canvas protocol.
what was wrong with it?
Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas.
And its important to make it a non-intrusive. So, the plan is:
- create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes.
- this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering.
This will ensure a backend agnostic nature of new morphic rendering code.
If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :)
Regards, Javier.
2010/5/23 Igor Stasenko <siguctua@gmail.com>
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project