- Dillo-dev - lists.mailman3.com

Dillo config in LTIB

by jcid＠dillo.org

Hi, On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: > Hi, > > I installed Dillo in LTIB and while the splash page went up, > clicking links reported a dns error. I checked out dillorc and > saw no setting related to dns. Dillo uses getaddrinfo(). It depends on the OS. > Trying a link to localhost also > gave I/O errors. This is strange... > My trace as follows: > > Nav_open_url: new url='http://www.dillo.org/' > DNS error: TRY_AGAIN > Dns_server [0]: www.dillo.org is (nil) Does "ping www.dillo.org" resolve? > Using localhost: > > Nav_open_url: new url='http://localhost:88' > Dns_server [0]: localhost is 127.0.0.1 > Connecting to 127.0.0.1 > ** WARNING **: IO_write, closing with pending data not sent > ** WARNING **: "GET / HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: localhost:88\x0D > Referer: http://localhost:88/\x0D > User-Agent: Dillo/2.1\x0D > \x0D > " > > Thanks for any help. It looks like something external closed the connection. Firewall? -- Cheers Jorge.-

Oct. 12, 2010

Dillo config in LTIB

by vic＠smartqsys.com

Hi, I installed Dillo in LTIB and while the splash page went up, clicking links reported a dns error. I checked out dillorc and saw no setting related to dns. Trying a link to localhost also gave I/O errors. My trace as follows: Nav_open_url: new url='http://www.dillo.org/' DNS error: TRY_AGAIN Dns_server [0]: www.dillo.org is (nil) Using localhost: Nav_open_url: new url='http://localhost:88' Dns_server [0]: localhost is 127.0.0.1 Connecting to 127.0.0.1 ** WARNING **: IO_write, closing with pending data not sent ** WARNING **: "GET / HTTP/1.1\x0D Connection: close\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: localhost:88\x0D Referer: http://localhost:88/\x0D User-Agent: Dillo/2.1\x0D \x0D " Thanks for any help. Vic

Oct. 12, 2010

Pending tasks

by Johannes.Hofmann＠gmx.de

On Mon, Oct 11, 2010 at 01:33:17PM -0300, Jorge Arellano Cid wrote: > Hi, > > With regard to: > > > 1 provide a dillo css compatibility table (and keep it up to date) > > 2 optimizing line-breaks - i.e. break at '-' but don't > > break e.g. Dillo (after the 'D'). > > 3 support for > > 4 support for text-indent > > 5 support font-variant > > 6 support more vertical-align options > > 7 make thickness of lines for underline and line-through > > depending on the font size and weight > > 8 support more border-style options (dotted, dashed ...) > > 9 support border-collapse (table related) > > 5 and 7 are in testing phase (in the repo). > AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by > corvid. > > After the big table rendering work long ago, I'm studying the > tables code again. > > Please notice that the doxygen dw documentation on table > algorithms (the math formulas part) is not up-to-date. It's done > in a different way since the big patch. > > My idea is to refresh my memory on this part of the code, and > then to try to devise a way to implement 8 and 9. At the same > time, working on this part will help for 6. > > Most probably we'll have to try to tackle these complex > problems coordinating our effort/knowledge. I'll be in better > shape to help with this after working for a while on tables. > > @Johannes, @corvid, please state what are your plans for work > on these remaining parts (if there's one already). I'm still working on CSS for the <html>-element (the issue reported by Jeremy). As my original patch had issues with pages that have multiple <head> elements, I decided to make some major changes to the StyleEngine-API. It looks ok now, but I need to do some more tests. Cheers, Johannes

Oct. 11, 2010

Pending tasks

by jcid＠dillo.org

Hi, With regard to: > 1 provide a dillo css compatibility table (and keep it up to date) > 2 optimizing line-breaks - i.e. break at '-' but don't > break e.g. Dillo (after the 'D'). > 3 support for > 4 support for text-indent > 5 support font-variant > 6 support more vertical-align options > 7 make thickness of lines for underline and line-through > depending on the font size and weight > 8 support more border-style options (dotted, dashed ...) > 9 support border-collapse (table related) 5 and 7 are in testing phase (in the repo). AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by corvid. After the big table rendering work long ago, I'm studying the tables code again. Please notice that the doxygen dw documentation on table algorithms (the math formulas part) is not up-to-date. It's done in a different way since the big patch. My idea is to refresh my memory on this part of the code, and then to try to devise a way to implement 8 and 9. At the same time, working on this part will help for 6. Most probably we'll have to try to tackle these complex problems coordinating our effort/knowledge. I'll be in better shape to help with this after working for a while on tables. @Johannes, @corvid, please state what are your plans for work on these remaining parts (if there's one already). -- Cheers Jorge.-

Oct. 11, 2010

Re: project list for sponsoring test period

by Johannes.Hofmann＠gmx.de

On Mon, Oct 11, 2010 at 12:54:37PM +0200, Johannes Hofmann wrote: > > Andreas installed mercurial in dillo.org - thanks Andreas! > I have setup a repository for css_compat. So the tests are version > controlled now. Here is how it works: > > Create a clone on your local workstation: > hg clone ssh://dillo.org/css_compat . Argh, that should have been: hg clone ssh://dillo.org//sfhome/groups/dillo/htdocs/css_compat > > Edit, hack, test, etc... > hg add foo.html > hg commit > > To publish the changes: > hg push > > This should update the CSS tests on the website. In the beginning > please verify that permissions are ok. It should work > automatically, but well - you know... > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 11, 2010

Re: project list for sponsoring test period

by Johannes.Hofmann＠gmx.de

On Wed, Oct 06, 2010 at 02:56:32PM -0400, Jorge Arellano Cid wrote: > On Mon, Oct 04, 2010 at 02:16:57PM +0200, Johannes Hofmann wrote: > > On Mon, Oct 04, 2010 at 07:59:45AM -0400, Jorge Arellano Cid wrote: > > > On Sun, Oct 03, 2010 at 09:16:30PM +0200, Johannes Hofmann wrote: > > > > [...] > > > > BTW, what do you think about adding the css_compat/ directory to the > > > > repo (under doc)? That would give us version control and it would > > > > document our progress. > > > > > > Having the test cases visible as HTML from the site is very > > > helpful IMHO. Unfortunately I don't yet know of a way of browsing > > > raw files from hg web interfaces (it may be doable). > > > > For my own website I have > > > > [hooks] > > changegroup = hg up > > > > in the .hgrc. So everytime I push to it, the files are updated. > > We could do the same for the CSS tests. > > Yes, it seems fair enough. > > FWIW, so long we've had the HTML test suite, and the personal > test pages each one of us develops. As you explained, the problem > is how to automate HTML rendering tests. I hesitate to include an > html test-page collection in the tarball because it would grow > bigger and bigger and nobody would apply to test each one > everytime a relevant change is made! :) > > I like the CSS checklist we have because it is sorted by > property and provides test-cases we can reference by URL, and it > lives outside the tarball so its size can grow independently. > > A fast way to check the tests is to provide an image with the > correct rendering in the test page (maybe with an explanation > too). It takes more time to prepare though, and each time you > update the page you have to also update the screenshot. Quite a > burden. > > I don't have a good solution yet. These days I've been working > with Gecko and Dillo. Having the test page showed in both > provides for a "dynamic screenshot" from Gecko. This avoids the > burden of updating the image, with the advantage of showing how > Gecko renders unespecified parts of the SPEC. > > An HTML test-page, with written explanations of what to check > for, and two browsers is the fastest/simplest solution I see so > far. (It also has the advantage of almost anyone being able to do > the test). > > If we have it online (i.e. with http URLs), better, and if we > had some version control it may be what we need. > > > > > > > > Besides that I don't see the benefits of having css_compat/ > > > under version control, and our progress is more or less in the hg > > > log, but I see it can be more tightly coupled with the test case > > > if the extended comment makes a reference to it for instance. > > > Please explain me a bit because it may be I don't see the gains > > > because of lack of knowledge on my side! > > > > Basically I like to do almost everything under version control. Just > > yesterday I almost overwrote your vertical-align.html with my own > > version! > > Also just pushing my changes to dillo.org would be faster than > > copying the files manually. > > Do you have root on dillo.org? If so, you could install mercurial > > and I will set up a repo for the CSS tests. > > We can decide later whether we want to integrate it into the main > > dillo repo or not. > > Not me, but you can ask Andreas Kemnade. > He's our savvy sysadmin. Andreas installed mercurial in dillo.org - thanks Andreas! I have setup a repository for css_compat. So the tests are version controlled now. Here is how it works: Create a clone on your local workstation: hg clone ssh://dillo.org/css_compat . Edit, hack, test, etc... hg add foo.html hg commit To publish the changes: hg push This should update the CSS tests on the website. In the beginning please verify that permissions are ok. It should work automatically, but well - you know... Cheers, Johannes

