- Dillo-dev - lists.mailman3.com

[Dillo-dev]unsubscribe methods
by Patrick Shanahan Oct. 29, 2004

Oct. 29, 2004

* Haines Brown <brownh(a)hartford-hwp.com> [10-29-04 19:40]: > I've tried to get myself unsubscribed to this list (to which someone > kindly subscribed me without my knowledge or permission), by emailing > the admistrator, but it seems my letter ended up on hold > somewhere. Would somone kindly suggest an alternative method for me to > unsubscribe? There's no facility on the web page for doing so. there is a mailto address in every header from dillo-dev and webpage provision in the trailer mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=unsubscribe http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev directions for unsubing appear in the bottom section of the web page. ps: it is also common curtesy to give a subject indicative of the message content and to *not* hijack threads. Please have a good day and remember: read the instructions provided. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos

1 0

[Dillo-dev]Re: dillo patch: anchor names
by Jorge Arellano Cid Oct. 29, 2004

Oct. 29, 2004

Matthias, Maybe the most important guideline in this answer is that we're trying to provide good hint-messages for common HTML bugs, not being as picky (or correct) as the W3C's validator. The two main reasons behind this are that first, we do not want to (nor can) complicate too much the code inside dillo (some big browsers have several parsers inside), and we want to help to fix the most problematic HTML bugs (mainly nesting), not all. BTW, inside Dillo all the HTML-like content is currently parsed as HTML-4.01 with a few minor exceptions. HTML-4.01 is a good default because it tries hard to be backwards compatible. The third reason is that if the need for a formal validation arises, the W3C does a great job on it! :) On Wed, Oct 13, 2004 at 06:20:36PM +0200, Matthias Franz wrote: > Dear Jorge, > > here is the anchor name patch I promised you long time ago. > It does the following: > > * First of all, it evaluates the <!doctype> tag to find out whether > the document is HTML or XHTML. If the tag is wrong or missing, an > error is raised. Parsing <!doctype ...> is a good idea. Putting that info in a structure like this one: typedef enum { DT_NONE, DT_HTML, DT_XHTML } DocumentType; typedef struct { DocumentType Type; float Version; } DocumentInfo; allows for having all the information in one place, and to later decide whether to take some action or not. e.g. DT_NONE + DT_HTML + 4.01 means no doctype was given and that HTML-4.01 is assumed as default. DT_HTML + 4.01 means it was stated explicitly in doctype. > > * Dillo now distinguishes more carefully between head and body section There was a bug in dillo (up to rc1). A patch is now in CVS. When the HTML meta refresh warning was sent, it switched from IN_HEAD to IN_BODY. Note that for HTML-4.01: BODY: Start tag: optional, End tag: optional HEAD: Start tag: optional, End tag: optional > * The errors "<...> not allowed in body section" are now centralised > in Html_process_tag Could be. > Moreover, errors are raised in the following situations: > (After all, this was the goal!) > > * if an anchor name (defined by "name" or "id") is already defined OK. > For performance reasons, I have changed (very) few lines in dw_page.c > and dw_gtk_viewport.c. (pending as for the latest bugs found...) > > * if (in HTML mode) the "name" and "id" tags of <a> differ OK. > * if <a> tags are nested OK. > * extra_warning if an anchor name (defined by "name") was illegal for "id" OK. > > > NOT DONE: > > * warning if in XHTML <a> is used with "name" and no "id" > (according to the spec, this has no effect, which is probably not intended) OK. > * the "refresh" warning causes (like before) an error if further > head elements follow the <meta> Fixed in CVS now (Björn Brill). > > * I've discovered that some parts of the TagInfo structure are not used > any more, for example TagLevel and bits 2^0 = 1 and 2^2 = 4 of Flags. TagLevel is used extensively by the W3C+heuristics mode. Look at Html_tags_get_taglevel() calls. Yes, bits 0 and 2 are not yet used, but there they are just in case they're needed. > In particular, I didn't know how to define them for <!doctype> on line 4281. HTML elements can be of type 'block' or 'inline' (well, also 'flow'). And they can be containers of 'inline' or containers of 'blocks'. This is what the flags are. I'll comment that inside the code. For instance, <address> is an 'block' element, and a cointainer of 'inline' elements. address B8(0110) |||`- inline element ||`-- block element |`--- inline container `---- block container This is well defined here: http://www.cs.tut.fi/~jkorpela/html/nesting.html Now, as !doctype isn't there, an inline element that's a block container can appear almost anywhere (i.e. B8(0101)), and help to tackle the issue. > * IN_BUTTON in html.h is also not used any more; I've replaced it by the > new IN_A. Let IN_BUTTON be. As buttons can't be nested, it was meant to catch that one (not implemented yet). > * One change in Html_process_tag is more of a hack; I didn't want to > start rewriting everything without contacting you first. > > > You see that is still work to do in html.c, all the more because know > one could add error messages based on the distinction between HTML and > XHTML. (E.g., "&#X40;" is illegal in XHTML because of the uppercase "X".) > Would this kind of changes be welcome? Hmmm, I think this is too much by now. > I hope this patch can still make it into rc2. If you have comments or > questions, please let me know. As explained before, it better not be in rc2. Just bug-fixes. -- Regards Jorge.-

