Page 1 of 1

Gui - Tooltips can go off screen

Posted: Thu Dec 02, 2010 2:15 am
by Mloren
If you have a gui item with a tooltip on the far right of the screen, the tooltip text will be mostly off screen. It should reposition itself to always stay within the window.

Posted: Thu Dec 02, 2010 3:53 am
by macron12388
Is this really a bug? I mean it's only doing what it's designed to do.

You tell it to render text/other gui items starting at a certain 2d point on the screen, and render from there, it won't recognize whether it's out of bounds or anything.

I'm sure it wouldn't be that hard to modify that code so you can get it to do what you want it to do :) That's what's good about Irrlicht being open source.

Posted: Thu Dec 02, 2010 8:55 am
by hybrid
I think there's already a bug ticket for this on our tracker.

Posted: Thu Dec 02, 2010 9:45 am
by CuteAlien
No, that one on the bug-tracker was for menus. And it's basically fixed for those already, although not sure yet if that is sufficient (I only prevented it in automatic cases, but still did allow setting it manually outside - which when I think about it now sounds reasonable so we could close that bug probably (will look at it in the evening)).

So new bug, I'll take a look and thanks for reporting :-)

Posted: Thu Dec 02, 2010 10:37 am
by Mloren
macron12388 wrote:Is this really a bug? I mean it's only doing what it's designed to do.

You tell it to render text/other gui items starting at a certain 2d point on the screen, and render from there, it won't recognize whether it's out of bounds or anything.
Just to answer this: I'd call this a bug because there is no way currently to reposition the tooltip, you have no control over where it appears so if its off screen, your stuffed and there's nothing you can do about it (besides change the irrlicht source). I'd also call this a bug because it's different to how tooltips usually work (at least on windows and I assume other OS's are the same). They always reposition themselves to stay on screen no matter where the element they belong to is.

Posted: Thu Dec 02, 2010 12:56 pm
by hybrid
Oh sorry, just remembered this problem with rendering outside the window. But didn't we fix this for tool-tips even earlier? I think bitplane worked on such a problem pretty early after tooltip introduction. Anyway, should be fixed. Either by finding a better default place, or adding an alignment option for the tooltip

Posted: Thu Dec 02, 2010 4:17 pm
by macron12388
Mloren wrote:
macron12388 wrote:Is this really a bug? I mean it's only doing what it's designed to do.

You tell it to render text/other gui items starting at a certain 2d point on the screen, and render from there, it won't recognize whether it's out of bounds or anything.
Just to answer this: I'd call this a bug because there is no way currently to reposition the tooltip, you have no control over where it appears so if its off screen, your stuffed and there's nothing you can do about it (besides change the irrlicht source). I'd also call this a bug because it's different to how tooltips usually work (at least on windows and I assume other OS's are the same). They always reposition themselves to stay on screen no matter where the element they belong to is.
Ahh, I see. If the only way to fix it is changing the irrlicht source, I guess it is a bug.

Posted: Thu Dec 02, 2010 6:12 pm
by bitplane
IIRC the one I fixed was to do with the tooltip appearing directly under or right next to the mouse position, so the hovered element would change when you next moved the mouse, which made the tooltips flicker on and off.

Any fix would have to watch out for that problem, the naive fix of just calling rect.constrainTo(screenRect) would probably reintroduce it.

Posted: Thu Dec 02, 2010 6:30 pm
by CuteAlien
bitplane wrote:IIRC the one I fixed was to do with the tooltip appearing directly under or right next to the mouse position, so the hovered element would change when you next moved the mouse, which made the tooltips flicker on and off.

Any fix would have to watch out for that problem, the naive fix of just calling rect.constrainTo(screenRect) would probably reintroduce it.
Hehe, I remember fixing that one also once in some situation :-) Guess it's one of those re-appearing bugs - I'll try to take care, thx.

Posted: Thu Dec 02, 2010 8:45 pm
by CuteAlien
Hm, I can't reproduce it here (testing with Irrlicht 1.7.2 branch).
Seems to work already. Which version did you use?


Here's my test-code:

Code: Select all

#include <irrlicht.h>
#include <iostream>

using namespace irr;
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;

#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#endif

struct SAppContext
{
	IrrlichtDevice * device;
    irr::gui::IGUIButton * buttonHide;
    irr::gui::IGUIButton * buttonRemove;
};


class MyEventReceiver : public IEventReceiver
{
public:
	MyEventReceiver(SAppContext & context) : Context(context) { }

	virtual bool OnEvent(const SEvent& event)
	{
		if (event.EventType == EET_GUI_EVENT)
		{
			switch(event.GUIEvent.EventType)
			{
            case EGET_BUTTON_CLICKED:
                if ( event.GUIEvent.Caller == Context.buttonHide )
                {
                    Context.buttonHide->setVisible(false);
                }
                else if ( event.GUIEvent.Caller == Context.buttonRemove )
                {
                    Context.buttonRemove->remove();
                }
                break;
			default:
				break;
			}
		}

		return false;
	}

private:
	SAppContext & Context;
};


int main()
{
	video::E_DRIVER_TYPE driverType = video::EDT_OPENGL;
	IrrlichtDevice * device = createDevice(driverType, core::dimension2d<u32>(640, 480));
	if (device == 0)
		return 1; // could not create selected driver.

	video::IVideoDriver* driver = device->getVideoDriver();
	IGUIEnvironment* env = device->getGUIEnvironment();
	
	SAppContext context;
	context.device = device;
    context.buttonHide = env->addButton( irr::core::rect<s32>(20,20, 100, 40), 0, -1, L"hide", L"tooltip_hide");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(20,50, 100, 70), 0, -1, L"remove", L"tooltip_remove");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(0,0, 100, 20), 0, -1, L"left-top", L"tooltip_lefttop");
    
    context.buttonRemove = env->addButton( irr::core::rect<s32>(300,0, 400, 20), 0, -1, L"top", L"tooltip_lefttop");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(540,0, 640, 20), 0, -1, L"top-right", L"tooltip_lefttop");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(540,100, 640, 120), 0, -1, L"right", L"tooltip_lefttop");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(540,460, 640, 480), 0, -1, L"right-bottom", L"tooltip_lefttop");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(300,460, 400, 480), 0, -1, L"bottom", L"tooltip_lefttop");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(0,460, 100, 480), 0, -1, L"bottom left", L"tooltip_lefttop");
    context.buttonRemove = env->addButton( irr::core::rect<s32>(0,200, 100, 220), 0, -1, L"left", L"tooltip_lefttop");
        
	MyEventReceiver receiver(context);
	device->setEventReceiver(&receiver);
	

	while(device->run() && driver)
	{
		if (device->isWindowActive())
		{
			driver->beginScene(true, true, SColor(0,200,200,200));
	
			env->drawAll();
		
			driver->endScene();
		}
	}

	device->drop();

	return 0;
}

