Re: GSoC frames idea
by Chris Young
On Thu, 26 Mar 2009 19:06:40 +0000, John-Mark Bell wrote:
> On Thu, 2009-03-26 at 19:01 +0100, Chris Young wrote:
> > On Thu, 26 Mar 2009 18:43:02 +0000, John-Mark Bell wrote:
> >
> > > Obviously, when navigating between pages, scrollbar widgets should be
> > > removed/added as appropriate by the core. Thus, the frame object should
> > > probably store the current offsets etc so it can recreate the widget if
> > > the user navigates back to the page.
> >
> > The tabs system also needs improving as at the moment there is no way
> > of telling the core when you are switching tabs, so it can
> > destroy/create scrollbars as appropriate - unless the platform code
> > can keep track of which scrollbars are on which page?
>
> Given the point is to make things simpler for the frontends, I'm not
> entirely sure what the best solution is here. It would be useful to have
> input from the other frontend implementors. TBH, it's a very long time
> since I went near the core/frontend interface in anger. So, regardless
> of what I think, other people are significantly better placed to design
> this API.
Michael's "get scrollbars for browser window" sounds like it will do
the trick.
If the scrollbars are going to have to be clippable, that's me stuffed
anyway (I think) - so I'd have to use the core rendered ones.
Chris
14 years
Re: GSoC frames idea
by John-Mark Bell
On Thu, 2009-03-26 at 22:53 +0100, Paweł Blokus wrote:
> > Does the frontend need to care about the content?
> >
>
> It uses bw->current_content for calling content_redraw, so yes it
> does.
I guess the corollary to my question was "does the frontend need to call
content_redraw()?". I'd need to investigate to give you an answer. It'd
be kinda nice to be able to hide the content stuff from the frontends
completely. For redraw, assuming that it's not too tied in to the
current way of doing things, the frontend could just call some API
(browser_window_redraw(), say) and leave it to the browser window to
determine which content(s) to redraw.
> Also, your question made me realise that enabling frames would
> also affect printing, pdf export, box tree saving and maybe something
> other that needs to process all frames.
Yes, indeed. On the upside, however, I expect all of these are already
broken by frames (even on RISC OS), so you can't make it any worse.
> The only consolation is that
> at the moment even if the frames were supported (I'm talking about GTK
> now) these actions wouldn't affect the nested ones so anything done in
> this direction would be an improvement. Maybe something like
>
> while (c = browser_window_next_content)
> print,export,box(c)
>
> would be enough? But wouldn't it be going back to the start point
> somehow?
I think so, yes. I'll see if I can investigate the possibility of
divorcing the frontends from contents completely.
> I guess what I should know first is how RISC OS prints frames.
Badly. :)
J.
14 years
Re: GSoC frames idea
by Paweł Blokus
2009/3/26 John-Mark Bell <jmb(a)ecs.soton.ac.uk>:
> On Wed, 2009-03-25 at 23:09 +0100, Paweł Blokus wrote:
>>
>> A frame redraw would be handled like a regular one with the difference
>> that the frame offsets in the BW would have to be taken into account.
>> Also, as a BW would be bound up with several contents a way of passing
>> the one to be redrawn would have to be added.
>
> I think it would make more sense to have a 1:1 mapping between contents
> and frame objects. Then, perhaps, have the content handler in the frame
> object bubble the redraw request up the frames tree where it finally
> arrives in the browser_window, which then propagates the request up to
> the frontend.
>
That was actually my intention, hence the content pointer inside the
frame struct. (I guess it didn't help me writing "The remaining
variables would be shifted to the frame struct" in the matter of
clearance :) ). By bounding I meant the browser window holding the
root of the frames tree and that the content couldn't be simply
accessed for redraw from bw->current_content any more. This way the
concerned content would be one parameter to be passed for redrawing
and it's offsets on the main canvas another one.
14 years
test-to-c.xsl failure
by John-Mark Bell
LibDOM's DOMTS converter doesn't appear to work at all right now:
xsltproc -o test/xml/c/documentgetdoctype.c
test/transform/test-to-c.xsl test/xml/tests/documentgetdoctype.xml
Unrecognized element metadata
If I remove the entire <metadata>...</metadata> block from the source
file, it then complains about <load>
J.
14 years
Re: GSoC libDOM proposal
by James Shaw
2009/3/22 Bo Yang <struggleyb.nku(a)gmail.com>
>
> 3. After the core module pass the tests, the Events module will be
> implemented. The Events module is a relatively small module and some of its
> interfaces should implemented in Core module's objects. Just like, the
> EventTarget interface should be implemented by the Node object. So, the
> Events module comes earlier than the HTML module in my plane. Of course, we
> need the XSLT file to create tests and make sure the Events module pass
> them. I will spend two weeks to do this.
>
When I attempted this a year ago, I found the XML test suite to be very
difficult to transform. Because C isn't as object oriented as the other
languages already covered by the suite, tasks such as overriding functions
and implementing 'instanceof' operators were complex or near-impossible.
I'd think that you'll need quite a bit of prior experience with XSLT in
order to tackle this. A month for the core feels realistic but, obviously,
it does depend on the number of working hours will expect to have in a week.
If you haven't already, do refer to the notes I made:
http://source.netsurf-browser.org/trunk/dom/docs/TestSuite?revision=3624&...
my attempts at the XSLT:
http://source.netsurf-browser.org/trunk/dom/test/
Hope that helps
James
14 years
GSoC libDOM proposal
by Bo Yang
Hi dear developers,
I am a GSoC applicant (my nickname in #netsurf is struggleyb),
generally I am interested in the project libDOM. Netsurf is really a small &
fast browser now, but there is no complete DOM implementation in it. Many
modern web pages contain Javascript, which is mostly used to manipulate the
DOM of the web page. So, it is necessary to add DOM support to Netsurf as
soon as possible. And that is just what I want to do in this summer.
The DOM implementation in libDOM is part of the DOM core level 3 now.
It is created by John-Mark Bell(jmb) at July 2007. Generally, my work is to
complete the Core module , add Events/HTML modules support to it and
integrate it into Netsurf. For details:
1. The final DOM implementation will use a vtable structure, so the first
step is to convert the existing implementation to use the vtable structure.
This task has been completed partly. I think this part will be completed
before the summer start.
2. Complete the missing implementation of Core module and test it. There are
some functions left as unimplemented in the existing Core module, I will
complete these functions firstly. And I think it is better to test earlier
than later, so it is testing time after the Core module completion. W3C
provides a DOM Test Suite at http://www.w3.org/DOM/Test/ which is used to
test whether any DOM implementation is standard compliant. I will write some
XSLT files to translate the test files, and test the Core implementation.
This task will cost me about one month, I estimate.
3. After the core module pass the tests, the Events module will be
implemented. The Events module is a relatively small module and some of its
interfaces should implemented in Core module's objects. Just like, the
EventTarget interface should be implemented by the Node object. So, the
Events module comes earlier than the HTML module in my plane. Of course, we
need the XSLT file to create tests and make sure the Events module pass
them. I will spend two weeks to do this.
4. And then it is the HTML module. Just implement it and the make it pass
the tests. I think two weeks is needed for this task.
5. After all these modules passed the tests, I will integrate the libDOM
into Netsurf to replace the libxml2 library's xmlDocPtr with dom_document.
And there are many other changes like this. I will change the the Netsurf
parser binding code to use the new DOM structure and the corresponding Node
instead of xmlNode. And then, I will make DOM events available in Netsurf. I
mean, all events such as
mouseover/mouseout/DOMNodeInserted/DOMNodeRemoved/DOMAttrModified will hook
up with Netsurf rendering code. Three or four weeks are necessary to
complete this task.
6. Finally, the new libDOM's features will be written down on wiki or some
other place. Most of the DOM interfaces/methods are explained very well on
the W3C's standard, I think we have no need to write another document to
explain our interfaces. But, we should write documents to explain how each
Interface in DOM mapped into our implementation. And how should our clients
to use our library and how it is designed internally to help later
developers to catch up easily. This task will be done in one week.
The above is my proposal for summer project, and it is based on my
understanding and recent work for Netsurf. Could you please give me some
advice? Any comment will be appreciated very much! Thanks!
Regards!
Bo
14 years
BeOS build broken
by François Revol
[root@laptop /work/netsurf/netsurf]# gmake
M.CONFIG: building with JPEG support
M.CONFIG: building without JNG/MNG/PNG support
M.CONFIG: building without PDF export
M.CONFIG: building without glibc internal iconv
M.CONFIG: building with PNG support
Makefile:804: warning: overriding commands for target `build-beos-beos/
deps/content_content.d'
Makefile:786: warning: ignoring old commands for target `build-beos-
beos/deps/content_content.d'
Makefile:804: warning: overriding commands for target `build-beos-beos/
deps/content_fetch.d'
Makefile:786: warning: ignoring old commands for target `build-beos-
beos/deps/content_fetch.d'
Makefile:804: warning: overriding commands for target `build-beos-beos/
deps/content_fetchcache.d'
Makefile:786: warning: ignoring old commands for target `build-beos-
beos/deps/content_fetchcache.d'
...
COMPILE: utils/utils.c
gcc: cannot specify -o with -c or -S and multiple compilations
COMPILE: utils/utf8.c
gcc: cannot specify -o with -c or -S and multiple compilations
In svn history I noticed:
r6624 | dsilvers | 2009-02-26 12:08:07 +0100 (Thu, 26 Feb 2009) | 1
line
Allow non-gcc-2.x builds to use -MMD -MT -MF flags to dep-as-we-
compile, reducing build time quite a bit
I suppose gcc2 wasn't tested with this setup and actually goes through
both codepaths.
François.
14 years
