September 2006 - Dillo-dev - lists.mailman3.com

Campaign to help Dillo survive
by Alan Carvalho de Assis 03 Oct '06

03 Oct '06

Hi all, I am writing a document to convince some company to help Dillo project. I think it is an idea we need fight for. I invite everybody to help to improve this document, when we get a powerful document we will send it for some friends at Nokia, Motorola and others. The early version can found here: http://fornix.sourceforge.net/wiki/index.php/Campaign_to_help_Dillo_survive Be free do edit this wiki. Thank you, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- Não importa o que os outros irão pensar, A cura para a infelicidade é a felicidade

4 11

Re: [Dillo-dev] Dillo FLTK CVS
by Alan Carvalho de Assis 02 Oct '06

02 Oct '06

Hi Michal, On 9/29/06, Michal Nowak <xnowak01(a)stud.fit.vutbr.cz> wrote: > Hi Alan, > > well I am not sure how you could do it i(=desktop@floppy) but I think > Dillo will be quite large with staticaly linked with fltk2. > Do you know how large is it? > May I ask you, how many space have you got on the floppy? Or you mean > "the floppy" (1.4 MiB)? It would be great proof of concept... Well, I am formatting it at 1.74 MB, and I will use compressed fs (squashfs). I think it will get ~ 3MB. Kernel: ~ 600KB (I am using kernel-tiny patch) Kdrive: ~ 600KB (I am using uClibc) Dillo-fltk: < 1.8 MB > The troubles with funds... it's quite longstanding problem. Dillo neads > fulltime dev or two. There are companies which has Dillo build in their > products and sold them, well, that's OK, but thay give nothing back... > just sitting and waiting for Jorge. Comunity of Dillo is rather small, > people from developed countrie have fast computers -> lack of hunger for > such think Dillo is. Probably nobody will pay for releasing "another > browser", coz hey have ff, opera, konq etc. Dillo will be the best option for cheap linux cell phones. Then when these cell phone companies realise it is a best option it will invest. To do it we need emphasize Dillo qualities: the faster browser ever, the smallest footprint, etc. It is just "blow one's own horn" :) > But you can help Dillo with submitting code, if ou want to :). Doing a small linux distro I will help to demonstre as powerful dillo is. And it will demonstre too the small dillo footprint. > CU, > Michal > Cheers, Alan

2 1

Dillo FLTK CVS
by Alan Carvalho de Assis 29 Sep '06

29 Sep '06

Hi people, I am new in this list and I have a silly question. I want to compile dillo with no GTK libs. I already compiled kdrive and fltk with uClibc, now I just need to compile dillo. My problem is where to find the dillo fltk tree, I download the default CVS tree (dillo module), but it is not fully fltk, just the download.cc use fltk. I search at mail list and google, but don't find anything. Where can I download the dillo fltk source code? I know it is in development, but it is not problem. Thank you, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- Não importa o que os outros irão pensar, A cura para a infelicidade é a felicidade

2 4

Opening new URL in same instance and -s option
by Rainer M Krug 21 Sep '06

21 Sep '06

Hi I have two questions first: I would like to be able to have only one instance of dillo open and when I try to open a new url (from outside dillo), that this url is opened in the old instance. Is this possible, and if yes, how? second: I have seen emails concerning running dillo in server mode (dillo -s server). I tried it, but dillo didn't know -s. Is this feature imp[lemented, and if yes, how can I access it? Thanks a lot for a brilliant lightning fast browser, Rainer -- Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology and Entomology University of Stellenbosch Matieland 7602 South Africa Tel: +27 - (0)72 808 2975 (w) Fax: +27 - (0)21 808 3304 Cell: +27 - (0)83 9479 042 email: RKrug(a)sun.ac.za Rainer(a)krugs.de

1 0

[abc@ai1.anchorage.mtaonline.net: frames/fltk]
by Jorge Arellano Cid 14 Sep '06

14 Sep '06

