The placement of the cursor sometimes was wrong under Windows. (The bug
could be reproduced under Linux by changing the configuration files.)
The problem was caused by the height of the text box and the permission
to wrap the text on a new line. This caused the cursor position to
return to the beginning of the line.
Fixes bug #17220 using patch #3822.
Most references to and dependencies on Subversion have been removed.
"+svn" is now "+dev". Files that can't be fixed yet have a FIXME-GIT
comment in them; most of these are in the website tests.
------------------------------------------------------------------------
Tag-Name: v0_4_8rc1
This commit was manufactured by cvs2svn to create tag 'v0_4_8rc1'.
This purportedly fixes bug #18793.
(Candidate for 1.10, PLEASE TEST!)
The conditionals in question:
> if (scroll_type == ONSCREEN || ONSCREEN_WARP) {
This *always* evaluates to true when scroll_type != ONSCREEN, because
ONSCREEN_WARP is an enum member with a non-zero value. The bogus code is
effectively the same as:
> if ((scroll_type == ONSCREEN) || true) {
Which was most likely not the author's intention (fendrin in r49988).
Therefore, I've replaced the conditionals with what should be the
correct way to do what I suspect was meant above:
> if (scroll_type == ONSCREEN || scroll_type == ONSCREEN_WARP) {
This seems to fix the viewport centering issues for me, but it would be
nice if people reported their own experience with the fix before
backporting it to 1.10.
This is possible as a side-effect of 2013-02-03T19:05:22Z!jt_coding@verizon.net. I think it looks
kind of cool, but if it turns out to be a bad idea, it can be easily
reverted (just a matter of changing a single "false" to "true").
there was a chance of them not firing ever since WML division was
changed to floating point.
Also changelog entries for this and 2013-02-01T04:48:38Z!jt_coding@verizon.net.
...fields and implement a button to toggle them all at once
Also needed to do some refactoring to achieve the tracking part. Not
that anyone really needs to see that in a separate commit.
...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.
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.
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.
This is necessary to have accurate vision if shroud updates are
delayed. (The alternative would be to clear the undo stack before
saving the game, which would likely surprise many players and would
require handling sighted events before actually saving.)
