7:39 a.m.
The core treeview code behaves a bit better now. The main improvements
are to mouse input handling, textarea editing and tree rendering.
The GTK and RISC OS front ends passing of browser_mouse_state has also
been fixed for various faults. I believe Chris has updated the Amiga
front end's browser_mouse_state setup too.
There are still some remaining issues. Key ones are:
CORE1: The core now supports arbitrary line heights, but this is
currently set to a fixed 20px instead of being based on the
font size. This is because in the GTK front end, the desktop
dpi is not available at the time the trees are initialised and
generated at startup. See GTK1.
CORE2: Selected nodes aren't updated as you drag.
CORE3: The core draws its own caret instead of calling the front end
to draw its own caret.
CORE4: The path to the icon directory is stored in a Choices option.
If this gets saved to the Choices file, and the location
of the icons changes, it will never find them and there is no
way to update the option. Maybe it should use the resources
path and add the icons sub directory to that or something.
RISC OS1: If you start editing a hotlist entry by selecting it and then
using the Selection > Edit menu, if you press the SHIFT key, it
ends the edit as if you'd pressed escape. If you type some
text before pressing SHIFT, it behaves correctly. The core
does not seem to get given the SHIFT keypress when it fails.
I don't know enough about RISC OS to know what might be
happening here. If you start the edit by CTRL+Clicking or
ALT+Clicking the text, SHIFT behaves correctly.
RISC OS2: While editing text in a treeview textarea, text selection
drag redraws are a bit broken. This could well be the core,
but it works on the GTK front end.
GTK1: The GTK front end doesn't set up the dpi until a browser window
is opened. The treeview code needs it when its initialised,
which happens before this.
With respect to NetSurf 2.7 release, my evaluation is:
NetSurf 2.7 Blockers:
+ RISC OS1
NetSurf 2.7 Blockers if not too difficult
+ GTK1
+ CORE1 (trivial, after GTK1 is done)
+ CORE4
Any comments?
If GTK1 is fixed, I'll fix CORE1. I will also do CORE2 if it doesn't look
like too much work.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
9:17 a.m.
In article <5187088891tlsa(a)netsurf-browser.org>,
Michael Drake <tlsa(a)netsurf-browser.org> wrote:
NetSurf 2.7 Blockers:
+ RISC OS1
NetSurf 2.7 Blockers if not too difficult
+ GTK1
+ CORE1 (trivial, after GTK1 is done)
+ CORE4
GTK1 done by Rob.
CORE1 done.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
12:23 p.m.
On 17 Dec, Michael Drake wrote in message
<5187088891tlsa(a)netsurf-browser.org>:
CORE3: The core draws its own caret instead of calling the front
end
to draw its own caret.
Is there a way for the core to ask a front-end to plot a caret? I couldn't
see one, but may have been looking in the wrong places.
RISC OS1: If you start editing a hotlist entry by selecting it and
then
using the Selection > Edit menu, if you press the SHIFT key,
it ends the edit as if you'd pressed escape. If you type some
text before pressing SHIFT, it behaves correctly. The core
does not seem to get given the SHIFT keypress when it fails.
I don't know enough about RISC OS to know what might be
happening here. If you start the edit by CTRL+Clicking or
ALT+Clicking the text, SHIFT behaves correctly.
I think the mouse drag code was passing in spurious Alt-, Ctrl- and Shift-
mouse events even when there was no drag in progress. As long as the
pointer was over the active text box, this went unnoticed.
Should be fixed in 11090; hopefully the change hasn't broken anything else,
given my limited grasp of the core mouse stuff.
I'll look into RISC OS2 when I get chance.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
1:15 p.m.
In article <mpro.ldl1my01wn2c001a0.lists(a)stevefryatt.org.uk>,
Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
On 17 Dec, Michael Drake wrote in message
<5187088891tlsa(a)netsurf-browser.org>:
> CORE3: The core draws its own caret instead of calling the front
> end to draw its own caret.
Is there a way for the core to ask a front-end to plot a caret? I
couldn't see one, but may have been looking in the wrong places.
The browser window code does it for forms. browser_window_place_caret()
in desktop/textinput.c calls gui_window_place_caret(). And there's
another to remove the caret. The desktop/textinput module is for html form
code. The desktop/textarea module is used in treeviews and it currently
draws its own caret.
I think the mouse drag code was passing in spurious Alt-, Ctrl- and
Shift- mouse events even when there was no drag in progress. As long as
the pointer was over the active text box, this went unnoticed.
Should be fixed in 11090; hopefully the change hasn't broken
anything
else, given my limited grasp of the core mouse stuff.
Cool, thanks! Seems to be working fine. :)
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
5:20 a.m.
On 17 Dec, Michael Drake wrote in message
<5187274ee9tlsa(a)netsurf-browser.org>:
In article <mpro.ldl1my01wn2c001a0.lists(a)stevefryatt.org.uk>,
Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
> Is there a way for the core to ask a front-end to plot a caret? I
> couldn't see one, but may have been looking in the wrong places.
The browser window code does it for forms. browser_window_place_caret()
in desktop/textinput.c calls gui_window_place_caret(). And there's
another to remove the caret.
Thanks -- I was looking in the wrong places. For some reason, I'd assumed
it might fall into a graphics/plotters kind of area.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
1:40 p.m.
On Fri, 17 Dec 2010 17:23:22 +0000, Steve Fryatt wrote:
> RISC OS1: If you start editing a hotlist entry by selecting it
and then
> using the Selection > Edit menu, if you press the SHIFT key,
> it ends the edit as if you'd pressed escape. If you type some
> text before pressing SHIFT, it behaves correctly. The core
> does not seem to get given the SHIFT keypress when it fails.
> I don't know enough about RISC OS to know what might be
> happening here. If you start the edit by CTRL+Clicking or
> ALT+Clicking the text, SHIFT behaves correctly.
I think the mouse drag code was passing in spurious Alt-, Ctrl- and Shift-
mouse events even when there was no drag in progress. As long as the
pointer was over the active text box, this went unnoticed.
I'm confused. When the pointer exits the text edit area, the edit
gets cancelled here. Is this what you were seeing on the RISC OS
build? Or is it supposed to do that (seems a bit weird)?
Chris
1:51 p.m.
In article
<OUT-4D0BAEA5.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
I'm confused. When the pointer exits the text edit area, the
edit
gets cancelled here. Is this what you were seeing on the RISC OS
build? Or is it supposed to do that (seems a bit weird)?
It's not supposed to do that, and it doesn't on RISC OS or GTK.
How are you starting the edit? Via a [ctrl or alt]+click or via a menu
option to edit the selected node?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
2:01 p.m.
On Fri, 17 Dec 2010 18:51:20 +0000 (GMT), Michael Drake wrote:
In article
<OUT-4D0BAEA5.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
> I'm confused. When the pointer exits the text edit area, the edit
> gets cancelled here. Is this what you were seeing on the RISC OS
> build? Or is it supposed to do that (seems a bit weird)?
It's not supposed to do that, and it doesn't on RISC OS or GTK.
How are you starting the edit? Via a [ctrl or alt]+click or via a menu
option to edit the selected node?
[Ctrl or Alt]-click
I don't have a menu option to start edits (should probably add one
though).
Chris
8:04 a.m.
On 17 Dec, Chris Young wrote in message
<OUT-4D0BAEA5.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>:
I'm confused. When the pointer exits the text edit area, the
edit gets
cancelled here. Is this what you were seeing on the RISC OS build?
Not quite. The RO treeview mouse drag code was setting the modifier key
bits of the core mouse state whenever they were pressed, even if there was
no mouse button activity, and passing the resulting non-clicks to
tree_mouse_action().
If the 'click' was outside the textarea, tree_mouse_action() seems to end
the edit unconditionally. Looking at it, I'm not sure if it should be more
choosy about this or not.
Or is it supposed to do that (seems a bit weird)?
I don't /think/ so.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
12:04 p.m.
On Sat, 18 Dec 2010 13:04:15 +0000, Steve Fryatt wrote:
On 17 Dec, Chris Young wrote in message
<OUT-4D0BAEA5.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>:
> I'm confused. When the pointer exits the text edit area, the edit gets
> cancelled here. Is this what you were seeing on the RISC OS build?
Not quite. The RO treeview mouse drag code was setting the modifier key
bits of the core mouse state whenever they were pressed, even if there was
no mouse button activity, and passing the resulting non-clicks to
tree_mouse_action().
If the 'click' was outside the textarea, tree_mouse_action() seems to end
the edit unconditionally. Looking at it, I'm not sure if it should be more
choosy about this or not.
I've fixed it now, but it was more-or-less caused by the same bug
(sending mouse events when no butons were pressed)
Chris
1:50 p.m.
On Fri, 17 Dec 2010 12:39:03 +0000 (GMT), Michael Drake wrote:
The core treeview code behaves a bit better now. The main
improvements
are to mouse input handling, textarea editing and tree rendering.
The GTK and RISC OS front ends passing of browser_mouse_state has also
been fixed for various faults. I believe Chris has updated the Amiga
front end's browser_mouse_state setup too.
Yes, I checked them after seeing your commits and added double-clicks
to the mouse events for browser windows, and middle-button
double-clicks to treeviews.
There might be a problem somewhere though, see my other message.
CORE1: The core now supports arbitrary line heights, but this
is
currently set to a fixed 20px instead of being based on the
font size. This is because in the GTK front end, the desktop
dpi is not available at the time the trees are initialised and
generated at startup. See GTK1.
Is the text size within treeview going to be picked up from NetSurf's
default text size (or an adjustment thereof)?
With respect to NetSurf 2.7 release
I didn't know there was going to be a 2.7 release :) But that's
probably my fault for not hanging around IRC.
Chris
1:59 p.m.
In article
<OUT-4D0BB0F7.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Fri, 17 Dec 2010 12:39:03 +0000 (GMT), Michael Drake wrote:
There might be a problem somewhere though, see my other message.
Try calling browser_mouse_state_dump() at the top of the
tree_mouse_action() function in desktop/tree.c. If you start an edit,
move the pointer out the edit area and find out what's logged, it might
shed some light.
Is the text size within treeview going to be picked up from
NetSurf's
default text size (or an adjustment thereof)?
At the moment, it just uses a hard coded default of 11pt.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
2:48 p.m.
On Fri, 17 Dec 2010 18:59:29 +0000 (GMT), Michael Drake wrote:
In article
<OUT-4D0BB0F7.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
> On Fri, 17 Dec 2010 12:39:03 +0000 (GMT), Michael Drake wrote:
> There might be a problem somewhere though, see my other message.
Try calling browser_mouse_state_dump() at the top of the
tree_mouse_action() function in desktop/tree.c. If you start an edit,
move the pointer out the edit area and find out what's logged, it might
shed some light.
Loads of blanks, except:
(19.834372) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.836845) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.852678) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.869620) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.876669) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.883726) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.903924) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
M2
(19.911971) content/llcache.c llcache_clean 1613: Attempting cache clean
(19.918947) content/llcache.c llcache_clean 1683: Size: 155979
(20.200233) desktop/mouse.c browser_mouse_state_dump 46: mouse state: P1
M2
(20.270057) desktop/mouse.c browser_mouse_state_dump 46: mouse state: P1
M2
(20.278605) desktop/mouse.c browser_mouse_state_dump 46: mouse state: C1
M2
(21.61202) desktop/mouse.c browser_mouse_state_dump 46: mouse state:
...which suggests I've clicked the mouse whilst holding modifier 2
(which is exactly what I have done).
There are two instances of P1 which I don't think is right, but
neither would I expect a spurious press at that stage to cause this
problem.
Any ideas?
Chris
2:59 p.m.
In article
<OUT-4D0BBE88.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
Loads of blanks, except:
mouse state: M2
mouse state: M2
mouse state: M2
mouse state: M2
mouse state: M2
mouse state: M2
mouse state: M2
mouse state: P1 M2
mouse state: P1 M2
mouse state: C1 M2
mouse state:
...which suggests I've clicked the mouse whilst holding modifier
2
(which is exactly what I have done).
There are two instances of P1 which I don't think is right, but
neither would I expect a spurious press at that stage to cause this
problem.
Any ideas?
You should only pass modifiers when there is also other actual mouse
action. So you should never get M2 (or M1 or M3) on its own.
Also, I'm concerned about "Loads of blanks". You shouldn't get any
blanks. If the mouse isn't clicking or dragging the treeview shouldn't be
informed about it.
And yeah, the two presses is wrong. You should get just:
mouse state: P1 M2
mouse state: C1 M2
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
3:33 p.m.
On Fri, 17 Dec 2010 19:59:42 +0000 (GMT), Michael Drake wrote:
You should only pass modifiers when there is also other actual mouse
action. So you should never get M2 (or M1 or M3) on its own.
Also, I'm concerned about "Loads of blanks". You shouldn't get any
blanks. If the mouse isn't clicking or dragging the treeview shouldn't be
informed about it.
And yeah, the two presses is wrong. You should get just:
mouse state: P1 M2
mouse state: C1 M2
Fixed all those, now working - thanks.
I copied the mouse code from the main browser version, which tracks
the mouse when no buttons are pressed, hence the blanks fault.
Chris
8:28 a.m.
On 17 Dec, Chris Young wrote in message
<OUT-4D0BB0F7.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>:
On Fri, 17 Dec 2010 12:39:03 +0000 (GMT), Michael Drake wrote:
> With respect to NetSurf 2.7 release
I didn't know there was going to be a 2.7 release :) But that's probably
my fault for not hanging around IRC.
Me neither, probably for the same reasons. :-)
Is there any info on this (particularly timescales)?
I had an idea that I might try and reorganise the RO frontend's toolbar code
with a view to finishing off the treeview stuff in a more elegant way than
currently seems possible. If we're working towards producing a stable
release, however, making big changes to the way that key bits of the RO GUI
work might not be such a good idea just now.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
9:20 a.m.
In article <mpro.ldog3606vxr5s019u.lists(a)stevefryatt.org.uk>,
Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
On 17 Dec, Chris Young wrote in message
<OUT-4D0BB0F7.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>:
> I didn't know there was going to be a 2.7 release :)
Is there any info on this (particularly timescales)?
Nothing definite. It was first mentioned when we met up to do some
development on 4th/5th Dec. I think it was said that the GTK front end
needs a new release. I don't think it will happen until an important
LibCSS change has landed and been tested thoroughly.
I had an idea that I might try and reorganise the RO frontend's
toolbar
code with a view to finishing off the treeview stuff in a more elegant
way than currently seems possible.
Cool.
If we're working towards producing a stable release, however,
making big
changes to the way that key bits of the RO GUI work might not be such a
good idea just now.
OK, I'll try to find out if there's any consensus on when we want to do
the next release. In the mean time, you can always do major changes on a
branch any time you like, and then merge the branch to trunk.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
7:04 p.m.
On 19 Dec, Michael Drake wrote in message
<5188198728tlsa(a)netsurf-browser.org>:
In the mean time, you can always do major changes on a branch any
time you
like, and then merge the branch to trunk.
That's probably the best plan.
As I've not done this before with NetSurf, can I just check the process (and
apologies if I've overlooked something on the website or Wiki)? Presumably
I can just create myself a named folder in the repository under branches/
and then take a copy of trunk/netsurf/ into that with a suitable name?
Thinking ahead slightly: what tools do you use to merge changes (from trunk
to branch or, ultimately, vice versa)? I tried experimenting on a local
copy of the old treeview branch a while back, and IIRC I found that it
didn't seem to work in the way I'm familiar with from within subversion.
Google lead me to svnmerge, but I wasn't sure if it was taking me in the
right direction or not.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
7:36 p.m.
In message <mpro.ldr47r09b2yz401b0.lists(a)stevefryatt.org.uk>
Steve Fryatt <lists(a)stevefryatt.org.uk> wrote:
As I've not done this before with NetSurf, can I just check the
process (and
apologies if I've overlooked something on the website or Wiki)? Presumably
I can just create myself a named folder in the repository under branches/
and then take a copy of trunk/netsurf/ into that with a suitable name?
Thinking ahead slightly: what tools do you use to merge changes (from trunk
to branch or, ultimately, vice versa)? I tried experimenting on a local
copy of the old treeview branch a while back, and IIRC I found that it
didn't seem to work in the way I'm familiar with from within subversion.
Google lead me to svnmerge, but I wasn't sure if it was taking me in the
right direction or not.
svnmerge was in use when svn itself didn't have any merge capabilities
(pre v1.5 I believe) and shouldn't be use anymore.
Cfr. svnbook at http://svnbook.red-bean.com/, more specifically
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
John.
--
John Tytgat
joty(a)netsurf-browser.org
5:19 p.m.
On 21 Dec, John Tytgat wrote in message
<23b7d58851.Jo(a)hobbes.bass-software.com>:
svnmerge was in use when svn itself didn't have any merge
capabilities
(pre v1.5 I believe) and shouldn't be use anymore.
Cfr. svnbook at http://svnbook.red-bean.com/, more specifically
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
Thanks for confirming that. I've used svn for merging branches on other
repositories without problems, but IIRC I couldn't get it to work on the
NetSurf branch I tried it with a while back.
At the time it wasn't essential, and by the time I had looked into it the
need had passed anyway. I'll have another read of the manual now I know it
/should/ work, and will come back with more useful requests for help should
it not behave again if/when I actually need to use it.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
12:52 p.m.
New subject: SVN Problems (was Treeview status)
On 21 Dec, Steve Fryatt wrote in message
<mpro.ldsu0y01s0iyo01fy.lists(a)stevefryatt.org.uk>:
On 21 Dec, John Tytgat wrote in message
<23b7d58851.Jo(a)hobbes.bass-software.com>:
> svnmerge was in use when svn itself didn't have any merge capabilities
> (pre v1.5 I believe) and shouldn't be use anymore.
Thanks for confirming that. I've used svn for merging branches on other
repositories without problems, but IIRC I couldn't get it to work on the
NetSurf branch I tried it with a while back.
I've gone back to this, and found the issue that I think I remember hitting
last time. The working copy I've got is of /branches/stevef/toolbars, which
in turn was a copy of /trunk/netsurf.
On that basis, svnbook suggests that I should be able to do
$ svn merge ^/trunk/netsurf
from my working copy directory and it will try to bring in any changes made
to the trunk since the branch was taken: which should be since r11119.
However, it actually results in
$ svn merge ^/trunk/netsurf --dry-run
--- Merging r2 through r2504 into '.':
...and a fair few conflicts...
--- Merging r2505 through r11269 into '.':
...and even more conflicts...
Summary of conflicts:
Text conflicts: 49
Tree conflicts: 253
Skipped paths: 5
A lot of the proposed changes look as if they're trying to restore things
that have long since been deleted or moved somewhere else, and it seems to
be trying to change files that I don't think it should be (based on watching
the commits that have been made since I took the branch).
If I try to use megrgeinfo to see what svn thinks it needs to check, I get
svn mergeinfo ^/trunk/netsurf --show-revs eligible
svn: Retrieval of mergeinfo unsupported by '.'
Presumably I've missed some vital step somewhere, although Chapter 4 of the
SVN Book doesn't make it obvious what -- the procedure described for
branching and merging seems to be what I'm following. I've certainly made
it work on a local repository before: same client, a 1.6-something server
and a much simpler set of changes to merge (perhaps I was just lucky on
those occasions).
I'm running the svn client 1.6.6, on Ubuntu 10.04 (this isn't on RISC OS).
Googling the errors seems to point towards client/server version
mis-matches.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 16 April 2011
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
4525
days inactive
4548
days old
netsurf-dev@netsurf-browser.org
20 comments
4 participants
participants (4)
-
Chris Young -
John Tytgat -
Michael Drake -
Steve Fryatt