-- Cheers Jorge.-

1 0

Serious Memory Allocation Strategy Problem in Cache_parse_header()
by R.L. Horn 08 Sep '06

08 Sep '06

I'm currently in the process of modifying dillo for use in browsing an http media server (yeah, I know it's httpd abuse, but it's only for a local network and I was running Apache anyhow). At present, this basically involves sending a modified downloads plugin an "execute" command and the MIME type when AbortEntry is true in Cache_process_queue() (the plugin then executes an agent which deals with the URL entirely independent of dillo). (Actually, this is functionality that would be nice in the main branch, albeit with its own plugin and user-selectivity. If there's interest, please let me know.) So far, so good -- it seems to work passably well and it only took a couple of hours. Easy peasey. Unfortunately, the first time I click on a 700M video stream, things go horribly wrong. Seems that Cache_parse_header() attempts to allocate memory for the entire content *before* the header has been checked for viewability (since the dispatcher isn't called until Cache_process_queue()). As it happens, this has been reported as bug 726. The upshot of all this is that when you click on a link, there had better be room for the whole thing in heap even though the content may never be read. Otherwise, glib just gives up and dumps core via g_malloc(). I think I can get around this by doing a Content-Type check in Cache_parse_header(). I'd be happy to provide a patch provided I can come up with a reasonably elegant solution. Any advice would be appreciated.

2 3

Patches
by Rob Cherveny 06 Sep '06

06 Sep '06

I have freebsd and am using dillo. Can someone help me install the patch for using tabs? Thank you rob -- "The trouble ain't that there is too many fools, but that the lightning ain't distributed right." Mark Twain

4 3

More signal :-)
by Roberto C. Sanchez 04 Sep '06

04 Sep '06

When will the transition to FLTK begin? Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto

3 3

The kind of computer that is perfect for Dillo
by Sam Trenholme 03 Sep '06

03 Sep '06

This is the kind of computer that is perfect for Dillo: http://linuxdevices.com/news/NS6828123924.html Summary: About $100, P166, 128 megs of memory, roughly the size of a VHS videocasette. This is the perfect computer for Dillo--128 megs of ram really isn't enough memory to run Firefox well, and Firefox's rendering will be quite slow on a P166, especially on big pages. That said, I feel there are some issues that stop Dillo from being the browser to use on such a machine. Now, before giving out my "shoulds", I understand what it takes to make code happen in the open source world: The submission of money or patches. I have my own little open-source project, and I do let out a sigh whenever someone says "Your program should be able to do XXX". I do listen to these requests, but it sometimes takes years for those requests to become real code. So, I hope people on this list will humour me and let me share my thoughts about Dillo. The problem is that Dillo doesn't support a lot of high-profile internet sites right now. OK, you say, so submit a patch and help with Dillo development. Well, the problem is that I don't think such a patch will be accepted by the Dillo developers. People, of course, know about the patches over at http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n This patched version of Dillo (or should I say, this fork of Dillo) also supports tabs, frames, UTF-8, and even has buggy support for real HTML redirects. I was able to read and send webmail both with Yahoo and Gmail using the "i18n" version of Dillo. I can't say the same for the last stock version of Dillo I tried; I understand that the "i18n" changes may make the code more messy. I think we're looking at different philosophies here, and I think we may hit the point of having a true fork should these enhancments continue to not be merged in to the main Dillo source. If I were to take some time out from my own project on work on Dillo, I would not work on the main version--I would work on the "i18n" version, since it is usable with a number of sites that the mainline Dillo can not access. I would look at the "i18n" version and try and add Javascript support to it (or, better yet, EMCAscript support). Personally, I think Dillo needs some level of Javascript support; a lot of high-profile sites (can we say MySpace and their crappy JavaScript and HTML) plain simply do not work without Javascript. I also believe that Dillo shouldn't try to get CSS support; the last thing I want is yet another browser with buggy CSS that I have to design around. If Dillo is going to support CSS, I don't think the support should become a part of a stable release of Dillo until Dillo can render ACID2 perfectly. A site that uses CSS is perfectly usable, albeit a bit ugly, in a browser that doesn't have CSS. Anyway, these are just my 2 millicents. I understand that it takes either real code or real money to make these changes real, and since I'm currently offering neither, feel free to cheerfully ignore my thoughts or to flame me to a crisp. :) - Sam