Oct. 11, 2010

small-caps

by jcid＠dillo.org

On Fri, Oct 08, 2010 at 08:45:21PM +0200, Johannes Hofmann wrote: > On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote: > > On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > > > Jorge wrote: > > > > I had to use mbrtowc() because for some reason utf8decode() > > > > didn't work for me. > > > > > > > > I tried: > > > > > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > > > @@ -27,6 +27,7 @@ > > > > #include <fltk/events.h> > > > > #include <fltk/Cursor.h> > > > > #include <fltk/run.h> > > > > +#include <fltk/utf.h> > > > > > > > > #include <stdio.h> > > > > #include <wchar.h> > > > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > > > memset (&st2, '\0', sizeof (mbstate_t)); > > > > for (curr = 0; next < len; curr = next) { > > > > next = theLayout->nextGlyph(text, curr); > > > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > > > if ((wcu = towupper(wc)) == wc) { > > > > /* already uppercase, just draw the character */ > > > > setfont(ff->font, ff->size); > > > > > > > > > > > > @corvid: do you see why? > > > > > > I think the 'end' is supposed to point to the byte past the end. > > > (If so, that would mean that I have a bug that happens to have no effect > > > where html.cc checks for ideographic chars.) > > > > Yes it works with 'end' pointing to 'next' ;) > > > > BTW, misc.c also uses the utf8decode(). > > > > I hesitate on whether to call utf8{de,en}code() directly from > > fltkviewbase.cc and fltkplatform.cc, or to add an API to the > > platform.hh, and implement it in layout.cc as nextGlyph(). The > > first one looks simpler. > > It's ok to call it directly. fltkviewbase.cc is > fltk-dependent anyway. > But we can't call the fltk-based utf8 methods directly from files > in dw/ that don't have the fltk prefix. Done! -- Cheers Jorge.-

Oct. 9, 2010

small-caps

by Johannes.Hofmann＠gmx.de

On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote: > On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > > Jorge wrote: > > > I had to use mbrtowc() because for some reason utf8decode() > > > didn't work for me. > > > > > > I tried: > > > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > > @@ -27,6 +27,7 @@ > > > #include <fltk/events.h> > > > #include <fltk/Cursor.h> > > > #include <fltk/run.h> > > > +#include <fltk/utf.h> > > > > > > #include <stdio.h> > > > #include <wchar.h> > > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > > memset (&st2, '\0', sizeof (mbstate_t)); > > > for (curr = 0; next < len; curr = next) { > > > next = theLayout->nextGlyph(text, curr); > > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > > if ((wcu = towupper(wc)) == wc) { > > > /* already uppercase, just draw the character */ > > > setfont(ff->font, ff->size); > > > > > > > > > @corvid: do you see why? > > > > I think the 'end' is supposed to point to the byte past the end. > > (If so, that would mean that I have a bug that happens to have no effect > > where html.cc checks for ideographic chars.) > > Yes it works with 'end' pointing to 'next' ;) > > BTW, misc.c also uses the utf8decode(). > > I hesitate on whether to call utf8{de,en}code() directly from > fltkviewbase.cc and fltkplatform.cc, or to add an API to the > platform.hh, and implement it in layout.cc as nextGlyph(). The > first one looks simpler. It's ok to call it directly. fltkviewbase.cc is fltk-dependent anyway. But we can't call the fltk-based utf8 methods directly from files in dw/ that don't have the fltk prefix. Cheers, Johannes

Oct. 8, 2010

small-caps

by corvid＠lavabit.com

Jorge wrote: > On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > > Jorge wrote: > > > I had to use mbrtowc() because for some reason utf8decode() > > > didn't work for me. > > > > > > I tried: > > > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > > @@ -27,6 +27,7 @@ > > > #include <fltk/events.h> > > > #include <fltk/Cursor.h> > > > #include <fltk/run.h> > > > +#include <fltk/utf.h> > > > > > > #include <stdio.h> > > > #include <wchar.h> > > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > > memset (&st2, '\0', sizeof (mbstate_t)); > > > for (curr = 0; next < len; curr = next) { > > > next = theLayout->nextGlyph(text, curr); > > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > > if ((wcu = towupper(wc)) == wc) { > > > /* already uppercase, just draw the character */ > > > setfont(ff->font, ff->size); > > > > > > > > > @corvid: do you see why? > > > > I think the 'end' is supposed to point to the byte past the end. > > (If so, that would mean that I have a bug that happens to have no effect > > where html.cc checks for ideographic chars.) > > Yes it works with 'end' pointing to 'next' ;) > > BTW, misc.c also uses the utf8decode(). > > I hesitate on whether to call utf8{de,en}code() directly from > fltkviewbase.cc and fltkplatform.cc, or to add an API to the > platform.hh, and implement it in layout.cc as nextGlyph(). The > first one looks simpler. > > Definitely what I like about using utf8{de,en}code() is that > there's no need to alter the locale (LC_CTYPE). If it's only used in fltk*, I think I'd call it directly.

Oct. 8, 2010

small-caps

by jcid＠dillo.org

On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > Jorge wrote: > > I had to use mbrtowc() because for some reason utf8decode() > > didn't work for me. > > > > I tried: > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > @@ -27,6 +27,7 @@ > > #include <fltk/events.h> > > #include <fltk/Cursor.h> > > #include <fltk/run.h> > > +#include <fltk/utf.h> > > > > #include <stdio.h> > > #include <wchar.h> > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > memset (&st2, '\0', sizeof (mbstate_t)); > > for (curr = 0; next < len; curr = next) { > > next = theLayout->nextGlyph(text, curr); > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > if ((wcu = towupper(wc)) == wc) { > > /* already uppercase, just draw the character */ > > setfont(ff->font, ff->size); > > > > > > @corvid: do you see why? > > I think the 'end' is supposed to point to the byte past the end. > (If so, that would mean that I have a bug that happens to have no effect > where html.cc checks for ideographic chars.) Yes it works with 'end' pointing to 'next' ;) BTW, misc.c also uses the utf8decode(). I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler. Definitely what I like about using utf8{de,en}code() is that there's no need to alter the locale (LC_CTYPE). -- Cheers Jorge.-

Oct. 8, 2010

small-caps

by jcid＠dillo.org

On Fri, Oct 08, 2010 at 12:27:21PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Just committed a patch for CSS' small-caps, > > > http://www.dillo.org/css_compat/tests/font-variant.html > > > > I don't think the letterSpacing value needs to be scaled down in the > > small-caps case. > > corvid, what do you think? > > If letter-spacing were originally specified in pixels or centimeters > or something, then it definitely wouldn't. If it were given in ems, > I'm not sure. > *does the usual "let's see what firefox does"* > It appears that firefox doesn't modify letter-spacing. I tried with ems and FF doesn't touch letter-spacing. Committed a patch to mimic this behaviour. -- Cheers Jorge.-

Oct. 8, 2010

small-caps

by corvid＠lavabit.com

Johannes wrote: > On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Just committed a patch for CSS' small-caps, > > http://www.dillo.org/css_compat/tests/font-variant.html > > I don't think the letterSpacing value needs to be scaled down in the > small-caps case. > corvid, what do you think? If letter-spacing were originally specified in pixels or centimeters or something, then it definitely wouldn't. If it were given in ems, I'm not sure. *does the usual "let's see what firefox does"* It appears that firefox doesn't modify letter-spacing.

Oct. 8, 2010

small-caps

by Johannes.Hofmann＠gmx.de

On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote: > Hi, > > Just committed a patch for CSS' small-caps, > http://www.dillo.org/css_compat/tests/font-variant.html I don't think the letterSpacing value needs to be scaled down in the small-caps case. corvid, what do you think? Cheers, Johannes

Oct. 8, 2010

small-caps

by corvid＠lavabit.com

Jorge wrote: > I had to use mbrtowc() because for some reason utf8decode() > didn't work for me. > > I tried: > > diff -r 686a69055264 dw/fltkviewbase.cc > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > @@ -27,6 +27,7 @@ > #include <fltk/events.h> > #include <fltk/Cursor.h> > #include <fltk/run.h> > +#include <fltk/utf.h> > > #include <stdio.h> > #include <wchar.h> > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > memset (&st2, '\0', sizeof (mbstate_t)); > for (curr = 0; next < len; curr = next) { > next = theLayout->nextGlyph(text, curr); > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > + wc = utf8decode(text + curr, text + next - 1, &cb); > if ((wcu = towupper(wc)) == wc) { > /* already uppercase, just draw the character */ > setfont(ff->font, ff->size); > > > @corvid: do you see why? I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)

