libufo-devel

[UFO-devel] UTextEdit reacting strangely

[Elie `w. B. <dro...@gm...>]

Hello again fellow UFO users,

This is probably my tenth problem submitted here, and I'd like to thanks
Johannes for the previous nine solutions to most of my problems. Before
submitting the problem, I'd like to thank him for his work that allowed us
to create something that looks fine and works in a fine way.

My current problem is that the cursor keys (or any other "special" key that
is supposed to act on the cursor) are inserting text characters in the text=
,
making it impossible to correctly move in the edited text. I'm using libufo
in a GLUT context, and I simply pasted my key handling code from the GLUT
sample.

I put a few screenshots online showing both our shiny interface (there are
five of them), and four showing the UTextEdit with cursor problems. These
are available on http://www.lwo-lab.net/nawart.

Code source is available via svn (information is specified on the same
page), and HEAD revision (should be 59) exhibits the problem for sure. I ca=
n
paste specific parts of the sourcecode that may seem relevant to one of you
if requested (either on the list or in private).

Thanks in advance !

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

[Johannes S. <sch...@us...>]

On Sunday 23 April 2006 15:38, Elie `woe` BLETON wrote:
> This is probably my tenth problem submitted here, and I'd like to thanks
> Johannes for the previous nine solutions to most of my problems. Before
> submitting the problem, I'd like to thank him for his work that allowed us
> to create something that looks fine and works in a fine way.

Thanks!

> My current problem is that the cursor keys (or any other "special" key that
> is supposed to act on the cursor) are inserting text characters in the
> text, making it impossible to correctly move in the edited text. I'm using
> libufo in a GLUT context, and I simply pasted my key handling code from the
> GLUT sample.

The bug is in the GLUT-to-UFO conversion of keys.
The third parameter of pushKey{Up,Down} should be 0, e.g.:
void
specialUpFunc(int key, int, int) {
	display->pushKeyUp(context, mapGlutSpecialKey(key), 0);
	if (context->needsRepaint()) {
		glutPostRedisplay();
	}
}
otherwise the key is echoed as char key event.

Thanks for reporting the bug. The developer CVS is already fixed and
it should soon be available via anonymous CVS.


Regards,
Johannes

Re: [UFO-devel] UTextEdit reacting strangely

[Elie `w. B. <dro...@gm...>]

>
> The bug is in the GLUT-to-UFO conversion of keys.
> The third parameter of pushKey{Up,Down} should be 0, e.g.:
> void
> specialUpFunc(int key, int, int) {
>         display->pushKeyUp(context, mapGlutSpecialKey(key), 0);
>         if (context->needsRepaint()) {
>                 glutPostRedisplay();
>         }
> }
> otherwise the key is echoed as char key event.


Note that specialFunc(int key, int, int) AND specialUpFunc(int key, int,
int) have to get patched in the same way in order to correctly solve the
bug.
HOME/END keys are not handled as it seems, but I didn't really looked close=
r
than simply testing the keystrokes.


Thanks for reporting the bug. The developer CVS is already fixed and
> it should soon be available via anonymous CVS.
>
>
Well, thanks for resolving it :)

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

[Elie `w. B. <dro...@gm...>]

Now that cursor keys are corrected, I noticed another error in the
UTextEdit.

If you create a UTextEdit filled with text large enough to fill the box a
few times. Now move the cursor using the key, and change "page". Now select
a position using the mouse. Kablam, the cursor is now at the position under
the mouse, but the text around it is on the first page. It's like cursor
coordinates are calculated with values that are not updated when the cursor
moves.
I'm still using GLUT, but this is reproductible in the "text" test program,
so I guess it's pretty much the same for everyone for that matter.

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

[Johannes S. <sch...@us...>]

Am Montag, 24. April 2006 20:36 schrieb Elie `woe` BLETON:
> Now that cursor keys are corrected, I noticed another error in the
> UTextEdit.
>
> If you create a UTextEdit filled with text large enough to fill the box a
> few times. Now move the cursor using the key, and change "page". Now select
> a position using the mouse. Kablam, the cursor is now at the position under
> the mouse, but the text around it is on the first page. It's like cursor
> coordinates are calculated with values that are not updated when the cursor
> moves.
> I'm still using GLUT, but this is reproductible in the "text" test program,
> so I guess it's pretty much the same for everyone for that matter.

The whole text moving for text widgets is borkened (the problem here is 
probably incorrect focusing with mouse, i.e. the wrong position in the text 
widget is returned when clicking with the mouse ...?).
Perhaps it should be removed in favor of a simple scroll pane ...


Regards,
Johannes

Re: [UFO-devel] UTextEdit reacting strangely

[Elie `w. B. <dro...@gm...>]

