<div dir="ltr">Hi Hilaire,<div> don't worry! I wish we could have a better testing system and improved SCM to avoid these kinds of problems, but we do not :-)</div><div><br><div> I prefer to make the formatting dependable of a parameter and not of an attribute of a Morph...</div><div> Attached is my proposal. At the end it does the same as yours but it does not depend on a Morph attribute. </div><div> Morph attributes are really difficult to find in the code and therefore difficult to know if they exist, how they behave, etc. </div><div> Let me know what you think.</div></div><div><br></div><div>Cheers!</div><div>Hernan.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 4, 2021 at 9:50 AM Hilaire Fernandes <<a href="mailto:hilaire@drgeo.eu">hilaire@drgeo.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><font size="+1">Hi Hernan,<br>
</font></p>
<p><font size="+1">Yes tooltips shoud be formatted by the system to
look uniform. Also it makes life easier for translators, they
does not have to worry about how to hand format the paragraphs,
being consistent from one translation to another one, etc. So
you really want the system to deal with it.<br>
</font></p>
<p><font size="+1">This was the behavior I experienced on GTK+,
Squeak and Pharo.</font></p>
<p><font size="+1">Before my change, Cuis presented tool-tips
occupying half of the screen width. This was really odd. I have
very long tool-tips in DrGeo, so it was a problem. To deal with
hand formatted tool-tips, I set this detection of linefeed, so
in this case no system formatting takes place.</font></p>
<p>I did not anticipate your situation, sorry for the inconvenience.</p>
<p>What we could do is to use a property to force for un-formatted
tool tips. This is what proposes the attached change set. The only
inconvenience for you is to set the property #balloonUnformatted
for each morph you want its tool tips un-formatted.</p>
<p>Is it an acceptable solution for you?<br>
</p>
<p>Best</p>
<p>Hilaire</p>
<br>
<div>Le 04/11/2021 à 02:14, Hernan Wilkinson
a écrit :<br>
</div>
<blockquote type="cite">
<div lang="x-unicode">
<div dir="ltr">Hi Hilaire,<br>
<div> the change set number 4922 changes the behavior of the
HoverHelpMorph. </div>
<div> I use it in LiveTyping to show the types of variables,
returns, etc. </div>
<div> Before that change set, the types were shown in a line,
for example:</div>
<div> < Morph # InnerListMorph | HandMorph | WidgetMorph
> </div>
<div> </div>
<div> With the change, the width of the hover help is much
smaller and it shows something like this:</div>
<div>
<div> < Morph # InnerListMorph </div>
<div>| HandMorph </div>
<div>| WidgetMorph > </div>
<br>
</div>
<div> Why did you make that change? I do not understand why if
the contents does not includes a line feed you are limiting
the width to 300... the strings I'm using do not have a line
feed. The code is bellow.</div>
<div><br>
</div>
<div>contents: aString<br>
| width |<br>
contents _ aString.<br>
width _ (contents includes: Character lf)<br>
ifTrue: [9999999] ifFalse: [300].<br>
textComposition _ TextComposition new.<br>
textComposition<br>
setModel: (TextModel withText: contents asText);<br>
extentForComposing: width@9999999.<br>
textComposition composeAll.<br>
self morphExtent: textComposition usedExtent + 8</div>
<div><br>
</div>
<div>Thanks!</div>
<div>Hernan.<br>
<br>
</div>
</div>
</div>
</blockquote>
<pre cols="72">--
GNU Dr. Geo
<a href="http://drgeo.eu" target="_blank">http://drgeo.eu</a>
<a href="http://blog.drgeo.eu" target="_blank">http://blog.drgeo.eu</a></pre>
</div>
</blockquote></div>