Hi Dave, Hi Marcel,

On 2023-12-17T10:08:27-05:00, lewis@mail.msen.com wrote:

> Hi Christoph,
>
> The idea is to compare the trunk image to the trunk-without-etoys image,
> where trunk-without-etoys is the result of running Marcel's script.
>
> Methods that exist only in the trunk image are assumed to be used only
> by Etoys, and are categorized under *Etoys.
>
> Methods that are identical in both images are assumed to belong in
> trunk, and are moved out of Etoys.
>
> Methods (and class definitions) that exist in both images but are
> different are set aside for future refactoring.

thanks for the context!

>
> For example, #wantsHalo may or may not be a method of general interest
> for trunk, but since it is never used in trunk-without-etoys, we assume
> that it is somehow related to Etoys usage and does not need to be in
> trunk.

No, #wantsHalo is indeed used in the Trunk-without-etoys. See Morph>>#handleMouseEnter:. :-)

>
> Certainly many of these category changes will turn out to be wrong, but
> it's a start.

So we could just move back the methods I mentioned in my previous message under point 1 to the Trunk? Who has classified them as "Etoys-only" - you or Marcel? I'm still trying to understand how this classification has been decided. :-)

>
> Dave
>
> On 2023-12-16T21:44:42+01:00,
> christoph.thiede(a)student.hpi.uni-potsdam.de wrote:
>
> > Hi Dave, hi Marcel, hi all,
> >
> > first, thank you a lot for working on this important refactoring!
> >
> > I have finally found some time to take a briefly look at these changes
> > (dtl's commits from 2023-11-25f.) and are confused by many of them.
> > Maybe you can help me understand the overall goal? :-) These changes
> > move many methods from other packages into the Trunk despite they are
> > still used in these other packages. I have made a non-exhaustive list
> > that fills about three workspaces, I will just briefly sketch two
> > categorizes:
> >
> > 1. Logic that IMHO belongs into a base package indeed: Morphic halo
> > invocation (#wantsHalo, #triggerHaloFor:after:,
> > #removePendingHaloFor:), Morphic halo's duplicate handles,
> > Morph>>#addMorphNearBack:, Morphic undo (MenuMorph>>#undoGrabCommand),
> > annotation setup (docking bar > extras), ProjectLauncher startUp (afaik
> > currently responsible for running changesets provided via command
> > line). I am unsure about uniclasses: Should they belong into the trunk?
> > I like to use a quick #newSubclass in different scripting/testing
> > situations.
> > 2. Logic that does belong to Etoys but is still intertwined with the
> > original package. If we unload the Etoys package today, this will lead
> > to DNUs in the trunk. Many of them might require better hooks (e.g.,
> > pragmas or registries) in the base packages. This is probably expected
> > at the current state of making Etoys optional, but I'm listing them
> > here for later reference anyway: Menu items in inspector/explorer (use
> > menu pragmas consistently, introduce pragmas for keyboard shortcuts),
> > CodeHolder>>#restoreTextualCodingPane, DeepCopier>>#mapUniClasses
> > (generic global fixup hook*),
> > NativeImageSegment>>#rootsIncludingPlayers, several preferences
> > (haloTransitions, captializedReferences, ...), ReleaseBuilder
> > ebautifyEtoys, ObjectlandMorph etoysProject
> > 2b. Logic that belongs to Etoys but abuses an unused internal hook of a
> > base package class:
> > MorphicModel>>#addModelYellowButtonMenuItemsTo:forMorph:hand:,
> > PasteUpMorph>>#drawOn: - this will conflict once we decide that these
> > classes want to use these hooks themselves, so they also would require
> > an explicit hook in the long term.
> >
> > Again, thank you a lot, and I am looking forward to talk about these
> > questions again, in particular about the first category. :-)
> >
> > Best,
> > Christoph

Best,
Christoph

---
Sent from Squeak Inbox Talk