A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-hjh.1453.mcz ==================== Summary ==================== Name: Morphic-hjh.1453 Author: hjh Time: 14 June 2018, 8:47:23.595445 am UUID: 709cc547-ea46-426f-86a7-e014af1a5f6b Ancestors: Morphic-cbc.1452 Moved Morph>>beTransparent to 'accessing' Added guard in MorphicProject>>updateLocaleDependents to check for the presence of Etoys Fix comment in Morph>>saveOnFile (SmartRefStream) This change makes 'New MorphicProject' work after unloading Etoys (Preference okToReinitializeFlaps not enabled ) =============== Diff against Morphic-cbc.1452 =============== Item was added: + ----- Method: Morph>>beTransparent (in category 'accessing') ----- + beTransparent + self color: Color transparent! Item was changed: ----- Method: Morph>>saveOnFile (in category 'fileIn/out') ----- saveOnFile + "Ask the user for a filename and save myself on a SmartRefStream file. Writes out the version and class structure. The file is fileIn-able. UniClasses will be filed out." - "Ask the user for a filename and save myself on a SmartReferenceStream file. Writes out the version and class structure. The file is fileIn-able. UniClasses will be filed out." | aFileName | aFileName := ('my {1}.morph' translated format: {self class name}) asFileName. "do better?" aFileName := UIManager default saveFilenameRequest: 'File name?' translated initialAnswer: aFileName. aFileName ifNil: [^ Beeper beep]. self allMorphsDo: [:m | m prepareToBeSaved]. self saveOnFileNamed: aFileName! Item was changed: ----- Method: MorphicProject>>updateLocaleDependents (in category 'language') ----- updateLocaleDependents "Set the project's natural language as indicated" + (self world respondsTo: #isTileScriptingElement) ifTrue: "Etoys present" [ ActiveWorld allTileScriptingElements do: [:viewerOrScriptor | + viewerOrScriptor localeChanged]]. - viewerOrScriptor localeChanged]. Flaps disableGlobalFlaps: false. (Preferences eToyFriendly or: [ (Smalltalk classNamed: 'SugarNavigatorBar') ifNotNil: [:c | c showSugarNavigator] ifNil: [false]]) ifTrue: [ Flaps addAndEnableEToyFlaps. ActiveWorld addGlobalFlaps] ifFalse: [Flaps enableGlobalFlaps]. (Project current isFlapIDEnabled: 'Navigator' translated) ifFalse: [Flaps enableDisableGlobalFlapWithID: 'Navigator' translated]. ScrapBook default emptyScrapBook. MenuIcons initializeTranslations. super updateLocaleDependents. "self setFlaps. self setPaletteFor: aLanguageSymbol." ! |
After unloading Etoys 'Projects' -> 'New project' -> 'New
MorphicProject' no longer works. Etoys implements #isTileScriptingElement. (see screen shot). After unloading only one sender it left - in method PasteUpMorph>>allTileScriptingElements. The fix proposed checks for the presence of #isTileScriptingElemen before calling allTileScriptingElements. Another solution could be to do the test _in_ method #allTileScriptingElements. Give back an empty collection (self respondsTo: #isTileScriptingElement) ifFalse: [^OrderedCollection new]. PasteUpMorph>> allTileScriptingElements "Answer a list of all the morphs that pertain to tile-scripting. A sledge-hammer" | all morphs | morphs := IdentitySet new: 400. (self respondsTo: #isTileScriptingElement) ifFalse: [^OrderedCollection new]. self allMorphsAndBookPagesInto: morphs. all := morphs select: [:s | s isTileScriptingElement]. " self closedViewerFlapTabs do: [:aTab | all addAll: aTab referent allTileScriptingElements]. " ^ all asOrderedCollection On Thu, 14 Jun 2018 06:47:32 0000, [hidden email] <[hidden email]> wrote: > A new version of Morphic was added to project The Inbox: > http://source.squeak.org/inbox/Morphic-hjh.1453.mcz > > ==================== Summary ==================== > > Name: Morphic-hjh.1453 > Author: hjh > Time: 14 June 2018, 8:47:23.595445 am > UUID: 709cc547-ea46-426f-86a7-e014af1a5f6b > Ancestors: Morphic-cbc.1452 > > Moved Morph>>beTransparent to 'accessing' > Added guard in MorphicProject>>updateLocaleDependents to check for the > presence of Etoys > Fix comment in Morph>>saveOnFile (SmartRefStream) > > This change makes 'New MorphicProject' work after unloading Etoys > (Preference okToReinitializeFlaps not enabled ) > > =============== Diff against Morphic-cbc.1452 =============== > > Item was added: > + ----- Method: Morph>>beTransparent (in category 'accessing') ----- > + beTransparent > + self color: Color transparent! > > Item was changed: > ----- Method: Morph>>saveOnFile (in category 'fileIn/out') ----- > saveOnFile > + "Ask the user for a filename and save myself on a SmartRefStream file. > Writes out the version and class structure. The file is fileIn-able. > UniClasses will be filed out." > - "Ask the user for a filename and save myself on a SmartReferenceStream > file. Writes out the version and class structure. The file is fileIn-able. > UniClasses will be filed out." > | aFileName | > aFileName := ('my {1}.morph' translated format: {self class name}) > asFileName. "do better?" > aFileName := UIManager default saveFilenameRequest: 'File name?' > translated > initialAnswer: aFileName. > aFileName ifNil: [^ Beeper beep]. > > self allMorphsDo: [:m | m prepareToBeSaved]. > > self saveOnFileNamed: aFileName! > > Item was changed: > ----- Method: MorphicProject>>updateLocaleDependents (in category > 'language') ----- > updateLocaleDependents > "Set the project's natural language as indicated" > > + (self world respondsTo: #isTileScriptingElement) ifTrue: "Etoys > present" [ > ActiveWorld allTileScriptingElements do: [:viewerOrScriptor | > + viewerOrScriptor localeChanged]]. > - viewerOrScriptor localeChanged]. > > Flaps disableGlobalFlaps: false. > (Preferences eToyFriendly or: [ > (Smalltalk classNamed: 'SugarNavigatorBar') ifNotNil: [:c | c > showSugarNavigator] ifNil: [false]]) > ifTrue: [ > Flaps addAndEnableEToyFlaps. > ActiveWorld addGlobalFlaps] > ifFalse: [Flaps enableGlobalFlaps]. > > (Project current isFlapIDEnabled: 'Navigator' translated) > ifFalse: [Flaps enableDisableGlobalFlapWithID: 'Navigator' translated]. > > ScrapBook default emptyScrapBook. > MenuIcons initializeTranslations. > > super updateLocaleDependents. > > "self setFlaps. > self setPaletteFor: aLanguageSymbol." > ! > > > Etoys_implements_isTileScriptingElement_Screenshot_2018-06-16.png (32K) Download Attachment Senders_of_isTileScriptingElement_Screenshot_2018-06-16.png (64K) Download Attachment |
On Saturday 16 June 2018 10:27 AM, H. Hirzel wrote:
> After unloading Etoys 'Projects' -> 'New project' -> 'New > MorphicProject' no longer works. > > Etoys implements #isTileScriptingElement. (see screen shot). After > unloading only one sender it left - in method > PasteUpMorph>>allTileScriptingElements and in Morph>>isTileScriptingElement. Both seem to be results of monkey-patching (understandable in research experiments). Wouldn't a better idea be to subclass EtoysMorph (Morph) and EtoysWorld (PasteUp) and move such methods into them? Like in EtoysPresenter? This will require a one-time effort in changing base Etoys class defs and methods. But this one-time change will payoff in terms of cleaner separation between Morphic and Etoys. Would this be too risky a change for 5.2 release? Regards .. Subbu |
On Sat, Jun 16, 2018 at 07:55:32PM +0530, K K Subbu wrote:
> On Saturday 16 June 2018 10:27 AM, H. Hirzel wrote: > >After unloading Etoys 'Projects' -> 'New project' -> 'New > >MorphicProject' no longer works. > > > >Etoys implements #isTileScriptingElement. (see screen shot). After > >unloading only one sender it left - in method > >PasteUpMorph>>allTileScriptingElements > > and in Morph>>isTileScriptingElement. Both seem to be results of > monkey-patching (understandable in research experiments). > > Wouldn't a better idea be to subclass EtoysMorph (Morph) and EtoysWorld > (PasteUp) and move such methods into them? Like in EtoysPresenter? > > This will require a one-time effort in changing base Etoys class defs > and methods. But this one-time change will payoff in terms of cleaner > separation between Morphic and Etoys. > > Would this be too risky a change for 5.2 release? Changing class names is likely to cause issues for project loading. It would be a good idea to put the proposed change into the inbox, but it would probably be best not to merge it until after the 5.2 release. Meanwhile, the proposal of Hannes seems to be an improvement over the current state, should that go to trunk? Dave |
In reply to this post by Hannes Hirzel
On Saturday 16 June 2018 10:27 AM, H. Hirzel wrote:
> Another solution could be to do the test_in_ method #allTileScriptingElements. > > > Give back an empty collection > > (self respondsTo: #isTileScriptingElement) ifFalse: [^OrderedCollection new]. > > PasteUpMorph>> > allTileScriptingElements > "Answer a list of all the morphs that pertain to tile-scripting. A > sledge-hammer" > > | all morphs | > morphs := IdentitySet new: 400. > (self respondsTo: #isTileScriptingElement) ifFalse: [^OrderedCollection new]. > self allMorphsAndBookPagesInto: morphs. Should the respondsTo check occur before initializing morphs? Why init morph if the check leads to a return? Regards .. Subbu |
In reply to this post by David T. Lewis
On Saturday 16 June 2018 09:08 PM, David T. Lewis wrote:
> Changing class names is likely to cause issues for project loading. It > would be a good idea to put the proposed change into the inbox, but it > would probably be best not to merge it until after the 5.2 release. I understand. Thanks for the quick sanity check. > Meanwhile, the proposal of Hannes seems to be an improvement over the > current state, should that go to trunk? I see no harm in putting it in. It fixes MorphicProject from breaking after unloading Etoys for now. Regards .. Subbu |
> On 16-06-2018, at 10:26 AM, K K Subbu <[hidden email]> wrote: > > On Saturday 16 June 2018 09:08 PM, David T. Lewis wrote: >> Changing class names is likely to cause issues for project loading. It >> would be a good idea to put the proposed change into the inbox, but it >> would probably be best not to merge it until after the 5.2 release. > > I understand. Thanks for the quick sanity check. It's so long since I did anything with project loading stuff that it may no longer be even close to correct - but aren't there fixup methods that can handle class shape changes ad so on? Do they not include handling class name changes? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Propaganda: a good look |
On Sat, Jun 16, 2018 at 10:39:35AM -0700, tim Rowledge wrote:
> > > > On 16-06-2018, at 10:26 AM, K K Subbu <[hidden email]> wrote: > > > > On Saturday 16 June 2018 09:08 PM, David T. Lewis wrote: > >> Changing class names is likely to cause issues for project loading. It > >> would be a good idea to put the proposed change into the inbox, but it > >> would probably be best not to merge it until after the 5.2 release. > > > > I understand. Thanks for the quick sanity check. > > It's so long since I did anything with project loading stuff that it may no longer be even close to correct - but aren't there fixup methods that can handle class shape changes ad so on? Do they not include handling class name changes? > Yes, that's right. Dave |
Free forum by Nabble | Edit this page |