The Inbox: System-bf.997.mcz

> On 25 January 2018 at 19:48, tim Rowledge <[hidden email]> wrote:
>
> >
> > > On 25-01-2018, at 7:56 AM, [hidden email] wrote:
> > >
> > > Simplify project dispatch selector detection. No hard-coded list. Almost
> > as good.
> >
> > Maybe I missed something about why this slightly odd abstraction was
> > needed, but what is inadequate about simply having implementations of
> > #startUpWithCaption:icon:at:allowKeyboard: in each project related class?
> > How are these cases so different to the usages of UIManager et al. that we
> > need yet another mechanism?
>
>
> ???This is code from before we had Project subclasses.
>

> I spent some (too much) time looking at how to remove the need for the Project>dispatchTo:addPrefixAndSend:withArguments:  method that I find rather irritating.
>
> I was able to find ways to remove it, though in several cases this was by an only slightly less ugly double-dispatch - though at least it doesn???t work by sleight of hand. tl;dr - see the bottom of this email ya lazy scunner.
>
> Following is my notes during the work -
> ===============
> PopUpMenu>startUpLeftFlush
> I don???t see any way that the original scenario for having this exist could still exist. Not to mention that MorphicProject already has its own #jumpToProject, making the entire dance pointless.
> Making MVCProject>>#jumpToProject just directly use PopUpMenu>>#mvcStartUpLeftFlush is a simple and direct improvement.
>
>
> PopUpMenu>>#startUpWithCaption:icon:at:allowKeyboard:
> NB: This mixes in the entire strangeness of MVCMenuMorph, which is used oddly.
> Divert via Project current uiManager instead of #dispatch???
>
> This really demonstrates what a terrible mess we have for menus. A complete replacement would be nice.
>
> SyntaxError class>>#open:
> This probably ought to be dealt with via a suitable ToolBuilder assembling the correct bits.
>
>
> PluggableFileList open stuff
> We get two different versions depending upon whether we use a form of
> `PluggableFileList getFolderDialog openLabel: ???foo??? ` {which is explicitly used in MVCProject>>#findAFolderForProject:label:}
> or
> `PluggableFileList new open`
> PluggableFileList is only really used in
>  - MVCProject>>#findAFolderForProject:label: which is used as part of Project loading and saving. The MorphicProject version explicitly uses FileList2 instead, so no need for Project based dispatching. In an MVCProject the ToolBuilder version fails because of a fatal problem in #buildPluggablePanel: - the children stuff is known faulty and needs fixing before we can do more. The not-ToolBuilder version is not used here. We should change to a file dialogue instead anyway.
>  - Several StandardFileMenu methods when non-Morphic (which would break other kinds of project of course) so no need for project dispatching. As a temporary ???fix??? I made a dispatch via UIManager.
>
> MailComposition
> - doesn't actually need a dispatch via Project since it is a ToolBuilder UI. Fixed the #open method
>
> FancyMailComposition
> Not a ToolBuilder thing yet.
> Weirdly two versions of morphic UI; a relatively clean one (FancyMailComposition new open)  and a lurid purple one (FancyMailComposition new openInMorphic). Is the lurid one intended to go with the violent blue file list for EToys? There are no senders of openInMorphic in the alpha image.
> Is there any good reason to have two extremely similar classes in the system? Does one of these actually do anything especially useful?
>
> Debugger>>#resumeProcess: is only sent from within the Debugger and Debugger>>#morphicResumeProcess: & Debugger>>#mvcResumeProcess: look tantalisingly similar. Maybe someone with recent experience of debugger hacking might look to merge them cleanly.
>
> Debugger class>>#context:
> was easy enough to simplify
>
> ??? and removes need for different Debugger class>>#mvcOpenContext:label:contents: and Debugger class>>#morphicOpenContext:label:contents:
>
> Debugger class>>#openOn:context:label:contents:fullView:
> again, the two versions are really similar but not quite identical and could almost certainly be merged to allow removal of the project dispatch.
> ================
>
> Summary
>  - Some work on a couple of Debugger methods could clean up some important code and reduce the confusion always engendered by splitting similar paths.
>  - FancyMailComposition may be something to remove and replace with the plain MailComposition. And purple? Really?
>  - PluggableFileList (and superclasses). Eurgh. So much complication and confusion. Best to replace it with a clean new class and decide exactly what we want.
>  - SyntaxError; convert to ToolBuilder.
>  - PopUpMenu and friends; aaaaaaaaaaaaaarrrrrgh! So much hideousness in so many places doing so many nasty things so many times over.
>

>
>
> > On 30-01-2018, at 9:56 AM, tim Rowledge <[hidden email]> wrote:
> >
> > Exactly. If there???s no major fault found with the changes I???ll properly push them out in a few days.
>
>
> > On 01-02-2018, at 4:13 PM, [hidden email] wrote:
> >
> > tim Rowledge uploaded a new version of System to project The Trunk:
> > http://source.squeak.org/trunk/System-tpr.999.mcz
>
> A warning - this stuff messes with the debugger amongst other things and so might break stuff. It all works in my systems but y???never know for other people.
>