- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Campaign to help Dillo survive

by Alan Carvalho de Assis

Hi Vincent, On 9/30/06, Vincent Thomasset <vincent.thomasset(a)skynet.be> wrote: > On Sat, 30 Sep 2006 09:27:21 -0600 > > I am writing a document to convince some company to help Dillo > > project. > > Great idea! > Thanks. > > First of all, i think this type of document should be written by > someone with a better English level and more closely related to > Dillo's development (no offense). ;-) > Sure, I am not a native and my english is too bad ... Good, I think your english is better than my english! :) Even if you don't have know about Dillo internals your help is welcome, give us your 2cts. > About your argument, i'm not sure those companies you listed would be > sensible to the fact that it is good to have an embedded open source > browser (at least not for the sake of it). I think they'd be more > likely to listen to the "what can Dillo offer you ?" or "why would you > want to middle/long term support this project ?" type of questions. > Yes, I agree with you. It need to be directed to companies necessity, but it is not fully technical issues, there is other non technical problems related. > Anyway, i assume Jorge already has gone through some of the questions > this document needs answering to, so maybe he is the most appropriate > person to help writing it (or to direct companies to if they would > like further informations). Yes, I agree newly. But everybody think everything is Jorge's work, if nobody begin to help Dillo will really die. > I salute your idea and wish the best to Dillo. > Thank you very much, I am waiting your help too :-) > Cheers, Cheers, > Vincent > Alan P.S.: Sorry I forgot do send for all.

Sept. 30, 2006

Re: [Dillo-dev] Campaign to help Dillo survive

by Vincent Thomasset

On Sat, 30 Sep 2006 09:27:21 -0600 "Alan Carvalho de Assis" <acassis(a)gmail.com> wrote: > Hi all, Hi, > I am writing a document to convince some company to help Dillo > project. Great idea! > 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. First of all, i think this type of document should be written by someone with a better English level and more closely related to Dillo's development (no offense). ;-) About your argument, i'm not sure those companies you listed would be sensible to the fact that it is good to have an embedded open source browser (at least not for the sake of it). I think they'd be more likely to listen to the "what can Dillo offer you ?" or "why would you want to middle/long term support this project ?" type of questions. Anyway, i assume Jorge already has gone through some of the questions this document needs answering to, so maybe he is the most appropriate person to help writing it (or to direct companies to if they would like further informations). I salute your idea and wish the best to Dillo. > Thank you, Cheers, Vincent

Sept. 30, 2006

Campaign to help Dillo survive

by Alan Carvalho de Assis

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

Sept. 30, 2006

Re: [Dillo-dev] Dillo FLTK CVS

by Alan Carvalho de Assis

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

Sept. 29, 2006

Re: [Dillo-dev] Dillo FLTK CVS

by Alan Carvalho de Assis

Hi Michal, sure, now I understand, I found it: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2006-March/002933.html My idea is to create a prove of concepts: I want create a graphical desktop on single floppy with web browser, without dillo-fltk it will be not possible. I wise Jorge get funds soon. Maybe an idea is do like blender was some times ago: ask users to help with money to he release the source code. It is not the better idea, but maybe can get results. Cheers, Alan On 9/29/06, Michal Nowak <newman.x(a)seznam.cz> wrote: > Hi Alan, > > please take some time to read this mailing list's archive and I am sure > you will understand all. Search for posts from Jorge a the keyword are > "fund", "funds", "funding". > > Michal > > > On 18:19 Fri 29 Sep , Alan Carvalho de Assis wrote: > > Hi Michal, > > thank you very much. > > I live in Brazil, it is so far Jorge's home :) > > > > Jorge, is there a possibility to share it with us? > > > > Best regards, > > > > Alan > > > > On 9/29/06, Michal Nowak <newman.x(a)seznam.cz> wrote: > > >I guess the fltk version is on Jorge's own PC, isn't it :). > > >Go there and take a look on it :). > > > > > >The fltk version is not yet released and who knows if it ever > > >be... > > > > > >Michal Nowak > > > > > > > > >On 15:34 Fri 29 Sep , Alan Carvalho de Assis wrote: > > >> 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 > > >> > > >> _______________________________________________ > > >> Dillo-dev mailing list > > >> Dillo-dev(a)dillo.org > > >> > > >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > > > > >_______________________________________________ > > >Dillo-dev mailing list > > >Dillo-dev(a)dillo.org > > >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > > > > > > > > -- > > ------------------------------------------------------------ > > | Alan Carvalho de Assis | > > ------------------------------------------------------------ > > -- > > Não importa o que os outros irão pensar, > > A cura para a infelicidade é a felicidade > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- Não importa o que os outros irão pensar, A cura para a infelicidade é a felicidade

Sept. 29, 2006

Re: [Dillo-dev] Dillo FLTK CVS

by Michal Nowak

Hi Alan, please take some time to read this mailing list's archive and I am sure you will understand all. Search for posts from Jorge a the keyword are "fund", "funds", "funding". Michal On 18:19 Fri 29 Sep , Alan Carvalho de Assis wrote: > Hi Michal, > thank you very much. > I live in Brazil, it is so far Jorge's home :) > > Jorge, is there a possibility to share it with us? > > Best regards, > > Alan > > On 9/29/06, Michal Nowak <newman.x(a)seznam.cz> wrote: > >I guess the fltk version is on Jorge's own PC, isn't it :). > >Go there and take a look on it :). > > > >The fltk version is not yet released and who knows if it ever > >be... > > > >Michal Nowak > > > > > >On 15:34 Fri 29 Sep , Alan Carvalho de Assis wrote: > >> 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 > >> > >> _______________________________________________ > >> Dillo-dev mailing list > >> Dillo-dev(a)dillo.org > >> > >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > > >_______________________________________________ > >Dillo-dev mailing list > >Dillo-dev(a)dillo.org > >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > > > > -- > ------------------------------------------------------------ > | Alan Carvalho de Assis | > ------------------------------------------------------------ > -- > Não importa o que os outros irão pensar, > A cura para a infelicidade é a felicidade

Sept. 29, 2006

Re: [Dillo-dev] Dillo FLTK CVS

by Alan Carvalho de Assis

Hi Michal, thank you very much. I live in Brazil, it is so far Jorge's home :) Jorge, is there a possibility to share it with us? Best regards, Alan On 9/29/06, Michal Nowak <newman.x(a)seznam.cz> wrote: > I guess the fltk version is on Jorge's own PC, isn't it :). > Go there and take a look on it :). > > The fltk version is not yet released and who knows if it ever be... > > Michal Nowak > > > On 15:34 Fri 29 Sep , Alan Carvalho de Assis wrote: > > 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 > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev(a)dillo.org > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- Não importa o que os outros irão pensar, A cura para a infelicidade é a felicidade

Sept. 29, 2006

Re: [Dillo-dev] Dillo FLTK CVS

by Michal Nowak

I guess the fltk version is on Jorge's own PC, isn't it :). Go there and take a look on it :). The fltk version is not yet released and who knows if it ever be... Michal Nowak On 15:34 Fri 29 Sep , Alan Carvalho de Assis wrote: > 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 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 29, 2006

Dillo FLTK CVS

by Alan Carvalho de Assis

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

Sept. 29, 2006

Opening new URL in same instance and -s option

by Rainer M Krug

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

Sept. 21, 2006

[abc@ai1.anchorage.mtaonline.net: frames/fltk]

by Jorge Arellano Cid

-- Cheers Jorge.-

Sept. 14, 2006

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by Jorge Arellano Cid