Posted: Fri Dec 03, 2010 1:57 am
by Mloren
I'm using the 1.7.1 normal download (not SVN).

I'm also running Irrlicht in a win32 window. When the window is maximized, the tool tip is actually moving to stay on screen but not quite enough, a single character is still off screen.

When the window is not maximized, it doesn't reposition it at all and its mostly off screen.

Screenshot: (tool tip coming from the little icon that is half under the left edge of the tool tip)

Image

Posted: Fri Dec 03, 2010 9:20 am
by CuteAlien
I just tried on Windows as well and at least my test-code works there also. I won't got back to Irrlicht 1.7.1 as 1.7.2 is already released, but I don't think anything changed since then in this code (last changes should have been for 1.7.1).

So maybe I just don't catch the right situation in my test-code. Could you try adapting it to reproduce the problem?

Posted: Sun Dec 05, 2010 5:56 am
by Mloren
ok I've reproduced this using the Win32 irrlicht sample.
When running this I ran with the options:
"b" Direct3D 9.0c
"a" Window with button (via CreationParam)

It's to do with resizing the window:

I added an IGUIImage to the sample with the tool tip "this is a test".
I put the image on the far right so it was just going outside the edge of the irrlicht window.
When mousing over the right of the image, where it meats the edge of the window, the tool tip shows correctly, repositioning itself to stay on screen.
Now re-size the main window by clicking the right edge and dragging it in, make it smaller so that the image is now half off screen.
Mouse over it and see the tool tip is also off screen.

So I guess the issue is that while the tool tip stays within the irrlicht window, it doesn't move to stay within the parent window.

Posted: Sun Dec 05, 2010 12:42 pm
by hybrid
Well, this could also be a problem of dimension propagation, or border calculation due to the external window.