On 9 Mar, Michael Drake wrote in message
<[email protected]>:
> 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.
Thanks for that. I've not had chance to play with the updates yet, but will
have a look when I get time; it might not be this week, though.
> 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?
Could be. I'll have a look at the scroll_visible callback then, too -- I
certainly wouldn't rule out the possibility that I've got the offset
calculations wrong somewhere.
> 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.
Ah. Was this intentional (and there's no easy way to re-implement it), or
is the missing-ness just the fact that I've commented out the relevant code?
Just for completeness, I'm still aware that I need to work on:
-- SSL certificates (in progress, but things keep coming up this week to get
in the way :-),
-- Toolbars in all of the treeview windows. I'm thinking about this, as I
would prefer to modularise it a bit more than it currently seems to be.
AFAICT, the current implementation would require themes.c to know about the
innards of the three tree-dependent modules, which is at odds with the way
everything else has been done. As a result, I was leaving this to the end,
and thinking around the problem in the meantime (not least as I'm still
learning new things about the toolbar code every time I look at it).
-- Bits like the recent URL completion, that need revisiting and either
fixing or removing. A grep of the source for \sf should find these, as I
tagged them when commenting out so that I could find them again.
-- Edit dialogue boxes in the hotlist. I can't see any hooks in the core to
make these work, which is why I'd removed them for the time being. Is this
something else that might need adding back into the core, or have I just
missed the interface?
There may be more odds and ends, too. I haven't got the sources open in
front of me at the moment. I know that mouse and keyboard interfaces to the
treeview still need a bit of work (although I think your mods today have
done some of that).
> 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.
I haven't been able to make the PNGs work yet, unfortunately. It's probably
something fundamental that I'm not understanding, but so far I can't make
anything display. Having tried the various forms of URL suggested here, I
get the following appearing in the log file at startup
content/fetchcache.c fetchcache 154: url
file:///NetSurf:/Resources/Icons/directory.png
content/content.c content_create 409: url
file:///NetSurf:/Resources/Icons/directory.png -> 0x259eeac8
content/content.c content_add_user 1157: content
file:///NetSurf:/Resources/Icons/directory.png (0x259eeac8), user 0x3a3e8
0x0 0x0
content/fetchcache.c fetchcache_go 260: url
file:///NetSurf:/Resources/Icons/directory.png, status TYPE_UNKNOWN
but no images in the treeview itself. If I put one of the URLs into the
address bar of the browser, the image displays fine.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
