Dear Dillo developers, I have been using Dillo since about 0.2.x, and would like to start this email with "Hail Caesar and everything". Thank you! I am really looking forward to the day I replace Firefox with Dillo completely. These are the reasons I won't do it today: 1. Internally, Dillo uses GTK1, which, internally, uses LATIN1. As I am Czech, the last lines of my install process would be $ make install $ strings src/dillo | grep iso8859 $ sed -e 's/iso8859-1/iso8859-2/g;' < ./src/dillo > ~/bin/dillo which happens to work. I suppose that the transition to FLTK will make me able to vies pages in other charsets too. This problem is adressed in http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n (Are you guys considering any of the patches included in that?) 2. Lack of CSS support. I am aware of http://www.dillo.org/download/dillo-0.8.0-css-3.tar.gz (which, BTW, needs to have a few syntax errors fixed before it compiles, see PS). However, it doesn't do much - looking at http://www.dillo.org won't even let me click on the links. 3. Dillo does not have tabbed browsing. I know it's just a convenience, not really related to fast rendering and stuff, but this convenience is just so ... you know, convenient :-) This is also patched into http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n After these issues are resolved, you have a converted Firefox user (not that I would use anything else but Dillo for e.g. reading documentation). OTOH, don't waste your time on frames and javascript, everybody knows it's evil. Sincerely Jan PS: Compiling http://www.dillo.org/download/dillo-0.8.0-css-3.tar.gz on FreeBSD 6.0-RELEASE-p7 with gcc (GCC) 3.4.4 [FreeBSD] 20050518 stops with the following errors: In file included from doctree.c:40: css.h:267:8: warning: extra tokens at end of #endif directive doctree.c: In function `Doctree_construct': doctree.c:746: error: label at end of compound statement doctree.c: In function `Doctree_draw_text': doctree.c:806: error: label at end of compound statement The src/css.h ends with #endif __CSS_H__ which I just commented properly, and the empty labels case DW_STYLE_DISPLAY_LAST: /* compiler happiness */ } and case DOCTREE_ELEMENT: /* compiler happiness */ } in src/doctree.c can obviously be deleted. Then it compiles smoothly.
One of my wishes would be to have some limit for the cache growing endlessly. I run Dillo on a old Libretto 100CT (166MHz/32MB) and if surfing for long periods (especially when viewing large images) the system goes on knees swapping and eventually Dillo gets killed for hogging all the memory. :S Of course there's generally a lot of work to do on the browser and this feature might require significant changes to the code (?)...
Hi, On Sat, May 27, 2006 at 10:46:56PM +0300, Joonas Saarinen wrote:
One of my wishes would be to have some limit for the cache growing endlessly. I run Dillo on a old Libretto 100CT (166MHz/32MB) and if surfing for long periods (especially when viewing large images) the system goes on knees swapping and eventually Dillo gets killed for hogging all the memory. :S Of course there's generally a lot of work to do on the browser and this feature might require significant changes to the code (?)...
Not that hard! Just look inside cache.c and add a remove function for images when the cache size surpasses a certain threshold. An algorithm/heuristic that pleases a diverse group of users is much more difficult. You have to care about not removing images that are currently being displayed (e.g. when using multiple Dillo windows, or removing an image that's being displayed in a page that loads lots of images). Al this blurb reduces to a ref count. -- Cheers Jorge.-
Hi Jan, On Sat, May 27, 2006 at 05:58:03PM +0200, Jan Stary wrote:
Dear Dillo developers,
I have been using Dillo since about 0.2.x, and would like to start this email with "Hail Caesar and everything". Thank you!
Thanks for the recognition.
I am really looking forward to the day I replace Firefox with Dillo completely. These are the reasons I won't do it today:
1. Internally, Dillo uses GTK1, which, internally, uses LATIN1. As I am Czech, the last lines of my install process would be
$ make install $ strings src/dillo | grep iso8859 $ sed -e 's/iso8859-1/iso8859-2/g;' < ./src/dillo > ~/bin/dillo
which happens to work.
... and also breaks iso8859-1 support.
I suppose that the transition to FLTK will make me able to vies pages in other charsets too.
Yes. This is the main point.
This problem is adressed in http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n (Are you guys considering any of the patches included in that?)
No. I've explained several times that this patches break some internal things in Dillo (as entities, forms, other charsets etc). In the meanwhile I consider this patches a good thing to have in an unofficial branch because the benefits from being able to read your own language sometimes are bigger than broken things with others. The real solution is to have Dillo use utf-8 internally and to convert other encodings to it. This is what we have with dillo FLTK2 (and something that GTK1 doesn't provide. BTW, this is also one of the main reasons for GTK2 existence). Bottom line: we do care about other languages and we're working towards a universal solution for it.
2. Lack of CSS support. I am aware of http://www.dillo.org/download/dillo-0.8.0-css-3.tar.gz (which, BTW, needs to have a few syntax errors fixed before it compiles, see PS). However, it doesn't do much - looking at http://www.dillo.org won't even let me click on the links.
We've done a lot in this respect. All the internal structures for Dw are designed with CSS in mind. The problem is we don't have the funds to have the main developer of Dw working full time on this. --It's frustrating.
3. Dillo does not have tabbed browsing. I know it's just a convenience, not really related to fast rendering and stuff, but this convenience is just so ... you know, convenient :-) This is also patched into http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n
After these issues are resolved, you have a converted Firefox user (not that I would use anything else but Dillo for e.g. reading documentation).
Quite simple to add! I've focused my time on making the FLTK2 prototype work though.
OTOH, don't waste your time on frames and javascript, everybody knows it's evil.
GREAT! I really wish this line of thought was predominant! (although it wouldn't be that hard to implement). -- Cheers Jorge.-
On Sat, May 27, 2006 at 05:58:03PM +0200, Jan Stary wrote:
Dear Dillo developers,
I have been using Dillo since about 0.2.x, and would like to start this email with "Hail Caesar and everything". Thank you!
I am really looking forward to the day I replace Firefox with Dillo completely. These are the reasons I won't do it today:
1. Internally, Dillo uses GTK1, which, internally, uses LATIN1. As I am Czech, the last lines of my install process would be
$ make install $ strings src/dillo | grep iso8859 $ sed -e 's/iso8859-1/iso8859-2/g;' < ./src/dillo > ~/bin/dillo
which happens to work. I suppose that the transition to FLTK will make me able to vies pages in other charsets too.
BTW, please send me some latin2 URLs for development tests. -- Cheers Jorge.-
BTW, please send me some latin2 URLs for development tests.
-- Cheers Jorge.-
Hi Jorge, http://www.root.cz/ http://www.abclinuxu.cz/ http://www.wp.pl/ should be fine. Michal
participants (4)
-
Jan Stary
-
Joonas Saarinen
-
Jorge Arellano Cid
-
newman.x@seznam.cz