bug #17220 help

Discussion of all aspects of the game engine, including development of new and existing features.

Moderators: Forum Moderators, Developers

ToyBoy
Posts: 4
Joined: March 28th, 2013, 4:10 am

bug #17220 help

Post by 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
Posts: 1449
Joined: April 13th, 2008, 12:41 am

Re: bug #17220 help

Post by 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
Posts: 4
Joined: March 28th, 2013, 4:10 am

Re: bug #17220 help

Post by 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
Posts: 1449
Joined: April 13th, 2008, 12:41 am

Re: bug #17220 help

Post by Max »

ToyBoy wrote: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
Posts: 4
Joined: March 28th, 2013, 4:10 am

Re: bug #17220 help

Post by 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.

User avatar
Iris
Site Administrator
Posts: 6646
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: bug #17220 help

Post by Iris »

Max wrote: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.
Max wrote: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.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.

Max
Posts: 1449
Joined: April 13th, 2008, 12:41 am

Re: bug #17220 help

Post by 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
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Re: bug #17220 help

Post by SkeletonCrew »

ToyBoy wrote: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
Posts: 3
Joined: March 30th, 2013, 5:18 am

Re: bug #17220 help

Post by 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
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Re: bug #17220 help

Post by 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
Posts: 1449
Joined: April 13th, 2008, 12:41 am

Re: bug #17220 help

Post by Max »

before text box is filled up:
pango_ellipses_1.PNG
pango_ellipses_1.PNG (14.54 KiB) Viewed 4566 times
entering one more char:
pango_ellipses_2.PNG
pango_ellipses_2.PNG (15.7 KiB) Viewed 4566 times
entering another char:
pango_ellipses_3.PNG
pango_ellipses_3.PNG (14.81 KiB) Viewed 4566 times
one more:
pango_ellipses_4.PNG
pango_ellipses_4.PNG (17.14 KiB) Viewed 4566 times
selecting all text:
pango_ellipses_5.PNG
pango_ellipses_5.PNG (13.76 KiB) Viewed 4566 times

pangopo
Posts: 3
Joined: March 30th, 2013, 5:18 am

Re: bug #17220 help

Post by pangopo »

here is an animated png
wesnoth17220bug.png
wesnoth17220bug.png (730.4 KiB) Viewed 4549 times
raw pngs
pngs.zip
(736.78 KiB) Downloaded 260 times

User avatar
8680
Moderator Emeritus
Posts: 742
Joined: March 20th, 2011, 11:45 pm
Location: The past

Re: bug #17220 help

Post by 8680 »

I’ve converted that non-portable animated PNG (or, rather, the provided sequence of inanimate PNGs) to a GIF.
Attachments
wesnoth17220bug.gif
wesnoth17220bug.gif (544.93 KiB) Viewed 4530 times

pangopo
Posts: 3
Joined: March 30th, 2013, 5:18 am

Re: bug #17220 help

Post by 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
01.png (13.82 KiB) Viewed 4530 times
02.png
02.png (13.84 KiB) Viewed 4530 times

SkeletonCrew
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Re: bug #17220 help

Post by 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

Post Reply