The Inbox: Morphic-kfr.1540.mcz
Locked
 
|
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-kfr.1540.mcz ==================== Summary ==================== Name: Morphic-kfr.1540 Author: kfr Time: 23 September 2019, 9:52:14.252115 pm UUID: 19e57221-4088-0f49-9549-22e1270e933b Ancestors: Morphic-mt.1539 If a morph is flexed, it's owner must be deleted =============== Diff against Morphic-mt.1539 =============== Item was changed: ----- Method: Morph>>privateDelete (in category 'submorphs-add/remove') ----- privateDelete "Remove the receiver as a submorph of its owner" + self isFlexed ifTrue:[^owner delete]. owner ifNotNil:[owner removeMorph: self].! |
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
I'm not sure if this is the right way to delete a flexed morph. Somebody with a better understanding than me must check if this is the right way to do this. Here is a test that leaves a green TransformationMorph before this change: rect := RectangleMorph new openInWorld. rect heading: 45.0. rect delete. Best, Karl. On Mon, Sep 23, 2019 at 9:52 PM <[hidden email]> wrote: A new version of Morphic was added to project The Inbox: |
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
PS: I have made work around for this issue before in these places: FlapTab privateDeleteReferent MenuMorph delete SystemWindow delete Best, Karl On Mon, Sep 23, 2019 at 10:02 PM karl ramberg <[hidden email]> wrote:
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
-1 for adding such a side effect to Morph >> #privateDelete. Best, Marcel
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
Here is another suggestion: Morph>>delete "Remove the receiver as a submorph of its owner and make its new owner be nil." | oldWorld | self removeHalo. self isFlexed ifTrue:[self removeFlexShell]. (oldWorld := self world) ifNotNil: [ self disableSubmorphFocusForHand: self activeHand. self activeHand releaseKeyboardFocus: self; releaseMouseFocus: self]. owner ifNotNil: [ self privateDelete. "remove from world" self player ifNotNil: [:player | oldWorld ifNotNil: [ player noteDeletionOf: self fromWorld: oldWorld]]]. Best, Karl On Tue, Sep 24, 2019 at 9:21 AM Marcel Taeumel <[hidden email]> wrote:
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
-1 :-) If a flex shell (aka. transform morph) shouldn't lay around invisibly in a world, that world should take care of it ... or *maybe* the transform morph. Think about scroll panes. There, it is okay to have an invisible transform morph with no children (or submorphs). Best, Marcel
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
Ok, Then I don't know how to fix this. Best, Karl On Tue, Sep 24, 2019 at 9:52 AM Marcel Taeumel <[hidden email]> wrote:
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
In reply to this post by marcel.taeumel
I still don’t get this. How is a flexShell different than a halo or a player ? Best, Karl On Tue, 24 Sep 2019 at 09:52, Marcel Taeumel <[hidden email]> wrote:
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
Hi Karl. :-) > I still don’t get this. How is a flexShell different than a halo or a player? - A halo is kind of a (context) menu for morphs in general. - A flexShell is an instance of TransformationMorph. - A player is an etoys-specific thing to manage etoys scripts where costumes are the (maybe flexed) morphs. If you rotate a system window and close that, the flex shell disappears as expected because of SystemWindow >> #delete. In this example, it does not: rect := RectangleMorph new openInWorld. rect heading: 45.0. rect delete. Since ScrollPane uses TransformMorph and not TransformationMorph, we can safely implement #removedMorph: there and get rid of some #isFlexed or #isFlexMorph calls. ... we should rename "TransformationMorph" to "FlexShell" at some point ... Best, Marcel
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
... on second thought: Maybe it is not that easy: | rect flex | rect := RectangleMorph new openInWorld. rect heading: 45.0. flex := rect owner. rect delete flex add: Morph new. ... the flex should still be in the world, right? Best, Marcel
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
Even though I cannot solve this issue, I made some changes in Trunk to handle such empty transformation morphs more conveniently. Best, Marcel
|
|
|
In reply to this post by marcel.taeumel
Marcel,
Rotation is ambiguous: - as a geometric op on a morph and all its submorphs (heading), or - as a geometric op on a morph's form only (rotation) BorderedMorph new in: [ :panel | | button | panel openInWorld; heading: 45.0. button := EllipseMorph new. panel addMorph: button. ] should button also be rotated? Currently it does. But if I don't want button to be rotated but placed as is? Should we add methods #rotate: and #rotationInDegrees methods on a morph for disambiguation? Regards .. Subbu On 26/09/19 1:11 PM, Marcel Taeumel wrote: > ... on second thought: Maybe it is not that easy: > > | rect flex | > rect := RectangleMorph new openInWorld. > rect heading: 45.0. > flex := rect owner. > > rect delete > flex add: Morph new. > > ... the flex should still be in the world, right? > > Best, > Marcel >> >> Am 26.09.2019 09:35:23 schrieb Marcel Taeumel <[hidden email]>: >> >> Hi Karl. :-) >> >> > I still don’t get this. How is a flexShell different than a halo or a player? >> >> - A halo is kind of a (context) menu for morphs in general. >> - A flexShell is an instance of Transform*ation*Morph. >> - A player is an etoys-specific thing to manage etoys scripts where >> costumes are the (maybe flexed) morphs. >> >> If you rotate a system window and close that, the flex shell >> disappears as expected because of SystemWindow >> #delete. In this >> example, it does not: >> >> rect := RectangleMorph new openInWorld. >> rect heading: 45.0. >> rect delete. >> >> Since ScrollPane uses TransformMorph and not TransformationMorph, we >> can safely implement #removedMorph: there and get rid of some >> #isFlexed or #isFlexMorph calls. >> >> ... we should rename "Transform*ation*Morph" to "FlexShell" at some >> point ... >> >> Best, >> Marcel >>> >>> Am 26.09.2019 07:45:00 schrieb karl ramberg <[hidden email]>: >>> >>> I still don’t get this. How is a flexShell different than a halo or a >>> player ? >>> Best, >>> Karl >>> >>> On Tue, 24 Sep 2019 at 09:52, Marcel Taeumel <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> -1 :-) >>> >>> Well, #delete should just delete the morph from its owner. That >>> morph shouldn't care about other constraints *in* that owner. It >>> makes things just too complicated. >>> >>> If a flex shell (aka. transform morph) shouldn't lay around >>> invisibly in a world, that world should take care of it ... or >>> *maybe* the transform morph. >>> >>> Think about scroll panes. There, it is okay to have an invisible >>> transform morph with no children (or submorphs). >>> >>> Best, >>> Marcel >>>> >>>> Am 24.09.2019 09:42:25 schrieb karl ramberg >>>> <[hidden email] <mailto:[hidden email]>>: >>>> >>>> Here is another suggestion: >>>> >>>> Morph>>delete >>>> "Remove the receiver as a submorph of its owner and make its >>>> new owner be nil." >>>> | oldWorld | >>>> self removeHalo. >>>> self isFlexed ifTrue:[self removeFlexShell]. >>>> (oldWorld := self world) ifNotNil: [ >>>> self disableSubmorphFocusForHand: self activeHand. >>>> self activeHand >>>> releaseKeyboardFocus: self; >>>> releaseMouseFocus: self]. >>>> owner ifNotNil: [ >>>> self privateDelete. "remove from world" >>>> self player ifNotNil: [:player | >>>> oldWorld ifNotNil: [ >>>> player noteDeletionOf: self fromWorld: oldWorld]]]. >>>> >>>> Best, >>>> Karl >>>> >>>> On Tue, Sep 24, 2019 at 9:21 AM Marcel Taeumel >>>> <[hidden email] <mailto:[hidden email]>> wrote: >>>> >>>> -1 for adding such a side effect to Morph >> #privateDelete. >>>> >>>> What about adding TransformMorph >> #removedMorph: and >>>> checking for "self owner = self world"? >>>> >>>> Best, >>>> Marcel >>>>> >>>>> Am 23.09.2019 22:16:59 schrieb karl ramberg >>>>> <[hidden email] <mailto:[hidden email]>>: >>>>> >>>>> PS: I have made work around for this issue before in these >>>>> places: >>>>> >>>>> FlapTab privateDeleteReferent >>>>> MenuMorph delete >>>>> SystemWindow delete >>>>> >>>>> Best, >>>>> Karl >>>>> >>>>> On Mon, Sep 23, 2019 at 10:02 PM karl ramberg >>>>> <[hidden email] <mailto:[hidden email]>> wrote: >>>>> >>>>> I'm not sure if this is the right way to delete a >>>>> flexed morph. >>>>> Somebody with a better understanding than me must check >>>>> if this is the right way to do this. >>>>> Here is a test that leaves a green TransformationMorph >>>>> before this change: >>>>> http://source.squeak.org/inbox/Morphic-kfr.1540.mcz >>>>> >>>>> rect := RectangleMorph new openInWorld. >>>>> rect heading: 45.0. >>>>> rect delete. >>>>> >>>>> Best, >>>>> Karl. >>>>> >>>>> On Mon, Sep 23, 2019 at 9:52 PM >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> A new version of Morphic was added to project The >>>>> Inbox: >>>>> http://source.squeak.org/inbox/Morphic-kfr.1540.mcz >>>>> >>>>> ==================== Summary ==================== >>>>> >>>>> Name: Morphic-kfr.1540 >>>>> Author: kfr >>>>> Time: 23 September 2019, 9:52:14.252115 pm >>>>> UUID: 19e57221-4088-0f49-9549-22e1270e933b >>>>> Ancestors: Morphic-mt.1539 >>>>> >>>>> If a morph is flexed, it's owner must be deleted >>>>> >>>>> =============== Diff against Morphic-mt.1539 >>>>> =============== >>>>> >>>>> Item was changed: >>>>> ----- Method: Morph>>privateDelete (in category >>>>> 'submorphs-add/remove') ----- >>>>> privateDelete >>>>> "Remove the receiver as a submorph of its >>>>> owner" >>>>> + self isFlexed ifTrue:[^owner delete]. >>>>> owner ifNotNil:[owner removeMorph: self].! >>>>> >>>>> >>>> >>> > > |
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
Hi Subbu, transformations usually add up. So, yes, the submorph should be rotated, too. Let's not make the situation in Morphic more confusing by somehow "resetting" the transformation of added submorphs. It would be either tricky to compute or awkwardly to hack into the canvas-drawing and event-handling code. In Morph, #heading: and #rotationDegrees: are interchangeable concepts. Both are currently in the Etoys protocol anyway. > But if I don't want button to be rotated but placed as is? Label placement and resizing in such transformed views is tricky. Think of a rotated street map with straight labels... the application developer can figure this out. :-) For now. I guess. Best, Marcel
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
In reply to this post by marcel.taeumel
On Thu, Sep 26, 2019 at 9:35 AM Marcel Taeumel <[hidden email]> wrote:
Because I fixed it ;-).
Probably the whole flexing stuff is something for someone daring a deep refactoring of morphic. As far as I remember it was added as a work around, therefor we get this weird adding "private" owner. Best, Karl
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
In reply to this post by marcel.taeumel
On Thu, Sep 26, 2019 at 9:41 AM Marcel Taeumel <[hidden email]> wrote:
If you do this you are asking for trouble I think. Best, Karl
|
Re: The Inbox: Morphic-kfr.1540.mcz
|
|
> If you do this you are asking for trouble I think. A "replace" operation is usually implemented via "remove" and "add"... I think that is is in the same category as calling "delete" from a workspace and not through tools. Best, Marcel
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |