bug #17220 help
Moderator: Forum Moderators
bug #17220 help
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.
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.
Re: bug #17220 help
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).
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).
Re: bug #17220 help
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.
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.
Re: bug #17220 help
i was talking about the filter input box (after you connect to the add-on server).ToyBoy wrote:The add-ons dialog has the same behavior.
other input boxes seem fine as well - e.g. load game dialog (maybe that's gui1, haven't looked).
Re: bug #17220 help
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.
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.
Re: bug #17220 help
Wrong. The Add-ons Manager/Get Add-ons dialog is GUI1 in both 1.10 and trunk/1.11.x unless you pass theMax 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.
--new-widgets
switch in the command line.Incidentally, my statement above also applies to Load Game.Max wrote:other input boxes seem fine as well - e.g. load game dialog (maybe that's gui1, haven't looked).
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.
Re: bug #17220 help
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).
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
Re: bug #17220 help
The are not three dots but an ellipsis [1]. IIRC this is only implemented in GUI2 since it uses pangoToyBoy 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.
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/
Re: bug #17220 help
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.
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.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
Re: bug #17220 help
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.)
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.)
Re: bug #17220 help
before text box is filled up:
entering one more char:
entering another char:
one more:
selecting all text:
Re: bug #17220 help
here is an animated png
raw pngs
raw pngs
Re: bug #17220 help
I’ve converted that non-portable animated PNG (or, rather, the provided sequence of inanimate PNGs) to a GIF.
- Attachments
-
- wesnoth17220bug.gif (544.93 KiB) Viewed 6511 times
Re: bug #17220 help
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.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
Re: bug #17220 help
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
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