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.
Steve: 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 neither? 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. Paul: 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 -- Michael Drake (tlsa) http://www.netsurf-browser.org/
