[Cuis-dev] Change in HoverHelpMorph

[Hernan Wilkinson]

Hi Hilaire,
 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 :-)

 I prefer to make the formatting dependable of a parameter and not of an
attribute of a Morph...
 Attached is my proposal. At the end it does the same as yours but it does
not depend on a Morph attribute.
 Morph attributes are really difficult to find in the code and therefore
difficult to know if they exist, how they behave, etc.
 Let me know what you think.

Cheers!
Hernan.

On Thu, Nov 4, 2021 at 9:50 AM Hilaire Fernandes <hilaire at drgeo.eu> wrote:

> Hi Hernan,
>
> 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.
>
> This was the behavior I experienced on GTK+, Squeak and Pharo.
>
> 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.
>
> I did not anticipate your situation, sorry for the inconvenience.
>
> 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.
>
> Is it an acceptable solution for you?
>
> Best
>
> Hilaire
>
> Le 04/11/2021 à 02:14, Hernan Wilkinson a écrit :
>
> Hi Hilaire,
>  the change set number 4922 changes the behavior of the HoverHelpMorph.
>  I use it in LiveTyping to show the types of variables, returns, etc.
>  Before that change set, the types were shown in a line, for example:
>  < Morph # InnerListMorph | HandMorph | WidgetMorph >
>
>  With the change, the width of the hover help is much smaller and it shows
> something like this:
>  < Morph # InnerListMorph
> | HandMorph
> | WidgetMorph >
>
>  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.
>
> contents: aString
> | width |
> contents _ aString.
> width _ (contents includes: Character lf)
> ifTrue: [9999999] ifFalse: [300].
> textComposition _ TextComposition new.
> textComposition
> setModel: (TextModel withText: contents asText);
> extentForComposing: width at 9999999.
> textComposition composeAll.
> self morphExtent: textComposition usedExtent + 8
>
> Thanks!
> Hernan.
>
> --
> GNU Dr. Geohttp://drgeo.euhttp://blog.drgeo.eu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211104/4ed997b3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4966-HoverHelpFormatting-HernanWilkinson-2021Nov03-21h28m-HAW.001.cs.st
Type: application/octet-stream
Size: 2345 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211104/4ed997b3/attachment-0001.obj>