On Thu, Sep 07, 2006 at 07:38:27PM -0500, R.L. Horn wrote: > On Thu, 7 Sep 2006, Jorge Arellano Cid wrote: > > >>(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.) > > > > Yes, more or less this is the plan. > > Great! > > > OK, a good workaround is to check for huge filesizes while parsing the > >header and to set as if no Content-length was given in that case. This > >is simple and will work. > > That's kind of what I did. Actually, I just removed the code that had to do > with static buffers entirely (while still allowing for a Content-length > check). > > If the GTK branch weren't pretty well deprecated, I'd go ahead and do it > right: Add a boolean to the "entry" structure to indicate a fully allocated > buffer and complete the allocation (where reasonable) at dispatch time. The flag is already there: > if ( (Length = Cache_parse_field(header, "Content-Length")) != NULL ) { > entry->Flags |= CA_GotLength; /*** Here! ***/ > entry->TotalSize = strtol(Length, NULL, 10); > g_free(Length); > if (entry->TotalSize < entry->ValidSize) > entry->TotalSize = 0; > } -- Cheers Jorge.-

Sept. 8, 2006

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by R.L. Horn

On Thu, 7 Sep 2006, Jorge Arellano Cid wrote: >> (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.) > > Yes, more or less this is the plan. Great! > OK, a good workaround is to check for huge filesizes while parsing the > header and to set as if no Content-length was given in that case. This > is simple and will work. That's kind of what I did. Actually, I just removed the code that had to do with static buffers entirely (while still allowing for a Content-length check). If the GTK branch weren't pretty well deprecated, I'd go ahead and do it right: Add a boolean to the "entry" structure to indicate a fully allocated buffer and complete the allocation (where reasonable) at dispatch time.

Sept. 8, 2006

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by Jorge Arellano Cid

Hi, On Wed, Sep 06, 2006 at 08:12:42PM -0500, R.L. Horn wrote: > 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.) Yes, more or less this is the plan. > > 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. Yes. I fixed this sometime ago in the FLTK2 branch... > > 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. OK, a good workaround is to check for huge filesizes while parsing the header and to set as if no Content-length was given in that case. This is simple and will work. (My FLTK2 source uses automatic buffers from a new library I made that also replaces glib). -- Cheers Jorge.-

Sept. 7, 2006

Serious Memory Allocation Strategy Problem in Cache_parse_header()

by R.L. Horn

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.

Sept. 7, 2006

Re: [Dillo-dev] Patches

by Jan Stary

On Sep 03 14:22:41, Rob Cherveny wrote: > I have freebsd and am using dillo. > Can someone help me install the patch > for using tabs? just use ports/www/dillo-i18n h.

Sept. 6, 2006

Re: [Dillo-dev] More signal :-)

by Jorge Arellano Cid

On Mon, Sep 04, 2006 at 08:57:14PM +0200, leslie.polzer(a)gmx.net wrote: > On Sun, Sep 03, 2006 at 10:50:21AM -0400, Jorge Arellano Cid wrote: > > > On Fri, Sep 01, 2006 at 02:03:42PM -0400, Roberto C. Sanchez wrote: > > > > > When will the transition to FLTK begin? > > > > ?? > > > > It started a long time ago, circa the beginning of 2005, with the > > rendering abstraction layer. Now we have a prototype that's very > > advanced and unreleased. > I suppose the OP wanted to know when the FLTK port will be released. I don't know; most probably when we have the funds. Otherwise we have yet to decide what to do. > One question and a comments: why is it unreleased at this time? Some companies want to have an advantage to justify investment (as a six month window for instance), some others not. This may be the case. Companies looking to reduce costs, just take whatever is there and don't give back. BTW, this happened most of the time with the GTK1 branch of Dillo. FWIW, our idea has always been to have a Free SW Dillo with a view to accomplish its goals. If we had aimed for selling Dillo as propietary SW, it would have happened already. > I'm one of the people waiting for the FLTK thing to show up before I > look whether I'm able and willing to contribute to Dillo. It's a great > browser, and I'd like to help, but not by working on code that's > obsolete. Good! Sure, I understand the point. BTW, do you have FLTK2 experience? How much time are you willing to contribute to development? -- Cheers Jorge.-

Sept. 4, 2006

Re: [Dillo-dev] More signal :-)

by leslie.polzer＠gmx.net

On Sun, Sep 03, 2006 at 10:50:21AM -0400, Jorge Arellano Cid wrote: > On Fri, Sep 01, 2006 at 02:03:42PM -0400, Roberto C. Sanchez wrote: > > > When will the transition to FLTK begin? > > ?? > > It started a long time ago, circa the beginning of 2005, with the > rendering abstraction layer. Now we have a prototype that's very > advanced and unreleased. I suppose the OP wanted to know when the FLTK port will be released. One question and a comments: why is it unreleased at this time? I'm one of the people waiting for the FLTK thing to show up before I look whether I'm able and willing to contribute to Dillo. It's a great browser, and I'd like to help, but not by working on code that's obsolete. Leslie -- gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 http://nic-nac-project.de/~skypher/

Sept. 4, 2006

Re: [Dillo-dev] Patches

by Rob Funky

Perfect! Thankyou! I could not locate that page with google! Rob On 9/3/06, Tito <farmatito(a)tiscali.it> wrote: > > On Sunday 3 September 2006 20:22, Rob Cherveny wrote: > > I have freebsd and am using dillo. Can someone help me install the > patch > > for using tabs? > > http://teki.jpn.ph/pc/software/index-e.shtml > > > Thank you > > rob > > > > _______________________________________________ > Dillo-dev mailing list > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 3, 2006

Re: [Dillo-dev] Patches

by Tito

On Sunday 3 September 2006 20:22, Rob Cherveny wrote: > I have freebsd and am using dillo. Can someone help me install the patch > for using tabs? http://teki.jpn.ph/pc/software/index-e.shtml > Thank you > rob >

Sept. 3, 2006

Patches

by Rob Cherveny

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

Sept. 3, 2006

APOLOGY Re: Very, very strange (was Re: CSS, JS, tabs, frames )

by Beartooth

On Sun, 03 Sep 2006 13:54:51 -0400, Beartooth wrote: > On Sat, 02 Sep 2006 16:28:26 -0400, Beartooth wrote: > >> [...] > > I read Jorge Arellano Cid's reply to the above (dated 9/2 at 5:56); moved > to the next post and checked that; and started getting back to the > previous, in order to ask a follow-up question about fluxbox, which he had > mentioned. > > Suddenly I can't. Clicking back on it fails. Hitting enter after that > fails. Going to another dillo post and then back fails both times. Even > going to another gmane group and coming back to this one fails both times. Sorry! Posted to wrong list; belongs, obviously, in Pan; I'll put it there. Again, my apologies! -- Beartooth Staffwright, Wordcrafty Squirreler FC5; Pine 4.64, Pan 0.14.2.91; Privoxy 3.0.3; CXO 5.0.1 Dillo 0.8.5, Opera 9.01, Firefox 1.5, Galeon 2.0.1 Remember I have little idea what I am talking about.

Sept. 3, 2006

Very, very strange (was Re: CSS, JS, tabs, frames )

by Beartooth

