- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Thanks

by Maurice McCarthy

The invitation is nice but I don't think I have the skill. Where I work if something is not functioning then you a) hit it with a scaffold pole b) if its too small, hit it with a shifter (adjustable spanner) c) take it apart and clean it d) if its electrical push every button in sight e) when you know you've really broken it then f) call the maintenance dept. Maurice On Sat, Oct 25, 2003 at 12:05:36AM +0200 or thereabouts, Diego S?enz wrote: > El Fri, 24 Oct 2003 20:31:46 +0100 > Maurice McCarthy <maurice.mccarthy(a)ntlworld.com> escribio: > > > Hi folks > > > > Just to say thanks one last time. I'm going to leave you all in peace to > > get on with your projects. > This can be your proyect too and you do not need to make a war for it ;) > > Diego. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 25, 2003

/. html fix

by johannes leimbach

Hi! As dillo can't show /. properly (messed up html code), someone made up a modified html.c, which can render broken html. This patch was mentioned in this mailing list some time ago (i think it was even me who asked). Ehem, anyway, I've lost the link to it, and -call me stupid- I can't find it anymore using google or the mailing list search :/ Sorry.. So can please someone give me the link for the html.c fix again? Thanks, johannes :)

Oct. 25, 2003

Re: [Dillo-dev] Thanks

by Diego Sáenz

El Fri, 24 Oct 2003 20:31:46 +0100 Maurice McCarthy <maurice.mccarthy(a)ntlworld.com> escribio: > Hi folks > > Just to say thanks one last time. I'm going to leave you all in peace to > get on with your projects. This can be your proyect too and you do not need to make a war for it ;) Diego.

Oct. 24, 2003

Thanks

by Maurice McCarthy

Hi folks Just to say thanks one last time. I'm going to leave you all in peace to get on with your projects. Thinks I sussed cvs OK but I've not managed to install Frank's patch yet - not even 20030926. But none of that is your problem. It's not whether you win or lose, It's how you place the blame! (Snoopy) Great Work Thaks Again Maurice

Oct. 24, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Paul Pelzl

On Fri, Oct 24, 2003 at 05:21:07PM +0200, Frank de Lange wrote: > Melvin Hadasht wrote: > > >>>e.g. Alt-Tab is used by many window managers, and generally, I expect > >>>key combinations with the Alt modifier more at the level of > >>>windows. (IMO, no modifiers should be used for link navigation, > >>>conflicts with other functions have to be resolved somehow.) > >>> > >>> > >>Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that > >>combination is not used by any of the window managers I use/have used. > >> > >> > > > >Just wanted to say that WindowMaker uses MOD1 (alt) Up/Down to raise/lower > >the window It also use CTRL-MOD1 Left/Rigth to switch to next/previous > >workspace > >MOD1-Tab is used to switch windows. But as long as the keys are > >configurable, > >I don't see this as a problem. I think WindowMaker is one of the most > >spread > >window manager among users that do not use Gnome or KDE. > > > >I'd suggest Ctrl-Arrows. Ctrl-Arrows are used in text editor to jump to > >next > >words, so users will mostly try Ctrl-Arrow instead of Alt-Arrow > > > > > > > Ah, WindowMaker... used it around 1996, did not remember that binding... > > Anyway, Ctrl-<cursor_keys> is used (by me at least) for workspace (or > 'virtual desktop') switching, ALT-CTRL-<cursor_keys> for window movement > between workspaces, etc. > > So... more opinions? The default setup of the Ion window manager uses only Mod1-* bindings, but requires rather a lot of them. I am using Ctrl-arrows for that reason. Also I agree with Melvin that this choice is intuitive because Ctrl-arrows jumps across words in many word processors. Of course, you won't find me complaining as long as the gtkrc magic is available... Paul

Oct. 24, 2003

Re: [Dillo-dev] Bug #502 solved

by Jorge Arellano Cid

On Fri, 24 Oct 2003, Frédéric Bothamy wrote: > Hello, > > I submitted the bug #502 a while ago about some PNG images not displayed > correctly. And today someone finally gave the explanation: the Debian > web server sends GIFs images with image/png content type (and png > extension) (for more details, see > http://lists.debian.org/debian-www/2003/debian-www-200310/msg00133.html) > > Could someone, please, close this (non-)bug? Deleted! BTW, this is one of the wonderful effects to adhering to standards and not to try to silently "correct" what is wrong. Many webmasters provide broken HTML because the tools they use to test it don't tell them there're bugs in the first place. Appart from what Ralph brilliantly exposes in "The decommoditization of protocols" (http://www.levien.com/free/decommoditizing.html) when standards are met, development of new tools to work with compliant objects gets much easier. I should really write a bit about the link between adhering to standards and its impact in the democratization of internet information access... > Sorry for not testing this issue enough and thanks for this wonderful, > lightweight browser. You're welcome. Cheers Jorge.-

Oct. 24, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Melvin Hadasht wrote: >>>e.g. Alt-Tab is used by many window managers, and generally, I expect >>>key combinations with the Alt modifier more at the level of >>>windows. (IMO, no modifiers should be used for link navigation, >>>conflicts with other functions have to be resolved somehow.) >>> >>> >>Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that >>combination is not used by any of the window managers I use/have used. >> >> > >Just wanted to say that WindowMaker uses MOD1 (alt) Up/Down to raise/lower >the window It also use CTRL-MOD1 Left/Rigth to switch to next/previous workspace >MOD1-Tab is used to switch windows. But as long as the keys are configurable, >I don't see this as a problem. I think WindowMaker is one of the most spread >window manager among users that do not use Gnome or KDE. > >I'd suggest Ctrl-Arrows. Ctrl-Arrows are used in text editor to jump to next >words, so users will mostly try Ctrl-Arrow instead of Alt-Arrow > > > Ah, WindowMaker... used it around 1996, did not remember that binding... Anyway, Ctrl-<cursor_keys> is used (by me at least) for workspace (or 'virtual desktop') switching, ALT-CTRL-<cursor_keys> for window movement between workspaces, etc. So... more opinions? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 24, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Jorge Arellano Cid

On Fri, 24 Oct 2003, Melvin Hadasht wrote: > > >e.g. Alt-Tab is used by many window managers, and generally, I expect > > >key combinations with the Alt modifier more at the level of > > >windows. (IMO, no modifiers should be used for link navigation, > > >conflicts with other functions have to be resolved somehow.) > > > > Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that > > combination is not used by any of the window managers I use/have used. > > Just wanted to say that WindowMaker uses MOD1 (alt) Up/Down to raise/lower > the window It also use CTRL-MOD1 Left/Rigth to switch to next/previous workspace > MOD1-Tab is used to switch windows. But as long as the keys are configurable, > I don't see this as a problem. I think WindowMaker is one of the most spread > window manager among users that do not use Gnome or KDE. > > I'd suggest Ctrl-Arrows. Ctrl-Arrows are used in text editor to jump to next > words, so users will mostly try Ctrl-Arrow instead of Alt-Arrow > > > user experimentation and feedback > > could be used to find the most acceptable combination. This can then be > > set as default, while those who do not like it for whatever reason are > > free to change it. > > Definitly! > > -- > Melvin Hadasht Ditto! Cheers Jorge.-

Oct. 24, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Jorge Arellano Cid

Hi, Here go my comments on the keyboard navigation patches. I like them, and would like to commit it probably in the next version (kbd3). Note: we use to work heavily on patches and commit only after they're stable or polished. All this with a view to keep a relatively stable CVS source tree to work with. This is different to the usual model, but it has its rewards. With regard to the keyboard navigation patch, it probably can be polished better when on CVS, so here my remarks to make the next version into the sources. On Fri, 24 Oct 2003, Frank de Lange wrote: > Sebastian Geerken wrote: > > >I would at least leave the traditional line, for reasons of > >consistence. Perhaps the link may be also highlighted, in a lighter > >color than the background color (and lightgray for white etc., look at > >Dw_style_color_create, which is used for shaded colors for borders)? > >This would make it unconfusable with text selections. > > I have tried using tile and stipple fill patterns for focus highlight, > this did not give useable results. Next on the line is color, with a > (stippled/dashed) frame around the link. This is a good idea. Having the spaces inside links highlighted and the whole kbd. nav. current link in a distinctive pattern or color. One thing I noticed between kbd1 and kbd2 is that sometimes the latter makes odd jumps when using UP and DOWN keys. For instance with "gtk-types.html" page from GTK+'s manual. The "directional" navigation of links feels very handy and intuitive. One thing that can be improved is when the current link is outside the screen not to jump to it upon a key press but to find the most appropriate one within the displayed area. This would allow for a smooth keyboard navigation by integrating with the scrolling keys. Sincerely Jorge.-

Oct. 24, 2003

Bug #502 solved

by Frédéric Bothamy

Hello, I submitted the bug #502 a while ago about some PNG images not displayed correctly. And today someone finally gave the explanation: the Debian web server sends GIFs images with image/png content type (and png extension) (for more details, see http://lists.debian.org/debian-www/2003/debian-www-200310/msg00133.html) Could someone, please, close this (non-)bug? Sorry for not testing this issue enough and thanks for this wonderful, lightweight browser. Fred PS: for anyone interested in using Dillo 0.7.3 with tab+frame patch (v10) under Debian woody (i386 only), I have an unofficial package available at http://olympie.dyndns.org/debian/debs/dillo_0.7.3-1.3_i386.deb.

Oct. 24, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Melvin Hadasht

> >e.g. Alt-Tab is used by many window managers, and generally, I expect > >key combinations with the Alt modifier more at the level of > >windows. (IMO, no modifiers should be used for link navigation, > >conflicts with other functions have to be resolved somehow.) > > Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that > combination is not used by any of the window managers I use/have used. Just wanted to say that WindowMaker uses MOD1 (alt) Up/Down to raise/lower the window It also use CTRL-MOD1 Left/Rigth to switch to next/previous workspace MOD1-Tab is used to switch windows. But as long as the keys are configurable, I don't see this as a problem. I think WindowMaker is one of the most spread window manager among users that do not use Gnome or KDE. I'd suggest Ctrl-Arrows. Ctrl-Arrows are used in text editor to jump to next words, so users will mostly try Ctrl-Arrow instead of Alt-Arrow > user experimentation and feedback > could be used to find the most acceptable combination. This can then be > set as default, while those who do not like it for whatever reason are > free to change it. Definitly! -- Melvin Hadasht

Oct. 24, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >I would at least leave the traditional line, for reasons of >consistence. Perhaps the link may be also highlighted, in a lighter >color than the background color (and lightgray for white etc., look at >Dw_style_color_create, which is used for shaded colors for borders)? >This would make it unconfusable with text selections. I have tried using tile and stipple fill patterns for focus highlight, this did not give useable results. Next on the line is color, with a (stippled/dashed) frame around the link. >e.g. Alt-Tab is used by many window managers, and generally, I expect >key combinations with the Alt modifier more at the level of >windows. (IMO, no modifiers should be used for link navigation, >conflicts with other functions have to be resolved somehow.) Hm, Alt-Tab is not bound by default... Alt-(cursor_key) is, but that combination is not used by any of the window managers I use/have used. currently the bindings for Tab and Shift-Tab are the same as they are in CVS Dillo: they focus the next GTK+ widget in the page (in emulation of gtk_container_focus()). The modifier-less 'hjkl' key pattern is probably a good choice for those who are used to vi (and friends). Together with 'b' and space for scrolling, comma and period for history navigation and 'enter' for link activation it is possible to move anywhere you want using only one hand. Since the current version of the patch allows anyone to change keyboard bindings, user experimentation and feedback could be used to find the most acceptable combination. This can then be set as default, while those who do not like it for whatever reason are free to change it. [LIST]: given the slow uptake of the patches I might follow Sylpheed-claws' model of releasing an extended version in addition to just releasing patches. This should give the patches more exposure (they are now only known to those reading the list/archives), and should lead to a better quality - eventually. Any input on this? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 24, 2003

