the GUI tooltips apear to be broken

[nuggreat]

As brought up on the kOS reddit HERE the TOOLTIP suffix for labels appears to be broken,

This is the code I used to try to get said tooltips to work according to the documentation, all 3 displayed GUI elements should have different tooltips but on mouse over none of them show.

LOCAL interface IS GUI(200).

LOCAL iField IS interface:ADDTEXTFIELD("a").
LOCAL iLabel IS interface:ADDLABEL("Tooltip Test").
LOCAL iDone IS interface:ADDBUTTON("Done").

SET iField:TOOLTIP TO "something should show".
SET iLabel:TOOLTIP TO "still nothing".
SET iDone:TOOLTIP TO "press to close".

interface:SHOW().

LOCAL done IS FALSE.
SET iDone:ONCLICK TO { SET done TO TRUE. }.
WAIT UNTIL done.
CLEARGUIS().

I tested this on kOS 1.1.5.0 and KSP 1.3.1

[Dunbaratu]

Okay, I see the problem in the GUI code.

The way that tooltips work in Unity3d's IMGUI is nothing like how an actual GUI tooltip is supposed to work. This is a fact they should have red-flagged in a major way with giant signposts because NOBODY would assume it works the way it actually does.

You hear "tooltip" and assume it means "Once you define the tooltip for a widget, then the GUI system will automatically make that little string appear on screen next to the mouse when the mouse hovers over this widget."

Nope. That's not what it means in Unity3d's IMGUI.

What it actually means is this:

1 - Unity3d will set a global string variable called GUI.tooltip for you that contains the tooltip for the widget the pointer is hovering on, so you don't have to track the mouse position to find out which tooltip string is currently appropriate.

2 - But it won't actually DO anything with that global string variable. At all. It just sets it in a global variable so the program can read what it is. It renders nothing for you about it.

3 - Instead you (the writer of the C# code) are expected to decide how you want to show the tooltip, and you have to write the code to paint it somewhere, yourself, your way. The example in their docs has you simply doing this at the bottom of drawing your window in your window-painting OnGUI() callback:

if (GUI.Tooltip != "")
   GUI.Label(Rect(200,100,40,10),GUI.Tooltip);

(So that example is, "if you see that there is a tooltip set, then paint it as a label in this fixed rectangle position inside the window". This would be something you'd draw in, say a status line in the window perhaps, or a title bar of the window.).
But it's up to the programmer using Unity3d to decide to draw it, and where. It doesn't draw itself.

You can see an example of this in our own toolbar window in kOS. Notice as you move your mouse across the different things in that window, the bottom line of the window changes the text to the tooltip for that thing. I wrote that code a while ago, but hadn't noticed that the GUI code donated to us lacked the feature. I hadn't known that it was an unimplemented feature to be added later.

So, the problem in the GUI code kOS uses is that this step of drawing the tooltip is completely missing. It never bothers doing the step 3 above - with one exception - it does do it with the popup list selector widget - but not with any of the others.

So, there are three possible fixes I can think of:

A - We give the user access to reading GUI.Tooltip, and we do nothing else. We let them read that global themselves and decide if they'd like to paint it in a label somewhere in the window, and we document how this all works and give an example how to do it.

B - We make a special Label subclass called "ToolTipLabel" that we will always populate with GUI.Tooltip for the user. All the user has control over is where to put it in the window, and what style changes to give it, but the content will be fixed by us. This is a compromise in flexibililty versus simplicity between options A and C.

C - We just control everything without user choice at all. We decide where tooltips should go, what they should look like, and we automatically do it for the user, probably in a bar across the bottom of the GUI window (see the kOS toolbar widget as an example). This is the least hassle for the user but also has the least user choice in the matter.

[luovahulluus]

So, the tooltip string hovering next to the cursor is out of the question, right?

My first idea was this: Would it be possible to leave the tooltip as it is, and add an ONHOVER command? Something that would work like ONCLICK and ONCHANGE. This would give the user lots of control and would do so in a familiar setting. The user could just call function SetTooltipLabel, which would do the same as what the kOS window tooltip does, or could pop up another GUI window with lot's of content like pics or graphs, or could highlight parts ("click here to open the highlighted solar panel/fire this missile") or something. Then there would also have to be an OFFHOVER capability which could be set up to clear the label or whatever was done, when the cursor is not hovering on something. Maybe ONHOVER could be set (if so wanted) to the GUI, the outermost box, and would recognize which widget the cursor is hovering on?

If that is not doable, how about option A, which would act like B if you don't touch the default values? I can't really imagine what the option A would look like when implemented, so I don't even know if this suggestion makes any sense. In principle I like more control, but I can't assess if the extra hassle is worth the extra flexibility.

[Dunbaratu]

It might be possible to make the tooltip open a hovering box with just simple string text in it as you had originally expected it would, and as probably anyone else would have expected it to. I'm just nervous about getting it done fast given that I set a deadline for myself to get a release out and I don't really want to be spending all my free time on kOS nonstop, so a quicker solution would be preferred at least for now.

The uglier parts of doing it that way are this:

• That "global" GUI.Tooltip I was talking about isn't really global. I was simplifying for brevity. What it is is temporarily populated only as long as Unity3d engine is still calling your OnGUI() callback. (The method the C# programmer writes to draw the window innards each time the system wants to repaint it, many times a second.) Thus you cannot "see" the tooltip of one window "from another window". Unity3d will wipe the GUI.Tooltip value after the first window's OnGUI() is done, before the second window's OnGUI() is called. It only exists long enough for THAT window to see it.
• Thus using the GUI.Tooltip to pop open a second window that hovers means having to have the OnGUI() of the first window grab a copy of it and store it somewhere in the kOS mod's values before its OnGUI() call finishes. Then there would have to be a constantly monitoring thing for the second window that says "did a tooltip get written recently? If so I should open a window and paint it. Let me query where the mouse pointer is and use that to decide where to place this little window." It would also need to say "oh wait, no tooltip got written recently. I should close my window now because that probably means the mouse isn't hovering over the thing anymore."

It's technically do-able. I just worry about making sure I dot my I's and cross my T's properly because if I get one thing wrong in the hooks or the timings or have a weird race condition, it's going to mean stale tooltip windows handing around that won't go away, and we've all seen guis that glitch out like that and it's really annoying.