bug #17220 help

[ToyBoy]

I know this must be an inappropriate place to post this question.
I was assigned by my professor to fix this bug. https://gna.org/bugs/?17220 I have spent endless hours trying to find something. While debugging
I ended up in functions like set_cursor(). They are still not really helpful. I can't find out the function that is called when
the textbox overflows. If anyone can help me I would greatly appreciate it.

Thanks in advance.

[Max]

there are other text input fields that don't have this issue (e.g. filter in add-ons dialog), maybe start by looking at what's different...
both dialogs use the new GUI2 implementation that allows for customization of dialogs without changing the source. you find the definitions in data/gui/default.

there's some documentation on the wiki (synched from source): http://wiki.wesnoth.org/Category:GUI_WML_Reference

the right place to set your breakpoints is probably src/gui/widgets/text_box.cpp.
there's also a chance that the difference lies in how these dialogs are instantiated (src/gui/dialogs/*.cpp).

[ToyBoy]

The add-ons dialog has the same behavior. I thought it was working fine but it actually didn't.
There is this point that after it overflows it displays this 3 dots and everything gets [censored] up.
I want to find where this is happening and it is not in the text_box.cpp. I have set breakpoints all
over the place.

[Max]

The add-ons dialog has the same behavior.

i was talking about the filter input box (after you connect to the add-on server).

other input boxes seem fine as well - e.g. load game dialog (maybe that's gui1, haven't looked).

[ToyBoy]

Yes I did look at the filter. The behavior of the filter is not related to the text_box.cpp for sure because it didn't broke.
However I believe it is not a text_box. It is not exactly the expected behavior that a text_box should have.

edit: I am right now trying to find where the overflow is defined. And I have no luck so far.

[Iris]

there are other text input fields that don't have this issue (e.g. filter in add-ons dialog), maybe start by looking at what's different...
both dialogs use the new GUI2 implementation that allows for customization of dialogs without changing the source. you find the definitions in data/gui/default.

Wrong. The Add-ons Manager/Get Add-ons dialog is GUI1 in both 1.10 and trunk/1.11.x unless you pass the --new-widgets switch in the command line.

other input boxes seem fine as well - e.g. load game dialog (maybe that's gui1, haven't looked).

Incidentally, my statement above also applies to Load Game.

GUI1 and GUI2 dialogs and widgets are very different in implementation and architecture, and I don’t know either very well, but if you need to know the source code locations, everything GUI2 lives under src/gui/ (except for the WML portions in data/gui/, whereas everything GUI1 is directly under src/ (construct_dialog.?pp dialogs.?pp show_dialog.?pp) and src/widgets/.

Identifying what’s a GUI1 dialog and what is not is a bit trickier, unless you do text searches throughout the source code directory or pay attention to very subtle cues like push button behavior (GUI1 push buttons shift their contents by 1 pixel both on the x and y axes when pressed, GUI2 buttons do not do any shifting) and textbox borders (GUI1 textboxes lack borders, GUI2 textboxes have a golden frame).

The dialog displayed for naming a saved game when executing the Save Game action is GUI2, but you all probably gathered that already.

[Max]

it looks to me that the problem with the input text field might be caused by showing an ellipses. i can't find many places where this can happen (e.g. search for PangoEllipsizeMode).

[SkeletonCrew]

The add-ons dialog has the same behavior. I thought it was working fine but it actually didn't.
There is this point that after it overflows it displays this 3 dots and everything gets [censored] up.
I want to find where this is happening and it is not in the text_box.cpp. I have set breakpoints all
over the place.

The are not three dots but an ellipsis [1]. IIRC this is only implemented in GUI2 since it uses pango
for its rendering, (its reference manual is available online [2]). For the code you probably should look at:
- src/text.[ch]pp
- src/gui/widgets/text.[ch]pp
- src/gui/widgets/text_box.[ch]pp

Hope this helps you investigating the problem further.

[1] http://en.wikipedia.org/wiki/Ellipsis
[2] https://developer.gnome.org/pango/unstable/

[pangopo]

Trying to fix the same bug.

I noticed that the cursor gets messed up only when the Pango puts ellipsis at the beginning of the text box. I thought that the cursor was somehow moved by Pango putting ellipsis, but then, after setting PANGO_ELLIPSIZE_NONE, the problem still remained.

Then I noticed that text.cpp has set_cursor(...) method that changes selection_start_ property, which exactly matches with cursor position, except when it gets moved during the first text box overflow — the selection_start_ value doesn't change, but the actual cursor gets drew at a different position. So, using set_cursor(...) won't help since it doesn't actually set the cursor position.

After running the game through debugger for some time I started suspect calc_rects() from video.cpp, but I think that Pango is the one who messes with the cursor, since the cursor is stored and handled inside Pango. After reading Pango's docs, looking for something that is related to cursor and ellipsis, I found a function that supposedly changes cursor's position. But then, even if we can adjust the cursor position manually, we don't know where exactly the cursor should be. User can type at the end of the text box and get it overflowed, but a user also can type in the middle of a text and get the text box overflowed.

SceletonCrew, since you are probably the only person who understands GUI2 code, since you wrote it and currently maintain it, maybe you have some clues on why the cursor doesn't behave the way it should?

Fun fact: this bug is not reproducible on Ubuntu, but it is reproducible on, at least, Windows XP and Windows 7.

[SkeletonCrew]

I'm not entirely sure what's going wrong. Since I don't have access to a
Windows machine I can't reproduce the issue. Could somebody post screenshot
showing what exactly goes wrong. (I've heard before there are some Windows
specific issues with Pango.)

[Max]

before text box is filled up:

pango_ellipses_1.PNG (14.54 KiB) Viewed 6535 times

entering one more char:

pango_ellipses_2.PNG (15.7 KiB) Viewed 6535 times

entering another char:

pango_ellipses_3.PNG (14.81 KiB) Viewed 6535 times

one more:

pango_ellipses_4.PNG (17.14 KiB) Viewed 6535 times

selecting all text:

pango_ellipses_5.PNG (13.76 KiB) Viewed 6535 times

[pangopo]

here is an animated png

wesnoth17220bug.png (730.4 KiB) Viewed 6518 times

raw pngs

pngs.zip

(736.78 KiB) Downloaded 385 times

[8680]

I’ve converted that non-portable animated PNG (or, rather, the provided sequence of inanimate PNGs) to a GIF.

[pangopo]

Note that on the images i sent the cursor gets moved right after the ellispis. That's not always the case. It can move further to the right from the ellipsis depending on width of entered letters.

01.png (13.82 KiB) Viewed 6499 times

02.png (13.84 KiB) Viewed 6499 times

[SkeletonCrew]

ToyBoy, the problem is in the ttext::get_cursor_position() function.
pangopo is also looking into the issue and has joined our IRC chan.
I would advice you to also join the chan[1].

[1] #wesnoth-dev at irc.freenode.net