frames, tabs patch

by Jens Arm

Hi When will the frames- and tabs-patch integrated into CVS ? Jens

Oct. 24, 2003

Re: [Dillo-dev] Compatibility Patch

by Andreas Schweitzer

Hi, > This time i have a little patch for urls with white spaces, it > converts them to correct characters (%20), it works well, just > download the nav.diff.gz from my site and copy it to dillo/src > directory: I would say we should appreciate the effort, but this issue came up before - long time ago, so you can't know about it. But read, e.g. these threads : http://sourceforge.net/mailarchive/message.php?msg_id=1148257 http://sourceforge.net/mailarchive/message.php?msg_id=1167938 However, I would like to raise an issue here : I agree to stick to correct HTML. But isn't it worth only if the offending webmaster notices that his page is broken, instead of the surfer noticing it ? Or - actually, the user may not even know, why exactly the link is not working. I agree, that there are more important things to do than making nice looking popus that say "Dear user, the web page you are visiting is broken because of ..." so that the user can complain to the webmaster. But for the long run this could be considered. And only as long as dillo can easily detect errors, of course. In this case, would it make sense to adjust the Browser ID to include a messgage along the lines of : "Webmaster, you have a malformed URL in a page of yours." ? Just some thoughts, which probably won't make it before dillo is much more mature. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Oct. 24, 2003

Compatibility Patch

by Carlos Daniel Ruvalcaba Valenzuela

Hi everyone. This time i have a little patch for urls with white spaces, it converts them to correct characters (%20), it works well, just download the nav.diff.gz from my site and copy it to dillo/src directory: $ gunzip nav.diff.gz $ patch nav.c nav.diff Answare yes to the question that patchs mades to you. My Web: http://earth.prohosting.com/wbuffer Cheers Carlos Daniel Ruvalcaba

Oct. 24, 2003

Re: [Dillo-dev] FLTK

by Jorge Arellano Cid

Hi there! Just to add more information about FLTK: http://mail.gnu.org/archive/html/texmacs-dev/2003-02/msg00073.html Very informative. Cheers Jorge.-

Oct. 23, 2003

Re: [Dillo-dev] Can't find dpidrc

by Nigel Wilkinson

Thanks everyone Nigel

Oct. 23, 2003

Re: [Dillo-dev] FLTK

by Jorge Arellano Cid

Hi there! After the previous answers from Michael Sweet (forwarded to this list), Sebastian rose a key question: > GtkLayout is mainly there to overcome the limited size of X > windows. When I started to develop Dw, I first tried to get a similar > result by writing anything myself, but finally gave it up. Look at the > Gtk+ documentation, GtkLayout does some weird things which may not be > possible with FLTK. Once again, here're the answers. Cheers Jorge.- PS note: Fl_Help_View is a widget for basic HTML rendering. ---------- Forwarded message ---------- Date: Wed, 22 Oct 2003 16:03:52 -0400 From: Michael Sweet <mike(a)easysw.com> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: FLTK and Dillo Jorge Arellano Cid wrote: > ... > One interesting concern raised by Sebastian is about a way to > overcome the limited-window-size problem of X windows (GTK+ uses > GtkLayout to overcome it). I know FLTK runs on WIN32 so it should > have no problems with large windows, but I couldn't find any > formal doc stating it. This is an issue for us because of large > scrolled html pages (or should I say books?). Are you referring to the 16-bit coordinate issues? If so, those are also present on WIN32... FLTK 1.1.x uses 16-bit integers for coordinates, so to support views larger than 16-bits you'll need to do a little work yourself. For example, Fl_Help_View offsets the X,Y values by the current scroll position and does gross clipping of blocks to support really long HTML files. FLTK 2.x uses 32-bit integers for coordinates and doesn't have this limitation. It will also be providing device classes to support X11, PostScript, PDF, etc. rendering in a device- independent way. >>> 2.- Unicode, UTF-8. >>> This was the main reason for considering GTK2. Is FLTK ready >>> to render Unicode characters? >> >>The patched version is, and FLTK 2.0 will fully embrace UTF-8. > > > Do you mean current FLTK 2.0 CVS does not have the patch yet? AFAIK, 2.0 doesn't have it yet. Bill Spitzak is probably a better person to talk to on that issue, as I've been sticking to maintaining 1.1.x (lack of time on my part - too many other projects! :) > If so, can it be patched or should we use 1.1.4 + utf-8 patch? > > In other words, which version should we start testing with? > What's your advice to structure it (i.e on which widgets should > we base HTML rendering)? Use 1.1.4 + UTF-8 patch; 2.0 is still in a state of flux, and until we have the new device classes in place there may still be some API changes. If you write to 1.1.x now, the 1.x compatibility headers in 2.0 should be enough to support your apps with either release. You'll probably want to subclass Fl_Group and use the existing Fl_Scrollbar classes to provide your scrollbars. The Fl_Help_View widget might serve as a guide for your porting effort, as it supports a limited subset of HTML and does all of the scrolling, linking, etc. stuff. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com

Oct. 23, 2003

CSS

by Sebastian Geerken

Hi! At <http://www.dillo.org/CSS.html>, you'll find an updated version of a document I posted quite a while ago. What this text describes, is partly implemented (mainly to test the critical aspects of the design), I may soon make a tarball public, after some cleanups. The further development is unclear, since some parts have been rewritten, incremental development is difficult, and several general tests are necessary (performance, functionality etc). Sebastian

Oct. 23, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Sebastian Geerken

