Hi Dave,
thank you for this clarification! Now I can better understand your changes. I was just confused by the process in which these changes are integrated into the trunk, but I guess this is fine since it could mean that we are committing to making trunk-without-etoys reality before the next release. :-)
Best,
Christoph
---
Sent from Squeak Inbox Talk
On 2023-12-26T18:57:06+00:00, lewis@mail.msen.com wrote:
> Hi Christoph,
>
> When I said "trunk-without-etoys" I meant a trunk image after running
> Marcel's unload-etoys script. This is quite different from what you will
> see if you just remove the Etoys package from trunk.
>
> For the example of #wantsHalo, here are the steps to reproduce:
>
> 1) Start with trunk image Squeak6.1alpha-22743-64bit.zip
>
> https://files.squeak.org/trunk/Squeak6.1alpha-22743-64bit/
>
> 2) In that image, run the unload-etoys.33.cs change set (attachment to
> Marcel's email of 29-Aug-2023):
>
> https://lists.squeakfoundation.org/archives/list/squeak-dev(a)lists.squeakfoundation.org/message/4IJG2QQVPTWRTJ2TUIPVTQDLJNQVVW4R/attachment/4/unload-etoys.33.cs
>
> This is now a "trunk-without-etoys" image.
>
> 3) Look for senders of #wantsHalo. There are none.
>
> 4) Look at Morph>>handleMouseEnter: to confirm that it no longer sends
> #wantsHalo. The method history shows that this is one of many
> refactorings that Marcel did to clean up the separation of Etoys.
>
> Dave
>
> On 2023-12-26 17:41, christoph.thiede(a)student.hpi.uni-potsdam.de wrote:
>
> > Hi Dave, Hi Marcel,
> >
> > On 2023-12-17T10:08:27-05:00, lewis(a)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 [1]_
>
>
> Links:
> ------
> [1] https://github.com/hpi-swa-lab/squeak-inbox-talk