The Inbox: Morphic-hjh.1453.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Morphic-hjh.1453.mcz

commits-2
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."
  !


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

Hannes Hirzel
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
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

K K Subbu
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

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

K K Subbu
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

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

K K 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

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

timrowledge


> 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



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-hjh.1453.mcz

David T. Lewis
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