- Dillo-dev - lists.mailman3.com

Future of dillo2

by corvid＠lavabit.com

The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 (dillo+blfs mentioned previously by Jeremy in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/004009.html)

May 12, 2008

Daily builds and tests / 0install feeds / PIE

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey hey :) I setup two boxes (one x86 running Debian lenny, one x86_64 running Ubuntu Hardy) to build daily snapshots of dillo2 (and fltk2). Tarballs, logs and screenshots are located at https://winter.gotdns.org/~teythoon/build/dillo2/ [suggestions for more interesting screenshots are welcome, like some testcases...] I also created a 0install feed (see http://0install.net/) for those daily builds. If you are on a "not that outdated" linux distribution (think of the libraries) on either x86 or x86_64 you can start dillo by running $ 0launch https://winter.gotdns.org/~teythoon/build/0feeds/dillo-fltk.xml If there is some interest in this I will try to make the builds more general (linking against older/more general versions of the required libraries etc). 0install feeds require programs to be position independent. Not like - -fpic or -pie but they should work where ever they and their files lie within the virtual file system. This is mostly true for dillo. dpid is located via PATH but the location to the dpis is (somewhat) hardcoded into the dpirc. So I went into dpid.c/register_all and poked around. Attached is a patch that allows me to specify an additional location for dpis via the environment variable DPIPATH. I also reorganized the code somewhat to minimize code duplication and I removed usr_srv_num since it was unused. Please let me know what you think :) Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIJw6poPmwNWhsaZYRAj4hAJ4rmvSQPPnHiGFQMXaTAGw3wg4JOQCeM9M3 oT6YvhD/s1ncdMQqAMifxgA= =NxaA -----END PGP SIGNATURE-----

May 11, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by jcid＠dillo.org

On Sat, May 10, 2008 at 09:11:27PM +0000, corvid wrote: > Jorge wrote: > > There's still a bug hiding, most probably inside the code > > setting the scroll position in dw2. When you have a page with > > repush (i.e. with charset specified in META element, e.g. > > www.dillo.org :), and you scroll the page, and then reload. It > > will be shown from the origin, even though a_UIcmd_set_scroll_xy > > is called from nav.c:321 with the right coords (enable the _MSG > > to check). > > Scrolled down a little and hit reload. > In Layout::adjustScrollPos(), scrollY of 60 became 0 because > canvasAscent == 5 and canvasDescent == 5. > Looking at the backtrace, > a_UIcmd_set_scroll_xy() from a_Nav_expect_done() from a_Web_dispatch_by_type() > would seem to be too early. AFAIR it was handled with an idle function in dw1 in dillo1. Now it's also handled with an idle function, and I seem to recall Sebastian told me something about anchors long ago, but I don't remember. It is tricky because you have to handle several cases, with some events. For instance: * When the page is still loading and you have an anchor to scroll to. Here you have to retry until the page loads enough to scroll to the anchor, and you should keep watching just in case an image placed before the anchor arrives later, and then adjust again. Now if the user decides to scroll with the mouse, before the position settles, then you have to abort the idle scrolling, and let him control it. All this seasoned with window resize, page changes and other events. :-) -- Cheers Jorge.-

May 11, 2008

Future of dillo2

by jcid＠dillo.org

On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote: > Hi, Hi Sebastian! > just if you were courious: I'm still living and will continue working > on dillo. That's very good news. New developers are helping to push the project forward, and your presence is a very important asset for the team. > > On Sun, Apr 20, Jorge Arellano Cid wrote: > > [...] > > We could: > > > > * Attract new developers with a dillo2 release, > > leveraging the excellent documentation that we have. > > We have: > > - extensive documentations on the critical parts of dillo, expecially > on Dw, > - a prototype for CSS, and > - some more documents and prototypes on future ideas, including > scripting and graphical plugins. > > These should be copied on the web sever, and there should be a > prominent note on the web site linking to a new delevolers' section. > (Since attracting developers has high priority, this is what a visitor > should notice first.) Yes, I was planning on stating the quest for more developers in the splash page of the next release. BTW, it'd be great to also convert dillo2's plain text docs to doxygen format someday. > For those not listening to dillo-dev, it is important to know that > dillo is still an active project. I think we can sort the house and then make a release so the world knows. That's why having TABS and at least a CSS prototype matters. I don't want reviews to end with the typical line: "but no TABS and no CSS". ;-) If we have TABS (a thing I can spare some time to implement) and a CSS protoype published somewhere, the message will be more like: "it comes with: ..., antialiased fonsts, low-dependencies, UTF-8, TABS, and they already started with CSS." That sounds much better! > > * Planning for CSS, floating objects and TABS. > > (this are important features to a nice browsing experience) > > Just FYI: I've started a bit on floats. Jorge, I once told you that it > would take a week; actually it is a bit more complicated, nevertheless > it is not a big job like CSS. Speaking about floats, I was trying to make NBSP (non breaking spaces) work for pages like: http://fltk.org/newsgroups.php?gfltk.development+T (with a narrow window, the parenthesis are spared). but found that NBSP-handling wasn't coded in textblock yet: /* NOTE: Most code relies on that all values of nowrap are * equal for all words within one line. */ I planned to give it a try, but didn't know what was the model for handling it (a flag in the previous word, a flag in the previous and next word, an empty word, etc). Now that you're working in the textblock, can you give it a review? The attached patch is what the parser (html.cc) could look like to handle this. It uses WHITE_SPACE_NOWRAP in style, but I didn't know whether to use: addText(strdup(""), S_TOP(html)->style); or DW2TB(html->dw)->addSpace(S_TOP(html)->style); for NBSP whitespace. It should be simple to test with it. > > * Coordinate with FLTK2, DSL (Damn small linux) and other > > lightweight distros, Debian installer team, MINIX3, etc. > > Perhaps we can find there other "lightweight zealots". :-) Yes, and maybe someday people will start liking/using this lightweight browser. AMEN -- Cheers Jorge.-

May 11, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by corvid＠lavabit.com

Jorge wrote: > There's still a bug hiding, most probably inside the code > setting the scroll position in dw2. When you have a page with > repush (i.e. with charset specified in META element, e.g. > www.dillo.org :), and you scroll the page, and then reload. It > will be shown from the origin, even though a_UIcmd_set_scroll_xy > is called from nav.c:321 with the right coords (enable the _MSG > to check). Scrolled down a little and hit reload. In Layout::adjustScrollPos(), scrollY of 60 became 0 because canvasAscent == 5 and canvasDescent == 5. Looking at the backtrace, a_UIcmd_set_scroll_xy() from a_Nav_expect_done() from a_Web_dispatch_by_type() would seem to be too early.

May 10, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by jcid＠dillo.org

