It didn't work anymore, at all. Touchscreen polling occurred only
*after* waiting for a button had completed. So the touchscreen events,
if any, would be ignored until the user had pressed a button, possibly
firing off another action with that button press and forwarding the
touchscreen event to the next interface that got brought up as a
result.
Reusing this code and fixing it would require far more work than
rewriting everything anew with touchscreen devices in mind from the
beginning.
MtH: Resolved conflicts, mainly from the GMenu2X pointer to reference
change I did on 2015-04-21.
It was only used to fetch resY, so I replaced that by taking the
y-coordinate as an argument. That is also more consistent with the
x-coordinate which was already an argument.
The x-coordinate was changed to a signed int, since that is the norm
for paint coordinates. It can be useful for drawing widgets that are
partially off screen, for example during a (dis)appear animation.
In InputDialog, the ButtonBox field was changed from a pointer to
a plain data member. There was no need to dynamically allocate it.
Previously, IconButton instances to be added to button boxes were
allocated with new, but never freed with delete.
unique_ptr makes sure the buttons will be freed along with the button
box that owns them, or when code calls ButtonBox::clear.
The destructor of ButtonBox has been made redundant by this change, so
it's gone.
This was only called form ButtonBox, so I moved the code there.
I still think a paint method shouldn't be repositioning widgets, but
that's something for a later cleanup.
Nowhere in the code do we actually mix IconButtons and Links (the other
Button subclass), so I'm thinking of breaking up this class hierarchy
or at least making the inheritance private.
Also switched to C++11 style loops.
