June 2004 - Dillo-dev - lists.mailman3.com

[Dillo-dev]BUG#569

by Jorge Arellano Cid

Hi there, What do you guys think of this? 569 Impact: feature fault At: run time Type: misbehaviour Comments: In Dillo, BACK button sends me to other previous html file, not to the previous position in the same file. It is a problem. I tested this BACK BUTTON function in Mozilla and IE. They worked. Please solve this glitch. I really need this function. HTReproduce: In a long html file, click a tag that sends you to the another part in the same html file. Then click BACK BUTTON in the menu bar. You would be in the previous other html file, not in the previous position in the same file. It is a fault behavior. WorkedBy: polsci* hitel* net Submitter: polsci* hitel* net Since the beginning, Dillo's behaviour is as described above. We have received almost no complaints, so it doesn't seem that bad in practice. Would it be worth to change it? Cheers Jorge.-

June 19, 2004

[Dillo-dev]BUG#570

by Jorge Arellano Cid

Hi Sebastian, Please give a look at BUG#570: 570 Impact: soft error At: run time Type: render bug Comments: Inconsistent render. First load or reload renders different than cached load (back/forward) HTReproduce: open dillo, nav to http://slskboard.savagenews.com/index.php (notice the first forum name i.e.) press back press forward (different cell width) WorkedBy: nobody Submitter: unknown it is very interesting and perhaps related to the rendering problem of our home page with dialups (resizing of alt-sized cells to actual image size). Cheers Jorge.-

June 19, 2004

Re: [Dillo-dev]thread-safe X at fresco

by Jorge Arellano Cid

On Fri, 18 Jun 2004, robert w hall wrote: > The thread-safe versions of XFree3.3.3.1 have disappeared from > linuxsavvy, (and my own attempts too recompile my own have produced > useable, but not wholly error-free results)... > > But I note that vintage.fresco.org still has two earlier thread-safe > Xlibs, 3.1.2 and 3.2, linked statically. I have REENTRANT 3.3.2 libs that work for me. If you want I can pack them for you to try... Cheers Jorge.-

June 19, 2004

[Dillo-dev]thread-safe X at fresco

by robert w hall

The thread-safe versions of XFree3.3.3.1 have disappeared from linuxsavvy, (and my own attempts too recompile my own have produced useable, but not wholly error-free results)... But I note that vintage.fresco.org still has two earlier thread-safe Xlibs, 3.1.2 and 3.2, linked statically. Anyone used these? dillo glib gtk appear only to use libX11, libXext, (which is all the earlier fresco 3.1.2 package provides). Bob Going bravely backwards from kernel 2.6.7! -- robert w hall

June 18, 2004

Re: [Dillo-dev]Problems with the activation of the URL entry

by Jorge Arellano Cid

On Thu, 17 Jun 2004, Jorge Arellano Cid wrote: > > Sebastian, > > On Tue, 15 Jun 2004, Jorge Arellano Cid wrote: > >>> When a_Interface_entry_open_url is called in this case, >>> gtk_editable_get_chars returns an empty string, it seems that the >>> "real" copying of the selection in Interface_entry_paste_selected is >>> somehow delayed. As workarounds, I see two possible solutions: >>> >>> 1. Also queueing our code in an idle function. The attached patch >>> demonstrates this successfully, although it has to be cleaned up >>> (in some cases, the active idle function has to be removed again). >>> >>> 2. Calling a_Interface_entry_open_url directly with the contents of >>> the selection. (But how do I get the latter?) >> >> The safe way to get 2) is to call a_Nav_push from the callback, >> and not to worry about a_Interface_... functions. That way, the >> selection is handled as a link. >> >> The only glitch is that the entry is not inmediately changed, >> but the stop button will serve as feedback (it shows activity). > > Oh, later I realized that this is not enough to solve the > problem, because there's a race condition if the selection is not > retrieved by catching the "selection_received" signal. > > Now I have some code that does this and will commit after some > polishing. Done. > PS: Is there anyone using a 2.6.x linux kernel? I tried it > yesterday and viewing directory listings with dillo was painfully > slow. So I developed a patch for this, but I'm surprised noone > complained! and Done. Now the copy&paste into the "clear URL" button works by catching the "selection_received" signal. It was very hard to find out how its done because the GTK+ docs are incomplete, the GDK ones recommend using Xlibs directly (or the GTK API), and the example code in the GTK+ has the wrong parameters. The GDK sources shed some light. With regard to 2.6.x linux, it was a matter of adding some buffering, a stream transfer instead of FD was enough. Cheers Jorge.-

June 18, 2004

Re: [Dillo-dev]Problems with the activation of the URL entry

by Jorge Arellano Cid

Sebastian, On Tue, 15 Jun 2004, Jorge Arellano Cid wrote: >> When a_Interface_entry_open_url is called in this case, >> gtk_editable_get_chars returns an empty string, it seems that the >> "real" copying of the selection in Interface_entry_paste_selected is >> somehow delayed. As workarounds, I see two possible solutions: >> >> 1. Also queueing our code in an idle function. The attached patch >> demonstrates this successfully, although it has to be cleaned up >> (in some cases, the active idle function has to be removed again). >> >> 2. Calling a_Interface_entry_open_url directly with the contents of >> the selection. (But how do I get the latter?) > > The safe way to get 2) is to call a_Nav_push from the callback, > and not to worry about a_Interface_... functions. That way, the > selection is handled as a link. > > The only glitch is that the entry is not inmediately changed, > but the stop button will serve as feedback (it shows activity). Oh, later I realized that this is not enough to solve the problem, because there's a race condition if the selection is not retrieved by catching the "selection_received" signal. Now I have some code that does this and will commit after some polishing. Cheers Jorge.- PS: Is there anyone using a 2.6.x linux kernel? I tried it yesterday and viewing directory listings with dillo was painfully slow. So I developed a patch for this, but I'm surprised noone complained!

