<div dir="ltr"><div>Hi timothy,</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Best,</div><div>Tom<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 25, 2020 at 3:12 PM gettimothy via Squeak-dev <<a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:10pt"><div>Hi Tom,<br></div><div><br></div><div>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.<br></div><div><br></div><div>AND<br></div><div><br></div><div>when doing that, duplicate the Tests for those calls.<br></div><div><br></div><div>All the while asking for pointers on specific instances.<br></div><div><br></div><div><br></div><div>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.<br></div><div><br></div><div>Sound like a plan?<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br></div><br>
</blockquote></div>