Oct. 7, 2010

small-caps

by jcid＠dillo.org

Hi, Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html I had to use mbrtowc() because for some reason utf8decode() didn't work for me. I tried: diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h> #include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size); @corvid: do you see why? -- Cheers Jorge.-

Oct. 7, 2010

Re: project list for sponsoring test period

by jcid＠dillo.org

On Mon, Oct 04, 2010 at 02:16:57PM +0200, Johannes Hofmann wrote: > On Mon, Oct 04, 2010 at 07:59:45AM -0400, Jorge Arellano Cid wrote: > > On Sun, Oct 03, 2010 at 09:16:30PM +0200, Johannes Hofmann wrote: > > > [...] > > > BTW, what do you think about adding the css_compat/ directory to the > > > repo (under doc)? That would give us version control and it would > > > document our progress. > > > > Having the test cases visible as HTML from the site is very > > helpful IMHO. Unfortunately I don't yet know of a way of browsing > > raw files from hg web interfaces (it may be doable). > > For my own website I have > > [hooks] > changegroup = hg up > > in the .hgrc. So everytime I push to it, the files are updated. > We could do the same for the CSS tests. Yes, it seems fair enough. FWIW, so long we've had the HTML test suite, and the personal test pages each one of us develops. As you explained, the problem is how to automate HTML rendering tests. I hesitate to include an html test-page collection in the tarball because it would grow bigger and bigger and nobody would apply to test each one everytime a relevant change is made! :) I like the CSS checklist we have because it is sorted by property and provides test-cases we can reference by URL, and it lives outside the tarball so its size can grow independently. A fast way to check the tests is to provide an image with the correct rendering in the test page (maybe with an explanation too). It takes more time to prepare though, and each time you update the page you have to also update the screenshot. Quite a burden. I don't have a good solution yet. These days I've been working with Gecko and Dillo. Having the test page showed in both provides for a "dynamic screenshot" from Gecko. This avoids the burden of updating the image, with the advantage of showing how Gecko renders unespecified parts of the SPEC. An HTML test-page, with written explanations of what to check for, and two browsers is the fastest/simplest solution I see so far. (It also has the advantage of almost anyone being able to do the test). If we have it online (i.e. with http URLs), better, and if we had some version control it may be what we need. > > > > Besides that I don't see the benefits of having css_compat/ > > under version control, and our progress is more or less in the hg > > log, but I see it can be more tightly coupled with the test case > > if the extended comment makes a reference to it for instance. > > Please explain me a bit because it may be I don't see the gains > > because of lack of knowledge on my side! > > Basically I like to do almost everything under version control. Just > yesterday I almost overwrote your vertical-align.html with my own > version! > Also just pushing my changes to dillo.org would be faster than > copying the files manually. > Do you have root on dillo.org? If so, you could install mercurial > and I will set up a repo for the CSS tests. > We can decide later whether we want to integrate it into the main > dillo repo or not. Not me, but you can ask Andreas Kemnade. He's our savvy sysadmin. > > OTOH, yes, I see dillo would be in better shape test-wise if we > > could include an [automated] test framework in the tarball. This > > wasn't done because it takes some time and needs manpower we > > didn't have. > > At "Henning's company" we are also thinking about automated tests > for dillo. > My current idea is to create a new view, that writes text that can > easily be compared with expected results. That would be more flexible > than to compare bitmaps of rendered output, which might give to many > false positves. > If this works out we can think about integrating the framework into > dillo mainline, but currently it's just an idea. I have some automated tests too (e.g. URL resolver), but rendering is a different beast. That's my thoughts. -- Cheers Jorge.-

Oct. 6, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On 10/4/10, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Sat, Oct 02, 2010 at 06:00:54PM -0400, Benjamin Johnson wrote: >> I don't think basic functionality like local file browsing and HTTPS >> is unnecessary "load in every dillo code". If there's any situation >> where it's undesired, perhaps the code could be #ifdef'd out and a >> new autoconf option added (--disable-local-files, etc.) > > We already agreed quite some time ago on dillo-dev, that HTTPS > support could be integrated into the main dillo binary if that would > help to create proper HTTPS support. > For the current highly experimental HTTPS stuff DPI seems the right > place. Fair enough -- but local file browsing? Does that seriously bloat the browser so much it has to be implemented as an external service? That's something I'd expect *any* browser (or similar program) to have built-in. >> As far as sharing bookmarks, cookies, etc. between browser >> processes: most major browsers (IE, Firefox, Opera, probably Chrome) >> allow one browser process running, and if a second is started, it >> signals the first to take some action (create a new window, for >> instance). That would still require some amount of IPC, but it's >> less complicated than DPI, and certainly less wasteful since you >> don't have multiple instances loading the same UI, static libraries, >> etc. > > Notifying an already open browser instance instead of creating a new > process is just a workaround needed because of the long startup > times of today's browsers. I can see I'm not likely to win this one, so I suppose I'll drop it. At any rate, I did just think of a possible way to (re)implement DPI, using a dsock-like wrapper that hooks into the Windows messaging system. I *think* fltk can expose a window's internal handle, which is the main thing you'd need. Anyway, I'll get back to you once I've done a bit more research, and in the mean time, I'll try to split up that patch. I can think of worse ways to kill three hours... :-) Cheers, ~Benjamin

Oct. 4, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

On Sat, Oct 02, 2010 at 06:00:54PM -0400, Benjamin Johnson wrote: > On Sat, 02 Oct 2010 17:31:07 -0400, Diego . > <darkspirit5000(a)gmail.com> wrote: > > >Your solution only works for downloads. Your downloader can be made a > >DPI and you can chose wich to use. Actually downloads do not stop if > >dillo close. > > I'm well aware how DPI is implemented, and that downloads continue > when Dillo is exited. My solution is intended in part as a > temporary measure, since I need downloads to function regardless of > whether DPI is available or not. I do have concerns, however, with > both the specific implementation and general (perceived) necessity > of DPI. > > >If the problems are dup2 and sockets dpid can be change to work on > >windows. > >Dillo always ask the dpi that serves a service before conect to it. > >dpid run the DPI so can send dillo the right fd, socket, file or do > >other thing. > > I've been working on that, but with very limited success. dup2 and > sockets are the most immediate problem, but there are larger > problems beyond that (for example, packaging Dillo/DPI). > > >dpid avoid to load in every dillo code to handle DPIs or external > >programs that will use only one and avoid the synchronize thing. > > I don't think basic functionality like local file browsing and HTTPS > is unnecessary "load in every dillo code". If there's any situation > where it's undesired, perhaps the code could be #ifdef'd out and a > new autoconf option added (--disable-local-files, etc.) We already agreed quite some time ago on dillo-dev, that HTTPS support could be integrated into the main dillo binary if that would help to create proper HTTPS support. For the current highly experimental HTTPS stuff DPI seems the right place. > > As far as sharing bookmarks, cookies, etc. between browser > processes: most major browsers (IE, Firefox, Opera, probably Chrome) > allow one browser process running, and if a second is started, it > signals the first to take some action (create a new window, for > instance). That would still require some amount of IPC, but it's > less complicated than DPI, and certainly less wasteful since you > don't have multiple instances loading the same UI, static libraries, > etc. Notifying an already open browser instance instead of creating a new process is just a workaround needed because of the long startup times of today's browsers. Cheers, Johannes

Oct. 4, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Sun, 03 Oct 2010 16:22:27 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I doubt that libcurl would be an option, but as I said, feel free to > experiment. > > Cheers, > Johannes The idea would be to provide libcurl as an *alternative to* Dillo's implementation, not a replacement for it. Cheers, ~Benjamin

Oct. 3, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

