Hi there, This question:
What do you think of reviving use of the bug tracker for the various little things that are easy to forget about?
brings about a bigger topic: the future of dillo2. The goals of the project are: 1.- The democratization of internet information access 2.- Personal security and privacy 3.- High software efficiency I believe the key to achieving them are: a.- A larger development team. b.- A user community finding it useful. The vitality and development pace of the project are highly related to a). Point b), has been strong in the past; this is: judging from the received email feedback: http://www.dillo.org/emails.txt and from some surveys like:
On Sat, Aug 25, 2007 at 03:28:55AM +0200, Diego . wrote:
DesktopLinux.com has published the results of its anual (desktop)linux poll The interesting thing is in the 3rd question: Which web browsers do you frequently use on your Linux desktop(s)?
http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=archive&id=0813200
The interesting thing is that a frozen project have enough users to win over 3 fully developed browsers :) (optimistic without cure)
Point a) is key because it directly relates to the pace with which we pursue the moving target of Web browsing. Point b) is very important because if we end up with a browser that only a few people are willing to use, there's no point in it besides personal motivations. So: * Objective 1, is the result of a) and b). * Objective 2, needs the work of a). * Objective 3, is mainly achieved! How do we do it? i. - Increase the development team by adding 6+ new developers. ii.- Getting more involved with other projects. We could: * Attract new developers with a dillo2 release, leveraging the excellent documentation that we have. * Planning for CSS, floating objects and TABS. (this are important features to a nice browsing experience) * Coordinate with FLTK2, DSL (Damn small linux) and other lightweight distros, Debian installer team, MINIX3, etc. I don't want to miss the opportunity to thank the team for the excellent work during these months. Without you dillo2 wouldn't be so close to a release. Now, we need to plan, grow the number of developers, and bring dillo2 closer to its goals. These are just my views on the subject. Please share your thoughts, ideas and plans in this thread, so we can agree on a plan for the future. -- Cheers Jorge.-
I think the very first thing is to update the main dillo.org page so that visitors will know that dillo shows signs of life. (or, wait, second. After all, there are patches that need reviewing :)
On Mon, Apr 21, 2008 at 03:39:50PM +0000, corvid wrote:
I think the very first thing is to update the main dillo.org page so that visitors will know that dillo shows signs of life.
(or, wait, second. After all, there are patches that need reviewing :)
I agree. We should update the front page and make it a bit more optimistic :-). What is still missing for an official release apart from image maps? A problematic thing is that there are no official fltk2 packages for many distributions - or has that changed recently? I think, if we can then manage to get CSS support in, we will get many new users. I personally don't need TABS. Cheers, Johannes
Johannes wrote:
What is still missing for an official release apart from image maps?
For one thing, I think text search needs to work for phrases.
I think, if we can then manage to get CSS support in, we will get many new users. I personally don't need TABS.
Yes, if I look around on the web for discussion about dillo, it's mostly "it's fast, but it's useless because it can't do CSS."
On Mon, Apr 21, 2008 at 06:32:52PM +0000, corvid wrote:
Johannes wrote:
What is still missing for an official release apart from image maps?
For one thing, I think text search needs to work for phrases.
Yes, and <Esc> should consistently close dialogs... But that's just a minor issue.
I think, if we can then manage to get CSS support in, we will get many new users. I personally don't need TABS.
Yes, if I look around on the web for discussion about dillo, it's mostly "it's fast, but it's useless because it can't do CSS."
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Mon, Apr 21, 2008 at 08:40:45PM +0200, Johannes Hofmann wrote:
On Mon, Apr 21, 2008 at 06:32:52PM +0000, corvid wrote:
Johannes wrote:
What is still missing for an official release apart from image maps?
For one thing, I think text search needs to work for phrases.
Yes, and <Esc> should consistently close dialogs... But that's just a minor issue.
With the latest patch in CVS, it seems to do. Please test. The save dialog sometimes refuse to close when the focus is in the text input area and Escape works to restore what was there. I don't know whether this is standard or desired behaviour. I find this dialog bindings strange anyway, as it loses the filename when changing directory. If enough people find it odd, we may try to change it. -- Cheers Jorge.-
On Mon, Apr 21, 2008 at 08:40:45PM +0200, Johannes Hofmann wrote:
On Mon, Apr 21, 2008 at 06:32:52PM +0000, corvid wrote:
Johannes wrote:
What is still missing for an official release apart from image maps?
For one thing, I think text search needs to work for phrases.
Yes, and <Esc> should consistently close dialogs... But that's just a minor issue.
Oh, I forgot to mention that closing dillo's main windows with Escape is disabled to avoid accidentally closing the browser. -- Cheers Jorge.-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote:
On Mon, Apr 21, 2008 at 03:39:50PM +0000, corvid wrote:
I think the very first thing is to update the main dillo.org page so that visitors will know that dillo shows signs of life. I agree. We should update the front page and make it a bit more optimistic :-). +1
What is still missing for an official release apart from image maps? I like the way firefox is getting rid of more and more dialog boxes. Like the "find in page" command. In firefox the user enters the search string into a input field embedded in a bar emerging from the bottom of
A problematic thing is that there are no official fltk2 packages for many distributions - or has that changed recently? Not that I am aware of any (debian has no packages) and since there is no fltk2 release yet I wouldn't get my hopes up...
Also I'd like to see some infrastructure changes like a more advanced bug tracker / modify the existing one (user comments come to mind, and *please* get rid of the background image in the search results). the screen. This has several advantages: * avoid cluttering the desktop (this is even more important if the screen is very small [think mobile phones]) * avoid to cover the search result (this is possible if it isn't possible to scroll the windows content in a way that the search result is visible) * you always know which search box belongs to which browser window since the search bar is a part of that window (this gets even worse with tabs) Somewhat related I would suggest to get rid of the location dialog (ctrl + l). As far as I can see it has offers nothing more than entering the address directly into the url bar, so whats the point? Make ctrl + l a shortcut that moves the cursor to the url bar instead. Flickering... there was a thread about fltk and double buffer something... there is no flickering when scrolling a page on my machine (there are some artifacts in the scrollbar, it looks like it is jumping around a little or changing its size) but if I move the whole window it flickers a lot. And one more obscure bug I just noticed while playing around with the scrollbar: When I switch from one virtual desktop (my window manager is e17) to another with a dillo window on it and try to scroll the page it doesn't work. Most of the time it selects text on the page (it didn't when I recorded the movie, typical...). The problem goes away if I move or resize the window so I would guess that it has something to do with window coordinates / dimensions not being correct. I compiled dillo with fltk2 revision 6101. http://teythoon.cryptobitch.de/stuff/virtual-desktops.ogg For automated regression testing and other cool stuff I'd love to see a feature to render pages directly to an image without opening any windows. That would be totally awesome (hint, hint). thing
I think, if we can then manage to get CSS support in, we will get many new users. I personally don't need TABS. I agree that CSS is more important but it is also much harder. Tabs should be relatively straight forward since there is a tabs widget for fltk2 (judging by playing around with fluid2) and the dillo code is able to create new windows.
I think that creating snapshots is a good idea since it allows users to test dillo and see any improvements. In fact I was thinking about making (daily?) builds of dillo and fltk2 and creating a 0install stream for them. I was trying to build dillo on solaris the other day (as a die hard portability test... It is amazing how hard it is to get anything compile on solaris out of the box... some blame this on linuxisms, but I say this is just solaris being stubborn) but fltk2 spoiled all the fun by being the failing component. I filed a bug report but since then (that was like 8 weeks ago) there is no reaction :( Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE/QNoPmwNWhsaZYRAiV4AKCEWdN3FV1uClZJcUF5pWYB7cCLnwCeK43S dcA6i4YiWOub7E7W1iGgpdA= =S+kv -----END PGP SIGNATURE-----
On Sun, Apr 27, 2008 at 05:33:33AM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johannes Hofmann wrote:
On Mon, Apr 21, 2008 at 03:39:50PM +0000, corvid wrote:
I think the very first thing is to update the main dillo.org page so that visitors will know that dillo shows signs of life. I agree. We should update the front page and make it a bit more optimistic :-). +1
Also I'd like to see some infrastructure changes like a more advanced bug tracker / modify the existing one (user comments come to mind, and *please* get rid of the background image in the search results).
What is still missing for an official release apart from image maps? I like the way firefox is getting rid of more and more dialog boxes. Like the "find in page" command. In firefox the user enters the search string into a input field embedded in a bar emerging from the bottom of the screen.
This has several advantages: * avoid cluttering the desktop (this is even more important if the screen is very small [think mobile phones]) * avoid to cover the search result (this is possible if it isn't possible to scroll the windows content in a way that the search result is visible) * you always know which search box belongs to which browser window since the search bar is a part of that window (this gets even worse with tabs)
Somewhat related I would suggest to get rid of the location dialog (ctrl + l). As far as I can see it has offers nothing more than entering the address directly into the url bar, so whats the point? Make ctrl + l a shortcut that moves the cursor to the url bar instead.
On the other hand the dialogs allow to use dillo without panel (Ctrl-Space).
Flickering... there was a thread about fltk and double buffer something... there is no flickering when scrolling a page on my machine (there are some artifacts in the scrollbar, it looks like it is jumping around a little or changing its size) but if I move the whole window it flickers a lot.
Both are fltk bugs I think. I also see this with fltk test applications if I add clear_double_buffer(). We should submit bug reports for that.
And one more obscure bug I just noticed while playing around with the scrollbar: When I switch from one virtual desktop (my window manager is e17) to another with a dillo window on it and try to scroll the page it doesn't work. Most of the time it selects text on the page (it didn't when I recorded the movie, typical...). The problem goes away if I move or resize the window so I would guess that it has something to do with window coordinates / dimensions not being correct. I compiled dillo with fltk2 revision 6101.
I don't see this with dwm. Can you try whether fltk test applications show this behaviour too? Cheers, Johannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote:
On Sun, Apr 27, 2008 at 05:33:33AM +0200, Justus Winter wrote:
Somewhat related I would suggest to get rid of the location dialog (ctrl + l). As far as I can see it has offers nothing more than entering the address directly into the url bar, so whats the point? Make ctrl + l a shortcut that moves the cursor to the url bar instead.
On the other hand the dialogs allow to use dillo without panel (Ctrl-Space).
That's a nice feature, indeed. What about getting rid of the dialog box and just showing the panel on demand in "without panel" mode?
Flickering... there was a thread about fltk and double buffer something... there is no flickering when scrolling a page on my machine (there are some artifacts in the scrollbar, it looks like it is jumping around a little or changing its size) but if I move the whole window it flickers a lot.
Both are fltk bugs I think. I also see this with fltk test applications if I add clear_double_buffer(). We should submit bug reports for that.
If you have a small patch ready that introduces this behavior into one of their test programs I nominate you for this task :)
And one more obscure bug I just noticed while playing around with the scrollbar: When I switch from one virtual desktop (my window manager is e17) to another with a dillo window on it and try to scroll the page it doesn't work. Most of the time it selects text on the page (it didn't when I recorded the movie, typical...). The problem goes away if I move or resize the window so I would guess that it has something to do with window coordinates / dimensions not being correct. I compiled dillo with fltk2 revision 6101.
I don't see this with dwm. Can you try whether fltk test applications show this behaviour too?
http://teythoon.cryptobitch.de/stuff/virtual-desktops-fltk2-problem.ogg You are right, this seems to be a fltk2 bug. I will file a bug report for this problem. Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFyr6oPmwNWhsaZYRArM/AJ44W5nWh1xekGLtM1RrfmC9ujW3eACfTVbx OlU9NERtkjeQqraFwc96M2c= =pMct -----END PGP SIGNATURE-----
Hi, just if you were courious: I'm still living and will continue working on dillo. On Sun, Apr 20, Jorge Arellano Cid wrote:
[...] We could:
* Attract new developers with a dillo2 release, leveraging the excellent documentation that we have.
We have: - extensive documentations on the critical parts of dillo, expecially on Dw, - a prototype for CSS, and - some more documents and prototypes on future ideas, including scripting and graphical plugins. These should be copied on the web sever, and there should be a prominent note on the web site linking to a new delevolers' section. (Since attracting developers has high priority, this is what a visitor should notice first.) For those not listening to dillo-dev, it is important to know that dillo is still an active project.
* Planning for CSS, floating objects and TABS. (this are important features to a nice browsing experience)
Just FYI: I've started a bit on floats. Jorge, I once told you that it would take a week; actually it is a bit more complicated, nevertheless it is not a big job like CSS.
* Coordinate with FLTK2, DSL (Damn small linux) and other lightweight distros, Debian installer team, MINIX3, etc.
Perhaps we can find there other "lightweight zealots". :-) Sebastian P.S. I'll soon review the changes regarding redrawing and related. When working on floats, I noticed that the redraw optimization after resizes does not work fully correctly, there are situations where only a explicit redraw (e.g. hide and show window) makes size changes visible. P.P.S. In the doxygen documentation, there are two lists, html/bug.html and html/todo.html (generated from the \bug and \todo tags), with open issues. Furthermore, some problems are described in html/fltk-problems.html.
Hi Sebastian, On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote:
Hi,
just if you were courious: I'm still living and will continue working on dillo.
That's fantastic!
On Sun, Apr 20, Jorge Arellano Cid wrote:
[...] We could:
* Attract new developers with a dillo2 release, leveraging the excellent documentation that we have.
We have:
- extensive documentations on the critical parts of dillo, expecially on Dw, - a prototype for CSS, and - some more documents and prototypes on future ideas, including scripting and graphical plugins.
These should be copied on the web sever, and there should be a prominent note on the web site linking to a new delevolers' section. (Since attracting developers has high priority, this is what a visitor should notice first.)
For those not listening to dillo-dev, it is important to know that dillo is still an active project.
* Planning for CSS, floating objects and TABS. (this are important features to a nice browsing experience)
Just FYI: I've started a bit on floats. Jorge, I once told you that it would take a week; actually it is a bit more complicated, nevertheless it is not a big job like CSS.
* Coordinate with FLTK2, DSL (Damn small linux) and other lightweight distros, Debian installer team, MINIX3, etc.
Perhaps we can find there other "lightweight zealots". :-)
Sebastian
P.S. I'll soon review the changes regarding redrawing and related. When working on floats, I noticed that the redraw optimization after resizes does not work fully correctly, there are situations where only a explicit redraw (e.g. hide and show window) makes size changes visible.
I've seen this too but can't reproduce it consistently. Cheers, Johannes
P.P.S. In the doxygen documentation, there are two lists, html/bug.html and html/todo.html (generated from the \bug and \todo tags), with open issues. Furthermore, some problems are described in html/fltk-problems.html.
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote:
Hi,
Hi Sebastian!
just if you were courious: I'm still living and will continue working on dillo.
That's very good news. New developers are helping to push the project forward, and your presence is a very important asset for the team.
On Sun, Apr 20, Jorge Arellano Cid wrote:
[...] We could:
* Attract new developers with a dillo2 release, leveraging the excellent documentation that we have.
We have:
- extensive documentations on the critical parts of dillo, expecially on Dw, - a prototype for CSS, and - some more documents and prototypes on future ideas, including scripting and graphical plugins.
These should be copied on the web sever, and there should be a prominent note on the web site linking to a new delevolers' section. (Since attracting developers has high priority, this is what a visitor should notice first.)
Yes, I was planning on stating the quest for more developers in the splash page of the next release. BTW, it'd be great to also convert dillo2's plain text docs to doxygen format someday.
For those not listening to dillo-dev, it is important to know that dillo is still an active project.
I think we can sort the house and then make a release so the world knows. That's why having TABS and at least a CSS prototype matters. I don't want reviews to end with the typical line: "but no TABS and no CSS". ;-) If we have TABS (a thing I can spare some time to implement) and a CSS protoype published somewhere, the message will be more like: "it comes with: ..., antialiased fonsts, low-dependencies, UTF-8, TABS, and they already started with CSS." That sounds much better!
* Planning for CSS, floating objects and TABS. (this are important features to a nice browsing experience)
Just FYI: I've started a bit on floats. Jorge, I once told you that it would take a week; actually it is a bit more complicated, nevertheless it is not a big job like CSS.
Speaking about floats, I was trying to make NBSP (non breaking spaces) work for pages like: http://fltk.org/newsgroups.php?gfltk.development+T (with a narrow window, the parenthesis are spared). but found that NBSP-handling wasn't coded in textblock yet: /* NOTE: Most code relies on that all values of nowrap are * equal for all words within one line. */ I planned to give it a try, but didn't know what was the model for handling it (a flag in the previous word, a flag in the previous and next word, an empty word, etc). Now that you're working in the textblock, can you give it a review? The attached patch is what the parser (html.cc) could look like to handle this. It uses WHITE_SPACE_NOWRAP in style, but I didn't know whether to use: addText(strdup(""), S_TOP(html)->style); or DW2TB(html->dw)->addSpace(S_TOP(html)->style); for NBSP whitespace. It should be simple to test with it.
* Coordinate with FLTK2, DSL (Damn small linux) and other lightweight distros, Debian installer team, MINIX3, etc.
Perhaps we can find there other "lightweight zealots". :-)
Yes, and maybe someday people will start liking/using this lightweight browser. AMEN -- Cheers Jorge.-
The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 (dillo+blfs mentioned previously by Jeremy in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/004009.html)
On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote:
The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2
Quite funny! :-) Got to have courage to write such nonsense! Please feel free to write them to get that page back on track before somebody believes what was written. ;) More seriously, I'll update the CVS page with all the necessary intructions to build dillo2. Beware that dillo2 is aimed towards developers, not users, until its first release. That's the message we need to pass across. (I made the mistake with dillo1 and ended up with a perception even more strange than the page you cite). BTW, if you want to update the website, please do. Just let me write the 6 years page (after a frozen year, the project restarted at year 8). You can start before I write that page. -- Cheers Jorge.-
Jorge wrote:
On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote:
The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2
Quite funny! :-)
Got to have courage to write such nonsense!
It just shows what impression dillo gives a person who is focused on other things and giving the README a skim.
Please feel free to write them to get that page back on track before somebody believes what was written. ;)
I will.
BTW, if you want to update the website, please do.
I don't have access yet.
On Mon, May 12, 2008 at 12:20:45PM -0400, Jorge Arellano Cid wrote:
On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote:
The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2
Please feel free to write them to get that page back on track before somebody believes what was written. ;)
I have a BLFS Trac account so I can probably do it myself. But what should I change? At a glance: * We *do* support FTP and HTTPS. * Change "can support cookies" to "supports cookies". * "Dillo always interprets web pages as if they had the ISO-8859-1 encoding." True? * "useless for reading non-English web pages" Surely not true, though maybe "useless for reading multibyte-encoded pages" is true. Anything else? Regards, Jeremy Henty
Hi, On Mon, 12 May 2008 18:24:30 +0100 Jeremy Henty <onepoint@starurchin.org> wrote:
On Mon, May 12, 2008 at 12:20:45PM -0400, Jorge Arellano Cid wrote:
On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote:
The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2
Please feel free to write them to get that page back on track before somebody believes what was written. ;)
I have a BLFS Trac account so I can probably do it myself. But what should I change? At a glance:
* We *do* support FTP and HTTPS. * Change "can support cookies" to "supports cookies".
* "Dillo always interprets web pages as if they had the ISO-8859-1 encoding." True?
* "useless for reading non-English web pages" Surely not true, though maybe "useless for reading multibyte-encoded pages" is true.
Anything else?
Hmm, can you really fully test dillo in its build directory? You won't have the dpi stuff and loose functionality. Perhaps that should be noted too. Greetings Andreas Kemnade
On Mon, May 12, 2008 at 08:08:38PM +0200, Andreas Kemnade wrote:
Hmm, can you really fully test dillo in its build directory? You won't have the dpi stuff and loose functionality. Perhaps that should be noted too.
Good catch! We don't want BLFS telling users to run Dillo in ways we don't support. Personally I don't understand the author's fear of installing alpha software. Does Dillo's "make install" do anything other than install a few executables and config files? If not then what's the problem with installing it? Also, the instructions should specify " ./configure --prefix=/usr " as the BLFS convention is to install everything in /usr rather than /usr/local . Jeremy Henty
Hmm, can you really fully test dillo in its build directory? You won't have the dpi stuff and loose functionality. Perhaps that should be noted too. With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the attached script to run dillo in-tree which is nice if you just want to
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Kemnade wrote: try it out but should also be useful for development purposes (easily manage different branches without the need to install them somewhere). One catch is the way dillo expects the dpis to be in their own directory the script solves that by creating a temporary directory, but this seems like a bad hack. What is the big idea behind this anyway? * dpis cant usually write to "their" own directory anyway * afaik this isn't a namespace thing either (since the directory is named like the executable without the .dpi extension) So unless there's a reason that I cannot see I would suggest to get rid of the X/X.dpi thing all together and stuff them all into one directory. Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKdUToPmwNWhsaZYRAqtyAJwNUOKoOPhKxJGAKKRBl68kIQ5PCQCgpV3D VFbjZobjZbmkSbEFa8lyNAY= =ro4T -----END PGP SIGNATURE-----
On Mon, May 12, 2008 at 06:24:30PM +0100, Jeremy Henty wrote:
On Mon, May 12, 2008 at 12:20:45PM -0400, Jorge Arellano Cid wrote:
On Mon, May 12, 2008 at 03:52:59PM +0000, corvid wrote:
The consequences of not informing the outside world about the progress of dillo in any detail: http://wiki.linuxfromscratch.org/blfs/wiki/dillo2
Please feel free to write them to get that page back on track before somebody believes what was written. ;)
I have a BLFS Trac account so I can probably do it myself. But what should I change? At a glance:
* We *do* support FTP and HTTPS. * Change "can support cookies" to "supports cookies".
Yes, but https is basic. If a page has multiple images, the dialog window may spam the user once per image. That's why https went disabled for normal users, and experienced guys/devs were left the chance to enable it.
* "Dillo always interprets web pages as if they had the ISO-8859-1 encoding." True?
It depends on what dillo they talk about. It looks like a dillo2 page, and in that case, it's FLTK2-based, it has nothing to do with GTK1, glib nor GTK2, just FLTK2. The code is now a mixture of C/C++ instead of pure C, etc... It's important to make a difference between dillo1 (C lang, GTK1/glib, __unmantained__, and dillo2 (active branch). If we talk about dillo2 then the statement: "Dillo always interprets web pages as if they had the ISO-8859-1 encoding." is absolutely false.
* "useless for reading non-English web pages" Surely not true, though maybe "useless for reading multibyte-encoded pages" is true.
If we talk about dillo2, false again. Dillo2 uses utf-8 by default, and utf-8 is multibyte-encoded. On top of that we have all the work corvid put in the character decoding, so now dillo2 can decode a boat load of charsets into utf-8 using iconv. Non english pages render quite well provided you have the necessary fonts installed. There're a few exceptions as with those that render backwards or have collapsing glyphs. For instance, set: vw_fontname="DejaVu Sans" in ~/.dillo/dillorc2 and go to: http://www.gnu.org/home.fa.html Worth a thounsand words! then go to: http://www.gnu.org/ scroll to the bottom and you'll see plenty of non-english pages, that you can click into. If you go to: http://www.bds-bg.org/ you'll see windows-1251 charset handled properly by dillo. etc.
Anything else?
Yes, we should compile and provide this information from our web site. Otherwise it will be extremely hard for a non-developer to get right. A good diff document may be got from reviewing the Changelog alone. Here we have the record of all the work we've put in dillo2; from time to time I find there things forgotten long ago! I'll try to update some pages in the site as soon as I find some time. That's the point: lack of time/manpower. All the help is appreciated. Another very important point to be stated is that the plugins and the dpi daemon need to be installed for most things to work. After the build this is done with: make install-strip. Bottom line: current dillo2 is for developers. After we make a release it will be user ready. HTH. -- Cheers Jorge.-
On Mon, May 12, 2008 at 03:51:42PM -0400, Jorge Arellano Cid wrote:
[...] I'll try to update some pages in the site as soon as I find some time.
Just updated: http://www.dillo.org/cvs.html with directions on how to get dillo running. Developers, packagers, and experienced user should be pointed here. Somebody please check the directions work. :-P and: http://www.dillo.org/Plans.html with what's already done. Note that we have more features than what this page states. Some new features as: * multiple character sets (in both HTTP and META). * HTTP-1.1's chunked transfer support. * optional image loading. * experimental gzip decoder. * Implemented the file input control for forms. * Optimized scrolling. * 64-bit ready out of the box. should be added here. -- Cheers Jorge.-
* Jorge Arellano Cid <jcid@dillo.org> schrieb: Hi,
i. - Increase the development team by adding 6+ new developers. ii.- Getting more involved with other projects.
you can add me, as long as no C++ stuff is involved. (don't like it's overhead). I'm already working on German translation.
* Planning for CSS, floating objects and TABS. (this are important features to a nice browsing experience)
Missing CSS is really bad. I'm planning to write an universal but small CSS parser (as an separate library). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
participants (8)
-
4winter＠informatik.uni-hamburg.de -
akemnade＠informatik.uni-bremen.de -
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org -
sgeerken＠dillo.org -
weigelt＠metux.de