On Apr 21, 2017 11:23 AM, "Bert Freudenberg" bert@freudenbergs.de wrote:
On Thu, Apr 20, 2017 at 11:29 PM, Chris Cunningham cunningham.cb@gmail.com wrote:
On Thu, Apr 20, 2017 at 9:32 AM, Bert Freudenberg bert@freudenbergs.de wrote:
<snip/>
Yeah, isn't it fun to untangle a monolithic system? ;)
Not bad if you don't try and change things...
<snip/>
Anything else lying around?
There is also the stuff with hasNonStandardPalette and convertARGB etc which is only used if there are external forms, but that seems a bit harder to remove because the hooks need to be there. I think it's fine to leave that as it is, unless you notice something that's easily removable.
There is a new version in the inbox with those 4 method moved.
The rest are doable. THe right way to do them, I think, is to remove most of these methods completely from Form. Then, adjust the methods that call them (in Form) to do the standard form code; and have override varients in ExternalForm (and/or ExternalScreen) that does the very specific alternates
- or delegates to Form if it should. Those dependant methods seem to have
a lot of assumptions about what the other variants might be.
I might get to this next week at some point, but I won't promise anything.
I think we should leave this as is. The hooks need to stay in place if we still want to support external forms.
We might want to amend the comment in #hasNonStandardPalette with some mention of the new external graphics package.
- Bert -
I became interested in this because a test failed, so I can stop when it is deemed right to do so. That said:
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.
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.
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.
Thanks, cbc