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:
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.