<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr"><div>Hi Stef --</div><div><br></div>
                                        > <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">5)- beAllFont:</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Did the commentary in #font: help you understand the relationship between fonts, text attributes, and text style? The most basic usage is to set a #textStyle: and then use #contents: maybe just with a string, not text. If it is a text, text attributes will override the defaults coming from the current text style. #font: is expected to work very similar to what #beAllFont: did. Hmm....</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">The scale factor was by default initialized to 0.75 which made</span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> everything tiny; in 5.3 it was 1.0.</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Hmm... What's the platform you are working on? This should never happen in 6.0. 75% is a special case that must be selected by the user. It is never used automatically...</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 25.08.2022 12:27:59 schrieb Stéphane Rollandin <lecteur@zogotounga.net>:</p><div style="font-family:Arial,Helvetica,sans-serif">Some notes about porting muO to 6.0<br><br><br>Context:<br><br>I always develop on a stable release, that may be several versions <br>behind the current trunk. This makes updating everything to work on a <br>newer stable release a non-trivial task, always.<br><br>muO started around 2002/2003, when Squeak was at 3. something (later and <br>for a long time I worked on 3.8). I remember 3.8 to 3.9 being quite bad, <br>but it was always nice to discover the new features and play with them. <br>And now after twenty years muO has gone all the way to 6.0, which shows <br>a real concern about backward compatibility from the trunk developers - <br>so, thanks everybody!<br><br>Now all is not smooth and this time, moving from 5.1/5.3 to 6.0, I had <br>the feeling it was more bumpy because of a few actual non-compatible <br>changes. Their nature also made the corresponding porting issues <br>particularly difficult to pinpoint, leading at times to the wrong but <br>unsettling impression that something was deeply broken.<br><br><br>So here they are:<br><br><br>1)- becomeForward:<br><br>A lot of the intricate live dependency of interactive objects in muO was <br>just gone - living things were now dead; it seems things were broken all <br>over the place.<br><br>In fact it was just that #becomeForward: semantics had changed.<br><br>All my #becomeForward: calls had to be replaced with <br>#becomeForward:copyHash: with second argument true.<br><br>This one is quite nasty.<br><br><br>2)- setProperty:toValue:<br><br>Debuggers showed me all kind of objects receiving messages they had <br>nothing to do with. It seemed that object composition was scrambled, but <br>in fact...<br><br>#setProperty:toValue: semantics had changed<br><br>It now returns its second argument, so I had to add cascaded #yourself <br>calls in many places.<br><br>This one is nasty too.<br><br><br>3)- immutable arrays<br><br>In a couple of places I did use arrays written in their now immutable <br>form to store data that would later be updated. I had to use other ways <br>to instanciate the arrays.<br><br>This one is bad IMO. Not the fact that arrays can (and should most <br>often) be immutable, but the fact the default way to write an #(array) <br>or a 'string' now has a different semantics. Assuming as before that we <br>get mutable objects leads to bugs that are easy to catch, but I am <br>afraid there may be old code laying around in SqueakMap or other <br>repositories that will now break. Well maybe I'm wrong about that.<br><br><br>4)- FloatArray<br><br>FloatArray is now abstract; it must now be replaced with Float32Array.<br><br>Because I want muO to load and work both in 5.3 and 6.0 (which it does), <br>I had to to have the pre-installer create a dummy Float32Array class <br>before loading the muO code in 5.3.<br><br>No big deal, but again if some older forgotten packages are using <br>FloatArray, they will break.<br><br><br>5)- beAllFont:<br><br>This one is minor but still, #beAllFont: semantics changed. In 5.3 it <br>used to update the font of an existing text morph, now it is the same as <br>#font: and cannot be used that way - it must be sent before the text is set.<br><br>I just reverted it to its 5.3 behavior for muO.<br><br><br>6)- font sizes<br><br>In MuOTheme#addFonts: I had to give different font sizes numbers in 5.3 <br>and 6.0 in order to get the same actual font sizes on screen. Not sure <br>what happened there, I guess a bug was fixed (because the font support <br>is much nicer now in 6.0) but still that's an incompatible change.<br><br><br>7)- RealEstateAgent scaleFactor<br><br>The scale factor was by default initialized to 0.75 which made <br>everything tiny; in 5.3 it was 1.0.<br><br><br>8) minor stuff now fixed<br><br>There where other minor issues that were fixed in the update stream <br>after I signaled them on squeak-dev. I'll just mention them for <br>completeness sake:<br><br> - rehash was needed in SmartRefStream>>#next<br>    - #encompassing:, #merging: did not accept a Set anymore<br>      - a one-character wide TextMorph would not resize properly<br><br>All of this is now fine in 6.0, as of version 22110<br><br><br>All in all it was an interesting ride, and kudos to the developers for <br>all the work that went into 6.0!<br><br><br><br>Stef<br><br><br><br></div></blockquote></div>