June 17, 2004

Re: [Dillo-dev]More on the UTF-8 issue

by Todd Slater

On Wed, Jun 16, 2004 at 12:46:17PM -0700, sam+dillo(a)chaosring.org wrote: <snip> > As an aside, I think Dillo currently has excellent CSS support (namely, > none whatsoever). The thinking behing CSS is that a webpage > should be perfectly readable on a browser with no CSS support; the > content (if not the presentation) of a CSS webpage is perfectly > accessible from a non-CSS browser. > > I come from the "CSS shouldn't be done at all, or should be done > perfectly" camp. Considering the number of hacks web designers > have come up to make CSS visible to this browser yet invisible to > that browser [2], the last thing a webmaster wants is yet another > buggy CSS implementation. I couldn't agree more, and it's one of the reasons I use Dillo--to view pages according to their HTML structure. It's when you look at css-heavy pages that you appreciate webmasters that use the visibility feature of css to hide the navigation jumps to css-aware browsers; they become very user-friendly to non-css aware browsers. I suppose lynx would give the same effect :) Todd

June 16, 2004

Re: [Dillo-dev]More on the UTF-8 issue

by David McKee

On Wed, 16 Jun 2004 sam+dillo(a)chaosring.org wrote: > Jorge, in a message with the subject "UTF-8", sent on June 3rd, wondered > why someone would encode an English-language webpage with UTF-8. [ ... reasons snipped ... ] > Now, obviously, considering Dillo's target audience, it doesn't need > full Unicode support. But it would be nice if it could handle basic > UTF-8 encoded Latin-1 characters in web pages [1]. [...snip...] > [1] Some hacky code I once wrote, that reads UTF-8 from standard input, > and outputs iso 8859-1: > > if(c<128) { printf("%c",c); } > else { if(c < 0xe0) { /* two-byte sequence */ > v = c & 0x1f; v <<= 6; > c = getc(stdin); > v = v + (c & 0x3f); > printf("%c",v); } > else { /* multi-byte sequence */ > while(c & 0xc0 == 0x80 && !feof(stdin)) { > c = getc(stdin); } > } > } > > (This code, FWIW, is public domain) > > It is probably better to simply use iconv. Just as a note, I find no iconv(1) or iconv(3) on my (old!) system, so ./configure would have to be able to make some decisions if things went that way... -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

June 16, 2004

[Dillo-dev]More on the UTF-8 issue

by sam+dillo＠chaosring.org

First of all, I would like to thank Jorge for working on Dillo; it fills the need for there to be a lightweight *nix browser for older systems and times when one doesn't want to devote a lot of system resources just to access the world wide web. It is an excellent browser. When performing cross-browser verification, I discovered that Dillo 0.8.1 does not honor the following line in an HTML header: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Despite the presence of this line, Dillo assumed that the web page was encoded in Latin-1. Jorge, in a message with the subject "UTF-8", sent on June 3rd, wondered why someone would encode an English-language webpage with UTF-8. I can not speak for other webmasters, but the reason I personally encode my webpage in UTF-8 is because I do my web design on a Fedora Core 2 box, an OS that generally assumes that plain text files are encoded with Unicode instead of the iso-8859 mess. Also, Unicode gives one the flexibility to have Greek letters for Greek words, Cryllic letters for Russian words, and what not. Not to mention a number of attractive typographical symbols that Latin 1 does not have. Now, obviously, considering Dillo's target audience, it doesn't need full Unicode support. But it would be nice if it could handle basic UTF-8 encoded Latin-1 characters in web pages [1]. As an aside, I think Dillo currently has excellent CSS support (namely, none whatsoever). The thinking behing CSS is that a webpage should be perfectly readable on a browser with no CSS support; the content (if not the presentation) of a CSS webpage is perfectly accessible from a non-CSS browser. I come from the "CSS shouldn't be done at all, or should be done perfectly" camp. Considering the number of hacks web designers have come up to make CSS visible to this browser yet invisible to that browser [2], the last thing a webmaster wants is yet another buggy CSS implementation. - Sam [1] Some hacky code I once wrote, that reads UTF-8 from standard input, and outputs iso 8859-1: if(c<128) { printf("%c",c); } else { if(c < 0xe0) { /* two-byte sequence */ v = c & 0x1f; v <<= 6; c = getc(stdin); v = v + (c & 0x3f); printf("%c",v); } else { /* multi-byte sequence */ while(c & 0xc0 == 0x80 && !feof(stdin)) { c = getc(stdin); } } } (This code, FWIW, is public domain) It is probably better to simply use iconv. [2] http://centricle.com/ref/css/filters/ shows all of the common CSS hacks webmasters do these days.

June 16, 2004

Re: [Dillo-dev]Dillo & linuxmail.org

by Jorge Arellano Cid

Hi Lars, On Wed, 16 Jun 2004, Lars Segerlund wrote: > > I just checked out the latest dillo and I can alsost get my > linuxmail.org account to run in it. > > Does anybody have any idea about what might be the problem ? The site relies heavily on Javascript. Looking at the source for the login page, it expects javascript functions to MD5-encode the password before form submittion. It may be possible to bypass the problem by giving the MD5 encoded password (+ the mangling it uses) so dillo can finally get the FORM accepted by the server. It also looks as they give you a permanent cookie that can avoid the login process to some extent. So allow them for that domain. In a nutshell: the problem is mandatory javascript; it may be solved with some clever hacks though. Cheers Jorge.-

June 16, 2004