4 4

[Dillo-dev]news about memory leak
by Riccardo Mottola Oct. 29, 2004

Oct. 29, 2004

Hey, I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I noted however that: - clicking the reload button in thight succession gets an increment of about 4K every time - the leak is consitent, you can make the amount of leaked memory skyrocket to megabytes. - clicking slowly, waitning 10 seconds each time does NOT make dillo leak I suspect the leak happens if you click reload before dillo has "finished" the page and the "stop button" is disabled. I used a very simple page: <html>this is a test</html> Cheers, Riccardo

2 2

[Dillo-dev]Protocol Handlers
by Lee Bigelow Oct. 28, 2004

Oct. 28, 2004

Hello there, I was playing with the dpi's and made one for ed2k:// links (based on the Hello World example). It was just a quicky, and not generally useful, but I was wondering if anyone was working on a general protocol handler. Along these lines: - Dillo doesn't recognize the protocol so sends it to say external.dpi - external.dpi reads an external.conf file that has a list of protocols and respective external handlers. - If it finds a matching protocol it sends the url(%s), or just the url data (%r), to the handler. - If there's no matching protocol it could show an edit page (like bookmarks modify) for the external.conf. This could be used for mailto:, nntp:, telnet:, etc.. Anyhow, I starting playing with it, and I thought I should check to see if anyone else was also working on it before I went any further. Also, if there's any advice on the approach, or code I should look at, that would be cool. I am no expert C programer, I'm just reading the docs and modifying the code the other fellows already did. (I hope that's ok) -- Lee Bigelow <ligelowbee(a)yahoo.com>

2 1

[Dillo-dev]CYGWIN compatibility
by Jorge Arellano Cid Oct. 28, 2004

Oct. 28, 2004

Hi, Sometime ago I forwarded this message to dillo-dev: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002295.html <q> Hi anyone, I successfully compiled and installed dillo-0.8.2 on an AMD K7 600MHz: $ uname -a CYGWIN_NT-5.0 fermat 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown Cygwin It runs very well, so you can update your compatibility file ;) Greetings, Marianne </q> Has anyone contacted Marianne to know the recipe? -- Cheers Jorge.-

1 0

[Dillo-dev]Re: Dillo
by Jorge Arellano Cid Oct. 27, 2004

Oct. 27, 2004

On Wed, Oct 27, 2004 at 04:48:37PM -0700, Eugenia Loli-Queru wrote: > >>Please note that the front-end of Gnomefiles has been specifically > >>optimized to work well with Dillo, > > > > I noted, good HTML, and it looks pretty too. > > Thanks, I have made sure that our other sites, osnews.com and nmcx.com also > render well. :) Great! > > > If you can add the missing </form> tag, the application-submit > >process on www.GnomeFiles.org may be finished by using a standard > >dillo-0.8.3. That'd be good news for our users. > > Please retry. I have changed the code to allow Dillo and added the missing > tag. Thanks! > Hmm, I can't seem to make dillo login to gnomefiles's dev corner. I have > edited my .dillo/cookiersrc file to say DEFAULT ALLOW but it still doesn't > login... Oh, it's "DEFAULT ACCEPT". BTW, I use: <q> DEFAULT DENY [...] www.gnomefiles.org ACCEPT_SESSION <q> > Do you have a better luck with it? Yes! By using a standard dillo-0.8.3, I was able to go through the whole process without any hassle. As a result, Dillo has now its own record at www.gnomefiles.org, and it's the first on the "Latest Software" list at the time of this writing. Thanks for your help. -- Cheers Jorge.-

