Possible issue with tree+textarea redraw?

Michael Drake tlsa at netsurf-browser.org
Tue Mar 9 14:42:18 GMT 2010

I've done some updates on the treeview branch.  Changes were mostly to
improve the treeview's behaviour a bit.  I also added support for drags to
the RISC OS front end.


Does the drag change look OK?  It works for drags on the hotlist, which
uses the mouse_at function in treeview.c.  The history and cookie manager
use their own mouse_at functions, so they aren't fixed.  I'm not sure if
there was a reason for them using different mouse tracking functions.

Also, drags still don't seem to terminate correctly in textareas when you
do an edit in the hotlist (on RISC OS).  I remember that there was some
issue with tree origin and textareas.  Could it be related to that?

The browser window core code informs the front end how a drag has been
interpreted, so that the front end can do something specific for it. 
Maybe we need that for the treeview code too?  So that dragging a
selection shows the "marching ant" selection box, dragging a hotlist entry
shows that something is being moved and text selection drags would do

The recent URL thing was removed when the global history stuff was moved
to the core, so the gright menu icon next to the URL bar in the RISC OS
front end could be removed now.

In order to make use of desktop filetype sprites for tree icons, the core
would need to be altered to ask the front ends for bitmap structures,
rather than content structures.  Otherwise we can use the PNGs exactly
like the GTK front end does.


Edits to titles in the hotlist are forgotten after NetSurf quits (as noted
by Chris).

In desktop/tree.c tree_mouse_action() at line 1577 we have "scroll to the
bottom element then back to the top".  I'm not sure why we're doing that. 
Should the core treeview code not just have some way of telling the front
end that the extents of the tree have changed?

When you edit an entry and the textarea appears, it increases the width of
the tree.  (A horizontal scrollbar appears on nsgtk).  I think that should
be avoided.

The textarea widget draws its own caret, instead of using the OS caret. 
If you look at the old textinput code, you can see it uses an OS caret. It
gets redrawn by the front end, after NetSurf's redraw is done.  The
textarea widget should also use the front end caret.  Using the OS caret
can be important e.g. for ensuring that the window gets input focus, and
so that it looks the same everywhere on the desktop.

Best regards,



Michael Drake (tlsa)                  http://www.netsurf-browser.org/

More information about the netsurf-dev mailing list