On Mon, Oct 20, Frank de Lange wrote: > Sebastian Geerken wrote: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > > words of a multi-word link. Somewhere, it is documented, that you > > have to highlight up to strlen(word->content.data.text) + 1, to > > highlight also the space. > > > > > Hmmm... that was intentional, so that focused links could be recognized > more easily... You should have commented in the code :-) > Same for the next one by the way. Anyway, it would be > even better if the focus could be drawn in another pattern or color, so > that it is visible even when overlayed with a selection or found highlight. [other posting] > {Have you thought about | Is there} a way to highlight text using a > pattern (like the 'gray-out' highlight for images)? I have explicitly > not used a line-stile highlight for keyboard focus, because this makes > it often hard to see where focus is. Links are sometimes small, no more > than a '*' or a subscripted number. A line-style highlight is hard to > see in those cases... I do agree that it is necessary to use a different > highlight style for focus, search and selection, but the traditional > focus highlight ((dotted/dashed) line around word) is not very useful in > many cases. This goes even more for people with bad eyesight. I would at least leave the traditional line, for reasons of consistence. Perhaps the link may be also highlighted, in a lighter color than the background color (and lightgray for white etc., look at Dw_style_color_create, which is used for shaded colors for borders)? This would make it unconfusable with text selections. [first posting] > Btw, apart from looking only fleetingly at it, did you try keyboard > navigation? If so, any remarks about the functionality itself? I like it, it's, aside from some glitches, quite what I meant with "geometrical navigation". The standard keys are worth to discuss, e.g. Alt-Tab is used by many window managers, and generally, I expect key combinations with the Alt modifier more at the level of windows. (IMO, no modifiers should be used for link navigation, conflicts with other functions have to be resolved somehow.) Sebastian

Oct. 23, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Jorge Arellano Cid

On Mon, 20 Oct 2003, Frank de Lange wrote: > Sebastian Geerken wrote: > > >Hi, > > > >I've only taken a glance at it, but made two changes to Frank's > >work. The patch is attached, and is to be applied after Frank's patch: > >The changes: > > > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > > words of a multi-word link. Somewhere, it is documented, that you > > have to highlight up to strlen(word->content.data.text) + 1, to > > highlight also the space. > > > > > Hmmm... that was intentional, so that focused links could be recognized > more easily... Same for the next one by the way. Anyway, it would be > even better if the focus could be drawn in another pattern or color, so > that it is visible even when overlayed with a selection or found highlight. > > Btw, apart from looking only fleetingly at it, did you try keyboard > navigation? If so, any remarks about the functionality itself? > > Cheers//Frank Use of innuendo or sarcasm will not help to get some feedback on this mailing list... Jorge.-

Oct. 23, 2003

Re: [Dillo-dev] Can't find dpidrc

by ferdif＠optusnet.com.au

On Wed, Oct 22, 2003 at 11:49:56PM +0100, Nigel Wilkinson wrote: > Hi folks > > I've just built dillo-0.8.0-pre from the CVS but when I try to use bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi or in the ~/.dillo/dpi directory (and its right, they aren't there. Where is it or what is the format so that I can create it. If you simply ran ./configure then do echo dpi_dir=/usr/local/lib/dillo/dpi > ~/.dillo/dpidrc If you ran something like ./configure --prefix=somepath then do echo dpidrc=somepath/lib/dillo/dpi > ~/.dillo/dpidrc I'll fix this in my next patch. Cheers Ferdi

Oct. 23, 2003

Re: [Dillo-dev] localhost

by Thorben Thuermer

