July 2009 - Dillo-dev - lists.mailman3.com

perhaps an iterator bug
by corvid＠lavabit.com 03 Sep '09

03 Sep '09

I was trying the new search functionality a bit more and found this (it's also present in my Dec 2008 dillo*). With the page: <table> <tr><td>no close-tr <tr><td>has a close-tr</tr> <tr><td>here's another line</tr> </table> if I search for "rh", it finds one instance of it split between the second and third table rows. * My older dillos were lost in a tragic "I don't think I need my CVS stuff anymore" accident.

3 4

Planning
by jcid＠dillo.org 02 Sep '09

02 Sep '09

Hi, Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work. * Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html * Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick. * Handle negative values in CSS. e.g. wikipedia. * What will we do with xhtml? To render or not to render... FF doesn't validate. BUG#732 One solution is to add a notification widget area below the control panel that hides/unhides as the find bar, to warn when a xhtml file has detected bugs (we'd also move the meta refresh warning to display here). I already have a simple patch to add xhtml rendering. The widget implemetation is the missing part. It should be much simpler than the close button in each tab. :-) e.g. http://planet.postgresql.org/ * Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole. * dpi for "view page source" (it re-uses search capability). This requires a check of the current data-passing inside DPIP. * Improve the DPI development/debug framework. * https dialog bombing issue. BUG#868 AKA make https dpi a server (i.e. not a filter dpi). * Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it. *   handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock. * FTP download doesn't work?! -- Cheers Jorge.-

5 19

Happy announcement (not SW)
by jcid＠dillo.org 18 Aug '09

18 Aug '09

Hi guys, I'm quite happy to let you know that yesterday 19 Aug, my first daughter Lisa was born! Everything is OK, we're vey happy with this "release" :) and I just wanted to communicate it here, so you more or less know or understand my activities (or lack of) in the next days. :-) -- Cheers Jorge.-

12 13

Re: patch: media_type pref
by corvid＠lavabit.com 05 Aug '09

05 Aug '09

Jorge wrote: > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > It makes more sense to have a pref that the user can > > control than for us to guess what they might like > > based on screen size or whatever, I think. > > I hesitate on this. For instance: if media_type is defined to > "handheld" and there's no such remote CSS, at least it should > fallback to "screen". If there is a handheld style sheet available and dillo is running on a handheld, it would be a shame not to use it. I'm hoping that the page author would have the sense to supply something for type "all". > Maybe it's more practical to provide custom stylesheets (as the > current "style.css". e.g. small_screen.css, print.css) and to > allow switching among them from the "Tools" menu. > > What do you think? I think someone using handheld would want to use both the page author's handheld-specific code and a user style suitable for their device. I'll send this to the list in case anyone with experience using such devices with the web has opinions to share.

3 3

Re: dillo crash at dlib/dlib.c:173
by stevegigijoe＠yahoo.com.tw 29 Jul '09

29 Jul '09

Hello guys I'm Sorry. Corvid is right. I must mass up something :p Steve ______________________________________________________________________________________________________ ¥I¶O€~®e¶qµL€W¡HYahoo!©_Œ¯¹q€l«Hœc2.0§K¶Oµ¹§A¡A«H¥ó¥Ã»·€£¥²§R¡I http://tw.mg0.mail.yahoo.com/dc/landing

1 0

dillo crash at dlib/dlib.c:173
by stevegigijoe＠yahoo.com.tw 29 Jul '09

29 Jul '09

Hello all After update, the dillo crash while opening http://www.google.com.tw on dlib/dlib.c:173 The array haystack is null and unchecked cause the problem... Log as below gigijoe@user-desktop:~/dillo2$ gdb src/dillo GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) r Starting program: /home/gigijoe/dillo2/src/dillo [Thread debugging using libthread_db enabled] paths: Cannot open file '/home/gigijoe/.dillo/keysrc' paths: Cannot open file '/usr/local/etc/dillo/keysrc' paths: Using internal defaults... dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://www.google.com.tw' [New Thread 0xb795b8e0 (LWP 11430)] [New Thread 0xb782bb90 (LWP 11433)] Dns_server [0]: www.google.com.tw is 74.125.19.105 74.125.19.106 74.125.19.99 74.125.19.104 74.125.19.103 74.125.19.147 [Thread 0xb782bb90 (LWP 11433) exited] Connecting to 74.125.19.105 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb795b8e0 (LWP 11430)] 0x0807ee7c in dStristr (haystack=0x0, needle=0x810c13f "javascript") at dlib.c:173 173 for (i = 0, j = 0; haystack[i] && needle[j]; ++i) Current language: auto; currently c (gdb) q The program is running. Exit anyway? (y or n) y Steve ______________________________________________________________________________________________________ ¥I¶O€~®e¶qµL€W¡HYahoo!©_Œ¯¹q€l«Hœc2.0§K¶Oµ¹§A¡A«H¥ó¥Ã»·€£¥²§R¡I http://tw.mg0.mail.yahoo.com/dc/landing

3 2

dIsspace
by corvid＠lavabit.com 28 Jul '09

28 Jul '09

When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.

3 6

exit codes
by corvid＠lavabit.com 24 Jul '09

24 Jul '09

I checked what bash sees when dillo returns -1 for bad cmdline argument, and $? shows 255. It seems that out of range values turn into 255. Not that anyone will ever care beyond zero vs nonzero, but I'd like to change it to something valid. I could change it to 1...or 2...or I could use the values from sysexits.h (i.e., borrow their values as opposed to including it, since it doesn't appear to be standard). Any opinions?

1 0

Problem: Dillo2 does not recognize True Type font
by ericshliao＠gmail.com 19 Jul '09

19 Jul '09

I built dillo2 for my Debian5 desktop and found that Chinese text were not correctly displayed. All Chinese glyphs are displayed in empty blocks. I found that it's because the dillo2 that I built only recognized type1 font and did not recognize truetype font. I did a small test as the stated in the following to find the cause. I know it is not normal, because people don't have such problem. I wonder if this problem can be solved by setting proper ./configure options or by modifying Makefile. If you have any idea, please help. Thanx. At first, I suspect that FLTK2 does not support multi-national language dispaly. So I wrote a small program to test it. I used: "g++ -o fltkhello1 fltkhello1.cxx -I/usr/local/include -L/local/lib -lfltk2 -lXext -lXft -lX11 -lXi -lm" to compile. The result is not not satisfying. With the help from fltk-dev mail list, I tried "fltk2-config --compile fltkhello1.cxx" and got correct result. In fact, "fltk2-config --compile fltkhello1.cxx" will execute the following command to compile: gcc -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor -o fltkhello1 fltkhello1.cxx -L/usr/local/lib /usr/local/lib/libfltk2.a -lX11 -lXi -lXinerama -lXcursor -lXft -lpthread -lm -lXext -lsupc++ The interesting part is: my previous faulty compile command made my program only recognize type1 font (such as Bitstream Charter), and no truetype font is recognized. The problem was corrected by calling "fltk2-config --compile fltkhello1.cxx". Because in my desktop, all the Chinese glyphs are provided by truetype font, it caued FLTK2 program won't dispaly Chinese glyphs. I also add some code in Dillo 2 source code to hardcode fontname to be used to draw text, I found that only typ1 font was recognized, all truetype fonts are not recognized.

3 5

[patch] check for dpip_tag == NULL in https.c
by Johannes.Hofmann＠gmx.de 19 Jul '09

19 Jul '09

Hi, I was getting frequent https.filter.dpi with dpip_tag == NULL. Attached patch adds a check for that case. If nobody objects I'd commit this in a few days. Cheers, Johannes

3 4