6:47 a.m.
As it's probably more relevant to folk here than on the users list, I've put
a Todo list up on the Wiki covering the RISC OS frontend: specifically (at
present) the outstanding work and issues in the core treeview branch WRT
RISC OS.
http://wiki.netsurf-browser.org/Todo/RISC_OS_frontend
It covers the items in my own list that I was maintaining here, and it's
almost certainly incomplete: comments, amendments, additions welcome. I'm
finding that I didn't use several affected areas of the browser that much,
so there will be things (like URL Suggest) that I've overlooked or got wrong
in re-implementation.
I'm hoping that I should have some more free time available for NetSurf now
that Wakefield is out of the way, so with any luck I'll be able to start
working through the items on the list again.
Now that 2.5 is out of the way, what is the plan for the branch and is there
any firm timescale set for when it will be merged?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
7:02 a.m.
On Mon, 26 Apr 2010 22:47:01 +0100, Steve Fryatt wrote:
As it's probably more relevant to folk here than on the users
list, I've put
a Todo list up on the Wiki covering the RISC OS frontend: specifically (at
present) the outstanding work and issues in the core treeview branch WRT
RISC OS.
http://wiki.netsurf-browser.org/Todo/RISC_OS_frontend
A couple of those need implementing in the Amiga frontend code too
IIRC:
--8<--
Drags on treeview nodes need to gain an icon to drag, to indicate
that a drag is in progress and make it clear to the user that there is
something to drop.
Drags on treeview nodes need to utilise AutoScroll when available.
--8<--
The first of these - obviously the icon displaying bit is frontend,
but ideally we need a line drawn on to show where the item is going to
be dropped, which probably ought to go in the core (the frontend has
no knowledge of where the gaps between lines are anyway).
The second I hadn't actually thought about.
There was another one relating to dragging which has been mentioned
before - drag-selection boxes (bounding boxes, crawling ants or
whatever you want to call them) need implementing. My opinion is that
along with the line indicating where an item is being dropped, the
drag-select box should also be drawn by the core. Have you added such
a thing to the RISC OS frontend code?
Chris
7:58 a.m.
On 26 Apr, Chris Young wrote in message
<OUT-4BD61BA3.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>:
On Mon, 26 Apr 2010 22:47:01 +0100, Steve Fryatt wrote:
> http://wiki.netsurf-browser.org/Todo/RISC_OS_frontend
A couple of those need implementing in the Amiga frontend code too IIRC:
--8<--
Drags on treeview nodes need to gain an icon to drag, to indicate that a
drag is in progress and make it clear to the user that there is something
to drop.
Drags on treeview nodes need to utilise AutoScroll when available.
--8<--
The first of these - obviously the icon displaying bit is frontend, but
ideally we need a line drawn on to show where the item is going to be
dropped, which probably ought to go in the core (the frontend has no
knowledge of where the gaps between lines are anyway).
That makes sense, I think.
The second I hadn't actually thought about.
This is part of the RISC OS drag API, so I had assumed it would fall to the
front-end to handle. There's no reason why the core couldn't do it, I
suppose -- it could work through the scroll_visible callback.
There was another one relating to dragging which has been mentioned
before
- drag-selection boxes (bounding boxes, crawling ants or whatever you want
to call them) need implementing. My opinion is that along with the line
indicating where an item is being dropped, the drag-select box should also
be drawn by the core. Have you added such a thing to the RISC OS frontend
code?
Not yet: the whole user-facing part of the treeview drags leave a lot to be
desired in the new RO frontend at present.
I think this would have to be partly handled by the core, at least, because
as with the drop-line, I don't think we know whether the mouse drag starts
over a node or the space between nodes. We would also have to know which
nodes fell into the resulting drag area, so as to select, deselect or toggle
them.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
3:06 a.m.
On Mon, 26 Apr 2010 23:58:27 +0100, Steve Fryatt wrote:
We would also have to know which
nodes fell into the resulting drag area, so as to select, deselect or toggle
them.
The core already handles that bit. I can drag an (invisible) box
around a number of items and they will be selected.
Chris
6:56 a.m.
In article <mpro.l1iahf04r94g003qb.lists(a)stevefryatt.org.uk>,
Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
On 26 Apr, Chris Young wrote in message
<OUT-4BD61BA3.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>:
> > Drags on treeview nodes need to gain an icon to drag, to
indicate
> > that a drag is in progress and make it clear to the user that there
> > is something to drop.
> The first of these - obviously the icon displaying bit is
frontend, but
> ideally we need a line drawn on to show where the item is going to be
> dropped, which probably ought to go in the core (the frontend has no
> knowledge of where the gaps between lines are anyway).
I agree.
> There was another one relating to dragging which has been
mentioned
> before - drag-selection boxes (bounding boxes, crawling ants or
> whatever you want to call them) need implementing. My opinion is that
> along with the line indicating where an item is being dropped, the
> drag-select box should also be drawn by the core.
Yes, I agree that drawing it in the core would be simplest.
I think this would have to be partly handled by the core, at least,
because as with the drop-line, I don't think we know whether the mouse
drag starts over a node or the space between nodes. We would also have
to know which nodes fell into the resulting drag area, so as to select,
deselect or toggle them.
I think once a treeview drag starts, the core needs to tell the front end
how the drag has been interpreted, like the browser window drag code.
This way the front end can tell if the drag is a selection drag or a node
drag. If the latter, the front end would show the icon to indicate
something's being dragged.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
6:38 a.m.
In article <mpro.l1i76d02bcgz403qb.lists(a)stevefryatt.org.uk>,
Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
As it's probably more relevant to folk here than on the users
list, I've
put a Todo list up on the Wiki covering the RISC OS frontend:
specifically (at present) the outstanding work and issues in the core
treeview branch WRT RISC OS.
That's useful, thanks.
Now that 2.5 is out of the way, what is the plan for the branch and
is
there any firm timescale set for when it will be merged?
There's no firm deadline, but I'd like to get it merged to trunk sooner
rather than later.
The new cache changes will probably have caused some conflicts with trunk.
Could someone merge the trunk changes into the core treeview branch?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
4894
days inactive
4897
days old
netsurf-dev@netsurf-browser.org
5 comments
3 participants
participants (3)
-
Chris Young -
Michael Drake -
Steve Fryatt