[Cuis-dev] prevent resizing

[Gerald Klix]

Hi Mark,

please apologize that I do not send mail to your GMail account.
They won't accept my mail, because it's not DKIM-signend,
but they send me DKIM-signed spam about once week.
Result: I blocked a wide range of IP addresses belonging to them
at my firewall; even DNS is blocked, so no mail from or to GMail.


Back to your question(s), especially to those you did not ask :]

1) Adding morphs in #initialize and then removing them in a subclass' 
#initialize
method creates some objects that will immediately become garbage,
it's a waste of resources. Therefore a better solution is to factor
out that creation of the adjuster morphs into a separate method
and redefine that method in that subclass to do nothing.

2) The "best" solution is to start with that fixed size window
as a superclass and make SystemWindow a subclass containing
the resizing logic including the adjusters instance variable.
If there are many applications for fixed size windows,
this huge change will be well worth it.

3) Your original questions has two answers:

a) For reasons unknown to me – if I had to guess,
I would say memory consumption – when Morphic for Squeak
was invented a PC/Mac with 32 *Mega*bytes of main memory
was a huge machine – the submorphs instance variable always
holds an array and not, as one might expect, an OrderedCollection.
Therefore removing or adding a sub-morph is an operation
more costly than you might suspect. If you look at
Morph>>#removeAllMorphsIn: you will see that
Juan went to great length to make that operation still
efficient.

b) Iterating over collections while changing them is
prone for disaster in most programming languages.

For Cuis' sub-morphs you can use `self submorphs do:`
instead of `submorphsDo:`, because #submorphs
answers a copy of that aforementioned array of sub-morphs.
In this particular case you can even get away by using
#submorphsDo: and removing the adjuster morphs one by one,
because removing a morph boils down to sending #privateRemove:
to the SystemWindow instance. #privateRemove: is defined like this.

privateRemove: aMorph
     "Private! Should only be used by methods that maintain the 
ower/submorph invariant."
     submorphs := submorphs copyWithout: aMorph.

You see that #privateRemove copies the submorphs array,
therefor you are safe.
So if you do it that way, you create eight copies of that sub-morph array,
of which 7 immediately become garbage.


HTH and Best Regards,

Gerald


On 8/22/24 3:21 AM, Mark Volkmann via Cuis-dev wrote:
> Thanks so much Gerald! Is there a reason why you collect the morphs to
> remove in an OrderedCollection and then iterate over that to delete them
> versus just removing them in the block passed to submorphsDo?
>
> On Wed, Aug 21, 2024 at 11:12 AM Gerald Klix via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hi Mark, Hi Juan,
>>
>> It can be done by removing the adjuster morphs.
>> Please see the attached file-out of FixedSizeSystemWindow.
>>
>> You can use this code snippet to test it:
>> FixedSizeSystemWindow editText: (TextModel withText: 'Test')  label:
>> 'Test' wrap: false
>>
>> On 8/21/24 4:10 PM, Juan Vuletich via Cuis-dev wrote:
>>> On 8/21/2024 10:55 AM, Mark Volkmann via Cuis-dev wrote:
>>>> Is there an easy way to configure a subclass of SystemWindow from
>>>> being resized by the user by dragging a corner or edge?
>
>