...from non-editable textboxes
This effectively removes the selection/cursor manipulation part of
2012-12-23T06:10:31Z!shadowm@wesnoth.org. Without obvious visual cues as to what textbox has the current
focus it is only good for confusing users. Additionally, at least two
existing GUI-based IRC programs seem to do without selection/cursor
manipulation on the channel/query view box.
...(actually quadruplicate) events. Changed from 2012-12-23T06:10:46Z!shadowm@wesnoth.org.
Due to the way focusing works, the focus switch in the middle of the
forwarding action would create a duplicate event for the origin textbox,
resulting in a duplicate event for the target (a total of four events to
process).
Instead, make the implementation of gui::textbox::handle_event()
forwarding-aware, and provide a wrapper for the events engine
implementation to use by default.
...non-editable textboxes used to do
This should solve various focus-stealing issues related to the Filter
textbox in the old-lobby since non-editable textboxes gained the
ability to have focus in 2012-12-23T06:10:31Z!shadowm@wesnoth.org.
Avoid crash near end of games with turn limits.
Properly identify poison immune units.
Better timing for keep switching.
Handle more weapon specials involving damage.
...if not replacing the old values.
Thus positive numbers will always make the unit easier to hit, while
negative numbers always make it harder. (bug #20242)
This allows WML authors to not worry about special cases like horsemen
in forests. In addition, should it be decided to change how that case
is defined (currently by setting forest=-70), that change could be
done without changing the WML for effects that add to (or subtract
from) defenses.
...after resending relevant events to its input target
This effectively fixes bug #5877, *again*. 2012-12-23T06:10:46Z!shadowm@wesnoth.org introduced quite a
regression in the form of switching the focus permanently as soon as the
user presses the modifier key in Shift+<arrow> and Shift+C, requiring
improbable typing skills to get e.g. a Shift+C event _before_ a solitary
left or right Shift event.
...events on textboxes"
This reverts commit 2012-12-23T07:29:01Z!shadowm@wesnoth.org.
While ignoring solitary modifier keys is good and all, it may be
potentially counterproductive to do so if SDL's definitions of such ever
change, and this is not the right approach to handling the actual issue.
...on textboxes
This allows selection manipulation shortcuts to work on the lobby
backlog textbox as intended by 2012-12-23T06:10:31Z!shadowm@wesnoth.org. This cropped up as a
side-effect of 2012-12-23T06:10:46Z!shadowm@wesnoth.org. Since neither left or right Shift yield
printable characters, it makes no sense to process them when not
acting as key modifiers.
...for a non-editable textbox
Content-altering events on a non-editable textbox are forwarded to the
edit target textbox as long as it is editable itself.
In particular, multiline textboxes. And more specifically, the old
(default) lobby backlog textbox. This is a rather revolutionary feature.
Wesnoth is truly this century's greatest pioneer in user interface
design and implementation.
A few caveats:
* In order for this to not conflict with other textboxes' selections, I
had to make it possible for non-editable textboxes to get focus. In
the particular case of the lobby, the result can be visually
confusing since we don't currently have a way to show that a
non-editable textbox has focus. This will be addressed by another
commit later.
* Moving the mouse for the first time after the old lobby is shown
causes the filter box to display a black rectangle at the start when
it is grayed out. This appears to be a side-effect of the way mouse
events are handled in GUI1 textboxes, and it can actually happen
without this commit too if one *clicks* on the filter textbox
instead.
* Shift+Up, Shift+Down, Shift+PgUp, Shift+PgDown do not do anything
yet.
* Shift+Home, Shift+End adjust the selection relative to the start of
the box's overall contents as opposed to the current line.
...so it actually works at all
Because of the questionable console commands handler design, the command
list isn't populated until the handler's dispatch() method is called for
the first time. We can call it with an empty command string to work
around this; the empty command is ignored and we get the command list
populated so we can actually build an autocompletion dictionary with it.
Previously, the autocompletion dictionary would be always empty.
