Hi timothy,

what I could gleam from the Roassal codebase, my assumption is that their
design initially started out with an arbitrary graphics backend in mind
but, gradually, some lower-level aspects leaked into the domain-specific
high-level code. You can see that the codebase contains two or three
classes specifically with "Athens" in their name, which typically aim to
abstract and collect the interface needed by Roassal to produce graphics.
So, our goal would be to extend these abstractions to serve the use cases
where Athens-specific code currently exists in the Roassal domain layer.
Then, we can "simply" go in, provide a second interface that uses Balloon
as its backend and we're done! Since an incremental process is obviously
beneficial here and will yield the fastest sense of progress, starting out
by creating this Balloon interface and making it just about serviceable is
what we currently have in our repo. I believe Balloon as an engine should
be able to express just about all the requirements that Roassal puts on
Athens, even though I'm rather sure we'll have to employ some trickery for
e.g. text.

To make it more concrete: I think your approach of going test by test or
example by example should work well. Ideally, you would compare the output
of each example with what you find in Pharo and see where things are
currently entirely broken or missing. If you then encounter a test/example
that uses Athens-specific code, try to isolate the code in one of the
abstraction classes, such as the RSAthensMorph or RSAthensRenderer and try
to provide an equivalent implementation for our own RSBalloonMorph and
RSBalloonRenderer classes. Eventually, we can then simply not load the
RSAthensMorph and RSAthensRenderer were all Athens-specific code is
isolated and should thus no longer encounter code that cannot load in
Squeak.

Additionally, it may be worthwhile to keep a separate document in case we
encounter larger architectural issues where Roassal and Athens code are
intertwined, such that the Roassal team can review the document rather than
having to sift through a pull request of thousands of lines.

Best,
Tom

On Sun, Oct 25, 2020 at 3:12 PM gettimothy via Squeak-dev <
squeak-dev at lists.squeakfoundation.org> wrote:

> Hi Tom,
>
> After thinking on it, it makes sense to port all the pharo Athens calls to
> methods in "some appropriate class" in the Balloon or Graphics area and
> modifying the pharo call to those methods to use the Balloon/Graphics
> methods.
>
> AND
>
> when doing that, duplicate the Tests for those calls.
>
> All the while asking for pointers on specific instances.
>
>
> The approach gives me a needed structure, instead of doing "stupid stuff"
> like cloning in the GraphicsPaint class from Athen's directly into squeak,
> just to make things work.
>
> Sound like a plan?
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201025/166958da/attachment.html>