April 2004 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] ftp, ssl, download plugins not working

by Jorge Arellano Cid

On Sun, 18 Apr 2004, Barry Kauler wrote: > Jorge, > Below is a repeat of part of my last posting in thread "Can't start dpid". > I would like to know, is there anything further that I can do > to help chase this bug down? Yes, surely you can! Yesterday it happened to me on my machine, so today (Sunday 18), I'm going trying to chase the bug. Probably I'll add some debugging code to the dpis and try to reproduce the bug, then I'll contact you. Cheers Jorge.- > > > > First, check whether the bookmarks dpi works. If it does, then > > > the dpid launch (by dillo) and dpi launch (by dpid) are ok. If > > > this is true, test with the hello and the ftp dpis. > > > > > > If all of them work, we should be looking closer into the > > > downloads dpi. > > > > Yes, bookmarks works! > > After creating a bookmark, I then selected it, and this is the stdout: > > > > Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] > > Dpi: [Dpi_process_io] IOClose > > Nav_open_url: Url=>http://www.goosee.com< > > > > However, ftp doesn't work. Here is the output: > > > > Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< > > url_str = ftp://ibiblio.org/pub/Linux/distributions > > Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] > > Dpi: [Dpi_process_io] IOClose > > > > That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference. > > > > Regards, > > Barry Kauler > > > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev(a)lists.auriga.wearlab.de > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > >

April 18, 2004

ftp, ssl, download plugins not working

by Barry Kauler

Jorge, Below is a repeat of part of my last posting in thread "Can't start dpid". I would like to know, is there anything further that I can do to help chase this bug down? > > First, check whether the bookmarks dpi works. If it does, then > > the dpid launch (by dillo) and dpi launch (by dpid) are ok. If > > this is true, test with the hello and the ftp dpis. > > > > If all of them work, we should be looking closer into the > > downloads dpi. > > Yes, bookmarks works! > After creating a bookmark, I then selected it, and this is the stdout: > > Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] > Dpi: [Dpi_process_io] IOClose > Nav_open_url: Url=>http://www.goosee.com< > > However, ftp doesn't work. Here is the output: > > Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< > url_str = ftp://ibiblio.org/pub/Linux/distributions > Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] > Dpi: [Dpi_process_io] IOClose > > That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference. > > Regards, > Barry Kauler > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 18, 2004

[Dillo-dev]Bookmarks, Tabs

by Tom Barnes-Lawrence

