- Dillo-dev - lists.mailman3.com

[Dillo-dev][PATCH] use an alternative rcfile from command line
by Tito July 10, 2005

July 10, 2005

Hi to all, this little patch adds a command line option ( -R --rcfile) to specify an alternative rcfile from the command line. This is useful if you are calling dillo from scripts or other applications and you need to enable/disable some options for a particular task. The patch is against dillo 8.5. Please apply if you think it is ok to do so and the patch fits in the dillo philisophy. Ciao, Tito

1 0

[Dillo-dev]viewing non-web files, thanks, etc
by Daniel C. Bastos July 6, 2005

July 6, 2005

I'm a dillo user, not a developer, but I sat down one day to write a quick patch to get dillo to let me quickly view PDF files because I read lots of them from the web. So I wrote a program called quick and then I wrote a patch to get dillo to call quick when it's a file that quick can open. I'm happy with the benefit, but this is not a patch for dillo, it's just a hack to get me happy (I didn't use glib, for example.) I wanted to drop you guys this message to tell you guys that there's one user who would like such feature in dillo and I should perhaps ask you guys how you would build such feature in dillo if you were to sit down today and do it. Who knows? I could do it myself, if it won't be too complicated. I also wanted to say thanks. I think the software is great. http://math.utoledo.edu/~dbastos/files/patch/patch_dillo_cache.c http://math.utoledo.edu/~dbastos/files/quick-0.1.tar.gz

4 6

Re: [Dillo-dev]cookies dpi over https and dpi framework
by Diego Sáenz July 3, 2005

July 3, 2005

Hello, i have found that the problem was in https dpi. Under some circunstances, self signed certificate and formated in some way, the https dpi died. I send a patch to fix it. The patch is for dillo 0.8.5 but surely it works in previous versions, only touches dpi/https.c, it works with or without cookies.dpi patch, whitout cokies.dpi patch only the first dillo have cookies. I send a this mail with cc to the list to make it,the new(and the fix), public so the people can test it ASAP. Diego Sáenz/DarkSpirit. 8<--------------------CUT HERE------------------>8 diff -pru dillo-0.8.5-DIRTY/dpi/https.c dillo-0.8.5-WORK/dpi/https.c --- dillo-0.8.5-DIRTY/dpi/https.c 2005-07-03 23:25:06.000000000 +0200 +++ dillo-0.8.5-WORK/dpi/https.c 2005-07-03 23:29:23.000000000 +0200 @@ -331,6 +331,7 @@ static int handle_certificate_problem(SS int retval = -1; long st; char buf[4096]; + char * cn, * cn_end; X509 * remote_cert; @@ -363,12 +364,16 @@ static int handle_certificate_problem(SS case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: /*Either self signed and untrusted*/ /*Extract CN from certificate name information*/ - strncpy(buf, (strstr(remote_cert->name, "/CN=") + 4), - (size_t)(strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - - strstr(remote_cert->name, "/CN=")- 4)); + cn = strstr(remote_cert->name, "/CN=") + 4; + if (cn == NULL) break; + + if ((cn_end = strstr(cn, "/")) == NULL ) cn_end = cn + strlen(cn); + + strncpy(buf, cn, (size_t) (cn_end - cn)); + /*Add terminating NULL*/ - buf[strstr(strstr(remote_cert->name, "/CN=") + 4, "/") - - strstr(remote_cert->name, "/CN=")- 3] = 0; + buf[cn_end - cn] = 0; + sock_handler_printf(sh, 1, "<dpi cmd='dialog' msg='%s%s' alt1='%s' alt2='%s' alt3='%s'>", "The remote certificate is self-signed and untrusted.\n" 8<----------------------CUT HERE------------------------>8 El Tue, 28 Jun 2005 00:13:24 +0200 Jorgen Viksell <jviksell(a)dillo.org> escribio: > OK, now it's up at: > https://www.dillo.org/~jviksell/test.php > http://www.dillo.org/~jviksell/test.php > > It sends four secure cookies and four unsecure. > > Cheers, > Jörgen

1 0

[Dillo-dev]dillo on sparc64
by Damien COUDERC July 3, 2005

July 3, 2005

Hi, i have problems with dillo on sparc64. When using a mechanism of OpenBSD 's malloc i'm able to detect a bug in the dpi stuff. At the moment i've found that the function Dpi_append_io_buf() in the file src/IO/dpi.c is wrong. The following line is reallocating a buffer: conn->Buf = g_realloc(conn->Buf, (gulong)io->Status); But when debugging the values of io->Status don't seem to be adequate. I haven't been able to completely fix it as the code is seriously lacking of comment. To be honest i don't even completely understand what this chunk is doing and the code is so unreadable that it doesn't help (not to be harsh but just to give my humble opinion). Damien

3 4

[Dillo-dev]small question about TagInfo in html.c
by Wim De Smet July 2, 2005

July 2, 2005

Hey, What exactly do the EndTag en TagLevel fields in the TagInfo struct stand for? I was going to add the "q" function but I'm not sure what I should fill in here. (and it wasn't directly clear from the otherwise excellent src docs). TIA, Wim

2 3

[Dillo-dev]cookies dpi over https and dpi framework
by Diego Sáenz June 25, 2005

June 25, 2005

Hello, now that i have some free time i want to test the cookies dpi over https like Jorge suggested. I need the server so i ask to the webmaster if he can mount some https pages with cookies for the test, like Jorge suggested too. About other things and thinking about the future, i have some ideas about DPI framework and DPIs that can be useful, maybe. Register and init DPIs I think that the way that gives more adventages is to let dpid manage this using dpidrc to store the list of available DPIs(updated each time dpid is runned with the installed DPIs in the system and in the HOME/.dillo/dpi directory), and the metadata about DPIs: mime types or protocol that manages that DPI, menu entries or buttons that DPIs need and the more important if a user wants use(enabled) that DPI or not(disabled) dpidc need new commands (enable, disable, list DPIs) and individual register of DPIs(dpidc register directory/where/the/new/DPI/is) When a new DPI is register dpid run the DPI and ask the DPI metadata which a new DPI command(<dpi cmd='give_metadata'> ?) and the DPI returns the metadata in a text key-value format, for example a dpi that converts rtf and pdf files to html can send postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf (with the right mime type of course) After this dpid stores the metadata in dpidrc file. For example: DPI=rtf_pdf_viewer state=enabled or disabled or ... postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf And now three ways to get the new metadata in dillo or the DPIs that understand them: 1) The pasive solution. when a DPI start it read the dpidrc searching the metadata that it understand. (A DPI that manages mime types, so dillo do not need to do it, can make a list with the name and mimes that understand each DPI) 2) Active, but silly one. Dpid re-send the metadata to each other DPI, with a new DPI command, and each DPI redo his internal state with the metadata it understand. This is the worst solution because dpid need to run all DPIs to be sure that metadata arrives to the right DPI. 3) The complex and flexible solution, my prefered one. There is a key-value(send_me) in the DPIs metadata to register keys of metadatas. Dpid understand this key(send_me) and have a internal list to send the metadatas to the right DPI. If a DPI send a key registered with the send_me key while registering, dpid sends the change to the DPI that registered that key so it can update its internal data, caches, whatever. Example: A mime DPI manages the files with mime types unknows to dillo. When it register send this metadata and is stored in dpidrc like part of its metadata send_me=mime_understand Then after the rtf_pdf_viewer DPI is registered, and if it is enabled, dpid send to the mime DPI the DPI=rtf_pdf_viewer mime_understand=text/x-rtf,text/x-pdf and mime DPI updates its state so it can call rtf_pdf_viewer when find a rtf or pdf file. Pros: - It is so flexible that new keys and resources can be used by new DPIs while dpid, or even dillo in some case, do not need to be updated to understand it. - Do not need to modify dillo internals or few Cons: - Dpid, dpidc and DPIs need to be modified - And more, sure Protocols and mime DPIs Based in the xproto DPI i think that a DPI can manage all the protocols and mime formats that dillo do not understand. Dillo simply passes the url or stream(or file location) to that DPI when it do not understand the format and the DPI using a list call the right DPI, script, wathever to manage it. That last DPI open an app, return a data in format that dillo understand(html, gif, jpg, png), etc. Image/objets html tags can call the protocol_and_mime_DPI, with some care and a especial dpi tag, so new formats can be viewed in dillo, if a DPI converts them to formats understanded by dillo, in the right place in the page. A interesting idea is to can embed apps, like sylpheed embed dillo, in the space of a image or object with new tags and/or pasing the WID. The protocol_and_mime_DPI send a html page to dillo when there is more than a DPI or action, download included, for a protocol or mime to ask the user what to do, set default action, etc Pros: - All code is outside dillo - Compatible with all Cons: - Can need news dpi tags - And more, sure HTML GUI When dillo support frames(The only think because i do use an old dillo 0.8.0 patched with frames sometimes is because it have frames)/iframe/objects(this tag can include html to, but frames are better) the dillo GUI can be a html page, with a iframe that contains the viewed web page, and a DPI that modifies the GUI html page. The new thing is that the DPI can use a cache file with that html page that dillo loads at start so dillo init is as fast as now, only loading the DPI when needed. All DPIs that generate html must use the same CSS so all have the same look. Pros: - Make dillo core small - Look is fully configurable - DPIs can register menus and buttons and dillo do not need even to know or have the list of buttons or menus registered in mem an in each dillo Cons: - Need to add remote control dpi tags to dillo - And more, sure Adding all Only frames, and new dpi tags need to be done in dillo core and it gives, when the DPIs needed and dpid are done, a very flexible interface to cordinate DPIs and for example that the DPIs GUI elements can be implemented step by step based on funcionality without touching dillo internals and not all at same modifing dillo core or doing it unestable. Only some ideas. If somebody wants to disscuss them, destroy them, blame about my english or me and my sleep state at this time i have my e-mailbox and eyes open to read all of them. Diego Sáenz/DarkSpirit.

