On 23 May 2013 07:46, Balázs Kósi rebmekop@gmail.com wrote:
Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
Eek! ToolBuilder should be (*) the only package to use Morphs. Is there any value in keeping MCTool's build-if-ToolBuilder-or-roll-own-if-not?
Two ways of building UIs means they _will_ diverge. ToolBuilder's the correct way to build a UI, so the fallback position can only rot.
frank
(*) for standard tools especially!
I think this is because, back in 2004 when Avi made Monticello, we did not have the trunk process we have now, and it was easier to diverge than to try to integrate.
I know of no reason we still need MCTool. But if we do get rid of it, let's throw that modal junk out the window too!
On Thu, May 23, 2013 at 12:40 PM, Frank Shearar frank.shearar@gmail.comwrote:
On 23 May 2013 07:46, Balázs Kósi rebmekop@gmail.com wrote:
Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
Eek! ToolBuilder should be (*) the only package to use Morphs. Is there any value in keeping MCTool's build-if-ToolBuilder-or-roll-own-if-not?
Two ways of building UIs means they _will_ diverge. ToolBuilder's the correct way to build a UI, so the fallback position can only rot.
frank
(*) for standard tools especially!
On Thu, May 23, 2013 at 1:26 PM, Chris Muller asqueaker@gmail.com wrote:
I think this is because, back in 2004 when Avi made Monticello, we did not have the trunk process we have now, and it was easier to diverge than to try to integrate.
It's because, back in 2004, we didn't have ToolBuilder. The code to use ToolBuilder if it's available came much later.
I know of no reason we still need MCTool. But if we do get rid of it, let's throw that modal junk out the window too!
Yeah. I wonder what Pharo does, now that they're using Polymorph.
Colin
On 23 May 2013 21:26, Chris Muller asqueaker@gmail.com wrote:
I think this is because, back in 2004 when Avi made Monticello, we did not have the trunk process we have now, and it was easier to diverge than to try to integrate.
I know of no reason we still need MCTool. But if we do get rid of it, let's throw that modal junk out the window too!
Well, after I ripped out the Morphic stuff (inbox, Monticello-fbs.545, please comment!) MCTool still looks useful, as a place where default values live. In other words, it kind've plays the role of a mini theme.
I think I can see a few more things that could go, like #perform:orSendTo:.
frank
On Thu, May 23, 2013 at 12:40 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 23 May 2013 07:46, Balázs Kósi rebmekop@gmail.com wrote:
Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
Eek! ToolBuilder should be (*) the only package to use Morphs. Is there any value in keeping MCTool's build-if-ToolBuilder-or-roll-own-if-not?
Two ways of building UIs means they _will_ diverge. ToolBuilder's the correct way to build a UI, so the fallback position can only rot.
frank
(*) for standard tools especially!
squeak-dev@lists.squeakfoundation.org