[squeak-dev] The Trunk: SUnitGUI-fbs.57.mcz

karl ramberg karlramberg at gmail.com
Thu Jan 9 17:25:33 UTC 2014


+1

Cheers,
Karl


On Thu, Jan 9, 2014 at 6:17 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

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


More information about the Squeak-dev mailing list