<div dir="ltr"><div><div><div>I would say ToolBuilder-Morphic should depend on Morphic, not the other way around.<br></div>So why not putting PluggableSystemWindowWithLabelButton in ToolBuilder-Morphic?<br></div>Isn't it a pluggable extension for Morphic that should be used only thru ToolBuilder?<br>
</div>Otherwise, we can consider that as a bad usage of inheritance, or a case of Traits...<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/9 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 9 January 2014 14:27, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
> On 9 January 2014 13:34, Colin Putney <<a href="mailto:colin@wiresong.com">colin@wiresong.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>><br>
>>><br>
>>> It does for SUnit what older commits did for MVC and Morphic: moves<br>
>>> the UI-framework-specific code to that particular UI framework, so<br>
>>> that the core of ToolBuilder remains UI agnostic.<br>
>>><br>
>>> The problem with shrinking that you refer to is, presumable, that<br>
>>> SUnitToolBuilderTests superclass == AnObsoleteToolBuilderTests? I'd<br>
>>> noticed that, and asked on the list how I might fix that. If you can<br>
>>> suggest an action I can take to remedy the problem, I'm all ears.<br>
>><br>
>><br>
>> No, the problem with shrinking is that I want to remove SUnitToolBuilder<br>
>> without removing TestRunner.<br>
>><br>
>> TestRunner provides a GUI for running tests. SUnitToolBuilder provides<br>
>> infrastructure for testing a GUI. They *sound* similar, but really they're<br>
>> completely different, and should be in separate packages.<br>
><br>
> Yes, they are different.<br>
><br>
>> On the other hand, the ToolBuilder packages were already separate from each<br>
>> other. Admittedly, if you don't have MVC in the image, you probably don't<br>
>> want ToolBuilder-MVC either, but that's not a reason to tie them together;<br>
>> it's reasonable to want MVC only and not use ToolBuilder at all. It seems<br>
>> that these changes have introduced coupling to what was already a nicely<br>
>> modularized group of packages.<br>
>><br>
>> I'm sorry I didn't notice this when you first brought it up—I was busy with<br>
>> dirty-world stuff in May and not paying much attention to the Internet. I<br>
>> think the right thing to do is just revert these changes.<br>
><br>
> I suspect that the bug might stem from me looking at system<br>
> categories, not at packages. ToolBuilder is one of the packages (only<br>
> it and HelpSystem, in fact) that do the Right Thing sub-package-wise.<br>
><br>
> You're right. I'll revert the changes.<br>
<br>
</div></div>Undoing these changes, I think I realise why I did it. Morphic depends<br>
on ToolBuilder-Morphic, and I tried to break that dependency by<br>
folding TB-M into Morphic. Once that was done, what's good for one<br>
framework should be good for the others. Only of course while Morphic<br>
shouldn't depend on TB-M, folding TB-M into Morphic means that Morphic<br>
still depends on TB, which it shouldn't. (Because using TB was<br>
supposed to be optional. It's TOOLBuilder, not GenericUIBuilder.<br>
<br>
So Morphic still depends on ToolBuilder-Morphic, because<br>
PluggableSystemWindowWithLabelButton subclasses PluggableSystemWindow,<br>
and because UserDialogBoxMorph uses PluggableButtonMorphPlus.<br>
<br>
frank<br>
<br>
>> Colin<br>
<br>
</blockquote></div><br></div>