On Sun, Oct 03, 2010 at 03:13:51PM -0400, Benjamin Johnson wrote: > On Sun, 03 Oct 2010 14:36:14 -0400, Johannes Hofmann > <Johannes.Hofmann(a)gmx.de> wrote: > > >Do you plan to get the windows port into dillo mainline, or do you > >want to maintain it as a patch? > > Getting it into Dillo mainline was always my intention. I do plan > to maintain the SourceForge site for binary releases and other > Windows-specific components, similar to GIMP for Windows. > > >If you plan to get it in, I would suggest to focus on getting in > >what you have before doing other stuff. > > I'm just trying to look ahead, that's all. > > In a nutshell, I'm faced with some difficult technical hurdles, and > somewhat a conflict of interests. On the one hand, I personally am > not fond of DPI, and (as you've seen) question its necessity, > particularly for such basic functionality as non-HTTP protocol > support. On the other, my goal is (and has always been) to get my > code into Dillo mainline, since I have neither the interest nor > resources to maintain a full-blown fork. > > >That would mean: > > > >* splitting up your patch into smaller chunks, > > each with a description of what it does and why it's needed. > > It should be obvious for each patch that it does what you > > described and only that. > > I tried to do that already. The problem is that this is a very > complicated patch, and all the individual "subpatches" are highly > interdependent on one another. In order to effectively split the > patch, I would essentially have to re-code each change manually, > which I currently lack the time to do. That's fine, but I fear nobody else will do the work for you. > > >* Avoid any changes to the code base that are not necessary for the > > windows port (e.g. the include path changes in src/table.cc, or > > the fix for the race mentioned in html.cc - if you think there is a > > bug, this should be discussed on the list independent from the win > > port. The same for the change in decode.c). > > I have not made a single change that is not necessary for the > Windows port. The include path changes are necessary because MinGW > does not accept them as written (relative to the top-level source > directory). Regarding the race condition, that already *has* been > discussed on the list, and the fix was specifically necessary for > the Windows port: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-August/007652.html I have missed that. But I still fail to see why we should need to wait until there is no more connection open - that could take ages. > > >* This iowatch kludge is nasty - as you also state in the > > comment. This must be fixed in some other way. Did you do some > > research on the fltk lists about this? Is this solved in fltk-1.3? > > Yes, I did do research on the fltk lists -- that's how I discovered > its necessity. To wit: > > http://www.mail-archive.com/fltk-bugs@easysw.com/msg01341.html > > Unfortunately, WSAAsyncSelect() doesn't appear to be the only > problem. I patched the fltk source to disable USE_ASYNC_SELECT, to > no avail. That's when I decided to implement the timeout kludge, in > the interest of having *something* working, which I considered > better than having nothing at all. The bug is marked as resolved for fltk-1.3. I'd suggest to write a test program to check whether it works as you expect in fltk-1.3. > > I dislike the timeout kludge as well, since it's slow and extremely > unstable, but as of yet have not found a workable alternative > considering the current implementation. I haven't been able to dig > further into fltk itself, due to lack of time and familiarity with > the codebase (though I intend to someday, as there are some other > things in there that need work, like popup menus on Windows 95). > > By the way, this is one reason I was interested in an alternate > implementation using libcurl -- it would be much simpler than trying > to implement low-level, cross-platform I/O ourselves. I doubt that libcurl would be an option, but as I said, feel free to experiment. Cheers, Johannes

Oct. 3, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Sun, 03 Oct 2010 14:36:14 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Do you plan to get the windows port into dillo mainline, or do you > want to maintain it as a patch? Getting it into Dillo mainline was always my intention. I do plan to maintain the SourceForge site for binary releases and other Windows-specific components, similar to GIMP for Windows. > If you plan to get it in, I would suggest to focus on getting in > what you have before doing other stuff. I'm just trying to look ahead, that's all. In a nutshell, I'm faced with some difficult technical hurdles, and somewhat a conflict of interests. On the one hand, I personally am not fond of DPI, and (as you've seen) question its necessity, particularly for such basic functionality as non-HTTP protocol support. On the other, my goal is (and has always been) to get my code into Dillo mainline, since I have neither the interest nor resources to maintain a full-blown fork. > That would mean: > > * splitting up your patch into smaller chunks, > each with a description of what it does and why it's needed. > It should be obvious for each patch that it does what you > described and only that. I tried to do that already. The problem is that this is a very complicated patch, and all the individual "subpatches" are highly interdependent on one another. In order to effectively split the patch, I would essentially have to re-code each change manually, which I currently lack the time to do. > * Avoid any changes to the code base that are not necessary for the > windows port (e.g. the include path changes in src/table.cc, or > the fix for the race mentioned in html.cc - if you think there is a > bug, this should be discussed on the list independent from the win > port. The same for the change in decode.c). I have not made a single change that is not necessary for the Windows port. The include path changes are necessary because MinGW does not accept them as written (relative to the top-level source directory). Regarding the race condition, that already *has* been discussed on the list, and the fix was specifically necessary for the Windows port: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-August/007652.html > * This iowatch kludge is nasty - as you also state in the > comment. This must be fixed in some other way. Did you do some > research on the fltk lists about this? Is this solved in fltk-1.3? Yes, I did do research on the fltk lists -- that's how I discovered its necessity. To wit: http://www.mail-archive.com/fltk-bugs@easysw.com/msg01341.html Unfortunately, WSAAsyncSelect() doesn't appear to be the only problem. I patched the fltk source to disable USE_ASYNC_SELECT, to no avail. That's when I decided to implement the timeout kludge, in the interest of having *something* working, which I considered better than having nothing at all. I dislike the timeout kludge as well, since it's slow and extremely unstable, but as of yet have not found a workable alternative considering the current implementation. I haven't been able to dig further into fltk itself, due to lack of time and familiarity with the codebase (though I intend to someday, as there are some other things in there that need work, like popup menus on Windows 95). By the way, this is one reason I was interested in an alternate implementation using libcurl -- it would be much simpler than trying to implement low-level, cross-platform I/O ourselves. > * I don't like the DSOCK_NETINET_IN_H and similar defines to include > the right files on each platform. Can't we always include > dsock.h which in turn includes all necessary files? I wasn't sure whether or not to do that, but I erred on the side of selectively including files since it seemed the more conservative option. If you don't like it, feel free to change it. > Cheers, > Johannes Cheers, ~Benjamin

Oct. 3, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

On Sat, Oct 02, 2010 at 03:55:32PM -0400, Benjamin Johnson wrote: > On Sat, 02 Oct 2010 15:27:30 -0400, Johannes Hofmann > <Johannes.Hofmann(a)gmx.de> wrote: > > >I like them and actually there is no way around it. One great > >feature of dillo is that you can fire up multiple processes very > >fast and still have access to the same bookmarks and cookies. > > (1) Can't that be implemented without a separate server process? Sure, you can use flock() or something like that. I think we even had this for cookies some time ago. But you get stale locks and all that. A separate process is the cleaner solution imho. > > (2) Is there any reason to run multiple Dillo processes, anyway? Yes. There are lots of reasons actually. Here are some: * You have separate caches. Stopping one process frees the cache and deletes the history of that process. * If one process crashes the other one continues. That's what google seems to do now with chrome. Dillo had this feature much earlier. * You could have multiple dillo instances on separate X11 sessions. > > (3) How does that affect other protocols (FTP, HTTPS, local file browsing?) ? > > >>>>On a related note, is there any reason not to cut DPI out of the > >>>>download system, i.e. just invoke a separate downloader process > >>>>directly? I'm considering implementing that at least as a temporary > >>>>solution, using my own self-contained download tool. > >>> > >>> The default downloader is a separate process. Before it, we > >>>used a call to wget from a separate process too. You're welcomed > >>>to hook your own preferred application, that's the idea of dpi. > >> > >>Well, I meant that more in the sense of "since the downloader's a > >>separate process anyway, why go through DPI at all?" > > > >Well, we have all the infrastucture for DPI already, why use a new > >mechanism? > > What's the advantage to doing it through DPI, besides that the > infrastructure's already there? See above. > > Despite its perceived redundancy, my mechanism is ultimately > simpler, since there's no interprocess communication involved. It's > also a bit more efficient, since it cuts out the middleman (dpid). I think the efficency argument doesn't count here. If you start a download, the single IPC to the DPI is certainly not an issue. > > I think, by the way, there *are* clear advantages to a separate > downloader: among other things, it allows downloads to continue > after the user exits the browser. On the other hand, I don't see > why the user would need cookies after the browser has exited. Again, see above for reasons to have multiple dillo processes running. > > >>>>Or is something more passed through than just a URL? > >>> > >>> Maybe the target directory&savename. I don't remember well... > >>>You can make the dpip functions log the messages to a file > >>>without much hassle, and see what actually happens. > >> > >>I wrote my own downloader, and patched Dillo so it calls my program > >>directly, bypassing DPI. (It also bypasses the Dillo file dialogs, > >>since my program displays its own.) So far everything seems to be > >>working nicely. > >> > >>I've only implemented the patch for Windows so far, and it needs a > >>bit of cleanup, but if you're curious you can see it here: > >>http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff > >> > >>and the downloader itself: > >>http://dillo-win32.sourceforge.net/dlgui.html > >> > >>I'm tempted to port Dillo to libcurl now, since it works so nicely > >>in my own program, and seems like it would be much more portable > >>(and stable, on Windows) than the current implementation. It would > >>also allow for easier implementation of other protocols, like HTTPS > >>and FTP. Any thoughts? > > > >Hm, sounds like a massive change in a core component, but feel free to > >experiment. > > Well, I've already done one of those with dsock, so why not another? :-) Do you plan to get the windows port into dillo mainline, or do you want to maintain it as a patch? If you plan to get it in, I would suggest to focus on getting in what you have before doing other stuff. That would mean: * splitting up your patch into smaller chunks, each with a description of what it does and why it's needed. It should be obvious for each patch that it does what you described and only that. * Avoid any changes to the code base that are not necessary for the windows port (e.g. the include path changes in src/table.cc, or the fix for the race mentioned in html.cc - if you think there is a bug, this should be discussed on the list independent from the win port. The same for the change in decode.c). * This iowatch kludge is nasty - as you also state in the comment. This must be fixed in some other way. Did you do some research on the fltk lists about this? Is this solved in fltk-1.3? * I don't like the DSOCK_NETINET_IN_H and similar defines to include the right files on each platform. Can't we always include dsock.h which in turn includes all necessary files? Cheers, Johannes