7 12

Problems with gziped content encodings pages and proposal
by Diego Sáenz 03 Sep '06

03 Sep '06

Hello. I am a daily user of dillo and i am finding problems with pages served with content-encoding = gzip and dillo mime detection code. For example when i try to open en.wikipedia.org or es.wikipedia.org dillo says "HTTP warning: Content-Type 'text/html; charset=utf-8' doesn't match the real data" When download with wget y see that the problem is that the page is gziped so i think that now wikipedia sends pages with conten-encoding: gzip. Proposal I have a proposal to use DPIs to manage protocols, mime, encodings and maybe scripts whitout modifing dillo source code each time that a dpi is added. Before in the list i have defended to have mime, protocols and script DPIs that call the right DPI for each task when dillo ask for a unknown mime type, protocol or script but this do not fit very well with the DPI infrastructure and need more DPI process runing and that it is better to avoid. Sorry, i think that it was the better option. I think that the way to fit mime handling with DPIs is to use the documented (but not fully implemented) concept of DPI service. In DPIs docs dillo do not call directly a DPI it ask dpid for a service and dpid returns a DPI. In this way various DPIs can be installed for a given service and the user can use whatever he what. In fact in the code dillo ask dpid for a service, but dpid can not handle more than a DPI for a given service(it do extrange things). Basic idea: When dillo do not known how to access to a url like mms:/something or show a mime type like image/xpm it can ask for a protocol_mms service or mime_image%2Fxpm service. We can fix dpid too. It will only need a configuration file to store user preferences for each service. Details Protocol DPIs can translate the unknown protocol to http (like https, ftp and data DPIs) or show a html page with actions about the protocol. For example a mms DPI can show a page with options to hear the mms stream(with mplayer) or download it (with mimms). An extension to the download_gui DPI to support downloading unknown protocols can be usefull. When download is not one supported by wget it can send open_url to dillo or ask dpid ... Mime types need a mime_x-dillo%2Fx-unknown because a file can be send without content-type and dillo can fail to discover the mime. A DPI handling it can use 'file --mime ' and resend the file to dillo with correct mime. A way to not resend the file will be better, maybe dillo can cache it if the file is small and is not a local file. If it is local it can send the url or path. A dpid more flexible configuration is needed so users can use the 'file --mime' DPI with occet/stream if they want. Using a path to the DPI with base at ~/.dillo/dpi or the dpi_lib in dpidrc can be sufficient. Surely a fallback DPI can be usefull. If dpid can not return a DPI because there is not service for that mime dillo can ask for a mime_x-dillo%2Fx-service-not-found or mime_x-dillo%2Fx-fallback that DPI can show an error or list DPIs to download and install or show a search engine For security reasons a mime_... and inlined_mime_... groups of services can be needed so an image or an object tag data automatically loaded from a page to show can be diferent from user clicked ones. Content encoding can use a group of encoded_... service names. (content_gzip for example) This do not need to detect the encoding because if there is not content-encode it is not encoded. Fallback can be needed. Scripts need more thought but if dillo send scripts tags to script_aplication%2Fjavascript and implement html intrinsic events a DPI can start to do easy things as redirect, status line scrolls(sigh) or javascript based links. (javascript based links can be done with a protocol_javascript easely) I mail this because i want coments and help. If you has read this boring (and bad writed) text until here, please do not think on comments or help, Just do if! :) Diego. PS: I have a debt of a parser code to dillo. It only need a clean up but is finished and have less size that the old glib parser code. :P

2 4