[Cuis-dev] prevent resizing

[Mark Volkmann]

Gerald, thanks so much for explaining that!

On Thu, Aug 22, 2024 at 5:55 AM Gerald Klix via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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?
> >
> >
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240822/1ac042c6/attachment.htm>