<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 24, 2017 at 8:20 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Sat, Apr 22, 2017 at 3:49 AM, Chris Cunningham <span dir="ltr"><<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail-m_-6551855714365677876gmail-m_5815647768528482461gmail-h5"><div><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Apr 21, 2017 11:23 AM, "Bert Freudenberg" <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>> wrote:</span><span class="gmail-"><blockquote class="gmail-m_-6551855714365677876gmail-m_5815647768528482461gmail-m_1011197144872641419quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think we should leave this as is. The hooks need to stay in place if we still want to support external forms.<br></div><div><br></div><div>We might want to amend the comment in #hasNonStandardPalette with some mention of the new external graphics package.</div><font color="#888888"><div><br></div><div> - Bert -</div></font></div></div></div></blockquote></span></div></div></div><div dir="auto"><br></div></div></div><span class="gmail-"><div dir="auto">I became interested in this because a test failed, so I can stop when it is deemed right to do so. That said:</div><div dir="auto"><br></div><div dir="auto">The current methods calling the methods you mention will look very weird without the ExternalForm loaded. There are branches that make no sense with that package removed. I did 3+ years from now if someone needs to work on Form and especially those methods they might be tempted to just remove them and then we are much worse off. </div><div dir="auto"><br></div><div dir="auto">What I'm suggesting is to factor out ExternalForm versions of those methods into ExternalForm and ExternalScreen where they will make sense to someone looking over it in the future. In the process the methods in Form should also get simple and more understandable (although there is a lot of but twiddling left in them).  As a bonus I would leave a note in the Form comment about the existence of ExternalForm in case someone was looking for such a thing. </div></span></div></blockquote><div><br></div><div>Ah, I see what you mean. Basically the non-standard palette behavior would only be implemented in ExternalForm and ExternalScreen.</div><div><br></div><div>This makes sense, except that it would lead to lots of code duplication. The closest common ancestor of ExternalForm and ExternalScreen is Form, and I'm certain that's why Andreas put the code for dealing with non-standard palette code in Form. (I guess nowadays this could be solved with a NonStandardPaletteTrait that would be used by both ExternalForm and ExternalScreen, but I'm not sure this is preferable to just leaving it in Form).</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Yes this approach can also for over time - but at least ExternalForm will be consistent with itself.  And it might not for as fast asvleaving the mixed methods in there now. The only good way not to for is to put the classes back in, really.</div></div></blockquote><div><br></div></span></div></div></div></blockquote><div>Wow.  I was writing this on my phone over the weekend, and didn't check what the phone had done to what I tried to write.  The entire previous paragraph was about code rot:</div><div>     Yes this approach can also ROT over time - but at least ExternalForm will be consistent with itself.  And it might not ROT as fast as leaving the mixed methods in there now. The only good way not to ROT is to put the classes back in, really.</div><div>I wasn't talking about speed at all.  Took me awhile to decode what I had intended to write - so I'm not surprised you came away with the angle you did.  Basically, there is reason to be concerned about packages diverging to the point where it isn't as easy as pulling it back in - especially if no one uses the code.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div></div></span><div>It's not about speed, it's about being able to mix regular and external forms. But if you can refactor it so it still works and all the code is preserved, awesome!</div><div><br></div><div>One more thing: </div><div><br></div><div>It just occurred to me that the right place to put this is the Balloon3D repository:</div><div><a href="http://www.squeaksource.com/Balloon3D.html" target="_blank">http://www.squeaksource.com/<wbr>Balloon3D.html</a><br></div><div><br></div><div>I just added you as a developer. </div><div><br></div><div>I also noticed that there is already a Graphics-External package in there. I have not compared it to yours, but it might be interesting to check. </div><div><br></div><div>Again, thanks for doing this :)</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div><div>- Bert -</div> </div></font></span></div></div></div>
<br><br>
<br></blockquote></div><br></div></div>