On Fri, May 31, 2013 at 10:03 AM, <[hidden email]> wrote: Frank Shearar uploaded a new version of SUnitGUI to project The Trunk: One of the issues I ran into with shrinking goes back to this commit, which makes no sense to me. Frank, can you remember the reasons for this?
Colin |
On 9 January 2014 00:26, Colin Putney <[hidden email]> wrote:
> > > > On Fri, May 31, 2013 at 10:03 AM, <[hidden email]> wrote: >> >> Frank Shearar uploaded a new version of SUnitGUI to project The Trunk: >> http://source.squeak.org/trunk/SUnitGUI-fbs.57.mcz >> >> ==================== Summary ==================== >> >> Name: SUnitGUI-fbs.57 >> Author: fbs >> Time: 31 May 2013, 4:03:07.92 pm >> UUID: b836135e-01ed-4f6e-b671-36c56a5fa89a >> Ancestors: SUnitGUI-eem.56 >> >> Move ToolBuilder-SUnit to SUnitGUI-ToolBuilder. > > > > One of the issues I ran into with shrinking goes back to this commit, which > makes no sense to me. Frank, can you remember the reasons for this? 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. frank > Colin |
On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]> wrote:
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.
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.
Colin |
On 9 January 2014 13:34, Colin Putney <[hidden email]> wrote:
> > > > On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]> > 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. > Colin |
On 9 January 2014 14:27, Frank Shearar <[hidden email]> wrote:
> On 9 January 2014 13:34, Colin Putney <[hidden email]> wrote: >> >> >> >> On Thu, Jan 9, 2014 at 3:47 AM, Frank Shearar <[hidden email]> >> 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 |
On Thu, Jan 9, 2014 at 11:13 AM, Frank Shearar <[hidden email]> wrote:
Undoing these changes, I think I realise why I did it. Morphic depends Ah, that makes sense. So we need to figure out how to break that connection. Perhaps we'd get rid of all the Plus morphs and fold that functionality into either Morphic (PluggableFooMorph) or ToolBuilder (extensions to PluggableFooMorph) depending on whether its generally useful.
Colin |
In reply to this post by Frank Shearar-3
I would say ToolBuilder-Morphic should depend on Morphic, not the other way around. So why not putting PluggableSystemWindowWithLabelButton in ToolBuilder-Morphic?2014/1/9 Frank Shearar <[hidden email]>
|
+1 Cheers, Karl On Thu, Jan 9, 2014 at 6:17 PM, Nicolas Cellier <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |