| Age | Commit message (Collapse) | Author |
|---|
|
The tooltip isn't really interested in any keyboard and mouse
events, other than as a signal to close itself, so pass them back
to the parent dialog. From what I understand, the tooltip isn't
part of the dialog, so there should be no risk of going into an
infinite loop here.
|
|
|
|
|
|
|
|
Some backends may break as I only compiled SDL
|
|
Formerly there was much special handling for the Tooltip dialog in
GuiManager::runLoop. This was replaced by overloading the event handling
functions in Tooltip. Also the Tooltip was adapted to be run like every
other normal dialog.
svn-id: r54337
|
|
Before, it could be instantiated after an engine loaded and then was never deleted, causing memory fragmentation. Also removed inner tooltip call to the GuiManager runloop, which makes the logic simpler since the tooltip is a bit of a hack. I had to remove it because deleting _tooltip in the inner loop (called from tooltip itself) is trouble.
svn-id: r54311
|
|
svn-id: r54265
|
|
svn-id: r53160
|
|
With help of Tanoku tooltips were switched from widgets to dialogs
which helped to fix nasty bug with background not being restored.
Although it is basically a hack around inconsistent font backbuffering
in our GUI code, for the time being it is feasible.
The patch was extended with way to specify tooltip background in the
theme file.
svn-id: r51217
|
