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:
- Start with trunk image Squeak6.1alpha-22743-64bit.zip
https://files.squeak.org/trunk/Squeak6.1alpha-22743-64bit/
- 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.squeakfo...
This is now a "trunk-without-etoys" image.
Look for senders of #wantsHalo. There are none.
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:
- 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: