NetSurf on ARMv7 platforms
by John-Mark Bell
Afternoon,
So, NetSurf runs mostly ok on ARMv7 platforms with their backwards
incompatible unaligned LDR behaviour turned on. Tinct, however, appears
to perform some LDRs from unaligned addresses, resulting in crashes.
Here's a backtrace:
> Fatal signal received: Segmentation fault
>
> Stack backtrace:
>
> Running thread 0x59e53c
> ( 5a7ee0) pc: 462860 lr: 74f4c sp: 5a7ee4 __write_backtrace()
> ( 5a7f10) pc: 74d64 lr: 463298 sp: 5a7f14 ^ro_gui_signal()
> ( 5a7f38) pc: 463288 lr: 462f58 sp: 5a7f3c __unixlib_exec_sig()
> ( 5a7fa0) pc: 462a18 lr: 463870 sp: 5a7fa4 __unixlib_raise_signal()
> ( 5a7fb0) pc: 463774 lr: 5a6c48 sp: 5a6c04 __h_cback()
>
> Register dump at 005a7fb4:
>
> a1: 12f a2: 2d a3: 1f4 a4: 0
> v1: 0 v2: 0 v3: 202513b4 v4: 1
> v5: 3d5 v6: 0 sl: 41b78d39 fp: 67197124
> ip: 20248394 sp: 5a6c04 lr: 5a6c48 pc: 2024609c
> cpsr: 80000113
>
> 20246088 : .p.â : e21a7003 : ANDS R7,R10,#3
> 2024608c : .... : 0a000008 : BEQ &202460B4
> 20246090 : .àgâ : e267e003 : RSB R14,R7,#3
> 20246094 : ..^á : e15e0000 : CMP R14,R0
> 20246098 : .à Á : c1a0e000 : MOVGT R14,R0
> 2024609c : .??å : e59a9000 : LDR R9,[R10,#0]
> 202460a0 : ..@Ð : d040000e : SUBLE R0,R0,R14
> 202460a4 : ..?Ò : d2800003 : ADDLE R0,R0,#3
> 202460a8 : ..?À : c0800007 : ADDGT R0,R0,R7
>
> Invalid pc address bebeec
For reference, Tinct is loaded at 202416B4.
J.
13 years, 6 months
NetSurf hack weekend
by Daniel Silverstone
Greetings,
We agreed on IRC that we needed a hack weekend in order to get the last bits
finished for the 2.5 release. Since that needs to be out by the Wakefield
show; I suggest we ought to be having our hack weekend at least a month before
the show to allow for final twiddles, zip rolling, CD image prep, artwork,
press releases etc.
As such, I am proposing the weekend of the 27/28 March. I am prepared to host,
providing I'm not having to supply sleeping area to more than two people
(unless two of them are prepared to share the sofabed :-) -- Thusly arrival on
26th and departure on 29th is possible too.
Who is interested in attending and will they need accomodating?
Myself and Rob will obviously be here already, and I think at worst Vincent can
come across on the train for a day.
Also, we need a full list of the work remaining before 2.5 can be released.
My understanding of what remains code-wise is:
1. Cache rework
2. Hubbub up-to-spec
3. Hubbub interning strings with wapcaplet
4. refactor cmdline processing into core
If there's other things; please follow up to this thread with them.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
13 years, 8 months
Possible issue with tree+textarea redraw?
by Steve Fryatt
I've hit a problem with the redraw of trees containing a textarea in the
RISC OS front-end, while working on /branches/paulblokus/treeview (ie. the
core treeview stuff). I think the issue lies in the core, but since I'm not
that familiar with it, it would be useful if someone else could verify what
follows before any changes get made. I'm certainly not discounting the
possibility that I've got the RISC OS redraw code wrong. :-)
Both of the commits I've made (10068 and 10056) have a bug whereby textareas
in trees (created when an edit is started with a Ctrl-Click) don't show up
on screen unless the entire window is redrawn (when the graphics clip area
is clearly "big" compared to the text area itself).
The problem only shows up if the tree is drawn at a location in the window
other than (0,0), and the cause seems to be that the tree origin isn't
correctly being taken into account when positioning the textarea. If the
origin isn't (0,0), then the rubout box drawn in tree_draw() appears in the
correct place, but the textarea itself seems to be placed as if the origin
was (0,0) -- that is, the origin passed to tree_draw() isn't taken into
account.
The fact that the initial rubout box always ends up in the correct place
makes me suspect that I'm passing the correct coordinates through to
tree_draw().
Looking at the code in tree_draw() (inside desktop/tree.c), my suspicion is
that the problem lies in the call to textarea_redraw() at the end of
the function:
textarea_redraw(tree->textarea, x, y, clip_x, clip_y,
clip_x + clip_width, clip_y + clip_height);
Unlike the rest of the calls in the function, it uses the clip_ coordinates
instead of the absolute_ ones which take into account the tree's origin when
placing the clip window. Although this seems wrong, I can't quite explain
why it results in the exact symptoms I'm seeing; from my reading of the
code, it would only seem to affect the textarea's clip rectangle, and not
the actual position of the area itself. However, if I change it to
textarea_redraw(tree->textarea, x, y, absolute_x, absolute_y,
absolute_x + clip_width, absolute_y + clip_height);
then the RISC OS redraw code works correctly, and the gtk version (which I
think draws the tree at (0,0)) isn't broken as far as I can tell.
Could anyone with a better understanding of the treeview and textarea code
comment?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
13 years, 8 months
Re: Possible issue with tree+textarea redraw?
by Paweł Blokus
---------- Forwarded message ----------
From: Paweł Blokus <pblokus(a)gmail.com>
Date: 2010/2/23
Subject: Re: Possible issue with tree+textarea redraw?
To: Chris Young <chris.young(a)unsatisfactorysoftware.co.uk>
> Looks fine, except when the edit area appears, the whole tree moves
> and redraws without clearing the rendering area. Paul - am I supposed
> to be handling this somehow? How do I know an edit is about to happen
> in order to clear it?
No you aren't, the area that's going to be redrawn should always get
cleared by the core first. What do you mean with 'moves'? Does it get
scrolled through the scroll_visible callback or change it's origin
somehow? A screenshot would be helpful :)
Paul
13 years, 9 months
GSOC 2010
by Dharamveer Singh Chouhan
Hi,
I would like to work for netsurf in the upcoming summers. I have been using
Netsurf from some time. I really appreciate all the super efforts put in by
the developers.
Hats off to them. But as our browser is still young and many more features
can be added.
I would like to tell everyone that, i am good in C and possess good sharp
skill and command over language.
I am also good in actionscripts and PHP.
Regards and awaiting a positive hear from the community
Dharamveer Singh Chouhan
B.Tech.
2nd Year, IT-BHU
I may not be the best, but i am certainly not like the rest
13 years, 9 months
Wakefield 2010 show
by Rob Kendrick
Greetings.
I have received all the paperwork from Chris in order to book a stand
at Wakefield should we wish to.
It will be held on Saturday the 24th of April 2010, at the Cedar Court
Hotel, Denby Dale Road, Calder Grove, Wakefield, WF4 3QZ (just off
Junction 39 of the M1). I believe this to be a /different/ Cedar Court
hotel that the show was held at a couple of years back, but don't quote
me on that.
Pricing that Chris has provided me is as follows:
Stand rental (2m wide plot) £40 (discount from £90)
(Comes with 1 chair, and electricity!)
Additional chairs Free
Wi-Fi Access £13
(This seems pricey given it's likely to be rubbish.
I think perhaps 3G may be a better option.)
Backing panels £32
(Whoever rents these makes a fortune.)
Questions that need answering in order to fill in the forms:
* How many exhibitor passes will be required?
* Do we want a show theatre slot?
* How many computers/monitors/inkjets/lasers will be
be wanting to plug in? What other items?
Show guide entries:
Company name(s), Address, Tel, Fax, Email, Web URL. Looks like
no room for a blurb this year. I will, as always, strive for
NetSurf to be typeset correctly in the guide, but, as always,
will ultimately fail.
Now: Discuss!
B.
13 years, 9 months
RISC OS Themes and Toolbars?
by Steve Fryatt
I think I need some clues as to how the toolbars and themes work in the
RISC OS frontend, if anyone can help.
Based on the code in the old hotlist/global history/cookies modules, I'm
creating the hotlist window and toolbar as follows:
/* create our window */
hotlist_window.window = ro_gui_dialog_create("tree");
ro_gui_set_window_title(hotlist_window.window,
messages_get("Hotlist"));
/* (...create the treeview here...) */
/* Create our toolbar */
hotlist_window.toolbar = ro_gui_theme_create_toolbar(NULL,
THEME_HOTLIST_TOOLBAR);
if (hotlist_window.toolbar)
ro_gui_theme_attach_toolbar(hotlist_window.toolbar,
hotlist_window.window);
and then going on to open the window with:
if (!ro_gui_dialog_open_top(hotlist_window.window,
hotlist_window.toolbar, 600, 800)) {
/* ...do stuff to the opened window... */
}
Unfortunately, while the dialog opens fine, I don't get a toolbar.
Further investigation would seem to suggest that I'm getting a toolbar (or
at least a non-NULL pointer) back from ro_gui_theme_create_toolbar(), but
that ro_gui_theme_attach_toolbar() doesn't actually do anything, because it
checks if the value returned from the ro_gui_theme_toolbar_height() macro
for the bar is > 0 and skips past the pane attaching bit of the code if it
isn't. For the toolbars I've created, it isn't -- as far as I can tell,
because toolbar->max_height is still at 0 when the code is called.
Clearly toolbars do still work, as the main browser window has one. My
guess is that I'm not doing some vital initialisation on the hotlist bar,
but so far I can't spot what it is. As far as I can see, the themes have
been set up before the dialog boxes are created, so I'm assuming (pending
further investigation) that by the time the hotlist toolbar is created the
theme system knows what icons it contains and how big they are.
Is there any more info on how to use the RISC OS toolbars? If not, I'll
take a copy of the current RISC OS trunk and try to trace how things get set
up and initialised; I suspect it's a lot of work that I'd rather avoid if
anyone happens to know the answer, though.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
13 years, 9 months
Re: r9965 vince - in /trunk/netsurf/desktop: browser.c browser.h
by Daniel Silverstone
On Wed, Feb 10, 2010 at 11:37:07PM -0000, netsurf(a)semichrome.net wrote:
> + bw->status_text = NULL;
> + bw->status_text_len = 0;
I see no initialisation of status_match or status_miss
> void browser_window_set_status(struct browser_window *bw, const char *text)
> + if ((bw->status_text == NULL) || (bw->status_text_len < text_len)) {
> + /* no current string allocation or it is not long enough */
> + free(bw->status_text);
While free(NULL) is defined to be safe -- are we certain it is on all platforms
we port to?
> Modified: trunk/netsurf/desktop/browser.h
> +
> + /** cache of the currently displayed status text. */
> + char *status_text;
> + int status_text_len;
> + int status_match;
> + int status_miss;
The incorrect indentation indicates that the comment was space-indented rather than tabbed, and the three ints lack documentation strings.
How about:
char *status_text; /**< Current status bar text. */
int status_text_len; /**< Length of the ::status_text buffer. */
int status_match; /**< Number of times an idempotent status-set operation was performed. */
int status_miss; /**< Number of times status was really updated. */
?
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
13 years, 10 months
Hello, and a bug fix
by Rik Griffin
Hi,
I've just subscribed to this list so this is partly a test message to see
if things are working.
Also, I've been investigating bug #1729711:
http://sourceforge.net/tracker/index.php?func=detail&aid=1729711&group_id...
It seems that the status bar was being updated so frequently that when
gui_multitask was called during a fetch, Wimp_Poll always returned
immediately with a Wimp redraw window event, hence never yielding to other
applications.
My fix / quick hack, is to limit the frequency with with Wimp_ForceRedraw
can be called on the status bar. I don't know the procedure for submitting
changes to the repository, so I'll post it here:
In file riscos.gui.status_bar/c : function ro_gui_status_bar_set_text :
Replace these lines:
if (sb->visible)
xwimp_force_redraw(sb->w, 0, 0, sb->width - WIDGET_WIDTH, 65536);
With these:
if (sb->visible) {
static clock_t last = 0;
if (clock() > last + 50) {
xwimp_force_redraw(sb->w, 0, 0, sb->width - WIDGET_WIDTH, 65536);
last = clock();
}
}
I've replaced tabs with spaces to make this read better.
--
Rik Griffin
Software Engineer, Denbridge Marine Ltd
Registered in England and Wales at DSG, 43 Castle St, Liverpool. L2 9TL.
Registered Number 4850477.
13 years, 10 months
RISC OS front-end plotters
by Steve Fryatt
Can anyone give me some pointers as to how the RISC OS front-end's plotter
code is supposed to be used?
Specifically, the coordinate system has got me a bit puzzled. Am I correct
in thinking that a redraw loop should set ro_plot_origin_x and _y to the
window origin, and then work entirely in window coordinates thereafter?
And does that mean that when things like treeview's tree_draw() ask for x
and y coordinates, they do so relative to the window origin and not the
desktop graphics origin?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
13 years, 10 months