On Sat, 02 Sep 2006 16:28:26 -0400, Beartooth wrote: > [...] > Fwiw, as a thoroughly subtechnoid user, I've been running the "i18n misc" > dillo with tabs for quite a while now. (I'm not sure why -- most likely > some yum repository for FC5 sees it as a higher release number -- but I'm > glad.) > > The tabs are indeed a fine thing. Unfortunately, I can't offer anything in > return but praise; but this is meant to be read as a *lot* of that. There > have been times when I had as many as a dozen open, and always with great > success. Many, many thanks to the developers! I read Jorge Arellano Cid's reply to the above (dated 9/2 at 5:56); moved to the next post and checked that; and started getting back to the previous, in order to ask a follow-up question about fluxbox, which he had mentioned. Suddenly I can't. Clicking back on it fails. Hitting enter after that fails. Going to another dillo post and then back fails both times. Even going to another gmane group and coming back to this one fails both times. The log shows things like this : [btth@localhost ~]$ cat PanTemp Sun, 03 Sep 2006 13:46:39 - Loaded 5 articles for group "saved_posts" in 0.1 seconds (82 art/sec) Sun, 03 Sep 2006 13:46:39 - Scored 5 entries in 0.0 seconds (5000 articles/sec) Sun, 03 Sep 2006 13:46:39 - Saved 3269 articles in "gmane.comp.web.dillo.devel" in 0.1 seconds (30435 art/sec) Sun, 03 Sep 2006 13:46:57 - Loaded 3269 articles for group "gmane.comp.web.dillo.devel" in 0.1 seconds (42898 art/sec) Sun, 03 Sep 2006 13:46:57 - Scored 3269 entries in 0.0 seconds (113807 articles/sec) Sun, 03 Sep 2006 13:50:51 - Error reading file "/home/btth/.pan/messages/cache/20060902215624.GF2570(a)dillo.org.msg": Failed to open file '/home/btth/.pan/messages/cache/20060902215624.GF2570(a)dillo.org.msg': No such file or directory Sun, 03 Sep 2006 13:50:51 - Error reading file "/home/btth/.pan/messages/cache/20060902215624.GF2570(a)dillo.org.msg": Failed to open file '/home/btth/.pan/messages/cache/20060902215624.GF2570(a)dillo.org.msg': No such file or directory [btth@localhost ~]$ Wha hoppen?? Is it on my end??? -- Beartooth Staffwright, Wordcrafty Squirreler FC5; Pine 4.64, Pan 0.14.2.91; Privoxy 3.0.3; CXO 5.0.1 Dillo 0.8.5, Opera 9.01, Firefox 1.5, Galeon 2.0.1 Remember I have little idea what I am talking about.

Sept. 3, 2006

Re: [Dillo-dev] More signal :-)

by Jorge Arellano Cid

On Fri, Sep 01, 2006 at 02:03:42PM -0400, Roberto C. Sanchez wrote: > When will the transition to FLTK begin? ?? It started a long time ago, circa the beginning of 2005, with the rendering abstraction layer. Now we have a prototype that's very advanced and unreleased. See: http://www.dillo.org/Plans.html (the green balls are already there). -- Cheers Jorge.-

Sept. 3, 2006

Re: [Dillo-dev] Problems with gziped content encodings pages and proposal

by Jorge Arellano Cid

