Re: r9035 MarkieB - in /branches/MarkieB/gtkmain: content/fetchcache.c desktop/browser.c gtk/gtk_scaffolding.c gtk/gtk_toolbar.c gtk/gtk_window.c gtk/gtk_window.h
by John-Mark Bell
On Tue, 2009-08-04 at 08:21 +0000, netsurf(a)semichrome.net wrote:
> Modified: branches/MarkieB/gtkmain/content/fetchcache.c
> URL: http://source.netsurf-browser.org/branches/MarkieB/gtkmain/content/fetchc...
> ==============================================================================
> --- branches/MarkieB/gtkmain/content/fetchcache.c (original)
> +++ branches/MarkieB/gtkmain/content/fetchcache.c Tue Aug 4 03:21:47 2009
> @@ -1156,83 +1096,97 @@
> }
>
> free(scheme);
> + fetchcache_redirect_common(c, parent_was_verifiable, url, referer, parent);
> + free(referer);
> +}
> +
> +/**
> + * common logic from fetchcache_redirect() / fetchcache_search_redirect()
> + * \param c the content param from the original function
> + * \param verifiable parent_was_verifiable [false for search_redirect]
> + * \param url the url being considered; redirect_common() shall free() it
> + * \param referer referer [ / NULL particularly for search_redirect]
> + * \param parent parent content [ / c for search_redirect]
> + */
> +
> +void fetchcache_redirect_common(struct content *c, bool verifiable, char *url,
> + const char *referer, struct content *parent)
I would much prefer it if url was const here. This means that the caller
must free it, which seems reasonable, given they created it.
J.
11 years, 9 months
Re: r9079 struggleyb - in /branches/struggleyb/libdom-remain: include/dom/bootstrap/ src/bootstrap/ src/core/
by John-Mark Bell
On Thu, 2009-08-06 at 10:32 +0000, netsurf(a)semichrome.net wrote:
> Modified: branches/struggleyb/libdom-remain/src/bootstrap/init_fini.c
> URL: http://source.netsurf-browser.org/branches/struggleyb/libdom-remain/src/b...
> ==============================================================================
> --- branches/struggleyb/libdom-remain/src/bootstrap/init_fini.c (original)
> +++ branches/struggleyb/libdom-remain/src/bootstrap/init_fini.c Thu Aug 6 05:32:21 2009
> @@ -38,7 +38,7 @@
> return err;
> }
>
> - err = dom_implregistry_dom_implementation_initialise(
> + err = dom_implregistry_initialise(
> alloc, pw);
This can all be on one line.
> Modified: branches/struggleyb/libdom-remain/src/core/attr.c
> URL: http://source.netsurf-browser.org/branches/struggleyb/libdom-remain/src/c...
> ==============================================================================
> --- branches/struggleyb/libdom-remain/src/core/attr.c (original)
> +++ branches/struggleyb/libdom-remain/src/core/attr.c Thu Aug 6 05:32:21 2009
> @@ -102,15 +100,16 @@
> }
>
> /**
> - * Initialis a dom_attr
> - *
> - * \param a The dom_attr
> - * \param doc The document
> - * \param name The name of this attribute node
> - * \param namespace The namespace of this attribute
> - * \param prefix The prefix
> - * \param specified Whether this node is a specified one
> - * \param result The returned node
> + * Initialise a dom_attr
> + *
> + * \param a The dom_attr
> + * \param doc The document
> + * \param name The name of this attribute node
> + * \param namespace The namespace of this attribute
> + * \param prefix The prefix
> + * \param specified Whether this node is a specified one
> + * \param result The returned node
> + * \return DOM_NO_ERR on success, appropriate dom_exception on failure
Whitespace.
> Modified: branches/struggleyb/libdom-remain/src/core/node.h
> URL: http://source.netsurf-browser.org/branches/struggleyb/libdom-remain/src/c...
> ==============================================================================
> --- branches/struggleyb/libdom-remain/src/core/node.h (original)
> +++ branches/struggleyb/libdom-remain/src/core/node.h Thu Aug 6 05:32:21 2009
> @@ -55,8 +56,8 @@
> void *vtable; /**< The protected vtable */
>
> struct lwc_string_s *name; /**< Node name (this is the local part
> - * of a QName in the cases where a
> - * namespace exists) */
> + * of a QName in the cases where a
> + * namespace exists) */
Ditto.
> Modified: branches/struggleyb/libdom-remain/src/core/typeinfo.c
> URL: http://source.netsurf-browser.org/branches/struggleyb/libdom-remain/src/c...
> ==============================================================================
> --- branches/struggleyb/libdom-remain/src/core/typeinfo.c (original)
> +++ branches/struggleyb/libdom-remain/src/core/typeinfo.c Thu Aug 6 05:32:21 2009
> @@ -12,15 +12,19 @@
>
> /**
> * Get the type name of this dom_type_info
> *
> - * \param ti The dom_type_info
> - * \param ret The name
> + * \param ti The dom_type_info
> + * \param ret The name
> + * \return DOM_NO_ERR on success, appropriate dom_exception on failure.
> + *
> + * We don's support this API now, so this function call always
> + * return DOM_NOT_SUPPORTED_ERR.
"don't" (and for the other occurrences in this file).
Aside from the above, the core branch is now fine to merge into trunk.
J.
11 years, 9 months
Native RISC OS build documentation
by Michael Drake
The native RISC OS build documentation has now been updated to cover the
issues raised in the thread on the netsurf-users mailing list.
Most of the instructions are now in Docs/BUILDING-RISC_OS, alongside the
instructions for building other versions of NetSurf.
Michael
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
11 years, 9 months
progress report N°11
by Mark
Hi,
well the 'main' gtk branch should now be more ready for merger as I have
hopefully implemented all of John-Mark's very constructive suggestions
to make the code more robust;
when that is merged, the gtk uploads branch would need reviewing one day
too;
as for windows branch, the 'clear screen' code that was necessary to
make the background redraw properly, particularly when scrolling, caused
unacceptable flickering; I had to change that particularly for the case
of gifs that caused flickering redraw loops at page load; now I've
simplified the screen clearing to allow the core to simply redraw the
page rather than utterly erasing it first, the background redraw bug has
reappeared; it *looks* as though the core is forgetting background
elements that it has drawn, although the chances are it's more connected
to the communication from the core to the screen
Be that as it may, I'm hopeful it'll be addressed, possibly I'll need
the assistance of those who may recognise the bug :-)
then there are the wayward 'images' that seemed to have appeared
originally when jpegs were being rendered to screen undecoded; so unless
it's connected to libmng - that I'll hope to cross-compile as I'll be
looking into liblcms - then it may be a case for 'those who may
recognise the bug' :-D
the good news is that windows branch now renders the main image types
including alpha-channel transparency, although the overhead for partial
transparencies of calculating an rgb value - that seems to work at a
reasonable speed in development - may be heavy for older machines, so a
conditional simpler implementation may be necessary
Best
Mark
http://www.halloit.com
Key ID 046B65CF
11 years, 9 months
The libDOM Events module is ready for review
by Bo Yang
Hi,
After more than one week coding, I have completed the Events
module. The API support status is at
http://wiki.netsurf-browser.org/LibDOM/Events_Support_Status. And the
Events module is added to the Core module and pass the DOMTS as the
Core module does. Also, the leak test for the Events module is well,
too. So I think it is applicable for review.
It is better if we can merge the Core module firstly, and then we
start the review of Events module and start write the HTML module
meanwhile.
Thanks a lot!
Regards!
Bo
11 years, 9 months
Re: r9108 chris_y - in /trunk/netsurf: amiga/bitmap.c amiga/bitmap.h image/bitmap.h image/gif.c
by John-Mark Bell
On Fri, 2009-08-07 at 21:16 +0000, netsurf(a)semichrome.net wrote:
> Author: chris_y
> Date: Fri Aug 7 16:16:49 2009
> New Revision: 9108
>
> URL: http://source.netsurf-browser.org?rev=9108&view=rev
> Log:
> Support new libnsgif by adding bitmap flag BITMAP_ABGR.
> This tells big endian systems that the data is in ABGR instead of RGBA.
> It should be ignored on little endian systems!
I really don't like this change. It makes things even more complex for
no good reason. Please revert this. I'll be making some changes to
libnsgif to make it behave as before (just without the hideous palette
entry generation that failed to compile with GCC4.4).
J.
11 years, 9 months
Progress report
by Paweł Blokus
Hi,
Since the last progress report I have completed both the scroll widget
and the select menu. Due to rounding errors the scroll sometimes has
some off by one rendering issues but I am not sure whether much can be
done about it. The resulting changes however, wouldn't be too
significant, so I think the code is ready for being reviewed.
At this point I am not sure what I should do next. I could start
working on the keyboard navigation, but I don't know if I can reach a
reasonable milestone as now I know my estimations of the required time
were too optimistic while I was writing my proposal. Also, I think,
once being reviewed, the treeview code would keep me busy in case some
non-cosmetic-only changes are requested. But this would need the code
to be reviewed before risc os working with it properly. Maybe there is
some part of the code you already know you are not satisfied with? If
so, don't wait for the main review with writing about it :)
11 years, 9 months
Events Generations
by Bo Yang
Hi,
For Events model, there are 7 types of MutationEvent, and they are
DOMCharacterDataModified, DOMAttrModified, DOMNodeInserted,
DOMNodeRemoval, DOMNodeInsertedIntoDocument,
DOMNodeRemovedFromDocument, DOMSubtreeModified.
I have supported the first 4 ones, but for the last three ones, I
think it is better to discuss something here.
1. For DOMNodeInsertedIntoDocument/DOMNodeRemovedFromDocument, the
spec ask that each Node inserted/removed from the document, we should
dispatch such an Event. But this may cause many events generated, do
you think they are indispensable for our implementation? Should we
support them now?
2. For the DOMSubtreeModified event, I think the best time it should
be generated is after a bunch of JS(or other scripts which manipulate
DOM) end. But how do we find that that is an end. I am wondering what
is the best way to deal with this event type...
Any advice are welcomed, thanks!
Regards!
Bo
11 years, 9 months
Re: r9027 jmb - /trunk/libnsgif/src/libnsgif.c
by Chris Young
On Mon, 03 Aug 2009 22:07:06 -0000, wrote:
> URL: http://source.netsurf-browser.org?rev=9027&view=rev
> Log:
> Stop utterly insane palette entry population.
> Palette entries are always ABGR, regardless of platform endianness.
> This change probably breaks big-endian platforms which, under the
> old approach, had palette entries of the form RGBA (assuming I
> understood the code correctly).
Yes it does, and it totally breaks NetSurf* as GIFs now have a
different byte order to every other bitmap.
Can we either change all the bitmap outputs to ABGR or (preferably)
leave them all as RGBA please?
Chris
* and any other user of libnsgif, although I don't know of any
currently.
11 years, 9 months
