[squeak-dev] The Inbox: Morphic-kfr.1540.mcz
K K Subbu
kksubbu.ml at gmail.com
Thu Sep 26 10:50:51 UTC 2019
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 <marcel.taeumel at hpi.de>:
>>
>> 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 <karlramberg at gmail.com>:
>>>
>>> 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 <marcel.taeumel at hpi.de
>>> <mailto:marcel.taeumel at hpi.de>> 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
>>>> <karlramberg at gmail.com <mailto:karlramberg at gmail.com>>:
>>>>
>>>> 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
>>>> <marcel.taeumel at hpi.de <mailto:marcel.taeumel at hpi.de>> 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
>>>>> <karlramberg at gmail.com <mailto:karlramberg at gmail.com>>:
>>>>>
>>>>> 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
>>>>> <karlramberg at gmail.com <mailto:karlramberg at gmail.com>> 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
>>>>> <commits at source.squeak.org
>>>>> <mailto:commits at source.squeak.org>> 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].!
>>>>>
>>>>>
>>>>
>>>
>
>
More information about the Squeak-dev
mailing list
|