Hello there,

Relating to the "mouse click selects crap" problem:
I tried to focus a bit on this problem, and provide some fix. I'm strugglin=
g
to find the problem. The position returned when clicking the mouse is
perfectly correct, but the line is wrong.

I think the problem is in utextlayout.cpp, in method
UTextLayout::viewToModel(pos), since it's iterating on lines from the
beginning of the text.

Offset should be adjusted on the displayed text start instead of the
absolute text start, but isn't for some reason. I wasn't able to find the
displayed text start (should be a "line offset"). If I knew where to find
it, I think I could probably patch this in order to get the mouse selection
work probably.
Please note that the (only) way I change the displayed text start is to add
enough text in the TextEdit, then move the caret down using arrow keys.

I don't understand how the text manages to scroll correctly when the caret
moves. I'm looking for some more insight, since I spent already most of the
day crawling in the code without much success.

Side note: In utextlayout.hpp, line 50, shouldn't "public" be "private".
Writing "public" twice doesn't issue a warning, but what's the point in
writing property-like methods if the members are publicly available.

As always, thanks in advance ...

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

[Johannes S. <sch...@us...>]

Hi Elie,

On Friday 28 April 2006 18:16, Elie `woe` BLETON wrote:
[...]
> Offset should be adjusted on the displayed text start instead of the
> absolute text start, but isn't for some reason. I wasn't able to find the
> displayed text start (should be a "line offset"). If I knew where to find
> it, I think I could probably patch this in order to get the mouse selection
> work probably.
> Please note that the (only) way I change the displayed text start is to add
> enough text in the TextEdit, then move the caret down using arrow keys.

This is entirely done in src/ui/ubasicstyle.cpp
line 873 to 881.
Here, the required offset is computed. But so far, you don't have a way to 
retrieve that value.
I'd really like to remove this piece of code as it's really messy.
Probably a scroll pane should work.
Otherwise an entirely new solution should be considered.

> I don't understand how the text manages to scroll correctly when the caret
> moves. I'm looking for some more insight, since I spent already most of the
> day crawling in the code without much success.
>
> Side note: In utextlayout.hpp, line 50, shouldn't "public" be "private".
> Writing "public" twice doesn't issue a warning, but what's the point in
> writing property-like methods if the members are publicly available.

Thanks.
Well, historically issues (as always). This used to be a struct ...

The text API is still a subject to change ...


Regards,
Johannes

Re: [UFO-devel] UTextEdit reacting strangely