Oct. 3, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Sat, 02 Oct 2010 17:31:07 -0400, Diego . <darkspirit5000(a)gmail.com> wrote: > Your solution only works for downloads. Your downloader can be made a > DPI and you can chose wich to use. Actually downloads do not stop if > dillo close. I'm well aware how DPI is implemented, and that downloads continue when Dillo is exited. My solution is intended in part as a temporary measure, since I need downloads to function regardless of whether DPI is available or not. I do have concerns, however, with both the specific implementation and general (perceived) necessity of DPI. > If the problems are dup2 and sockets dpid can be change to work on > windows. > Dillo always ask the dpi that serves a service before conect to it. > dpid run the DPI so can send dillo the right fd, socket, file or do > other thing. I've been working on that, but with very limited success. dup2 and sockets are the most immediate problem, but there are larger problems beyond that (for example, packaging Dillo/DPI). > dpid avoid to load in every dillo code to handle DPIs or external > programs that will use only one and avoid the synchronize thing. I don't think basic functionality like local file browsing and HTTPS is unnecessary "load in every dillo code". If there's any situation where it's undesired, perhaps the code could be #ifdef'd out and a new autoconf option added (--disable-local-files, etc.) As far as sharing bookmarks, cookies, etc. between browser processes: most major browsers (IE, Firefox, Opera, probably Chrome) allow one browser process running, and if a second is started, it signals the first to take some action (create a new window, for instance). That would still require some amount of IPC, but it's less complicated than DPI, and certainly less wasteful since you don't have multiple instances loading the same UI, static libraries, etc. ~Benjamin

Oct. 3, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Sat, 02 Oct 2010 15:27:30 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I like them and actually there is no way around it. One great > feature of dillo is that you can fire up multiple processes very > fast and still have access to the same bookmarks and cookies. (1) Can't that be implemented without a separate server process? (2) Is there any reason to run multiple Dillo processes, anyway? (3) How does that affect other protocols (FTP, HTTPS, local file browsing?) >> >>On a related note, is there any reason not to cut DPI out of the >> >>download system, i.e. just invoke a separate downloader process >> >>directly? I'm considering implementing that at least as a temporary >> >>solution, using my own self-contained download tool. >> > >> > The default downloader is a separate process. Before it, we >> >used a call to wget from a separate process too. You're welcomed >> >to hook your own preferred application, that's the idea of dpi. >> >> Well, I meant that more in the sense of "since the downloader's a >> separate process anyway, why go through DPI at all?" > > Well, we have all the infrastucture for DPI already, why use a new > mechanism? What's the advantage to doing it through DPI, besides that the infrastructure's already there? Despite its perceived redundancy, my mechanism is ultimately simpler, since there's no interprocess communication involved. It's also a bit more efficient, since it cuts out the middleman (dpid). I think, by the way, there *are* clear advantages to a separate downloader: among other things, it allows downloads to continue after the user exits the browser. On the other hand, I don't see why the user would need cookies after the browser has exited. >> >>Or is something more passed through than just a URL? >> > >> > Maybe the target directory&savename. I don't remember well... >> >You can make the dpip functions log the messages to a file >> >without much hassle, and see what actually happens. >> >> I wrote my own downloader, and patched Dillo so it calls my program >> directly, bypassing DPI. (It also bypasses the Dillo file dialogs, >> since my program displays its own.) So far everything seems to be >> working nicely. >> >> I've only implemented the patch for Windows so far, and it needs a >> bit of cleanup, but if you're curious you can see it here: >> http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff >> >> and the downloader itself: >> http://dillo-win32.sourceforge.net/dlgui.html >> >> I'm tempted to port Dillo to libcurl now, since it works so nicely >> in my own program, and seems like it would be much more portable >> (and stable, on Windows) than the current implementation. It would >> also allow for easier implementation of other protocols, like HTTPS >> and FTP. Any thoughts? > > Hm, sounds like a massive change in a core component, but feel free to > experiment. Well, I've already done one of those with dsock, so why not another? :-) ~Benjamin

Oct. 2, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Sat, Oct 02, 2010 at 02:48:06PM -0400, Benjamin Johnson wrote: > I meant to reply sooner, and got sidetracked with other things... > > On Thu, 30 Sep 2010 07:28:39 -0400, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > >On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote: > >>On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid > >><jcid(a)dillo.org> wrote: > >> > >>> The dpi framework works with isolated processes. A third option > >>>could be to make an alternative implementation that works in Win. > >>>For instance, is there a dbus port running in Win*? > >>> > >> > >>There is, although I have a couple reservations. I'm not sure how > >>cleanly it could be packaged, or whether it would run on Windows 9x > >>(one of my goals is to support all the way back to Windows 95). I > >>also have some personal dislike for it, after dealing with much > >>dbus-related breakage in my Linux development days. > >> > >>I do appreciate the suggestion, though, and if you think it could > >>work, I will certainly look into it. > > > > I haven't used dbus, but it's used in GNU/Linux by some big > >players so I guess it stabilized [1]. Any inter process message- > >passing lib will work, but implementing it well is a hard task, > >that's why I suggested dbus (it has undergone lots of testing). > >Probably there's a better candidate in the embedded area. > > > >[1] http://www.freedesktop.org/wiki/Software/DbusProjects > > My problem with dbus isn't so much stability, as complexity. It's > been a while since I've run Linux, but I vaguely remember dbus's > internal security/permissions were a nightmare. I also vote against dbus. It would be a new dependency and the size of the dbus tarball is currently more than twice the size of dillo-2.2.tar.bz2! > > I'll admit, I'm not the biggest fan of DPI anyway -- relying on > complex interprocess communication even for such simple things as > local file browsing seems like more trouble than it's worth. It's > better than the other way around, re-implementing operating system > functionality inside the browser (as a certain search giant has), > but I'm not yet convinced the advantages truly outweigh the > implementation hassles. I like them and actually there is no way around it. One great feature of dillo is that you can fire up multiple processes very fast and still have access to the same bookmarks and cookies. > > >>On a related note, is there any reason not to cut DPI out of the > >>download system, i.e. just invoke a separate downloader process > >>directly? I'm considering implementing that at least as a temporary > >>solution, using my own self-contained download tool. > > > > The default downloader is a separate process. Before it, we > >used a call to wget from a separate process too. You're welcomed > >to hook your own preferred application, that's the idea of dpi. > > Well, I meant that more in the sense of "since the downloader's a > separate process anyway, why go through DPI at all?" Well, we have all the infrastucture for DPI already, why use a new mechanism? > > >>Or is something more passed through than just a URL? > > > > Maybe the target directory&savename. I don't remember well... > >You can make the dpip functions log the messages to a file > >without much hassle, and see what actually happens. > > I wrote my own downloader, and patched Dillo so it calls my program > directly, bypassing DPI. (It also bypasses the Dillo file dialogs, > since my program displays its own.) So far everything seems to be > working nicely. > > I've only implemented the patch for Windows so far, and it needs a > bit of cleanup, but if you're curious you can see it here: > http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff > > and the downloader itself: > http://dillo-win32.sourceforge.net/dlgui.html > > I'm tempted to port Dillo to libcurl now, since it works so nicely > in my own program, and seems like it would be much more portable > (and stable, on Windows) than the current implementation. It would > also allow for easier implementation of other protocols, like HTTPS > and FTP. Any thoughts? Hm, sounds like a massive change in a core component, but feel free to experiment. Cheers, Johannes

