On 5 June 2013 15:45, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-06-04, at 22:57, Frank Shearar frank.shearar@gmail.com wrote:
On 20 May 2013 19:47, Frank Shearar frank.shearar@gmail.com wrote:
On 20 May 2013 19:42, commits@source.squeak.org wrote:
A new version of MorphicExtras was added to project The Inbox: http://source.squeak.org/inbox/MorphicExtras-fbs.108.mcz
==================== Summary ====================
Name: MorphicExtras-fbs.108 Author: fbs Time: 20 May 2013, 7:42:41.076 pm UUID: ff1de6e0-6c3a-4322-9c1a-ce0bed2406df Ancestors: MorphicExtras-fbs.107
A ScrapBook uses a BookMorph to store Morphs. It replaces Utilities' scrapsBook.
=============== Diff against MorphicExtras-fbs.107 ===============
You need to load the System-side changes (in the System-fbs.532 in the Inbox) before this one, or Bad Things Might Happen.
While this mainly works, under some conditions (I think clicking on the can itself?) you get a debugger because the ScrapBook isn't a morph; it just _has_ a morph. Implementing the missing method means hitting MNU after MNU as you implement many many Morph messages. Eventually you have to implement #privateOwner and then Bad Things Happen.
I really don't want to reimplement Morph's protocol in the ScrapBook, but I'm also really not a fan of proxying via #doesNotUnderstand: (because those kinds of proxies obscure the proxied object's API).
I'd love to hear some feedback on this work so I can close it off. It removes a class var from Utilities, and so makes Utilities that bit more pull-apart-able. (Eventually I'd like to see Utilities banished to the wilderness, but it's a long journey to that point.)
frank
Sounds like maybe it should be a morph, after all?
Yeah, I guess. That's what the image is telling me. I suppose in the grander scheme of things it doesn't matter too much, given that this is intrinsically a Morphic thing. Other UIs would have their own mechanism.
frank
- Bert -