On Sun, 19 Oct 2003 03:33:04 +0200 Ivo <ivop(a)euronet.nl> wrote: > Hi all, > > I noticed the following behaviour, with 0.7.3 and also with the current CVS > (just checked out the latest version an hour ago). When I type the > following at the location bar: > > localhost Connects to my webserver (prepends http://) > http://localhost:2317/ It connects to my geneweb server > localhost:2317 It fails, saying ERROR: unsupported protocol > > Is this normal and expected behaviour, or considered a bug? Opera, for > example, prepends http:// and all works like expected. this is 'exected'. if the URL already contains a ':', dillo will assume the part before it is the protocol... after all, if you enter "localhost:2317", you clearly want to connect to host 2317 (0.0.9.13) using the 'localhost' protocol. > --Ivo Thorben

Oct. 23, 2003

Re: [Dillo-dev] [PATCH] Version 12 of tab/frame/kbnav patch, solves problem with Tab

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [10-17-03 09:32]: > > Download instructions > ===================== > > The patch is made against 20031017/11:26GMT CVS. Do not forget to run > ./autogen.sh after applying the patch. You can find the patch on the > usual (ad-happy, use an ad-blocking proxy or sane browser) site: > > http://www.geocities.com/ikbenfrank/ > > More specifically: > > Dillo 0.8.0-pre (CVS) > ===================== > http://www.geocities.com/ikbenfrank/dillo-20031017-tabs.patch.gz > size: 85658 bytes (gzipped, as downloaded) > 373460 bytes (uncompressed) > md5sum: be0618ac0136fafd9f7f91ce8a4db142 (gzipped, as downloaded) > 41438b3b27bf45f23b6a9069eee37cb6 (uncompressed) Frank, I am unable to apply the patch against cvs.1022. Pardon my lack of knowledge. Is there a way to download the cvs for 1017 or is there a way to apply the patch against a later cvs. ps. I can supply the .rej files. tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Oct. 23, 2003

Re: [Dillo-dev] Can't find dpidrc

by Johann Koenig

On Thursday October 23 at 12:13am Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > > On Wednesday October 22 at 11:49pm > > Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > > > I've just built dillo-0.8.0-pre from the CVS but when I try to use > > > bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi > > On Wed, 22 Oct 2003 18:57:49 -0400 > Johann Koenig <explosive(a)att.net> wrote: > > > Had the same problem. From the error message, I was able to create > > it. > > > > jkoenig@note:~$ cat .dillo/dpidrc > > dpi_dir=/usr/local/lib/dillo/dpi > > jkoenig@note:~$ > > "cat .dillo/dpidrc" just gives me "no such file or directory" which is > not a surprise. I have no trouble creating it if I knew the format and > what has to go in there Right, I understand that. I just showed you the format. The error message that told me what the format was is this: GLib-CRITICAL **: file gstrfuncs.c: line 186 (g_strconcat): assertion `string1 != NULL' failed. dpi_service.c:85: dpi_dir: fopen : No such file or directory - /home/jkoenig/.dillo/dpidrc dpid.c:301: register_all: dpi_dir Error getting dpi directory path : waitpid: No child processes Dpi_start_dpid: n = 0 Dpi_check_dpid:: EAGAIN Capi_dpi_conn_timeout:: try 6 Dpi_get_dpid_uds_dir: No such file or directory -- -johann koenig My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp

Oct. 22, 2003

Re: [Dillo-dev] Can't find dpidrc

by Nigel Wilkinson

> On Wednesday October 22 at 11:49pm > Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > > I've just built dillo-0.8.0-pre from the CVS but when I try to use > > bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi On Wed, 22 Oct 2003 18:57:49 -0400 Johann Koenig <explosive(a)att.net> wrote: > Had the same problem. From the error message, I was able to create it. > > jkoenig@note:~$ cat .dillo/dpidrc > dpi_dir=/usr/local/lib/dillo/dpi > jkoenig@note:~$ "cat .dillo/dpidrc" just gives me "no such file or directory" which is not a surprise. I have no trouble creating it if I knew the format and what has to go in there Cheers Nigel

Oct. 22, 2003

Re: [Dillo-dev] Can't find dpidrc

by Johann Koenig

On Wednesday October 22 at 11:49pm Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > Hi folks > > I've just built dillo-0.8.0-pre from the CVS but when I try to use > bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi or in the > ~/.dillo/dpi directory (and its right, they aren't there. Where is it > or what is the format so that I can create it. Had the same problem. From the error message, I was able to create it. jkoenig@note:~$ cat .dillo/dpidrc dpi_dir=/usr/local/lib/dillo/dpi jkoenig@note:~$ -- -johann koenig My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp

Oct. 22, 2003

Can't find dpidrc

by Nigel Wilkinson

Hi folks I've just built dillo-0.8.0-pre from the CVS but when I try to use bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi or in the ~/.dillo/dpi directory (and its right, they aren't there. Where is it or what is the format so that I can create it. Cheers Nigel

Oct. 22, 2003

Re: [Dillo-dev] Re: Thanks

by Scorpio Rising

Behold, Maurice McCarthy scribed in runic symbols on a tube chassis: > Just to let you know. > > Downloaded and compiled 0.7.3 but was missing gtk+ or some of it anyhow. > Managed to sort it with help of Synaptic - which would not allow me to > install libgtk-2.0-dev for some dull reason but 1.2-dev went in OK. > Anyhow sorted after a while. Dillo-0.7.3 up and running. > > Off exploring > Maurice Awesome! Yeah, whenever I do an install, first thing I do is apt-get the [pkg]-dev for EVERYTHING! I compile so much stuff from tarball, that it just saves a lot of hassle ;-) -- Gregg

Oct. 22, 2003

Re: [Dillo-dev] Re: Thanks

by Maurice McCarthy

Just to let you know. Downloaded and compiled 0.7.3 but was missing gtk+ or some of it anyhow. Managed to sort it with help of Synaptic - which would not allow me to install libgtk-2.0-dev for some dull reason but 1.2-dev went in OK. Anyhow sorted after a while. Dillo-0.7.3 up and running. Off exploring Maurice On Wed, Oct 22, 2003 at 09:47:39AM +0100 or thereabouts, Maurice McCarthy wrote: > Many thanks to Johann and Gregg for the tips. I can compile and patch, > if its not too difficult (Thanks to studying the LFS course) but I'm not > up to speed with CVS yet. Just bought O'Reilly's Linux in a Nutshell and > have the Linux SA Handbook on order. So I'll give it all a go. > > Yipee > Maurice > ----------------- > > If you think Google's fast > Google with a Dillo! > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 22, 2003

Re: [Dillo-dev] A short potpourri

by johannes leimbach

> Again, it can be done. If you're a developer, > look at the code for selections (to know how to get > the word under the mouse pointer), then look at how > bookmarks are added (to learn how to send a dpi > command) and then read the dpi docs, to bind your dpi. > > HTH > Jorge.- Or you just go and download stardict from http://stardict.sourceforge.net/, select your word and have a nice translation without even recompiling dillo :) -- < bye > \ oO)-. /__ _\ \ \( | \__|\ | ' '--'

Oct. 22, 2003

Re: [Dillo-dev] Re: Thanks

by Maurice McCarthy

Many thanks to Johann and Gregg for the tips. I can compile and patch, if its not too difficult (Thanks to studying the LFS course) but I'm not up to speed with CVS yet. Just bought O'Reilly's Linux in a Nutshell and have the Linux SA Handbook on order. So I'll give it all a go. Yipee Maurice ----------------- If you think Google's fast Google with a Dillo!

Oct. 22, 2003

Re: [Dillo-dev] A short potpourri

by Jorge Arellano Cid

Hi Eythan, > > I have read that people use dillo to read > documents, long documents, and perhaps whole > books, or chapters... In such cases there comes > a time when a use of a dictionary is a must. Is > it possible to have a dpi that will allow for the > running of any shell command on a highlighted > portion of the screen? It can be done. > In this example running > a dictionary on a word? The output of the > command would go into a new tab, or window or > split of the current window, horizontally or > vertically, depending on the key-binding. I'd make the dpi have its own window and let dillo grab the word from the mouse pointer position before asking the dpi for the word. All with a keyboard shortcut; very practical! Again, it can be done. If you're a developer, look at the code for selections (to know how to get the word under the mouse pointer), then look at how bookmarks are added (to learn how to send a dpi command) and then read the dpi docs, to bind your dpi. HTH Jorge.-

Oct. 21, 2003

Re: Thanks

by Scorpio Rising