On Tue, Aug 29, 2006 at 06:40:40PM +0200, Diego Sáenz wrote: > Ok, second try(i have changed a pair of things): > > The general ideas are to enhance dpid to manage DPIs using services (Like documentation suggest) and to add code to dillo to implement protocols DPIs (without hardcoding them in dillo core), mime handlers DPIs and maybe scripts languages DPIs and content encodig DPIs(now encodigs DPIs are in doubt after your mail) > > Dpid will need configuration lines(in dpidrc) to associate server name with DPI path(A dpi dir based path allow a DPI to serve more that one service(in this proposal a javascript DPI will serve protocol_javascript, script_javascript and maybe mime_text/javascript services)). > > When dillo finds a protocol that it not handle in core (currently it handle http:, about: and dpi:) it ask for a service for that protocol(to dpid) and dpid returns the DPI from the configuration file(really a socket to comunicate with it). For the service name dillo add the protocol name to the "protocol_" string. > > The lines in dpidrc for current services can be this: > > protocol_file=file/file.dpi > protocol_ftp=ftp/ftp.filter.dpi > protocol_https=https/https.filter.dpi > protocol_data=datauri/datauri.filter.dpi > > I think i will allow the use of '*' to match any(even none) char until end of string in the configuration file. '*' will be checked last. It can be used by a ProtocolNotSupported.dpi that show an error or a page with protocols DPIs to download. > > The dpidrc line can be like this: > protocol_*=misc/ProtocolNotSupported.dpi > > For mime types it works similar. When the user clicks on a link or uses the url bar to view a mime type not handled by dillo the mime type is addeded to the "mime_" string to get the service name(dillo currently handles mime_text/html, mime_text/plain, mime_text/*, mime_image/gif, mime_image/jpeg, mime_image/png). When a not handled mime type is open because a page load dillo add the "_inlined" string to the previous string(example: For a bmp file used like image in a html page dillo will try the mime_image/x-bmp_inlined service) > > The use of '*' wildcard allow the use of one DPI to manage both services with only a configuration line if user wants. > > About mime type check/detection i am thinking on diferent options (mime detection/check go before mime DPIs) > 1a. Fixed service called for pages without mime types and ocet/stream (using this like unknown mime type) that returns a detected mime > 1b. Fixed service called for pages without mimes and for a list of configured mime types in dillorc > 2a. Check service per mime type with service names like mime_check_MIME/TYPE. Dillo send actuall type so the DPI handling the service can do something if detected mime is diferent from the server sended one.(ask the user, ignore error, stop load ...) > 2b. Like 2b, but only ask for a list of mimes configured in dillorc > > Scripts and content encoding work similarly. > > For more details i can send how the dpi tags will be and more about dillo-DPIs communication and dillo internal changes. At this phase I'd appreciatte much more the "general picture" rather than some implementation details. I mean. What's the problem you're trying to solve? What's the scheme you propose? Have you tested it to suit current functionality and maybe other problems too? For instance, if you click over a network radio link, it's not a good idea to use dillo to download the link data and to pass it via dpi to a dpi-radio plugin (and worst, to cache the stream! :). It's much better to cut the network connection from dillo and to handle the URL to a dedicated radio-stream program. In the case of a PDF. It would be nice to save the data to some temporary directory while you pipe it into xpdf or to let the user choose whether to save with a dialog. Same for a movie stream, etc, etc. > > > With regard to gzip encoding: zlib can do gzip decoding, and as > > it is already linked in Dillo, gzip decoding can be implemented > > inside Dillo (not using a dpi). > > Oh, i forgot it. Will you implement this? > > > This also avoids multiple dpi passes. For instance with dpi- > > decompress, gzipped isolatin2 would require one dpi pass for > > uncompress and another for latin2 to utf8. > > > > Inside-Dillo decoding also allows the idea of having a > > compressed cache in the future. > > I unknown if i can implement content encoding in dillo > internals so i will move it after dpid changes on implementation > complex. IMO this is much simpler tan what you're willing to try first. Beware. -- Cheers Jorge.-

Sept. 2, 2006

Re: [Dillo-dev] Re: CSS, JS, tabs, frames (Was: computer perfect for Dillo)

by Jorge Arellano Cid

On Sat, Sep 02, 2006 at 04:28:26PM -0400, Beartooth wrote: > On Fri, 01 Sep 2006 12:41:23 -0400, Jorge Arellano Cid wrote: > [...] > >>> Tabs, on the other hand, are extremely useful - I dream of the day > >> they come to dillo, making it able to have many pages rendered at > >> once (each with dillo's lightning speed). > > > > Yes, they're useful. I used to enjoy tabs in the window manager > > (fluxbox), but I also understand there's plenty of people without > > tabs in the window manager. > > > > The main reason for not coding tabs already in the official > > dillo is that there were higher priorities. The tabs patch was a > > several-features in a huge combo that the author was not willing > > to split. > > > > The good news of this story is that you can get that patchset > > from a compilation by kiyo on what's regarded as the "i18n misc" > > dillo: > > > > http://teki.jpn.ph/pc/software/index-e.shtml > > > > I find this compilation a very good thing to have, bacause > > users get what they want while we can work on a more long-term > > viable dillo (see rationale in my former posts). > [...] > Fwiw, as a thoroughly subtechnoid user, I've been running the "i18n misc" > dillo with tabs for quite a while now. (I'm not sure why -- most likely > some yum repository for FC5 sees it as a higher release number -- but I'm > glad.) > > The tabs are indeed a fine thing. Unfortunately, I can't offer anything in > return but praise; but this is meant to be read as a *lot* of that. There > have been times when I had as many as a dozen open, and always with great > success. Many, many thanks to the developers! Thanks for the recognition! :-) FWIW, if you pick the vanilla dillo and use fluxbox, you'll also have TABS (i.e. TABS have nothing to do with the number of open windows that dillo can handle). -- Cheers Jorge.-

Sept. 2, 2006

Re: [Dillo-dev] Re: FYI, there're near 250 subscribers in dillo-dev.

by Jorge Arellano Cid

On Sat, Sep 02, 2006 at 04:16:59PM -0400, Beartooth wrote: > On Fri, 01 Sep 2006 13:55:16 -0400, Jorge Arellano Cid wrote: > > > Quiet crowd, isn't it? :-) > > > > That keeps the signal/noise ratio high, > > just wish there was more signal! > > I'm guessing is that counts those of us following via Gmane, or at least > the ones who can post, since iirc posting requires a subscription. Any > guess at pure-lurker numbers? Subscribers. -- Cheers Jorge.-

Sept. 2, 2006

Re: CSS, JS, tabs, frames (Was: computer perfect for Dillo)

by Beartooth

On Fri, 01 Sep 2006 12:41:23 -0400, Jorge Arellano Cid wrote: [...] >>> Tabs, on the other hand, are extremely useful - I dream of the day >> they come to dillo, making it able to have many pages rendered at >> once (each with dillo's lightning speed). > > Yes, they're useful. I used to enjoy tabs in the window manager > (fluxbox), but I also understand there's plenty of people without > tabs in the window manager. > > The main reason for not coding tabs already in the official > dillo is that there were higher priorities. The tabs patch was a > several-features in a huge combo that the author was not willing > to split. > > The good news of this story is that you can get that patchset > from a compilation by kiyo on what's regarded as the "i18n misc" > dillo: > > http://teki.jpn.ph/pc/software/index-e.shtml > > I find this compilation a very good thing to have, bacause > users get what they want while we can work on a more long-term > viable dillo (see rationale in my former posts). [...] Fwiw, as a thoroughly subtechnoid user, I've been running the "i18n misc" dillo with tabs for quite a while now. (I'm not sure why -- most likely some yum repository for FC5 sees it as a higher release number -- but I'm glad.) The tabs are indeed a fine thing. Unfortunately, I can't offer anything in return but praise; but this is meant to be read as a *lot* of that. There have been times when I had as many as a dozen open, and always with great success. Many, many thanks to the developers! -- Beartooth Staffwright, Wordcrafty Squirreler FC5; Pine 4.64, Pan 0.14.2.91; Privoxy 3.0.3; CXO 5.0.1 Dillo 0.8.5, Opera 9.01, Firefox 1.5, Galeon 2.0.1 Remember I have little idea what I am talking about.

Sept. 2, 2006

Re: FYI, there're near 250 subscribers in dillo-dev.

by Beartooth

On Fri, 01 Sep 2006 13:55:16 -0400, Jorge Arellano Cid wrote: > Quiet crowd, isn't it? :-) > > That keeps the signal/noise ratio high, > just wish there was more signal! I'm guessing is that counts those of us following via Gmane, or at least the ones who can post, since iirc posting requires a subscription. Any guess at pure-lurker numbers? -- Beartooth Staffwright, Wordcrafty Squirreler FC5; Pine 4.64, Pan 0.14.2.91; Privoxy 3.0.3; CXO 5.0.1 Dillo 0.8.5, Opera 9.01, Firefox 1.5, Galeon 2.0.1 Remember I have little idea what I am talking about.

Sept. 2, 2006

More signal :-)

by Roberto C. Sanchez

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

Sept. 1, 2006

FYI, there're near 250 subscribers in dillo-dev.

by Jorge Arellano Cid

Quiet crowd, isn't it? :-) That keeps the signal/noise ratio high, just wish there was more signal! -- Cheers Jorge.-

Sept. 1, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Jorge Arellano Cid

Hi, On Thu, Aug 31, 2006 at 09:47:00PM -0700, Globe Trotter wrote: > Hi, > > I read this thread and every post on here, and decided to respond. I really > love dillo and am frustrated that I still have to use other hogs such as > firefox and would really love to see it move so that I don't have to. I've devoted almost seven years of my life to make it happen. Of course I'd also love to see Dillo fulfilling its goals! Now, with lack of manpower/funds, that's not going to happen. Even if only one core developer gets to be working full time on it, it's not enough manpower to keep the pace of the moving target that a web browser is. With two core developers plus the usual free-lance developers: it could be. > > --- Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Although I certainly regard the "i18n" patch-gathering as a > > good thing for the user, IMO dillo-gtk1 is a dead end from the > > development point of view (even if the gathered patches were in > > line with the rest of dillo's design, which is not the case). > > > > GTK1 is an abandoned library, it has become the much bigger, > > slower and capable GTK2, precisely because it was not suited for > > solving certain "desktop" problems. > > > > You can read Owen Taylor's "Internationalization in GTK+" paper > > for a more solid basis on i18n design decisions (Owen is one of > > the main authors of GTK1 and GTK2). > > > > http://developer.gnome.org/doc/whitepapers/gtki18n/index.html > > > > It can be thought that Dillo "i18n" would have more hope if > > ported to GTK2. Following this line, we made some benchmarks, > > investigated in more depth, I had some emails with Owen, we had a > > discussion in the mailing list, and it turned out that: > > > > * GTK2 could double Dillo's footprint. > > * GTK2 has different expose model that woul require a redesign > > of the incremental rendering inside Dillo. > > * Dillo would become much slower and resource hungry. > > > > If Dillo becomes slower and has a bigger footprint, its main > > advantages start to dissapear when compared with let's say > > Firefox or Opera. In that case even I'd prefer to wait a bit > > longer for Firefox to start and then have a featureful browser. > > > > Dillo's main advantage is a tradeoff of features for speed. If > > the speed edge disappears, what do we have? > > > > In short, after lots of investigation we decided to port Dillo > > to FLTK2 (Although there's plenty of information about this in > > the mailing list, I realize it would be good to recapitulate this > > story and make this information together with future plans > > available from one page in our site. This mail is the first step > > in that direction). > > I agree, but when are you planning on releasing the FLTK2 port? _Probably_ when funding happens. > I think a lot > of people are waiting for this before they even start doing anything with > developing more, etc. If there's people willing to develop for Dillo seriously (6 months+ period) reading this, please show up on this thread! We need steady developers, that's the way to advance the project. Of course fixing small glitches helps, but that's polishing, not mainline. > > With regard to Javascript, yes we also agree that we need to > > support some scripting language (ECMA or whatever). We've > > developed in this direction too (For instance we have the DOM > > code almost ready, and dpi can provide the link to the script > > interpreter; we even have developed a prototype for scheme). > > > > Tabs are easy to add too, and although I hate frames, they > > should be supported (sigh). BTW, I always had this in mind and > > that's why it was easy to make a frames patch. The networking > > code was already designed for the parallelism this task requires. > > It's a matter of implementing its rendering. > > > > Somehow people tend to believe that features are not there > > because the core team doesn't want them. Or even because they do > > not have room in a minimalistic browser. This is _not_ true. The > > main reason is lack of manpower. > > Agreed: no question. Developing any product, much less a fabulous one like > dillo, needs huge manpower. Thanks for recognizing our effort. > > > > The other reasons are the GTK1 issue explained above and that > > these patches were not in line with the rest of the design, and > > that they break several things too (I've always asked authors to > > let their users know what each patch breaks). > > > > Having another design idea is valid, but it can't be pushed > > against those who think different (see LKML for examples! ;-). > > Forks had been announced but none thrived. > > > > > > > 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. > > > > We think Dillo needs CSS, > > so don't panic dillo-dev subscribers! :-) > > > > As a matter of fact, the widget style structures inside Dillo > > are shaped for CSS, and we presented a CSS parser prototype at > > FOSDEM 2005. Merging the CSS parser into the current tree would > > start CSS support. > > > > As for your concerns, disabling this is a piece of cake. > > > > > > > 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. :) > > > > Real money is a problem I haven't figured how to solve yet. > > > > For instance, there're plenty of embedded-focused companies > > that are interested, or already working with Dillo. They seem > > to prefer to wait for us to develop, with a view to lower costs, > > rather than to contribute (patches or money) or fund some > > development. These are the cheap companies. > > > > Other companies have interest and money to fund and foster > > Dillo development. The problem here is that managers prefer to > > make a choice for the "tried and true" and not to risk their jobs > > in the company in case of failure. > > > > I don't know yet how to solve the second problem. Any help is > > welcomed. > > I don't see this dollars-problem being solved. One of the issues is that dillo > tries to be too strict in some regard. For instance, the https is disabled by > default and has to be enabled in the source code. Most users perhaps take a > binary from some RPM or somewhere, so it stays default most of the time. It > would really be nice if this was enabled/disabled by means of a "switch" and > one did not have to recompile the whole source code. I must say that this does > not solve the dollars question, but this is an issue worth considering. I whish it was that easy! Enabling https is a piece of cake, but some sites would lock dillo (the https dpi doesn't support multiple requests for the same site yet), and it's _not_ secure because it's not validating the certificates. Go try to explain that to a user, and sign a dillo version with https enabled. We can't because we're commited to security. We can let the user choose later to loose all protection, but this is his decision. (same as with the linux kernel). > Have you considered moving dillo to a community project model? It _is_ like that. > I know that > there are core developers and they could vet things submitted, but it would be > better if there were more contributor developers who submitted their > improvements. Something like, for instance, the R project in statistical > computing. Or for that matter, octave or xemacs and the like. Somehow, > somewhere earlier on, I got the impression that contributions are not really > encouraged: if it does not meet the core team's objectives, it is not cared > for. This is the situation for every single OSS project. Try to submit a patch against Linus' design decisions to LKML! > Maybe what I am suggesting is already done and maybe this is a false > impression on my part, and I am sorry if that is so. It was sad for me to re-read some posts by one guy that came with lots of radical ideas (not code), as rewriting the IO, eliminating the dillo plugin system, eliminating the CCC control chain "nightmare". (this is writing a different browser) He whined a lot and was very rude sometimes. Finally he decided to start a fork (IIRC), that in his view, would be much better than official Dillo. The fork never happened. Where's that code? Unfortunately what he said, more or less convinced some people in dillo-dev. From above it made sense. OTOH, he never realized that the CCC structure wasn't about just passing data, but about parallelism! That's why IMHO experienced developers tend to consider what the core team of any project thinks. We all know the core team may make mistakes, but they talk from experience and have deep knowledge of the systems they develop. It's also well known that when a core developer leaves, it's a _BIG_ loss. You can certainly find great developers elsewhere, buy no one will have the specific knowledge and experience of the one that leaves. It takes time to get there. Note: Oh, there were more brags (someone here remembers the one that bashed me and promised a much better and complete Dillo for windows in six months?) Years have passed since... Note2: making a patch and maintaining it are different things. Note3: making a patch that works, and one that fits with the design are also different things. The second one has less side effects and is easier to maintain. > I only know that I want dillo to succeed and replace firefox, the so-called > lightweight browser. I wish Dillo to succeed. We need manpower/funds. Can anyone here help with that? -- Cheers Jorge.-

Sept. 1, 2006

Re: [Dillo-dev] CSS,JS,tabs,frames (Was: computer perfect for Dillo)

by Jorge Arellano Cid

Hi Jan, On Thu, Aug 31, 2006 at 02:15:16PM +0200, Jan Stary wrote: > Hi all, > > On Aug 24 17:07:21, Sam Trenholme wrote: > > The problem is that Dillo doesn't support a lot of high-profile > > internet sites right now. > > > 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. > > On Aug 24 21:56:17, Hans Hohenfeld wrote: > > I definitely disagree. From my point of view, CSS is the most missing > > feature in Dillo. Frames are minor impotant (as only bad websites use > > them), Javascript is very much necessary, but CSS seems to be the most > > important feature Dillo needs. Some basic CSS attributes like colors, > > positioning would be a good start. I agree, that it is very important to > > implement CSS support as close to the standard as possible. > > I also think that CSS is the most missing feature - while a well > written page using CSS looks good even without it, many pages > just rely on being CSS-interpreted (or look ugly). HTML/CSS is > the most basic combo for a browser anyway, I think. Different people tend to prioritize differently. For instance, the embedded industry needs Javascript to develop custom GUIs and sometimes also for a certain site they _have_ to support. The soothing fact for CSS in Dillo is that the internal widget style design was made for CSS. So it's a matter of gluing it together. Once again: manpower > As for JavaScript, what pages worth reading need JavaScript to > work? With the lack of dillo-dev manpower, this is a feature > I don't really miss. I'm not fond of Javascript either; it's a big security hole, but I also understand that it's a good way for developing WEB based GUIs for networked services. > Tabs, on the other hand, are extremely useful - I dream of the day > they come to dillo, making it able to have many pages rendered at > once (each with dillo's lightning speed). Yes, they're useful. I used to enjoy tabs in the window manager (fluxbox), but I also understand there's plenty of people without tabs in the window manager. The main reason for not coding tabs already in the official dillo is that there were higher priorities. The tabs patch was a several-features in a huge combo that the author was not willing to split. The good news of this story is that you can get that patchset from a compilation by kiyo on what's regarded as the "i18n misc" dillo: http://teki.jpn.ph/pc/software/index-e.shtml I find this compilation a very good thing to have, bacause users get what they want while we can work on a more long-term viable dillo (see rationale in my former posts). > > Frames are evil, everybody knows that. Yes. Some sites need it though... (sigh) Lower priority. ... unless a company comes with some funds for speeding it. > > On Aug 26 12:11:46, Jorge Arellano Cid wrote: > > GTK1 is an abandoned library, it has become the much bigger, > > slower and capable GTK2, precisely because it was not suited for > > solving certain "desktop" problems. > > Dillo's main advantage is a tradeoff of features for speed. If > > the speed edge disappears, what do we have? > > Totaly agreed. > > > As a matter of fact, the widget style structures inside Dillo > > are shaped for CSS, and we presented a CSS parser prototype at > > FOSDEM 2005. Merging the CSS parser into the current tree would > > start CSS support. > > Looking at the FOSDEM presentation, I can't seem to > find the CSS bits (in neither mgp or html - > http://www.dillo.org/fosdem2005/dillo-18.html > points to "http://www.dillo.org/fosdem2005/....." > Can I get the CSS part of the presentation somewhere? Unfortunately not. :-( We gave that conference with Sebastian at FOSDEM 2005, and it had the plus of some live demos. One of them was a CSS prototype! Unfortunately on the next conference (LSM 2005, which is on video available from dillo.org) I was alone, and this DEMO wasn't presented. The demo consisted of a page with a link to its CSS stylesheet; the interesting part was that CSS was applied on-the-fly! This is: Dillo started normal incremental rendering (no CSS), and when the CSS stylesheet arrived later, and while still loading the page, in a blink it changed to show the CSS style, and continued with page rendering until it fully arrived. FWIW, while in Germany we discussed how to design scripting support. Now that Dillo produces a DOM it's a matter of using dpi to communicate with the scripting engine. A prototype was developed too. The main point is lack of manpower/funds. We can _not_ continue developing without time (spare time is unrealistic for such a complex project as this). That's why I've struggled to find a way to fund full time development for at least the two core developers. When finally a couple of companies were willing to invest, the "risk management" factor came in and stopped it. I don't know how to surpass this problem (see my previous email for more details). -- Cheers Jorge.-

Sept. 1, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Globe Trotter

Hi, I read this thread and every post on here, and decided to respond. I really love dillo and am frustrated that I still have to use other hogs such as firefox and would really love to see it move so that I don't have to. --- Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Although I certainly regard the "i18n" patch-gathering as a > good thing for the user, IMO dillo-gtk1 is a dead end from the > development point of view (even if the gathered patches were in > line with the rest of dillo's design, which is not the case). > > GTK1 is an abandoned library, it has become the much bigger, > slower and capable GTK2, precisely because it was not suited for > solving certain "desktop" problems. > > You can read Owen Taylor's "Internationalization in GTK+" paper > for a more solid basis on i18n design decisions (Owen is one of > the main authors of GTK1 and GTK2). > > http://developer.gnome.org/doc/whitepapers/gtki18n/index.html > > It can be thought that Dillo "i18n" would have more hope if > ported to GTK2. Following this line, we made some benchmarks, > investigated in more depth, I had some emails with Owen, we had a > discussion in the mailing list, and it turned out that: > > * GTK2 could double Dillo's footprint. > * GTK2 has different expose model that woul require a redesign > of the incremental rendering inside Dillo. > * Dillo would become much slower and resource hungry. > > If Dillo becomes slower and has a bigger footprint, its main > advantages start to dissapear when compared with let's say > Firefox or Opera. In that case even I'd prefer to wait a bit > longer for Firefox to start and then have a featureful browser. > > Dillo's main advantage is a tradeoff of features for speed. If > the speed edge disappears, what do we have? > > In short, after lots of investigation we decided to port Dillo > to FLTK2 (Although there's plenty of information about this in > the mailing list, I realize it would be good to recapitulate this > story and make this information together with future plans > available from one page in our site. This mail is the first step > in that direction). I agree, but when are you planning on releasing the FLTK2 port? I think a lot of people are waiting for this before they even start doing anything with developing more, etc. > With regard to Javascript, yes we also agree that we need to > support some scripting language (ECMA or whatever). We've > developed in this direction too (For instance we have the DOM > code almost ready, and dpi can provide the link to the script > interpreter; we even have developed a prototype for scheme). > > Tabs are easy to add too, and although I hate frames, they > should be supported (sigh). BTW, I always had this in mind and > that's why it was easy to make a frames patch. The networking > code was already designed for the parallelism this task requires. > It's a matter of implementing its rendering. > > Somehow people tend to believe that features are not there > because the core team doesn't want them. Or even because they do > not have room in a minimalistic browser. This is _not_ true. The > main reason is lack of manpower. Agreed: no question. Developing any product, much less a fabulous one like dillo, needs huge manpower. > > The other reasons are the GTK1 issue explained above and that > these patches were not in line with the rest of the design, and > that they break several things too (I've always asked authors to > let their users know what each patch breaks). > > Having another design idea is valid, but it can't be pushed > against those who think different (see LKML for examples! ;-). > Forks had been announced but none thrived. > > > > 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. > > We think Dillo needs CSS, > so don't panic dillo-dev subscribers! :-) > > As a matter of fact, the widget style structures inside Dillo > are shaped for CSS, and we presented a CSS parser prototype at > FOSDEM 2005. Merging the CSS parser into the current tree would > start CSS support. > > As for your concerns, disabling this is a piece of cake. > > > > 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. :) > > Real money is a problem I haven't figured how to solve yet. > > For instance, there're plenty of embedded-focused companies > that are interested, or already working with Dillo. They seem > to prefer to wait for us to develop, with a view to lower costs, > rather than to contribute (patches or money) or fund some > development. These are the cheap companies. > > Other companies have interest and money to fund and foster > Dillo development. The problem here is that managers prefer to > make a choice for the "tried and true" and not to risk their jobs > in the company in case of failure. > > I don't know yet how to solve the second problem. Any help is > welcomed. I don't see this dollars-problem being solved. One of the issues is that dillo tries to be too strict in some regard. For instance, the https is disabled by default and has to be enabled in the source code. Most users perhaps take a binary from some RPM or somewhere, so it stays default most of the time. It would really be nice if this was enabled/disabled by means of a "switch" and one did not have to recompile the whole source code. I must say that this does not solve the dollars question, but this is an issue worth considering. I doubt that you can get commercial vendors involved in this effort? The only other option is contributions, and even that is perhaps finite, especially if stuff people would like to see in their favorite browser is not going to show up. So, that leaves the contributions in terms of time and effort. Have you considered moving dillo to a community project model? I know that there are core developers and they could vet things submitted, but it would be better if there were more contributor developers who submitted their improvements. Something like, for instance, the R project in statistical computing. Or for that matter, octave or xemacs and the like. Somehow, somewhere earlier on, I got the impression that contributions are not really encouraged: if it does not meet the core team's objectives, it is not cared for. Maybe what I am suggesting is already done and maybe this is a false impression on my part, and I am sorry if that is so. I only know that I want dillo to succeed and replace firefox, the so-called lightweight browser. Thanks for reading! Best wishes, Trotter. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 1, 2006

Re: [Dillo-dev] CSS,JS,tabs,frames (Was: computer perfect for Dillo)

by Jan Stary

Hi all, On Aug 24 17:07:21, Sam Trenholme wrote: > The problem is that Dillo doesn't support a lot of high-profile > internet sites right now. > 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. On Aug 24 21:56:17, Hans Hohenfeld wrote: > I definitely disagree. From my point of view, CSS is the most missing > feature in Dillo. Frames are minor impotant (as only bad websites use > them), Javascript is very much necessary, but CSS seems to be the most > important feature Dillo needs. Some basic CSS attributes like colors, > positioning would be a good start. I agree, that it is very important to > implement CSS support as close to the standard as possible. I also think that CSS is the most missing feature - while a well written page using CSS looks good even without it, many pages just rely on being CSS-interpreted (or look ugly). HTML/CSS is the most basic combo for a browser anyway, I think. As for JavaScript, what pages worth reading need JavaScript to work? With the lack of dillo-dev manpower, this is a feature I don't really miss. Tabs, on the other hand, are extremely useful - I dream of the day they come to dillo, making it able to have many pages rendered at once (each with dillo's lightning speed). Frames are evil, everybody knows that. On Aug 26 12:11:46, Jorge Arellano Cid wrote: > GTK1 is an abandoned library, it has become the much bigger, > slower and capable GTK2, precisely because it was not suited for > solving certain "desktop" problems. > Dillo's main advantage is a tradeoff of features for speed. If > the speed edge disappears, what do we have? Totaly agreed. > As a matter of fact, the widget style structures inside Dillo > are shaped for CSS, and we presented a CSS parser prototype at > FOSDEM 2005. Merging the CSS parser into the current tree would > start CSS support. Looking at the FOSDEM presentation, I can't seem to find the CSS bits (in neither mgp or html - http://www.dillo.org/fosdem2005/dillo-18.html points to "http://www.dillo.org/fosdem2005/....." Can I get the CSS part of the presentation somewhere? Thanks Jan

Aug. 31, 2006

Re: [Dillo-dev] Problems with gziped content encodings pages and proposal

by Diego Sáenz

El Sun, 27 Aug 2006 12:53:47 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi, > > On Fri, Aug 25, 2006 at 03:49:10AM +0200, Diego Sáenz wrote: > > Hello again. > > > > > [...] > > > > 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! :) > > [...] > > > > I have started to code my proposal. > > Beware, your first mail is very hard to read an understand (I > don't understand it for instance). Sorry. I almost forgot how to write english when i do not write it in a long time. > The subject matter is complex, so I'd advice you to: take your > time, re-think, be more careful with your english, and to try to > express the ideas as clearly as possible. Ok, second try(i have changed a pair of things): The general ideas are to enhance dpid to manage DPIs using services (Like documentation suggest) and to add code to dillo to implement protocols DPIs (without hardcoding them in dillo core), mime handlers DPIs and maybe scripts languages DPIs and content encodig DPIs(now encodigs DPIs are in doubt after your mail) Dpid will need configuration lines(in dpidrc) to associate server name with DPI path(A dpi dir based path allow a DPI to serve more that one service(in this proposal a javascript DPI will serve protocol_javascript, script_javascript and maybe mime_text/javascript services)). When dillo finds a protocol that it not handle in core (currently it handle http:, about: and dpi:) it ask for a service for that protocol(to dpid) and dpid returns the DPI from the configuration file(really a socket to comunicate with it). For the service name dillo add the protocol name to the "protocol_" string. The lines in dpidrc for current services can be this: protocol_file=file/file.dpi protocol_ftp=ftp/ftp.filter.dpi protocol_https=https/https.filter.dpi protocol_data=datauri/datauri.filter.dpi I think i will allow the use of '*' to match any(even none) char until end of string in the configuration file. '*' will be checked last. It can be used by a ProtocolNotSupported.dpi that show an error or a page with protocols DPIs to download. The dpidrc line can be like this: protocol_*=misc/ProtocolNotSupported.dpi For mime types it works similar. When the user clicks on a link or uses the url bar to view a mime type not handled by dillo the mime type is addeded to the "mime_" string to get the service name(dillo currently handles mime_text/html, mime_text/plain, mime_text/*, mime_image/gif, mime_image/jpeg, mime_image/png). When a not handled mime type is open because a page load dillo add the "_inlined" string to the previous string(example: For a bmp file used like image in a html page dillo will try the mime_image/x-bmp_inlined service) The use of '*' wildcard allow the use of one DPI to manage both services with only a configuration line if user wants. About mime type check/detection i am thinking on diferent options (mime detection/check go before mime DPIs) 1a. Fixed service called for pages without mime types and ocet/stream (using this like unknown mime type) that returns a detected mime 1b. Fixed service called for pages without mimes and for a list of configured mime types in dillorc 2a. Check service per mime type with service names like mime_check_MIME/TYPE. Dillo send actuall type so the DPI handling the service can do something if detected mime is diferent from the server sended one.(ask the user, ignore error, stop load ...) 2b. Like 2b, but only ask for a list of mimes configured in dillorc Scripts and content encoding work similarly. For more details i can send how the dpi tags will be and more about dillo-DPIs communication and dillo internal changes. > With regard to gzip encoding: zlib can do gzip decoding, and as > it is already linked in Dillo, gzip decoding can be implemented > inside Dillo (not using a dpi). Oh, i forgot it. > This also avoids multiple dpi passes. For instance with dpi- > decompress, gzipped isolatin2 would require one dpi pass for > uncompress and another for latin2 to utf8. > > Inside-Dillo decoding also allows the idea of having a > compressed cache in the future. I unknown if i can implement content encoding in dillo internals so i will move it after dpid changes on implementation complex. I hoppe it is more clear now. Diego

Aug. 29, 2006

Re: [Dillo-dev] Problems with gziped content encodings pages and proposal

by Jorge Arellano Cid

Hi, On Fri, Aug 25, 2006 at 03:49:10AM +0200, Diego Sáenz wrote: > Hello again. > > [...] > > 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! :) > [...] > > I have started to code my proposal. Beware, your first mail is very hard to read an understand (I don't understand it for instance). The subject matter is complex, so I'd advice you to: take your time, re-think, be more careful with your english, and to try to express the ideas as clearly as possible. With regard to gzip encoding: zlib can do gzip decoding, and as it is already linked in Dillo, gzip decoding can be implemented inside Dillo (not using a dpi). This also avoids multiple dpi passes. For instance with dpi- decompress, gzipped isolatin2 would require one dpi pass for uncompress and another for latin2 to utf8. Inside-Dillo decoding also allows the idea of having a compressed cache in the future. -- Cheers Jorge.-

Aug. 27, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Diego Sáenz

El Sat, 26 Aug 2006 12:11:46 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: [...] > PS2: Diego: I'll answer you ASAP. Don't worry about the parser, > it's already done. OK. I am sorry about the parser.

Aug. 27, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Jorge Arellano Cid

Hi, On Thu, Aug 24, 2006 at 05:07:21PM +0000, Sam Trenholme wrote: > This is the kind of computer that is perfect for Dillo: > > http://linuxdevices.com/news/NS6828123924.html Very interesting article! > > 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. I also think there're 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. No problem. More often than not, the maintainer agrees with some of the requests. Lack of manpower is the main barrier. > > 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. Although I certainly regard the "i18n" patch-gathering as a good thing for the user, IMO dillo-gtk1 is a dead end from the development point of view (even if the gathered patches were in line with the rest of dillo's design, which is not the case). GTK1 is an abandoned library, it has become the much bigger, slower and capable GTK2, precisely because it was not suited for solving certain "desktop" problems. You can read Owen Taylor's "Internationalization in GTK+" paper for a more solid basis on i18n design decisions (Owen is one of the main authors of GTK1 and GTK2). http://developer.gnome.org/doc/whitepapers/gtki18n/index.html It can be thought that Dillo "i18n" would have more hope if ported to GTK2. Following this line, we made some benchmarks, investigated in more depth, I had some emails with Owen, we had a discussion in the mailing list, and it turned out that: * GTK2 could double Dillo's footprint. * GTK2 has different expose model that woul require a redesign of the incremental rendering inside Dillo. * Dillo would become much slower and resource hungry. If Dillo becomes slower and has a bigger footprint, its main advantages start to dissapear when compared with let's say Firefox or Opera. In that case even I'd prefer to wait a bit longer for Firefox to start and then have a featureful browser. Dillo's main advantage is a tradeoff of features for speed. If the speed edge disappears, what do we have? In short, after lots of investigation we decided to port Dillo to FLTK2 (Although there's plenty of information about this in the mailing list, I realize it would be good to recapitulate this story and make this information together with future plans available from one page in our site. This mail is the first step in that direction). With regard to Javascript, yes we also agree that we need to support some scripting language (ECMA or whatever). We've developed in this direction too (For instance we have the DOM code almost ready, and dpi can provide the link to the script interpreter; we even have developed a prototype for scheme). Tabs are easy to add too, and although I hate frames, they should be supported (sigh). BTW, I always had this in mind and that's why it was easy to make a frames patch. The networking code was already designed for the parallelism this task requires. It's a matter of implementing its rendering. Somehow people tend to believe that features are not there because the core team doesn't want them. Or even because they do not have room in a minimalistic browser. This is _not_ true. The main reason is lack of manpower. The other reasons are the GTK1 issue explained above and that these patches were not in line with the rest of the design, and that they break several things too (I've always asked authors to let their users know what each patch breaks). Having another design idea is valid, but it can't be pushed against those who think different (see LKML for examples! ;-). Forks had been announced but none thrived. > 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. We think Dillo needs CSS, so don't panic dillo-dev subscribers! :-) As a matter of fact, the widget style structures inside Dillo are shaped for CSS, and we presented a CSS parser prototype at FOSDEM 2005. Merging the CSS parser into the current tree would start CSS support. As for your concerns, disabling this is a piece of cake. > 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. :) Real money is a problem I haven't figured how to solve yet. For instance, there're plenty of embedded-focused companies that are interested, or already working with Dillo. They seem to prefer to wait for us to develop, with a view to lower costs, rather than to contribute (patches or money) or fund some development. These are the cheap companies. Other companies have interest and money to fund and foster Dillo development. The problem here is that managers prefer to make a choice for the "tried and true" and not to risk their jobs in the company in case of failure. I don't know yet how to solve the second problem. Any help is welcomed. BTW, this list has hundreds of subscribers. Please ask your questions, and send your ideas. If the core developers can't work full time on Dillo development, we'll not be able to keep the pace to chase this moving target of web browsing and Dillo will slowly die. Sebastian has a job and almost no time. If things don't change, I'll be in the same situation very soon. -- Cheers Jorge.- PS : Flames are not allowed in this mailing list. PS2: Diego: I'll answer you ASAP. Don't worry about the parser, it's already done.

Aug. 26, 2006

Re: [Dillo-dev] Problems with gziped content encodings pages and proposal

by Diego Sáenz

Hello again. I have started to code my proposal. I have a little patch with the easiest part (dillo protocol part) so people can test it if they want. The patch is highly experimental. Dpid is not modified so (until it(the most complex part)) DPI tree and names of protocols DPIs will be break. It can be solved with a few moves and renames, but do not try it in a non test system if you do not known what are you doing. The patch works with current cvs. After compiling a dillo with the experimental protocol patch when dillo finds a url that do not start with http: or about: it will ask to dpid for a service called protocol_PROTOCOL-PART-OF-URL (examples: protocol_ftp for ftp urls, protocol_data for data urls , protocol_javascript for javascript urls(if you delete the code in html.c that intercepts javascript), ...). I will use protocol_https for examples from now. How dpid is not changed it will exec ~/.dillo/dpi/protocol_https/protocol_https.dpi or $dpi_lib/dpi/protocol_https/protocol_https.dpi (in the case that the file was there when dpid started) The changed dpid will exec the user selected DPI for that service when done. Until that If anybody want to play with this code apply the patch, compile with care(do not install it for example), create a DPI(a filter script one for example) in .../dpi/protocol_YOUR-PREFERED-PROTOCOL/protocol_YOUR-PREFERED-PROTOCOL.filter.dpi , stop and restart dpid and test pointing compiled dillo to YOUR-PREFERED-PROTOCOL:WHATEVER-YOU-WANT I have make a script for javascript urls to test it(see upper comment). I will try to code a more complex part (mime) now. Diego.

Aug. 25, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Diego Sáenz

El Thu, 24 Aug 2006 17:07:21 +0000 (UTC) Sam Trenholme <sam+dillo(a)chaosring.org> escribio: [...] > 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. If you do it, i will try to make a Dillo Plug-In with it. A DPI will work unmodified with or without i18n-patch/fork. If you want any help about Dillo PlugIns ask in the list and i will try to help. > 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. I disagree with you. Dillo needs CSS, well better said i need a dillo with CSS :P and i think that a lot of persons need it too. Until dillo suport enought the standard and pass ACID2 a note "wait until CSS test passed before mail your webmaster or test a page with dillo(if you are a webmaster)" can be enought. Dillo is still beta. Diego.

Aug. 25, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Hans Hohenfeld

On Thu, Aug 24, 2006 at 05:07:21PM +0000, Sam Trenholme wrote: > 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. I have a laptop with Pentium M 266 MHz and 96 MB RAM. I'm using Firefox and Dillo on that machine, while Firefox is most times much to slow (and slows down the rest of the system). > > That said, I feel there are some issues that stop Dillo from being the > browser to use on such a machine. > I agree, that's why I still use firefox on my laptop (which is a pain) > 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 remember a discussion on this list about this patched Dillo version (or Fork). I think the main reason against it was, that the code is to much messed up and doesn't fit dillo programming guidlines (Naming Conventions and so on), but maybe I remember wrong. > > 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. > I definitely disagree. From my point of view, CSS is the most missing feature in Dillo. Frames are minor impotant (as only bad websites use them), Javascript is very much necessary, but CSS seems to be the most important feature Dillo needs. Some basic CSS attributes like colors, positioning would be a good start. I agree, that it is very important to implement CSS support as close to the standard as possible. > 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 > -- derhans > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 24, 2006

The kind of computer that is perfect for Dillo

by Sam Trenholme

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

Aug. 24, 2006

Problems with gziped content encodings pages and proposal

by Diego Sáenz

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

Aug. 24, 2006

printing from dillo

by Globe Trotter

is it possible to print a webpage from dillo? many thanks and best wishes! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

July 13, 2006

Re: [Dillo-dev] Re: how do i unsubscribe?

by Patrick Shanahan

* Andrew A. Gill <superluser(a)frontiernet.net> [07-03-06 19:34]: > Yes, I know that I'm a few weeks late to comment on this, but I > genuinely HATE HATE HATE these unsubscribe requests. > > So here's a quick thing on how to unsubscribe: amazing how much information can be found in an email header: List-Id: For dillo web browser developers <dillo-dev.dillo.org> List-Unsubscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@dillo.org?subject=unsubscribe> List-Archive: </pipermail> List-Post: <mailto:dillo-dev@dillo.org> List-Help: <mailto:dillo-dev-request@dillo.org?subject=help> List-Subscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@dillo.org?subject=subscribe> Sender: dillo-dev-bounces(a)dillo.org Errors-To: dillo-dev-bounces(a)dillo.org -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

July 4, 2006

Re: how do i unsubscribe?

by Andrew A. Gill

Yes, I know that I'm a few weeks late to comment on this, but I genuinely HATE HATE HATE these unsubscribe requests. So here's a quick thing on how to unsubscribe: <http://www.things.org/~jym/fqa/unsubscribe.html> How To Unsubscribe From Any Email List By Jym Dyer I'm on a lot of electronic mailing lists. A deluge of "unsubscribe" and "take me off this list" messages on multiple lists inspired the following, which I send out whenever it's needed. The feedback I get tells me it's useful. When you send "unsubscribe" requests to an email list, it lands in the mailboxes of hundreds of people who can't unsubscribe you. I can't unsubscribe you. Try the stuff below. Clip 'n' save these instructions for future reference. =============8<=============Cut-Here=============8<============= How To Unsubscribe From Any Email List 1. Look at the messages you've been getting on the list. Do they have "how to unsubscribe" messages near the end, or an email address to use in a "List-Unsubscribe:" header at the top? If so, follow those instructions. 2. Most lists these days, including all lists hosted by the big two (Yahoo! Groups and Topica), have an "-unsubscribe" alias for this purpose. For example, if you're on the WHATEVER list, either WHATEVER-unsubscribe(a)yahoogroups.com or WHATEVER-unsubscribe(a)topica.com would be the right address to use. (For the rest of this memo, let's assume that the WHATEVER list is at example.com -- that is, the alias is WHATEVER(a)example.com. If the list has a name like "WHATEVER-L", you might try steps 6 and 7 first.) 3. Otherwise, first send a request to the "-request" alias. For our example, that would be WHATEVER-request(a)example.com. This is often read by a human being, so write accordingly. In theory, all email lists are supposed to implement this address (though Yahoo! Groups does not). 4. If you get no response from the above, send mail to the "majordomo" alias. That's majordomo(a)example.com for our example. If the list is administered by the majordomo software, you'll get instructions for unsubscribing mailed back to you. 5. If you get no response, send mail to the "owner-" alias. For our example, owner-WHATEVER(a)example.com. This should go to the human who administers the list. 6. If you get no response, send mail to "LISTSERV". For our example, that address would be LISTSERV(a)example.com. The text of your message should be "SIGNOFF WHATEVER". 7. If you get no response, send mail to the "listproc" alias. For our example, that address would be listproc(a)example.com. The text of your message should be "unsubscribe WHATEVER". 8. If you get no response, send mail to the site "postmaster". For our example, that address is postmaster(a)example.com. Mention that you tried the previous five steps, to no avail. 9. If you get no response, send mail to "root". Our example address is root(a)example.com. Mention that you tried the previous six steps, to no avail. 10. If -- and only if -- all the above fail, send a message to the list itself. Make it courteous, particularly since the vast majority of the people reading it can't do a thing about it. The message should say something like, "How do I get off this list?", not "UNSUBSCRIBE." Try to avoid setting off a bunch of "me too" messages by saying something like, "Please don't chime in with a bunch of 'I want to unsubscribe too' messages." It's ridiculous that there are so many different ways to do this, and consequentially, so many email lists cluttered up with "UNSUBSCRIBE/ME TOO" messages. You'd think there'd be a standard of sorts, and there is: the "-request" alias dates back to the early days of the Internet. Smart systems like majordomo actually (1) handle messages that were sent to the "-request" alias and (2) filter out the "UNSUBSCRIBE/ME TOO" messages. It's a shame that newer stuff has come along that doesn't do either of these things, but since it's on the web, people seem excited about it (gee whiz!) even though it's a huge step backwards in technology. The "-unsubscribe" alias is a newer standard that's starting to gain ground, but that's no help for many of the older lists that haven't gotten around to implementing new features.

July 3, 2006

Re: [Dillo-dev] how do i unsubscribe?

by Kelson Vibber

Right here: http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev There's an unsubscribe form at the bottom of the page.

June 12, 2006

how do i unsubscribe?

by mike obrien

most of the time, i have no idea what tf you guys are talking about. mike

June 12, 2006

Doubt...

by Sandesh Sethia

Hello everyone, This is my first post on this group. I am a novice programmer who wanted to know that can I use GTKDFB for creating a PNG image of any window (browser especially) delivered to the GTKDFB toolkit through a C++ program ? Please someone do let me know at the earliest..... Thanks Sandesh

June 12, 2006