Hi all, I've got 2 questions to ask: 1)- I was on the list back in January, and amongst other things, I mentioned that I'd consider it a huge improvement if the bookmarks DPI were made to allow for a nested hierarchy of sections. Jorge and Thorben pointed out that it wasn't a priority at the time, and that I should write it myself if I wanted it. Unfortunately, I too had things to be doing back then, but about a month ago, I set about doing some work on such a thing. -It is written in Perl, rather than C; it seemed a good choice due to all the text manipulation, etc. This might be considered a problem if Dillo is being used on platforms where Perl isn't (readily) available, but AFAICT the Windows version of Dillo is a purely 3rd party thing that isn't directly supported by the project, and Perl for Windows does *exist*... I don't know if there'd be any other issues with this decision though. -I moved much of the Dillo-DPI specific stuff into a separate file, hoping to make it a Perl Module, but I know nothing about how that works (and I can't get the Camel book ATM because I'm broke) and couldn't understand the relevant man page, so I don't think it turned out how modules are supposed to. I mention this because it could maybe end up useable by any other Perl-based DPIs that get written. -It currently uses the "ngbm" DPI name (for "Next Generation BookMarks"), and uses ngbm.txt for the bookmarks file, to avoid breaking the existing bookmarks program. That's because it's not ready yet. -It *does* implement the nested sections stuff I wanted that the current bm dpi doesn't, with a file format that's backwards compatible with the current one- so you can get it to read your existing bm.txt file. -BUT I only worked on it for about a day, and much of that was spent trying to figure out how it was supposed to communicate, so it still doesn't have much of the important functionality, such as actually adding or modifying any bookmarks or sections. Also, as I was hacking away a lot to try to get it to work at all, there's a lot of commented-out debug stuff, and much of the notes and comments are probably wrong now (I don't think I fixed them whilst I was changing the code and the design). I didn't want to go quietly working away at it for ages and then find that actually someone else was quietly working away at the same thing, for example (also the DPI handling stuff got incredibly frustrating, which put me off doing any more for a while). Unfortunately, I kept forgetting to do *anything else* about it because I had other things to think about :P SO: Would this be of any interest to the project in whatever way? I figure I could (a) post the existing code, get a bit of feedback and then do some more work on it, or (b) give the code to the project and let someone else take it over from me. (or (c) I could just keep it to myself...) 2)-Since my high-res monitor blew up in December, I installed Frank's tabs+ frames patch, and I find it helps enormously- I don't think I could manage without it now. Unfortunately, AFAICT Frank has either left the project or gone on holiday or something (though I can't find any explanation anywhere), and the latest version on his site (which I'm using) only works with an old CVS version from November, so I'm still having to put up with the bugs that have been fixed in 0.8. Gah! I saw after 0.8 was released, someone on the list said he'd try to take on the tabs/frames patch in some way, but I didn't hear anything more about it. Is there *any* news on this whatsoever? I'd really like to be able to upgrade. Thanks in advance, Tom Barnes-Lawrence -- Signature? I have no need of signatures

April 18, 2004

Re: [Dillo-dev]HTML Policy and New parser improvements

by Jim Nutt

On Fri, 16 Apr 2004 12:59:35 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > After the new parser was introduced (0.8.0), Dillo featured > much better HTML error detection, but it rendered malformed HTML > a bit worst. It was a good trade off from the "standards" vertex > of the above mentioned triangle, but I also knew that it was not > going to be that much amusing for the "users" vertex. > > These days I've been working on improving the parser and > bug-meter by introducing information about the inline, block and > flow content models of HTML. > > After having that information in place, it was easy to produce > better and more accurate bug detection and also to improve the > rendering more towards what it used to be. > > So that's the good news: the new CVS contains code with an > improved parser that hopefully will be a glad surprise for our > users. Wow! I can see a big improvement, lots of sites that rendered readably, but 'iffy', are now much clearer and cleaner. -- jim nutt home: jim(a)nuttz.org jabber: jimnutt(a)jabber.com work: jimnutt(a)vestek.com ms msg: jim(a)nuttz.org pgp id: 1ECBCC78

April 16, 2004

[Dillo-dev]fonts

by Joe Corneli

My ~/.dillo/.dillorc contains # Fontname for variable width rendering (most of the text). # - some fonts may slow down rendering, some others not! # - try to tune a fontname/font_factor combination. # Ex. {helvetica, lucida, times, "new century schoolbook", utopia, ...} vw_fontname=utopia # Fontname for fixed width rendering (mainly <pre> quoted text) fw_fontname=courier # All fontsizes are scaled by this value (default is 1.0) font_factor=3.0 The font that is actually used appears to be the same as the default. Can you please suggest how to debug this or how to actually change the font? I'm running OS X, using Dillo 0.8.0 from Fink. Joe

April 16, 2004

[Dillo-dev]HTML Policy and New parser improvements

by Jorge Arellano Cid

Hi there, Most of us are familiarized with the aforism about our HTML parsing policy stated in the [Project Notes]: "Our policy with HTML is not to try to render badly written HTML, ideally send a warning message, and not to crash!" Here goes the rationale behind it. I wrote it sometime ago as an email answer, and here I quote an improved version: <q> About our parsing policy ------------------------ These days I have thought a lot about this subject. In fact an important part of the work of a project maintainer is indeed to make a stance on the difficult decisions; those that are not white or black, but a trade off. With regard to our parsing policy, imagine a triangle with the following vertices: * Standards (W3C) * Web site authors * Users Each vertex represents the exact position of its naming group. The inside area, the whole space of stances anyone could take. Each group has its own interests, sometimes opposed and sometimes very near. The position of a web browser can be visualized as a point within the area of that triangle determined by its development team. Dillo should have to be in the vertex of the W3C, but that would make it almost useless because of the horrible state of the HTML in the Web (aka. "Tag Soup"). For that reason we make some exceptions so that dillo can render a larger set of the web, by correcting some HTML faults, but we keep close to the W3C vertex. An standards compatible browser, as Mozilla, should be close to the W3C, but I understand it would never manage to be a canditate to replace IE if it did (a trade off). Actually it locates alongside the authors-users side AFAIU. As our main objective is the democratization of the access to the internet's information, and that has direct relation with the use of standards, we follow the path of respecting and promoting them. The idea of adding an HTML quality meter to the interface, in the form of a face icon and the number of detected errors, surges as a good idea to improve dillo as a QA tool for content authors. I've also thought of adding a "combat mode rendering" button. That is a way of parsing the worst sites into a basic an simple rendering. That way, users would be one click away from being able to "see" pages with awful HTML. These two ideas would help dillo to keep close to the correct vertex of the triangle, while also becoming a tool to help web authors to provide more standards compliant content. </q> After the new parser was introduced (0.8.0), Dillo featured much better HTML error detection, but it rendered malformed HTML a bit worst. It was a good trade off from the "standards" vertex of the above mentioned triangle, but I also knew that it was not going to be that much amusing for the "users" vertex. These days I've been working on improving the parser and bug-meter by introducing information about the inline, block and flow content models of HTML. After having that information in place, it was easy to produce better and more accurate bug detection and also to improve the rendering more towards what it used to be. So that's the good news: the new CVS contains code with an improved parser that hopefully will be a glad surprise for our users. From the Changelog: * Added container|inline model information to the HTML element table, and made the bug-meter and the parser aware of it. This both improves bug detection and rendering. * Fixed newly detected HTML bugs in bookmarks dpi and file.c. * Fixed opening files with a ':' character in its name (again). * Added binaryconst.h (allows for binary constants in C). * Fixed The ladder effect with lists (BUG#534). So go ahead and try it! Cheers Jorge.-

April 16, 2004

Re: [Dillo-dev]Can't start dpid

by Barry Kauler

> > I get this output from dillo on the stdout/errout: > > > > Nav_open_url: Url=>https://www.paypal.com< > > url_str = https://www.paypal.com > > Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] > > Dpi: [Dpi_process_io] IOClose > > > > The paypal site is working, I just checked with Mozilla. > > Hmmm, it could be an issue with wget. > > The https dpi is an experimental prototype, that's why it > wasn't announced with fanfare in 0.8.0. > Jorge, something that may interest you. In Puppy Linux I am also using the "Light" web browser, which is a frontend to Mozilla. Very very lightweight. For download it uses wget, which works fine. I can't recall exactly, but it downloads to the home folder, no choice, but it is possible to get the Moz destination dialog box to come up, but can't be changed out of the home folder. Light is not actively being developed anymore, but maybe the code would be useful, for reference on how he got wget going. > First, check whether the bookmarks dpi works. If it does, then > the dpid launch (by dillo) and dpi launch (by dpid) are ok. If > this is true, test with the hello and the ftp dpis. > > If all of them work, we should be looking closer into the > downloads dpi. Yes, bookmarks works! After creating a bookmark, I then selected it, and this is the stdout: Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] Dpi: [Dpi_process_io] IOClose Nav_open_url: Url=>http://www.goosee.com< However, ftp doesn't work. Here is the output: Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< url_str = ftp://ibiblio.org/pub/Linux/distributions Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] Dpi: [Dpi_process_io] IOClose That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference. Regards, Barry Kauler

April 16, 2004

Re: [Dillo-dev]what's the use of "EndTag" component of struct TagInfo?

by Jorge Arellano Cid

On Mon, 12 Apr 2004, [gb2312] Lei Jin wrote: > Its value can be "O" "F" "R", so what do they mean? Optional, Forbidden, Required as of the HTML4.01 SPEC. > AND Why use them? We follow the standards! :-) Cheers Jorge.-

April 15, 2004

Re: [Dillo-dev]dillo 0.8 fails to build on OS X 10.2.8

by Jorge Arellano Cid

On Mon, 12 Apr 2004, Brett Wynkoop wrote: > FYI- > Just tried to build a stock out of the box dillo 0.8 on Mac OS X. > Here are the results: > > In file included from /usr/local/include/gtk-1.2/gdk/gdktypes.h:33, > from /usr/local/include/gtk-1.2/gdk/gdk.h:31, > from /usr/local/include/gtk-1.2/gtk/gtk.h:31, > from mime.h:11, > from mime.c:12: > /usr/local/include/glib.h:491: conflicting types for `gssize' > /usr/local/include/glibconfig.h:57: previous declaration of `gssize' > /usr/local/include/glib.h:492: conflicting types for `gsize' > /usr/local/include/glibconfig.h:58: previous declaration of `gsize' > *** Error code 1 > > Stop in /Users/wynkoop/src/www/dillo-0.8.0/src/IO. > *** Error code 1 > > Stop in /Users/wynkoop/src/www/dillo-0.8.0/src. > *** Error code 1 > > Stop in /Users/wynkoop/src/www/dillo-0.8.0. > *** Error code 1 > > Stop in /Users/wynkoop/src/www/dillo-0.8.0. > ibook:~/src/www/dillo-0.8.0: > > Looks like a tail chasing issue to me. Will try and much with it > sometime latter and see what I can do to fix it. It looks like the problem is conflicting headers for glib. Cheers Jorge.-

April 15, 2004

Re: [Dillo-dev]international encodings

by Jorge Arellano Cid

On Wed, 14 Apr 2004, honza m. wrote: > hi, > first of all, some words of praise: i -love- dillo :e) fast, small, > doesn't repair html, has no javascript ... it's just great. biiig thanks > to all developers :e) :) ! > > anyway, i know there is a problem with non iso-8859-1 encodings, and i'd > like to help fixing it. but i've found that bug in the bugtracker in > "being worked on" and also in "not being worked on" bugs, so i know > nothing. and the mailing list search engine is so chaotic that i was > unable to find relevant posts. > so please some one tell me what's the status of this issue, or what are > the main problems, or something which would help me help you ;e) Please read the [Project Notes] link. It's a bit outdated but informative. At this time we're much closer to FLTK than to GTK+2 (yes, a lot of it has been discussed behind the scenes, and I hope to post more about the FLTK issue in some days...). The main issue for i18n is to have a way for rendering UTF-8, and there's where FLTK comes in. Cheers Jorge.- PS: As usual, when dillo-dev is silent lots of things r happening!

April 15, 2004