Behold, Maurice McCarthy scribed in runic symbols on a tube chassis: > Hi all > > As a linux learning running Woody from a home pc I'd just like to thank > you all for a great browser. The newer versions of Dillo compile quite nicely on Woody (that's what I have). If on the ./configure something appears "missing", apt-get the associated -dev file for that package and you'll be set! -- Gregg

Oct. 21, 2003

Re: [Dillo-dev] Thanks

by Johann Koenig

On Tuesday October 21 at 08:40pm Maurice McCarthy <maurice.mccarthy(a)ntlworld.com> wrote: > Hi all > > As a linux learning running Woody from a home pc I'd just like to > thank you all for a great browser. > > Came across it by chance looking for something else then was totally > surprised to find it in the Woody CD's! > > It goes great with Mutt. Fast. Heh, and you're using the version from woody, which is about a year or two old. Try CVS sometime, the improvements will blow you're mind :) If that's not enough, try Frank's tab/frame patch. It's wonderful. -- -johann koenig My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp

Oct. 21, 2003

Thanks

by Maurice McCarthy

Hi all As a linux learning running Woody from a home pc I'd just like to thank you all for a great browser. Came across it by chance looking for something else then was totally surprised to find it in the Woody CD's! It goes great with Mutt. Fast. Thanks again Maurice

Oct. 21, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >Hi, > >I've only taken a glance at it, but made two changes to Frank's >work. The patch is attached, and is to be applied after Frank's patch: >The changes: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > words of a multi-word link. Somewhere, it is documented, that you > have to highlight up to strlen(word->content.data.text) + 1, to > highlight also the space. > > - I've modified the page widget to draw the focus-highlighted text > with a border, not inverse, as done with found and selected text. > >Sebastian > > {Have you thought about | Is there} a way to highlight text using a pattern (like the 'gray-out' highlight for images)? I have explicitly not used a line-stile highlight for keyboard focus, because this makes it often hard to see where focus is. Links are sometimes small, no more than a '*' or a subscripted number. A line-style highlight is hard to see in those cases... I do agree that it is necessary to use a different highlight style for focus, search and selection, but the traditional focus highlight ((dotted/dashed) line around word) is not very useful in many cases. This goes even more for people with bad eyesight. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 20, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >Hi, > >I've only taken a glance at it, but made two changes to Frank's >work. The patch is attached, and is to be applied after Frank's patch: >The changes: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > words of a multi-word link. Somewhere, it is documented, that you > have to highlight up to strlen(word->content.data.text) + 1, to > highlight also the space. > > Hmmm... that was intentional, so that focused links could be recognized more easily... Same for the next one by the way. Anyway, it would be even better if the focus could be drawn in another pattern or color, so that it is visible even when overlayed with a selection or found highlight. Btw, apart from looking only fleetingly at it, did you try keyboard navigation? If so, any remarks about the functionality itself? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 20, 2003

Re: [Dillo-dev] FLTK

by Melvin Hadasht

[Thanks Indan for your reply] > If > the only reason to switch to GTK2 is to have better fonts support, then > I > would just stick to GTK 1 and use the freetype library directly, > something > along the line of prerendered fonts and use them as small pictures, > whatever is fastest. According to http://www.dillo.org/Notes.html, Gtk+ is seen as a mean to support Unicode, not as a mean to display "nice" fonts. But the issue of font rendering speed is also there and as you suggest, these can be optimized depending on context. > Personally I don't need unicode support, can > understand that there are a lot people that need or want it, but maybe > it's not Dillo's task to support it, maybe a poll on the main website to > ask the users about it? For me CSS support is much more important than > most other features. Personnaly, I'd prefere Unicode support (or more precisely multi languages support), than CSS support. I personnaly do not browse only English web pages, and as the Internet is meant to allow information sharing throughout the world, I think Unicode and multi-language support is important. IMO, more important than CSS support, but I let developers decide which is more important and which is easier to implement and which will be implemented first, as each feature depend not only on user wishes but also on available resources. I think Gtk+2 is a nice library which is meant for ease of use and to fullfill most developers wishes in an easy way. This introduces some more abstraction and generalization in the way its widgets are implemented at the cost of specialized and optimized implementations. On modern hardware (>1Ghz, not like my 266Mhz chip), the slower than gtk1.2 library should still be quite usable (although, I did not test it on fast hardware). For example, the GtkTreeView: it is a very flexible widget and provides many features, but it is not a specialized widget anymore, so it is way slower than GtkCList or GtkCTree (AFAIS, it is not used in Thunderbird). Concerning Pango, it has to analyze each string to decide with which rendering engine the string will be rendered, this implies analyzing each character to determine to which language class it belongs, if there are RightToLeft and LeftToRight words etc... Each language may use a different set of fonts, and each font must be checked for its size. This computation is complex so to achieve fast rendering Pango should be studied carefully and rendering or drawing (on the expose events) algorithms should hand crafted. For example, maybe knowing that the page is in a certain non-unicode encoding, we could spare Pango some of its computation if Pango API allows such approach. So to summarize: I think porting Gtk+2 would need a quite deep knowledge of Pango and Gtk2 drawing pipeline and even more efforts on optimizations, as Dillo is meant to be a fast browser before being feature- rich browser. -- Melvin Hadasht

Oct. 19, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Sebastian Geerken

Hi, I've only taken a glance at it, but made two changes to Frank's work. The patch is attached, and is to be applied after Frank's patch: The changes: - Fixed a bug in focus.c: Now, spaces are also drawn, between the words of a multi-word link. Somewhere, it is documented, that you have to highlight up to strlen(word->content.data.text) + 1, to highlight also the space. - I've modified the page widget to draw the focus-highlighted text with a border, not inverse, as done with found and selected text. Sebastian

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Eric GAUDET