Hi, On Thu, May 08, 2008 at 09:25:59PM +0000, corvid wrote: > Jorge wrote: > > > [Johannes wrote:] > > > I noticed one regression with the new anchor code: > > > The "Continue Reading Older Posts" link on www.boingboing.net > > > (e.g. http://www.boingboing.net/2008/04/03/#entry-44240) no longer > > > scrolls to the right position. > > > > There were mixed issues here. > > > > I just committed a patch that modifies/fixes anchor handling > > with repush (on the last weeks anchors didn't work for me even > > inside the bookmarks page). > > > > Now it works, and more like Firefox. This is, now reloading a > > page with fragment, scrolls to the fragment position, but going > > back and forward remembers the last user-scrolled position; quite > > comfortable. > > > > The page you mention, works OK when it's a local file, but not > > from the network. This looks like a bug hiding in the offset > > calculation or scroll adjustment while the page loads images. > > > > In brief: with the patch the situation improves a lot, and > > there's still a bug to fix. > > Things seem flaky now with redirection. > > Here's what happens if I > 1 type in dillo.org > 2 type in minix3.org > > $ dillo > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='about:blank' > Nav_open_url: new url='http://dillo.org' > Dns_server [0]: dillo.org is 0x8171648 > Connecting to 134.102.206.165 > Nav_open_url: new url='http://www.dillo.org/' > Dns_server [0]: www.dillo.org is 0x8194228 > Connecting to 134.102.206.165 > META Content-Type changes charset to: iso-8859-1 > Nav_open_url: new url='http://www.dillo.org/' > META Content-Type gave charset as: iso-8859-1 > a_Nav_expect_done: repush! > Nav_open_url: new url='http://minix3.org' > Dns_server [0]: minix3.org is 0x8147220 > Connecting to 130.37.20.20 > Nav_open_url: new url='http://www.minix3.org/' > Dns_server [0]: www.minix3.org is 0x8198090 > Connecting to 130.37.20.20 > a_Nav_expect_done: e2ereload! > META Content-Type changes charset to: iso-8859-1 > Nav_open_url: new url='http://www.dillo.org/' > META Content-Type gave charset as: iso-8859-1 > a_Nav_expect_done: repush! > > I did not press Back. Oh yes. I didn't want to dig deep into it, but after this there was no chance to hide. :) There was a semantic confussion with the E2EReload flag, which was split into URL_E2EQuery and URL_ReloadPage. Now we can tell the difference between an first-time E2EQuery and an E2E reload. Patch committed. There's still a bug hiding, most probably inside the code setting the scroll position in dw2. When you have a page with repush (i.e. with charset specified in META element, e.g. www.dillo.org :), and you scroll the page, and then reload. It will be shown from the origin, even though a_UIcmd_set_scroll_xy is called from nav.c:321 with the right coords (enable the _MSG to check). -- Cheers Jorge.-

May 10, 2008

[patch]: dillo2 configure.in update for latest GNU m4

by jcid＠dillo.org

On Sat, May 10, 2008 at 08:37:36AM +0100, Jeremy Henty wrote: > On Sat, May 10, 2008 at 07:45:27AM +0100, Jeremy Henty wrote: > > > ... "AC_SUBST(src doc)" complains that "src doc" is not a valid > > shell tag. ... Anyway, replacing "AC_SUBST(src doc)" with > > "AC_SUBST(src)" and "AC_SUBST(doc)" seems to fix things. Patch > > attached. > > On second thoughts, it appears that "AC_SUBST(src doc)" does nothing > because the *.in files don't contain "@src doc@", "@src@" or "@doc@" > anywhere. Maybe we should just delete it. Here's an alternative > patch that does that. Committed. -- Cheers Jorge.-

May 10, 2008

should zlib be required?

by joerg.sonnenberger＠web.de

On Sat, May 10, 2008 at 12:17:37PM +0000, corvid wrote: > Should zlib be required? Given many sites allow compression for HTML pages, it is useful to have around anyway. I would just make it a requirement. Joerg

May 10, 2008

should zlib be required?

by corvid＠lavabit.com

Should zlib be required? I notice that testing for zlib is currently just a part of deciding whether to enable png. I either need to make configure.in require it, or make zlib optional with some ifdefs. As for which, though, I don't have much of an opinion.

May 10, 2008

[patch]: dillo2 configure.in update for latest GNU m4

by onepoint＠starurchin.org

On Sat, May 10, 2008 at 07:45:27AM +0100, Jeremy Henty wrote: > ... "AC_SUBST(src doc)" complains that "src doc" is not a valid > shell tag. ... Anyway, replacing "AC_SUBST(src doc)" with > "AC_SUBST(src)" and "AC_SUBST(doc)" seems to fix things. Patch > attached. On second thoughts, it appears that "AC_SUBST(src doc)" does nothing because the *.in files don't contain "@src doc@", "@src@" or "@doc@" anywhere. Maybe we should just delete it. Here's an alternative patch that does that. Jeremy Henty

May 10, 2008