Keep track of where a mouse press started when deciding how mouse-over
and mouse-up should behave.
This handles the following situations:
1) If a mouse press starts outside a button (e.g. the UI background),
mouse-up inside the button has no effect. Previously, it triggered a
button click.
2) If a mouse press starts inside a button, the cursor moves outside of
its region, then back inside, the button will show as pressed.
Previously, it showed as highlighted instead of pressed.
This fix applies to drawPanelText(), where we used to hard-code
the text positions. Now we define the dimensions of the area where
the text is drawn (like we do for button texts) and calculate the
position based on the dimensions of the text string.
The drawPanelText() function is used for the Save, Quit, Protect
and Option dialogs, but for everything except the Option dialog it
already centered the text to the dialog. I decided to use this
centering mechanism for the title of the ITE Option dialog, even
though that changes the X coordinate by one pixel. Other than that,
it only affects the following texts:
ITE: Show Dialog / Reading Speed, Music and Sound
IHNM: Reading Speed, Music, Sound, Voices
I have verified that this looks at least ok for the English and
German versions of ITE, and the English, German, French and
Spanish versions of IHNM, so I'm reasonably confident that this
change is ok.
This involves moving the NSDockTilePlugIn code to backend/taskbar
and fixing style to follow our coding conventions. One make target
was also renamed. All in all there is no change in functionality with this
commit.
This allows to start a recently played game directly from the dock. The
ScummVM.app application should have been permanently added to the
dock and the menu is only present when ScummVM is not running. The
list of recently played game is written by the taskbar code in ScummVM.
The Dock Tile Plugin only reads that list to populate the menu.
This was part regression (ManagedSurface is picky about the order
of the parameters to the line drawing functions), part bug since
it was drawing a horizontal line instead of a vertical.
This call draws a very short vertical line to separate the
rightmost "join" of the middle horizontal bar in the inventory
dialog from the scrollbar. Unless you know what you're looking
for, it's pretty hard to spot the difference.
Thanks to dreammaster for figuring out the proper fix, while I
was still trying to figure out what it was trying to draw.
The former template hack relied on specialized functions for various types. We
use a hand crafted set of functions for serialization functionality now.
This patch fix bug #6841
If this runloop catches both the repeated key down event and the key up event.
In this case they key down will close the tooltip, because it got closed the key up event will be ignored.
As a result the LauncherDialog will never get notified the SHIFT state might have changed and not adapt the button description.
In this patch we just pass event to topDialog, if activeDialog was closed.
Also we must check, If topDialog doesn't exist.