...tidy... > OK, your response ( and the others ) has convinced me that this was a > bad idea :) > :-) More generally, my point was: there's a lot to do to improve Dillo, let's not waste our time fixing problems that are not supposed to exist in the first place. > I realize this thread comes up periodically, I only mentioned it this > time because it was a way of minimizing the problem outside of the > core, by reusing existing tools (like tidy). Also, it gets tiresome > loading up another browser after a while with large sites, like > slashdot, that can't easily fix their problems. ( That's one downside > of using dillo - once you get used it, it's hard to tolerate anything > else :) > Tidy is actually an excellent idea ... server side :-) This /. guy should give it a try. On the other hand, fixing a broken page client side everytime it's loaded really sounds terrible. About the list of excuses given for not fixing the bug right away, the only real one is the management's priorities. As for the rest, I would just say: - not fixing bugs because some customers rely on them is bad for business; - not fixing bugs beacuse it has a lot of dependencies tell the design is probably wrong; - not fixing bugs because "it's complicated" is really lame; - "why would anybody write a browser from scratch?" why would anybody do anyting? let's all use windos and IE6! Best, EG

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Stephen Lewis

On Sat, Oct 18, 2003 at 08:19:49PM -0700, Eric GAUDET wrote: > -- En reponse de "Re: [Dillo-dev] Re: /. crap" de Geoff Lane, le > 18-Oct-2003 : > >> I have a suggestion regarding this: > >> While supporting broken HTML isn't really in the project goals, > >> would it be possible to wrap a tool like htmltidy using the dpi? > >> > >> So that dillo itself never even gets delivered broken HTML at all, > >> becauses it's all been pre-processed into something valid... > > > > One of the objections to accepting and attempting to display broken HTML > > is that you have no idea if the browser interpretation of the bad HTML > > matches the intention of the author. <snip> > The only effort we make towards broken html is trying as hard as we can not > to segfault. If a broken page is not rendering properly in Dillo (or any > browser), it's a bug in the page, not a bug in Dillo. Period. OK, your response ( and the others ) has convinced me that this was a bad idea :) I realize this thread comes up periodically, I only mentioned it this time because it was a way of minimizing the problem outside of the core, by reusing existing tools (like tidy). Also, it gets tiresome loading up another browser after a while with large sites, like slashdot, that can't easily fix their problems. ( That's one downside of using dillo - once you get used it, it's hard to tolerate anything else :) -- Stephen Lewis

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Eric GAUDET

-- En reponse de "Re: [Dillo-dev] Re: /. crap" de Geoff Lane, le 18-Oct-2003 : >> I have a suggestion regarding this: >> While supporting broken HTML isn't really in the project goals, >> would it be possible to wrap a tool like htmltidy using the dpi? >> >> So that dillo itself never even gets delivered broken HTML at all, >> becauses it's all been pre-processed into something valid... > > One of the objections to accepting and attempting to display broken HTML > is that you have no idea if the browser interpretation of the bad HTML > matches the intention of the author. Not only that, but it is also a significant effort to : - detect that the html is broken (it can have thousands of different problems) - pick the right fix for it (the one that most browser will agree on, because there's no standard for rendering broken pages, by definition) - fix it so it displays somewhat properly (meaning, change the internal representation of the page) By "significant effort", I mean we need develpment time to add a lot of non-trivial error recovery code, and also it will slow down the rendering process because it will need some sort of second-pass parsing of the page. That's why Dillo's attitude is to stick to the standard, not because we're standard fanatics: that's the only way to have a bounded and reliable definitoin of what rendering should be. The only effort we make towards broken html is trying as hard as we can not to segfault. If a broken page is not rendering properly in Dillo (or any browser), it's a bug in the page, not a bug in Dillo. Period. Best, Eric ------------------------------------------------------------------------ Eric GAUDET <eric(a)rti-zone.org> Le 18-Oct-2003 a 20:10:05 "Parler pour ne rien dire et ne rien dire pour parler sont les deux principes majeurs et rigoureux de tous ceux qui feraient mieux de la fermer avant de l'ouvrir." ------------------------------------------------------------------------

Oct. 19, 2003

XHTML (was Re: /. crap)

by Kelson Vibber

On Saturday 18 October 2003 5:50 pm, Ivo wrote: > On Sunday 19 October 2003 01:53, Kelson Vibber wrote: > > I believe that's the reason the XHTML spec says it should not even be > > rendered if it's invalid. And believe me, this is a good way to ensure > > you've got valid code. > > Does this also work on IE? If it does, God forbid the day that some bright > engineer at MS decides they should change their code to try to render it > anyway. No, IE doesn't handle XHTML at all. However, XHTML was designed with backward compatibility in mind. If an XHTML page is sent with the content type text/html, it looks like HTML 4.01 with a few extra attributes that can be ignored. The content type for XHTML, application/xhtml+xml, is only recognized by a few browsers right now, possibly only the Gecko-based ones and Amaya. Since Mozilla trusts the server to send the correct mime type, it assumes that a text/html page is HTML, not XHTML, and parses it as HTML. Any errors found are treated the same way it treats errors in HTML. It's only when it's served with the XHTML mime type that Mozilla enforces the well-formed XML requirement. IE can trash XHTML if you're not careful, though - since IE assumes the server is likely to be misconfigured, it will sometimes see the XML declarations at the beginning of an XHTML file and try to display it as plain XML, even if your server has told it the file is HTML. I saw this when I had more than one stylesheet attached as an XML declaration. Browsers that really display XHTML (through an XML parser, requiring it to be well-formed) should put application/xhtml+xml in their HTTP Accept header. (Gecko browsers do.) Documents in XHTML 1.1 or using features only found in XHTML should always be served with this mime type. For XHTML 1.0 documents intended for a wider audience, the server should use content negotiation to determine which the browser can handle, and serve either text/html or application/xhtml+xml. I should mention that, AFAIK, the don't-even-render-it rule only applies to XML well-formedness. So mis-nested or extra tags (like the extra </td></tr> in Slashdot) would cause the browser to display an error, but unfamiliar tags (such as RDF embedded in XHTML) would simply be ignored as long as they don't invalidate the XML structure. For example, you can serve the following: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head><title>Blah</title></head> <body> <h1>Header</h1> <blargquote><img src="whatever.jpg" /></blargquote> </body> </html> ...and it will display the way you would expect - ignoring the fictitious "blargquote" element (which would be caught by a validator). But if you instead do this (note the missing close tag for blockquote): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head><title>Blah</title></head> <body> <h1>Header</h1> <blockquote><img src="whatever.jpg" /> </body> </html> ... Mozilla will display this error message: XML Parsing Error: mismatched tag. Expected: </blockquote>. Location: test.xhtml Line Number 8, Column 3: </body> --^ But if you send the exact same file with the text/html content type, it will use the HTML parser and try to guess where the blockquote is supposed to end. -- Kelson Vibber www.hyperborea.org

Oct. 19, 2003

localhost

by Ivo

Hi all, I noticed the following behaviour, with 0.7.3 and also with the current CVS (just checked out the latest version an hour ago). When I type the following at the location bar: http://www.cnn.com/ Opens the webpage (offcourse) www.cnn.com Opens the webpage (it prepends http://) http://localhost/ Connects to my webserver localhost Connects to my webserver (prepends http://) http://localhost:2317/ It connects to my geneweb server localhost:2317 It fails, saying ERROR: unsupported protocol Is this normal and expected behaviour, or considered a bug? Opera, for example, prepends http:// and all works like expected. --Ivo

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Ivo

On Sunday 19 October 2003 01:53, Kelson Vibber wrote: > I believe that's the reason the XHTML spec says it should not even be > rendered if it's invalid. And believe me, this is a good way to ensure > you've got valid code. Does this also work on IE? If it does, God forbid the day that some bright engineer at MS decides they should change their code to try to render it anyway. --Ivo

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Kelson Vibber

On Saturday 18 October 2003 2:22 pm, Geoff Lane wrote: > Now we know what to avoid, perhaps it's time to give up on HTML and try > again :-) I believe that's the reason the XHTML spec says it should not even be rendered if it's invalid. And believe me, this is a good way to ensure you've got valid code. I switched over a few sections of my website to send application/xhtml+xml when appropriate, and suddenly it was *really* obvious when a page had bugs on it! (The disturbing part was that Mozilla caught a few errors that slipped past both the WDG offline validator and the W3C online validator.) -- Kelson Vibber www.hyperborea.org

Oct. 18, 2003

Re: [Dillo-dev] Re: /. crap

by Geoff Lane

On Sun, Oct 19, 2003 at 09:46:01AM +1300, Stephen Lewis wrote: > I have a suggestion regarding this: > While supporting broken HTML isn't really in the project goals, > would it be possible to wrap a tool like htmltidy using the dpi? > > So that dillo itself never even gets delivered broken HTML at all, > becauses it's all been pre-processed into something valid... One of the objections to accepting and attempting to display broken HTML is that you have no idea if the browser interpretation of the bad HTML matches the intention of the author. HTML is well described so it's not exactly rocket science to generate gramatically correct HTML source. The fact that so many web pages generated programatically are seriously broken and there is huge resistance to correcting the situation is worrying. It means that not only do browsers have to deal with the many published versions of the HTML standards and the common propriatory extensions, they also have to be bug and interpretation of bad HTML compatible. The result will be that HTML is actually defined by the unpublished, defacto behaviour of the browser with the biggest installation base. It also means that browsers become hugely bloated as more and more variations to correct HTML have to be dealt with; with the bloat comes more difficult to correct bugs. Now we know what to avoid, perhaps it's time to give up on HTML and try again :-) -- Geoff Lane McDonalds hamburgers are made from 100% real clown meat.