1 0

[Dillo-dev]dillo-0.8.5.tar.bz2
by Jorge Arellano Cid June 19, 2005

June 19, 2005

Hi there! Well, everything is ready for the official announcement of the newest release of dillo (v. 0.8.5). I'll post in freshmeat tomorrow in the morning. BTW, I included a GPG signature for this release, so please remember to pick my new key (available from Authors page or from a keyserver) if you want to verify it. -- Cheers Jorge.-

2 1

[Dillo-dev]dillo-0.8.5-rc1.tar.bz2
by Jorge Arellano Cid June 17, 2005

June 17, 2005

Hi there, The release candidate one tarball for 0.8.5 is ready for testing. Please get it from: http://www.dillo.org/download/dillo-0.8.5-rc1.tar.bz2 This code has had a lot of testing so emphasis is on the build/compile process on the different platforms and on the file dpi. The file dpi now reacts to 'dpidc stop' and also to the DpiBye command issued by dpid after one hour of idleness. Please report back how it works so it can be released quickly. -- Cheers Jorge.-

8 9

Re: [Dillo-dev]RPMs
by Kelson Vibber June 17, 2005

June 17, 2005

On Thursday 16 June 2005 5:53 pm, Patrick Shanahan wrote: > SuSE 9.0 here: > ... Thanks! Anyway, I've got the main ones up. My UML collection is semi-trashed, so I couldn't get any of the really old distros built, and I'm running into problems with autoconf (or maybe automake, I can't remember) on Mandrake 10.0 and older (but fortunately the 10.1 RPM runs on 10.0). I'll try to find some time on the weekend to track down the autoconf issue and see if I can work out the problems with UML. Building from the final tarball should help. Done: Fedora 1-4 Red Hat 7, 9 SuSE 9.0, 9.1, 9.2 Mandrake 10.0, 10.1 Yellow Dog 3, 4 -- Kelson Vibber www.hyperborea.org

1 0

[Dillo-dev]RPMs
by Jorge Arellano Cid June 17, 2005

June 17, 2005

Hi Kelson, If you want to build RPMs, it looks like rc1 will become 0.8.5 so you only need to change configure.in: -AM_INIT_AUTOMAKE(dillo, 0.8.5-rc1) +AM_INIT_AUTOMAKE(dillo, 0.8.5) Unless somebody reports an error, I plan to officially announce it tomorrow. Now, if you need some extra time to prepare the RPMs, just let me know to delay it a bit. ;) -- Cheers Jorge.-

2 1