[Elie `w. B. <dro...@gm...>]

>
> in src/ui/ubasicstyle.cpp
> line 873 to 881.
>
> I'd really like to remove this piece of code as it's really messy.
> Probably a scroll pane should work.
> Otherwise an entirely new solution should be considered.
>

I'm not sure of getting all the concept behind UScrollPane completely. I'm
supposing a few things that are possibly all wrong, but please correct me
and provide some more explanation. I'm willing to contribute on this part a=
s
you see fit.

Hacky fix
Considering the bug that annoys me, I think it would be simpler to compute
the offset when it changes and store it as a member of UTextWidget. Which
means that caret movement might impact the offset as needed (I'm not really
sure on how that could be done), so the offending block of code in
ubasicstyle.cpp could be removed.

This solution could be binded to scrollbars via offset manipulation.
Overloading UScrollableWidget methods in UTextWidget to consider the offset
seems reasonable to me.

Scrollpane fix
After looking quickly at the code of uscrollpane.cpp, I'm not really sure o=
n
the way it works. I'm not familiar with the rendering aspect of the problem=
,
nor with the content manipulation of the problem.

Looking at the code I deducted a few things (that, you can translate to "he
didn't understand anything"). Please correct me and enlighten me on the
subject.

   - Scrollpanes are zones that are possibly larger that displayable
   area.
   - Displayed area is manipulable with UScrollPane methods, which
   provides additionnal methods for straight inclusion into other widget, l=
ike
   wheel handling. Special key handling (PG_UP, PG_DOWN, UP/DOWN/LEFT/RIGHT=
)
   doesn't seem to be considered in this part.
   - Scrollpanes are designed to be binded to scrollbars.
   - Scrollpane content is given by providing some UScrollableWidget to
   the constructor.

Looking at morewidgets.cpp (L83), I see that scrollbars are automaticly
added for listboxes.
Adding stuff to the listbox after creating the scrollpane works fine, the
scrollbars continue to work (and are properly resized) with the newly added
items.

This doesn't work for UTextEdit objects for some strange reason : scrollbar=
s
don't appear after typing text. Worse, cursor doesn't move the box if a
scrollpane is used -- which is normal if the "box moving" part is in the
specific drawing code of UTextWidget likes.

I'm eagerly waiting for your feedback before starting my coding night ;)

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

[Johannes S. <sch...@us...>]

Hi Elie,

sorry for the late response. I hope, your coding night was still succesful :)

On Friday 28 April 2006 20:46, Elie `woe` BLETON wrote:
> > in src/ui/ubasicstyle.cpp
> > line 873 to 881.
> >
> > I'd really like to remove this piece of code as it's really messy.
> > Probably a scroll pane should work.
> > Otherwise an entirely new solution should be considered.
>
> I'm not sure of getting all the concept behind UScrollPane completely. I'm
> supposing a few things that are possibly all wrong, but please correct me
> and provide some more explanation. I'm willing to contribute on this part
> as you see fit.

Some general comments:
The scroll pane is merely a container for a viewport and scroll bars.
The viewport is able to show only a part of a widget which is larger than the 
viewport itsself (which is simply done by adding this widget as child, moving 
it to negative position and clipping at the bounds of the viewport).
In ascii art:

(-x, -y)
	----------------
	|  (0,0)____   | 
	|       |xx|   |
	|       |xx|   |
	|       |__|   | 
	|              |
	----------------
viewport is inner rect, (scrollable) widget is outer rect
Only the part marked with xx is visible.
Moving the "view bounds" means in fact moving the scrollable widget
which is kinda below the viewport.


UViewport provides a stub (not yet implemented) to make sure that a specific 
rectangle is visible in the viewport.
One way would be to call UViewport::scrollRectToVisible(URectangle) after 
every movement of the text caret.

> Hacky fix
> Considering the bug that annoys me, I think it would be simpler to compute
> the offset when it changes and store it as a member of UTextWidget. Which
> means that caret movement might impact the offset as needed (I'm not really
> sure on how that could be done), so the offending block of code in
> ubasicstyle.cpp could be removed.
>
> This solution could be binded to scrollbars via offset manipulation.
> Overloading UScrollableWidget methods in UTextWidget to consider the offset
> seems reasonable to me.
>
> Scrollpane fix
> After looking quickly at the code of uscrollpane.cpp, I'm not really sure
> on the way it works. I'm not familiar with the rendering aspect of the
> problem, nor with the content manipulation of the problem.
>
> Looking at the code I deducted a few things (that, you can translate to "he
> didn't understand anything"). Please correct me and enlighten me on the
> subject.
>
>    - Scrollpanes are zones that are possibly larger that displayable
>    area.
yes.
>    - Displayed area is manipulable with UScrollPane methods, 
Which delegate it to the viewport.

>    which 
>    provides additionnal methods for straight inclusion into other widget,
> like wheel handling. Special key handling (PG_UP, PG_DOWN, 
> UP/DOWN/LEFT/RIGHT) doesn't seem to be considered in this part.

Not yet ... :)

>    - Scrollpanes are designed to be binded to scrollbars.
Desigend .. but you do not have to use them.

>    - Scrollpane content is given by providing some UScrollableWidget to
>    the constructor.

Yes (with some UViewport magic behind).

> Looking at morewidgets.cpp (L83), I see that scrollbars are automaticly
> added for listboxes.

As long as you add it to a scroll pane.

> Adding stuff to the listbox after creating the scrollpane works fine, the
> scrollbars continue to work (and are properly resized) with the newly added
> items.
>
> This doesn't work for UTextEdit objects for some strange reason :
> scrollbars don't appear after typing text. 
This is because it isn't derived from UScrollableWidget (probably).

> Worse, cursor doesn't move the 
> box if a scrollpane is used -- which is normal if the "box moving" part is
> in the specific drawing code of UTextWidget likes.

Should probably be done using UViewport::scrollRectToVisible(URectangle) ...


Regards,
Johannes