The kind of computer that is perfect for Dillo
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
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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
El Thu, 24 Aug 2006 17:07:21 +0000 (UTC) Sam Trenholme <sam+dillo@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.
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.
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
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.-
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.
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.-
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@dillo.org.msg": Failed to open file '/home/btth/.pan/messages/cache/20060902215624.GF2570@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@dillo.org.msg": Failed to open file '/home/btth/.pan/messages/cache/20060902215624.GF2570@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.
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.
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@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
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@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.-
participants (7)
-
Beartooth -
Diego Sáenz -
Globe Trotter -
Hans Hohenfeld -
Jan Stary -
Jorge Arellano Cid -
Sam Trenholme