1 0

[Dillo-dev]dillo-0.8.3 officially released!
by Jorge Arellano Cid Oct. 27, 2004

Oct. 27, 2004

Hi there, Finally the release process saw the light, and today the new dillo-0.8.3 was released! It went through a long testing process so we expect this one to be very stable and to have a good reception. The announcement was just submitted to freshmeat and it should appear in some minutes. Thanks to all the people that contributed to test the release candidates with their time and feedback. Go get it! Now, we'll focus on the next big steps. That's the FLTK port, new Dw abstraction layer, review of the CCC, caching, etc. We're preparing a prioritized tasks list with Sebastian and it will make it into its own HTML page. Sebastian: feel free to merge the new Dw abstraction layer into the CVS. Let's start this ASAP. -- Cheers Jorge.-

1 0

[Dillo-dev]dillo-0.8.3-rc3
by Jorge Arellano Cid Oct. 26, 2004

Oct. 26, 2004

Hi there, The tarball for dillo-0.8.3-rc3 is ready for download and testing. This is rc2 plus the fixes for cookies and the redirection loop (i.e. not current CVS). Please test it with sites that use cookies (as advogato) and with pages that use HTTP redirections (not meta-refresh). That's the emphasis area; the other aspects have been throughly tested during this cycle. Get it from: http://www.dillo.org/download/dillo-0.8.3-rc3.tar.bz2 The plan is to announce 0.8.3 on Wed 27. Please send your feedback! -- Cheers Jorge.-

5 14

[Dillo-dev]Possible RPM delays
by Kelson Vibber Oct. 25, 2004

Oct. 25, 2004

My main computer at home has been having problems lately. I *hope* it's just the video card (I would expect worse problems if it were the motherboard, CPU, or memory), but I think it's fair to warn you that if 0.8.3 final comes out before I've resolved the issues, I might not be able to build all the RPMs immediately. Kelson Vibber www.hyperborea.org

4 6

Re: [Dillo-dev]Caching
by Jorge Arellano Cid Oct. 22, 2004

Oct. 22, 2004

Brian, On Fri, Oct 22, 2004 at 09:00:27AM -0400, Brian Hechinger wrote: > > > ok, i will volunteer to do the caching portion. > > > > Good! We need developer power. > > and i need more experience. this'll be good for me. ;) > > > Read the docs, and when in the code, after the normal path, > > follow the End2End reload flag. You can also look how it is > > handled with plugins. > > i will do that today, i'll let you know what i can figure out on my own. > > > Beware: don't dig inside the CCC or you'll ge lost. I'm > > preparing a document on it, and without this material, it'd be > > almost impossible to figure it out. > > ok, then i'll be very careful to avoid it for now. ;) > > > It looks like a good idea to start with. Flexible and simple. > > that's what i was striving for. no need to add extra complexity for no good > reason. ;) > > > Caching is complex. Pragma inside meta whithin HTML is just one > > way. HTTP has several others (for instance you'll have to start > > reading at section 13 of rfc2068.txt (aka HTTP1.1). > > ok, in that case i propse to add Pragma first and once i get that working i'll > add the other methods as well. > > > To make things more interesting, if an RFC-compliant user agent > > (browser) is built, then it's very easy to abuse it. By sending > > no-cache directives for advertising for instance. > > hence the need for cacherc so that we can specify which servers we will honor > the no cache directive from. this is something we need to certain things to > work right, but like you said, we don't want to get abused by it either. > > > I hope this gets you started. When in doubt, please ask. > > i still have to go through End2End, but real quick, how would i go about > parsing the header looking for Pragma? what's the best place to do that? Look inside Cache_parse_header(). :-) -- Cheers Jorge.-

1 0