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