Oct. 18, 2003

Re: [Dillo-dev] Re: /. crap

by Stephen Lewis

On Sat, Oct 18, 2003 at 09:58:05PM +0200, The Night Howler wrote: <snip> > Maybe by version 1.0 we can include some kind of > "render_uglily_coded_webpage" function to deal with that, but as far > as I'm concerned I'm very happy with dillo the way it is. I have a suggestion regarding this: While supporting broken HTML isn't really in the project goals, would it be possible to wrap a tool like htmltidy using the dpi? So that dillo itself never even gets delivered broken HTML at all, becauses it's all been pre-processed into something valid... Just a thought :) -- Stephen Lewis

Oct. 18, 2003

Re: /. crap

by The Night Howler

Some comments on /. stuff : > This is the part where I rhetorically ask why anyone would write a > web browser from scratch, the goal of which is to render 100% > syntactically correct webpages really really fast. Are there not > enough existing web browsers whose goals are to render pages really > really fast? Oh, which ones ? On my P 120, which is my only computer, I tried mozilla and its derivatives - they filled up my 56 Mb of RAM just for loading and took a dozen of minutes to show up even a simple page. This without counting the megabytes they took on my hard-drive. So I had a few choices : either switch back to Windows 98 and Internet Explorer, which *is* in comparison damn fast, or use Lynx on my Debian. Or finding another fast linux-graphical browser. I browsed the net. I tested "browsers" like Chimera2, that no one ever heard about, and was very upset with every browser I tried until I found Dillo. Even if Dillo is very strict regarding HTML compliance of pages, it is, as far as I know, the only Linux graphical browser working correctly on legacy computers. > But I have other things to worry about, and you have > other browsers to choose from that render Slashdot just fine. Yes - it works fine with Lynx. I guess maybe we pushed the issue a little too hard - after all, Slashdot is not the only website that doesn't display correctly on Dillo. As the development philosophy is "stick to the standards", I think we shouldn't care too much about badly formatted pages. Maybe by version 1.0 we can include some kind of "render_uglily_coded_webpage" function to deal with that, but as far as I'm concerned I'm very happy with dillo the way it is. I guess for people like me, who use old computers in everyday's life, using Dillo+Lynx is a very good way of accessing a great part of the web resources. Best regards, Mathieu -- "Just living is not enough," said the butterfly, "one must also have freedom, sunshine, and a little flower." Hans Christian Andersen

Oct. 18, 2003