Oct. 2, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

I meant to reply sooner, and got sidetracked with other things... On Thu, 30 Sep 2010 07:28:39 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote: >> On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid >> <jcid(a)dillo.org> wrote: >> >> > The dpi framework works with isolated processes. A third option >> >could be to make an alternative implementation that works in Win. >> >For instance, is there a dbus port running in Win*? >> > >> >> There is, although I have a couple reservations. I'm not sure how >> cleanly it could be packaged, or whether it would run on Windows 9x >> (one of my goals is to support all the way back to Windows 95). I >> also have some personal dislike for it, after dealing with much >> dbus-related breakage in my Linux development days. >> >> I do appreciate the suggestion, though, and if you think it could >> work, I will certainly look into it. > > I haven't used dbus, but it's used in GNU/Linux by some big > players so I guess it stabilized [1]. Any inter process message- > passing lib will work, but implementing it well is a hard task, > that's why I suggested dbus (it has undergone lots of testing). > Probably there's a better candidate in the embedded area. > > [1] http://www.freedesktop.org/wiki/Software/DbusProjects My problem with dbus isn't so much stability, as complexity. It's been a while since I've run Linux, but I vaguely remember dbus's internal security/permissions were a nightmare. I'll admit, I'm not the biggest fan of DPI anyway -- relying on complex interprocess communication even for such simple things as local file browsing seems like more trouble than it's worth. It's better than the other way around, re-implementing operating system functionality inside the browser (as a certain search giant has), but I'm not yet convinced the advantages truly outweigh the implementation hassles. >> On a related note, is there any reason not to cut DPI out of the >> download system, i.e. just invoke a separate downloader process >> directly? I'm considering implementing that at least as a temporary >> solution, using my own self-contained download tool. > > The default downloader is a separate process. Before it, we > used a call to wget from a separate process too. You're welcomed > to hook your own preferred application, that's the idea of dpi. Well, I meant that more in the sense of "since the downloader's a separate process anyway, why go through DPI at all?" >> Or is something more passed through than just a URL? > > Maybe the target directory&savename. I don't remember well... > You can make the dpip functions log the messages to a file > without much hassle, and see what actually happens. I wrote my own downloader, and patched Dillo so it calls my program directly, bypassing DPI. (It also bypasses the Dillo file dialogs, since my program displays its own.) So far everything seems to be working nicely. I've only implemented the patch for Windows so far, and it needs a bit of cleanup, but if you're curious you can see it here: http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff and the downloader itself: http://dillo-win32.sourceforge.net/dlgui.html I'm tempted to port Dillo to libcurl now, since it works so nicely in my own program, and seems like it would be much more portable (and stable, on Windows) than the current implementation. It would also allow for easier implementation of other protocols, like HTTPS and FTP. Any thoughts? ~Benjamin

Oct. 2, 2010

A Dillo-Win32 update

by jcid＠dillo.org

On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote: > On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > > The dpi framework works with isolated processes. A third option > >could be to make an alternative implementation that works in Win. > >For instance, is there a dbus port running in Win*? > > > > There is, although I have a couple reservations. I'm not sure how > cleanly it could be packaged, or whether it would run on Windows 9x > (one of my goals is to support all the way back to Windows 95). I > also have some personal dislike for it, after dealing with much > dbus-related breakage in my Linux development days. > > I do appreciate the suggestion, though, and if you think it could > work, I will certainly look into it. I haven't used dbus, but it's used in GNU/Linux by some big players so I guess it stabilized [1]. Any inter process message- passing lib will work, but implementing it well is a hard task, that's why I suggested dbus (it has undergone lots of testing). Probably there's a better candidate in the embedded area. [1] http://www.freedesktop.org/wiki/Software/DbusProjects > On a related note, is there any reason not to cut DPI out of the > download system, i.e. just invoke a separate downloader process > directly? I'm considering implementing that at least as a temporary > solution, using my own self-contained download tool. The default downloader is a separate process. Before it, we used a call to wget from a separate process too. You're welcomed to hook your own preferred application, that's the idea of dpi. > Or is something more passed through than just a URL? Maybe the target directory&savename. I don't remember well... You can make the dpip functions log the messages to a file without much hassle, and see what actually happens. -- Cheers Jorge.-

Sept. 30, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > The dpi framework works with isolated processes. A third option > could be to make an alternative implementation that works in Win. > For instance, is there a dbus port running in Win*? > There is, although I have a couple reservations. I'm not sure how cleanly it could be packaged, or whether it would run on Windows 9x (one of my goals is to support all the way back to Windows 95). I also have some personal dislike for it, after dealing with much dbus-related breakage in my Linux development days. I do appreciate the suggestion, though, and if you think it could work, I will certainly look into it. On a related note, is there any reason not to cut DPI out of the download system, i.e. just invoke a separate downloader process directly? I'm considering implementing that at least as a temporary solution, using my own self-contained download tool. Or is something more passed through than just a URL? Thanks again, ~Benjamin

Sept. 30, 2010

A Dillo-Win32 update

by jcid＠dillo.org

