[Feature Suggestion] In-Place Tooltip

[oZone]

It would be good if Rainmeter could simulate in-place tooltip behaviour, when using ClipString in string meter.

For in-place tooltip behaviour, I mean show tooltip only when string is clipped and shows (...) ellipse.

[balala]

It would be good if Rainmeter could simulate in-place tooltip behaviour, when using ClipString in string meter.

For in-place tooltip behaviour, I mean show tooltip only when string is clipped and shows (...) ellipse.

Although I don't contest that this integrated into Rainmeter would be good, however such a behavior of skins can be already simulated using the existing features:

Code: Select all

[Rainmeter]
Update=-1
DynamicWindowSize=1
AccurateText=1

[Variables]
Text1=Some text to test the Tooltip feature
Text0=Some text
ClipStr=0

[MeasureWidth]
Measure=Calc
Formula=( [MeterString:W] < [MeterClipString:W] )
IfCondition=(#CURRENTSECTION#>=1)
IfTrueAction=[!SetOption MeterString TooltipHidden "0"][!UpdateMeter "MeterString"][!Redraw]
IfFalseAction=[!SetOption MeterString TooltipHidden "1"][!UpdateMeter "MeterString"][!Redraw]
DynamicVariables=1

[StringSt]
X=0
Y=0
Padding=15,5,15,5
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
StringEffect=Shadow
AntiAlias=1
Text=[#Text[#ClipStr]]
DynamicVariables=1

[MeterString]
Meter=STRING
MeterStyle=StringSt
W=120
H=14
ClipString=1
FontColor=220,220,220
FontEffectColor=0,0,0
SolidColor=0,0,0,150
LeftMouseUpAction=[!SetVariable ClipStr "(1-#ClipStr#)"][!UpdateMeter "#CURRENTSECTION#"][!UpdateMeter "MeterClipString"][!Redraw][!UpdateMeasure "MeasureWidth"]
TooltipText=[#Text[#ClipStr]]

[MeterClipString]
Meter=STRING
MeterStyle=StringSt
FontColor=220,220,220,1
FontEffectColor=0,0,0,1
SolidColor=0,0,0,1

As you can see, there are needed two String meters, with the same settings, except the size, the Clipstring and the colors of the second meter. All colors must be set to a transparency of 1 and the size (W and H options), as well as the ClipString must miss. [MeasureWidth] compares the width of the two meters and shows / hides the tooltip accordingly.

[SilverAzide]

It would be good if Rainmeter could simulate in-place tooltip behaviour, when using ClipString in string meter.

For in-place tooltip behaviour, I mean show tooltip only when string is clipped and shows (...) ellipse.

I made a similar suggestion several years ago here: https://forum.rainmeter.net/viewtopic.php?f=14&t=26338&p=137560#p137560. My approach was slightly different (i.e., to have a way to know when to set a tooltip), but my use-case was the same as yours.

Recently Brian responded on a different thread, here: https://forum.rainmeter.net/viewtopic.php?f=27&t=28950&p=166735&hilit=t%3D26338#p166696. The upshot is that this is a rather complex problem.

[Yincognito]

It would be good if Rainmeter could simulate in-place tooltip behaviour, when using ClipString in string meter.

For in-place tooltip behaviour, I mean show tooltip only when string is clipped and shows (...) ellipse.

You do NOT need the 2 string meters or transparency tricks at all, like balala suggested. He was indeed right that the behavior can be simulated using the existing features in Rainmeter, but the process is much simpler:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]

[MeasureString]
Measure=String
String=Some text
UpdateDivider=-1
IfMatch=^Some text$
IfMatchAction=[!SetOption #CURRENTSECTION# String "Some text to test the Tooltip feature"]
IfNotMatchAction=[!SetOption #CURRENTSECTION# String "Some text"]
IfMatchMode=1

[MeterString]
Meter=STRING
X=0
Y=0
H=14
ClipStringW=120
ClipString=2
Padding=5,5,5,5
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
StringEffect=Shadow
AntiAlias=1
FontColor=220,220,220,255
FontEffectColor=0,0,0,255
SolidColor=0,0,0,255
MeasureName=MeasureString
UpdateDivider=-1
Text=%1
ToolTipText=%1
ToolTipHidden=1
LeftMouseUpAction=[!UpdateMeasure MeasureString][!SetOption #CURRENTSECTION# TooltipHidden ([#CURRENTSECTION#:W]>120)][!UpdateMeter #CURRENTSECTION#][!Redraw]
DynamicVariables=1

As you can see, I used balala's sample as a starting point (the measure is not important, it's only there to toggle between generating a shorter or a longer string), but used ClipString=2 and ClipStringW=desiredvalue to achieve the desired result. Of course, the value for ClipStringW should be the same as the value in the LeftMouseUpAction bangs and a height (H) should be set on the meter, in order to prevent the text from wrapping (the first option chosen by ClipString=2 when text is larger than the W or ClipStringW values) and prioritize clipping instead:

ezgif.com-video-to-gif.gif

As balala proved in another thread (and I always learn and make ammends from lessons like that), sometimes there are much simpler ways to achieve something.

Note: The above code has a small "bug" (more like a lack of attention from my part) that is corrected in this post below (first code sample).

[balala]

You do NOT need the 2 string meters or transparency tricks at all, like balala suggested. He was indeed right that the behavior can be simulated using the existing features in Rainmeter, but the process is much simpler:

Agree, but ONLY if you know the limit width of the string, above which the Tooltip has to be displayed. In your case this is 120, but what if the string is returned for instance by a WebParser measure, and you don't know it (or its width) when you write the code of the skin?
I think in such a case using the two String meters (as suggested above) is the only possibility, at least with the current features of Rainmeter.

[Yincognito]

Agree, but ONLY if you know the limit width of the string, above which the Tooltip has to be displayed. In your case this is 120, but what if the string is returned for instance by a WebParser measure, and you don't know it (or its width) when you write the code of the skin?
I think in such a case using the two String meters (as suggested above) is the only possibility, at least with the current features of Rainmeter.

But isn't the maximum width one sets for a text to be clipped always a user decision? The 120 there is taken from your MeterString, it's not something I hardcoded there. It can be 300, 50, whatever the user wants it to be. After all, when making a skin, one has to know the width in pixels after which he wants the text to be clipped, hasn't he? In other words, it isn't a dynamic value that is always changing, it's a number chosen by the skin designer or the user, according to his needs.

Also, you don't have to know the width of the whole string. You only have to know above which value you want the string to be clipped. It has nothing to do with how WebParser gets stuff - unless you meant something else and I didn't understand where you were going with this...

[balala]

But isn't the maximum width one sets for a text to be clipped always a user decision? The 120 there is taken from your MeterString, it's not something I hardcoded there. It can be 300, 50, whatever the user wants it to be. After all, when making a skin, one has to know the width in pixels after which he wants the text to be clipped, hasn't he? In other words, it isn't a dynamic value that is always changing, it's a number chosen by the skin designer or the user, according to his needs.

Also, you don't have to know the width of the whole string. You only have to know above which value you want the string to be clipped. It has nothing to do with how WebParser gets stuff - unless you meant something else and I didn't understand where you were going with this...

Yes, but it has to be set manually. There is not possible to show the Tooltip only if the string is clipped and hide it if it isn't, for any string. If in your last code you change the IfMatch options of the [MeasureString] measure for instance to this:

Code: Select all

[MeasureString]
Measure=String
String=Some text
UpdateDivider=-1
IfMatch=^Some text to test this feature$
IfMatchAction=[!SetOption #CURRENTSECTION# String "Some text to test the Tooltip feature"]
IfNotMatchAction=[!SetOption #CURRENTSECTION# String "Some text to test this feature"]
IfMatchMode=1

then when the String option of the [MeasureString] measure is set to Some text to test the Tooltip feature, the Tooltip is displayed, while for Some text to test this feature it isn't, although in both cases the string is clipped.
With my code (using two string meters), whenever the meter is clipped, the Tooltip is displayed, while whenever the the meter isn't clipped, the Tooltip is hidden, no matter what text is shown.
The basic idea is to get the Tooltip shown, ONLY if the meter is clipped, no matter what string is shown. If you have to set the width manually (120 in your case), this is not possible. But it is, with the code using two String meters. That's the advantage of having two such String meters.

[Yincognito]

Ok, so I discovered a "bug" in my implementation. It should be <120 rather than >120 in the bangs, since we want the tooltip hidden (value 1, aka TRUE) when the text is less than the desired width (not more). Also, the meter should be updated before we set the tooltip hidden option. The updated code:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]

[MeasureString]
Measure=String
String=Some text
UpdateDivider=-1
IfMatch=^Some text$
IfMatchAction=[!SetOption #CURRENTSECTION# String "Some text to test the Tooltip feature"]
IfNotMatchAction=[!SetOption #CURRENTSECTION# String "Some text"]
IfMatchMode=1

[MeterString]
Meter=STRING
X=0
Y=0
H=14
ClipStringW=120
ClipString=2
Padding=5,5,5,5
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
StringEffect=Shadow
AntiAlias=1
FontColor=220,220,220,255
FontEffectColor=0,0,0,255
SolidColor=0,0,0,255
MeasureName=MeasureString
UpdateDivider=-1
Text=%1
ToolTipText=%1
ToolTipHidden=1
LeftMouseUpAction=[!UpdateMeasure MeasureString][!UpdateMeter #CURRENTSECTION#][!SetOption #CURRENTSECTION# TooltipHidden ([#CURRENTSECTION#:W]<120)][!UpdateMeter #CURRENTSECTION#][!Redraw]
DynamicVariables=1

And a WebParser sample for balala (notice that the bangs have to be moved in the FinishAction of the WebParser parent measure):

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]

[MeasureWeather]
Measure=WebParser
Url=https://weather.com/en-GB/weather/today/l/47.95,26.40
RegExp="(?siU).*"vt1observation":\{.*,"phrase":(.*),.*\}.*"
UpdateRate=600
FinishAction=[!UpdateMeasure MeasureObservationPhrase][!UpdateMeter MeterObservationPhrase][!SetOption MeterObservationPhrase ToolTipHidden ([MeterObservationPhrase:W]<120)][!UpdateMeter MeterObservationPhrase][!Redraw]
DynamicVariables=1

[MeasureObservationPhrase]
Measure=WebParser
Url=[MeasureWeather]
StringIndex=1
UpdateDivider=-1
RegExpSubstitute=1
Substitute='"':"","^(.*)$":"Mostly Cloudy Blah Blah Blah"

[MeterObservationPhrase]
Meter=STRING
X=0
Y=0
H=14
ClipStringW=120
ClipString=2
Padding=5,5,5,5
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
StringEffect=Shadow
AntiAlias=1
FontColor=220,220,220,255
FontEffectColor=0,0,0,255
SolidColor=0,0,0,255
MeasureName=MeasureObservationPhrase
UpdateDivider=-1
Text=%1
ToolTipHidden=1
ToolTipText=%1
DynamicVariables=1

The second part of the Substitute in the WebParser child measure is in case the Observation Phrase is too short and you can't see how it behaves on longer texts.

[Yincognito]

If in your last code you change the IfMatch options of the [MeasureString] measure for instance to this [...] then when the String option of the [MeasureString] measure is set to Some text to test the Tooltip feature, the Tooltip is displayed, while for Some text to test this feature it isn't, although in both cases the string is clipped.
With my code (using two string meters), whenever the meter is clipped, the Tooltip is displayed, while whenever the the meter isn't clipped, the Tooltip is hidden, no matter what text is shown.
The basic idea is to get the Tooltip shown, ONLY if the meter is clipped, no matter what string is shown. If you have to set the width manually (120 in your case), this is not possible. But it is, with the code using two String meters. That's the advantage of having two such String meters.

Yeah, you were right. However, this happened not because my approach was wrong, but because of the "bug" I mentioned in my previous post. Should be fixed now - let me know if it isn't.

[balala]

And a WebParser sample for balala (notice that the bangs have to be moved in the FinishAction of the WebParser parent measure):

Not sure what should I see on this code. What should I?