On 15 May 2013 10:05, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 14 May 2013 16:03, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>> On 2013-05-14, at 12:13, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>>> On 13 May 2013 22:09,  <commits at source.squeak.org> wrote:
>>>> Frank Shearar uploaded a new version of System to project The Trunk:
>>>> http://source.squeak.org/trunk/System-fbs.529.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: System-fbs.529
>>>> Author: fbs
>>>> Time: 13 May 2013, 10:09:14.405 pm
>>>> UUID: 2ba98257-9342-4eee-a927-a0c3d6deaf41
>>>> Ancestors: System-fbs.528
>>>>
>>>> Another tiny step in breaking the System -> MorphicExtras dependency. Locale class>>migrateSystem moves to MorphicExtras because, while it refers to other packages as well, MorphicExtras form the largest minority of package references.
>>>>
>>>> =============== Diff against System-fbs.528 ===============
>>>>
>>> <snip>
>>>> Item was removed:
>>>> - ----- Method: Utilities class>>scrapsBook (in category 'scraps') -----
>>>
>>> I realised this morning that this particular change is insufficient.
>>> There are a cluster of methods - the entire 'scraps' category - that
>>> ought to move to MorphicExtras [1]. That, too, is insufficient,
>>> because these methods all use the ScrapsBook class var. I propose to
>>> create a new class, ScrapsBook, in MorphicExtras, that implement
>>> versions of these methods. "Versions" because ScrapsBook will be a
>>> normal class holding an instvar named 'book'. ScrapsBook default will
>>> return a lazily instantiated canonical ScrapsBook, and the existing
>>> Utilities class methods in 'scraps' will simply delegate to this.
>>>
>>> That at least centralises the access to the ScrapsBook. I don't know
>>> how the ScrapsBook relates to the rest of the image, so I don't know
>>> how to fix the broader issue. In other words, System will still depend
>>> on MorphicExtras, but through an instance of a class, rather than
>>> through a class var.
>>>
>>> Thoughts? Particularly, how do I test that I haven't smashed anything
>>> before even bothering to submit something to the Inbox?
>>>
>>> frank
>>>
>>> [1] Because it uses a BookMorph. This, sadly, makes Morphic depend
>>> that little bit more on MorphicExtras. The solution to that would be
>>> moving BookMorph and friends to Morph, which seems undesirable.
>>
>> This is the Morphic trash can. Get it from the Object Catalog's "useful" category. Enable the preserveTrash preference, and the slideDismissalsToTrash pref too, for visual feedback.
>>
>> Now morphs that you delete via the pink halo handle get moved to the trash. Double-click the trash can to open the scraps book.
>
> Thanks!
>
> Apologies for the pun in the title; entirely intentional. The attached
> changeset shows how we can pull the ScrapsBook class var out of
> Utilities. It would require a second stage to remove the Utilities
> class >> #initialize.
>
> (I'm using a ChangeSet because I've already got two System-affecting
> submissions in the Inbox; I don't want to confuse myself any further.)
>
> One thing I haven't done yet is handling the double-clicking of the
> trash can. Currently there are a bunch of MNUs because the ScrapBook
> _uses_ a Morph, but isn't itself a Morph. Perhaps I should make it a
> Morph, even though I generally prefer has-a over is-a. If I continue
> with has-a Morph I can proxy methods directly. (I'm not a fan of
> #doesNotUnderstand: proxying; it hides the proxied protocol.)
>
> Thoughts?

(Take 2 on making a changeset that includes the minimal change, not
the entire Utilities class.

> frank
>
>> - Bert -
>>
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: move-trash-to-morphicextras.2.cs
Type: application/octet-stream
Size: 4750 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130515/1ce137fd/move-trash-to-morphicextras.2-0001.obj