On Wed, Sep 29, 2010 at 04:51:27PM -0400, Benjamin Johnson wrote: > The browser patch is about as stable as I can get it, so I thought > I'd send it in for your consideration. First the patch, then my > comments: > > http://dillo-win32.sourceforge.net/files/dillo-r1705-win32-20100913-merge.d… > > I'd consider this "merge-ready" in terms of completeness, though I > haven't much tested stability, and I'd need your opinion on coding > style. This is a long patch (~1740 lines), with a lot of separate > but closely-interconnected changes. I'd split it into smaller > subpatches, but I'm not really sure how practical (or possible) that > would be, so my apologies in advance for the length. > > I've run into a major impasse with DPI. Simply put, DPI is not > portable to non-Unix systems. Specifically, there are two main > problems as far as Windows is concerned: (1) lack of Unix signals, > and (2) non-interchangeability of file and socket descriptors. > Since I'm aiming for a native port, an emulation layer such as > Cygwin is absolutely not an option. > > I'm faced with a bit of a dilemma here. The two options I see are > to either redesign DPI, or ditch it altogether; and I don't think > anyone is too keen on either idea. I've considered a fork, but I'm > opposed to the idea on both practical and philosophical grounds (my > goal's to help, not to hurt upstream). Any suggestions? The dpi framework works with isolated processes. A third option could be to make an alternative implementation that works in Win. For instance, is there a dbus port running in Win*? -- Cheers Jorge.-

Sept. 30, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

The browser patch is about as stable as I can get it, so I thought I'd send it in for your consideration. First the patch, then my comments: http://dillo-win32.sourceforge.net/files/dillo-r1705-win32-20100913-merge.d… I'd consider this "merge-ready" in terms of completeness, though I haven't much tested stability, and I'd need your opinion on coding style. This is a long patch (~1740 lines), with a lot of separate but closely-interconnected changes. I'd split it into smaller subpatches, but I'm not really sure how practical (or possible) that would be, so my apologies in advance for the length. I've run into a major impasse with DPI. Simply put, DPI is not portable to non-Unix systems. Specifically, there are two main problems as far as Windows is concerned: (1) lack of Unix signals, and (2) non-interchangeability of file and socket descriptors. Since I'm aiming for a native port, an emulation layer such as Cygwin is absolutely not an option. I'm faced with a bit of a dilemma here. The two options I see are to either redesign DPI, or ditch it altogether; and I don't think anyone is too keen on either idea. I've considered a fork, but I'm opposed to the idea on both practical and philosophical grounds (my goal's to help, not to hurt upstream). Any suggestions? Thanks & cheers, ~Benjamin

Sept. 29, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

yOn Sun, Sep 26, 2010 at 12:04:06AM +0000, corvid wrote: > Johannes wrote: > > Ok here http://flpsed.org/tmp/html_element_style.diff is the updated > > patch. It brings back the bg_color dillorc option. Please give it a try. > > I'm getting an assertion failure with: > > <html> > <head> > <head> > </head> > <body> > </body> > </html> Oh, good point. This needs some thought...

Sept. 26, 2010

[bug]: ignored CSS attributes on html element

by corvid＠lavabit.com

Johannes wrote: > Ok here http://flpsed.org/tmp/html_element_style.diff is the updated > patch. It brings back the bg_color dillorc option. Please give it a try. I'm getting an assertion failure with: <html> <head> <head> </head> <body> </body> </html>

Sept. 26, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 21, 2010 at 10:20:27PM +0200, Johannes Hofmann wrote: > On Tue, Sep 21, 2010 at 01:39:47PM -0400, Jorge Arellano Cid wrote: > > On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote: > > > On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > > > > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > > > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > Please test attached patch. It is a bit more involved than I had > > > > > > > hoped, but it seems necessary after looking at the spec. > > > > > > > > > > > > en.wikipedia (with remote css off) gives me > > > > > > "** WARNING **: No background color found!" msgs. > > > > > > > > > > > > > > > > Yes, I think this is because I had to remove the > > > > > background-color property from the user-agent style in css.cc. > > > > > It's a bit weird: > > > > > The spec says, that the canvas color should either be the background color > > > > > assigned to the <html> tag, or if that has no background color, it > > > > > should be the background color of the <body> tag. > > > > > So we can't no longer set a background color in the user-agent > > > > > style. > > > > > If we assign it to the <html> tag, we will see a weird frame if page > > > > > authors set a background-color on the <body> tag. > > > > > If we assign it to the <body> tag, pages that set the > > > > > background-color for the <html> tag will have a frame. > > > > > > > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > > > > background-color if the page has no background-color on neither the > > > > > <html> nor the <body> tag. > > > > > Opinions? > > > > > > > > Can't we set both <html> and <body> ? > > > > > > Unfortunately no. > > > If we do that and the page sets background-color for body, we would > > > have a frame with our background-color and a box (for <body>) with > > > the background-color defined in the page. > > > Also if the page sets a background-color for <html>, we have a frame > > > with the pages background-color and a box with our color. > > > > I see... > > > > IMHO, having just one place for setting the appearance is an > > important asset (simplicity/orthogonality). > > > > If we can keep this feature without introducing an ugly hack > > I'd go for it. Now, as you know much better the implementation > > details, I leave it for you to decide. > > I fully agree, but currently I don't see any way to set the > background color from the user-agent-, or user-stylesheet such that it > works for pages that set background-color on the <html> element and > for pages that set background-color on the <body> element. > > I will prepare the patch and sleep some nights over it. Then we can > decide whether we commit it. Ok here http://flpsed.org/tmp/html_element_style.diff is the updated patch. It brings back the bg_color dillorc option. Please give it a try. Cheers, Johannes

Sept. 25, 2010

Re: Refreshing pages with incomplete images

by dennisn＠dennisn.dyndns.org

On Wed, 22 Sep 2010 11:06:50 -0400, Jorge Arellano Cid wrote: > On Wed, Sep 22, 2010 at 12:43:03AM -0400, Dennis Nezic wrote: > > Currently refreshing a page only redownloads the text portion (I > > believe) and not the images, which is perfect IF the images have > > been fully downloaded/cached. On my slow connection, image-downloads > > frequently timeout, and refreshing doesn't retry to get them :'(. > > With a slow connection (e.g. dialup), use something like: > > http_max_conns=2 /* or 3 */ > > in dillorc (this solves most of the problem). Yes, lowering that seems to have helped. > If a long image download stalls anyway, you will have to reload > the whole of it: right click image, "Isolate image", reload, > back. It would still be nice if this could be automated via the normal reload mechanism :D.

Sept. 24, 2010

AW: [Dillo-dev] patch: clearer msg when something can't be displayed as an image

by johannes.hofmann＠gmx.de

-----Urspr?ngliche Nachricht----- Von: corvid <corvid(a)lavabit.com> Gesendet: Di 21.09.2010 01:23 An: dillo-dev(a)dillo.org; Betreff: [Dillo-dev] patch: clearer msg when something can't be displayed as an image > I'm sure that our usual > HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" > sort of msg is confusing to users in a "What? Dillo doesn't understand > that character set?" sort of way when an img src attr is supposed to be > modified by javascript or something. > Looks good to me. Cheers, Johannes

Sept. 23, 2010

Refreshing pages with incomplete images

by jcid＠dillo.org

On Wed, Sep 22, 2010 at 12:43:03AM -0400, Dennis Nezic wrote: > Currently refreshing a page only redownloads the text portion (I > believe) and not the images, which is perfect IF the images have been > fully downloaded/cached. On my slow connection, image-downloads > frequently timeout, and refreshing doesn't retry to get them :'(. With a slow connection (e.g. dialup), use something like: http_max_conns=2 /* or 3 */ in dillorc (this solves most of the problem). If a long image download stalls anyway, you will have to reload the whole of it: right click image, "Isolate image", reload, back. -- Cheers Jorge.-

Sept. 22, 2010

Refreshing pages with incomplete images

by furaisanjin＠gmail.com

Hi. That's true. Probably we should have "reload image" in IMAGE OPTIONS menu. Regards, furaisanjin 2010/9/22 Dennis Nezic <dennisn(a)dennisn.dyndns.org>: > Currently refreshing a page only redownloads the text portion (I > believe) and not the images, which is perfect IF the images have been > fully downloaded/cached. On my slow connection, image-downloads > frequently timeout, and refreshing doesn't retry to get them :'(. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 22, 2010

Refreshing pages with incomplete images

by dennisn＠dennisn.dyndns.org

Currently refreshing a page only redownloads the text portion (I believe) and not the images, which is perfect IF the images have been fully downloaded/cached. On my slow connection, image-downloads frequently timeout, and refreshing doesn't retry to get them :'(.

Sept. 22, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 21, 2010 at 01:39:47PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote: > > On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > > > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > Please test attached patch. It is a bit more involved than I had > > > > > > hoped, but it seems necessary after looking at the spec. > > > > > > > > > > en.wikipedia (with remote css off) gives me > > > > > "** WARNING **: No background color found!" msgs. > > > > > > > > > > > > > Yes, I think this is because I had to remove the > > > > background-color property from the user-agent style in css.cc. > > > > It's a bit weird: > > > > The spec says, that the canvas color should either be the background color > > > > assigned to the <html> tag, or if that has no background color, it > > > > should be the background color of the <body> tag. > > > > So we can't no longer set a background color in the user-agent > > > > style. > > > > If we assign it to the <html> tag, we will see a weird frame if page > > > > authors set a background-color on the <body> tag. > > > > If we assign it to the <body> tag, pages that set the > > > > background-color for the <html> tag will have a frame. > > > > > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > > > background-color if the page has no background-color on neither the > > > > <html> nor the <body> tag. > > > > Opinions? > > > > > > Can't we set both <html> and <body> ? > > > > Unfortunately no. > > If we do that and the page sets background-color for body, we would > > have a frame with our background-color and a box (for <body>) with > > the background-color defined in the page. > > Also if the page sets a background-color for <html>, we have a frame > > with the pages background-color and a box with our color. > > I see... > > IMHO, having just one place for setting the appearance is an > important asset (simplicity/orthogonality). > > If we can keep this feature without introducing an ugly hack > I'd go for it. Now, as you know much better the implementation > details, I leave it for you to decide. I fully agree, but currently I don't see any way to set the background color from the user-agent-, or user-stylesheet such that it works for pages that set background-color on the <html> element and for pages that set background-color on the <body> element. I will prepare the patch and sleep some nights over it. Then we can decide whether we commit it. Cheers, Johannes

Sept. 21, 2010

[bug]: ignored CSS attributes on html element

by jcid＠dillo.org

On Sun, Sep 19, 2010 at 08:51:25PM +0200, Johannes Hofmann wrote: > On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > > Johannes wrote: > > > > > Please test attached patch. It is a bit more involved than I had > > > > > hoped, but it seems necessary after looking at the spec. > > > > > > > > en.wikipedia (with remote css off) gives me > > > > "** WARNING **: No background color found!" msgs. > > > > > > > > > > Yes, I think this is because I had to remove the > > > background-color property from the user-agent style in css.cc. > > > It's a bit weird: > > > The spec says, that the canvas color should either be the background color > > > assigned to the <html> tag, or if that has no background color, it > > > should be the background color of the <body> tag. > > > So we can't no longer set a background color in the user-agent > > > style. > > > If we assign it to the <html> tag, we will see a weird frame if page > > > authors set a background-color on the <body> tag. > > > If we assign it to the <body> tag, pages that set the > > > background-color for the <html> tag will have a frame. > > > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > > background-color if the page has no background-color on neither the > > > <html> nor the <body> tag. > > > Opinions? > > > > Can't we set both <html> and <body> ? > > Unfortunately no. > If we do that and the page sets background-color for body, we would > have a frame with our background-color and a box (for <body>) with > the background-color defined in the page. > Also if the page sets a background-color for <html>, we have a frame > with the pages background-color and a box with our color. I see... IMHO, having just one place for setting the appearance is an important asset (simplicity/orthogonality). If we can keep this feature without introducing an ugly hack I'd go for it. Now, as you know much better the implementation details, I leave it for you to decide. -- Cheers Jorge.-

Sept. 21, 2010

patch: clearer msg when something can't be displayed as an image

by corvid＠lavabit.com

I'm sure that our usual HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" sort of msg is confusing to users in a "What? Dillo doesn't understand that character set?" sort of way when an img src attr is supposed to be modified by javascript or something.

Sept. 21, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Sat, Sep 18, 2010 at 10:06:54PM -0400, Jorge Arellano Cid wrote: > On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > Johannes wrote: > > > > Please test attached patch. It is a bit more involved than I had > > > > hoped, but it seems necessary after looking at the spec. > > > > > > en.wikipedia (with remote css off) gives me > > > "** WARNING **: No background color found!" msgs. > > > > > > > Yes, I think this is because I had to remove the > > background-color property from the user-agent style in css.cc. > > It's a bit weird: > > The spec says, that the canvas color should either be the background color > > assigned to the <html> tag, or if that has no background color, it > > should be the background color of the <body> tag. > > So we can't no longer set a background color in the user-agent > > style. > > If we assign it to the <html> tag, we will see a weird frame if page > > authors set a background-color on the <body> tag. > > If we assign it to the <body> tag, pages that set the > > background-color for the <html> tag will have a frame. > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > background-color if the page has no background-color on neither the > > <html> nor the <body> tag. > > Opinions? > > Can't we set both <html> and <body> ? Unfortunately no. If we do that and the page sets background-color for body, we would have a frame with our background-color and a box (for <body>) with the background-color defined in the page. Also if the page sets a background-color for <html>, we have a frame with the pages background-color and a box with our color. Cheers, Johannes

Sept. 19, 2010

[bug]: segfault from CSS patch + table + drag and drop

by Johannes.Hofmann＠gmx.de

On Sun, Sep 19, 2010 at 03:36:18PM +0100, Jeremy Henty wrote: > > There is unfortunately a severe problem with the CSS patch that was > posted recently (the one that fixed the handling of CSS properties on > the HTML element). It makes Dillo segfault when you drag the cursor > across the text in a table cell. Test HTML and a gdb backtrace are > attached. You can see that dw::fltk::FltkViewBase::drawRectangle() is > called with a NULL color. That is probabely because I had to remove the background-color definition from the user-agent style (see the other mail regarding reintroduction of bg_color in dillorc). This should be fixed once we add bg_color or find another solution. Cheers, Johannes

Sept. 19, 2010

[bug]: segfault from CSS patch + table + drag and drop

by onepoint＠starurchin.org

There is unfortunately a severe problem with the CSS patch that was posted recently (the one that fixed the handling of CSS properties on the HTML element). It makes Dillo segfault when you drag the cursor across the text in a table cell. Test HTML and a gdb backtrace are attached. You can see that dw::fltk::FltkViewBase::drawRectangle() is called with a NULL color. I haven't determined exactly which circumstances trigger the problem - text in s and <li>s appears to be OK, but text in a <td> reliably segfaults. Any suggestions as to other elements that I could test? (NB: I compile Dillo with -O0, your backtrace may look a bit different if you use a different optimisation level. Also, I always run Dillo from valgrind.) Regards, Jeremy Henty

Sept. 19, 2010

[bug]: ignored CSS attributes on html element

by jcid＠dillo.org

On Sat, Sep 18, 2010 at 07:23:08PM +0200, Johannes Hofmann wrote: > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > Johannes wrote: > > > Please test attached patch. It is a bit more involved than I had > > > hoped, but it seems necessary after looking at the spec. > > > > en.wikipedia (with remote css off) gives me > > "** WARNING **: No background color found!" msgs. > > > > Yes, I think this is because I had to remove the > background-color property from the user-agent style in css.cc. > It's a bit weird: > The spec says, that the canvas color should either be the background color > assigned to the <html> tag, or if that has no background color, it > should be the background color of the <body> tag. > So we can't no longer set a background color in the user-agent > style. > If we assign it to the <html> tag, we will see a weird frame if page > authors set a background-color on the <body> tag. > If we assign it to the <body> tag, pages that set the > background-color for the <html> tag will have a frame. > > So maybe we need to reintroduce the bg_color dillorc option to set a > background-color if the page has no background-color on neither the > <html> nor the <body> tag. > Opinions? Can't we set both <html> and <body> ? -- Cheers Jorge.-

Sept. 19, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Sat, Sep 18, 2010 at 06:54:00PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > > Johannes wrote: > > > > Please test attached patch. It is a bit more involved than I had > > > > hoped, but it seems necessary after looking at the spec. > > > > > > en.wikipedia (with remote css off) gives me > > > "** WARNING **: No background color found!" msgs. > > > > > > > Yes, I think this is because I had to remove the > > background-color property from the user-agent style in css.cc. > > It's a bit weird: > > The spec says, that the canvas color should either be the background color > > assigned to the <html> tag, or if that has no background color, it > > should be the background color of the <body> tag. > > So we can't no longer set a background color in the user-agent > > style. > > If we assign it to the <html> tag, we will see a weird frame if page > > authors set a background-color on the <body> tag. > > If we assign it to the <body> tag, pages that set the > > background-color for the <html> tag will have a frame. > > > > So maybe we need to reintroduce the bg_color dillorc option to set a > > background-color if the page has no background-color on neither the > > <html> nor the <body> tag. > > Opinions? > > Is it incorrect for dillo to have a body textblock smaller than the whole page? If I check <body style="border: 1px solid black"> dillo </body> with dillo and firefox, it seems that both do more or less the same. Cheers, Johannes

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by corvid＠lavabit.com

Johannes wrote: > On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > > Johannes wrote: > > > Please test attached patch. It is a bit more involved than I had > > > hoped, but it seems necessary after looking at the spec. > > > > en.wikipedia (with remote css off) gives me > > "** WARNING **: No background color found!" msgs. > > > > Yes, I think this is because I had to remove the > background-color property from the user-agent style in css.cc. > It's a bit weird: > The spec says, that the canvas color should either be the background color > assigned to the <html> tag, or if that has no background color, it > should be the background color of the <body> tag. > So we can't no longer set a background color in the user-agent > style. > If we assign it to the <html> tag, we will see a weird frame if page > authors set a background-color on the <body> tag. > If we assign it to the <body> tag, pages that set the > background-color for the <html> tag will have a frame. > > So maybe we need to reintroduce the bg_color dillorc option to set a > background-color if the page has no background-color on neither the > <html> nor the <body> tag. > Opinions? Is it incorrect for dillo to have a body textblock smaller than the whole page? (I remember looking into this when we couldn't pop up menus below the bottom of the textblock, and I think it was either not quite trivial, or ugly to deal with, but if we accumulate other ugliness to work around it...)

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Sat, Sep 18, 2010 at 02:44:20AM +0000, corvid wrote: > Johannes wrote: > > Please test attached patch. It is a bit more involved than I had > > hoped, but it seems necessary after looking at the spec. > > en.wikipedia (with remote css off) gives me > "** WARNING **: No background color found!" msgs. > Yes, I think this is because I had to remove the background-color property from the user-agent style in css.cc. It's a bit weird: The spec says, that the canvas color should either be the background color assigned to the <html> tag, or if that has no background color, it should be the background color of the <body> tag. So we can't no longer set a background color in the user-agent style. If we assign it to the <html> tag, we will see a weird frame if page authors set a background-color on the <body> tag. If we assign it to the <body> tag, pages that set the background-color for the <html> tag will have a frame. So maybe we need to reintroduce the bg_color dillorc option to set a background-color if the page has no background-color on neither the <html> nor the <body> tag. Opinions? Cheers, Johannes

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by onepoint＠starurchin.org

On Fri, Sep 17, 2010 at 11:20:02PM +0200, Johannes Hofmann wrote: > Please test attached patch. It is a bit more involved than I had > hoped, but it seems necessary after looking at the spec. It works! Regards, Jeremy Henty

Sept. 18, 2010

[bug]: ignored CSS attributes on html element

by corvid＠lavabit.com

Johannes wrote: > Please test attached patch. It is a bit more involved than I had > hoped, but it seems necessary after looking at the spec. en.wikipedia (with remote css off) gives me "** WARNING **: No background color found!" msgs.

Sept. 18, 2010