- Dillo-dev - lists.mailman3.com

New table layout rocks!
by onepoint＠starurchin.org Feb. 14, 2008

Feb. 14, 2008

I've been collecting web pages that Dillo misrendered: truncated images, overlapping text, pages clipped at the right, etc. I'm really pleased to announce that the latest Dillo handles them all. This is a major improvement! I'm assuming this is the new table layout code at work. Regards, Jeremy Henty

5 31

[patch] fix HomeKey/EndKey behaviour
by Johannes.Hofmann＠gmx.de Feb. 7, 2008

Feb. 7, 2008

Hi the patch below makes HomeKey and EndKey work as it did in dillo1. I think I had introduced the current behaviour that also adjusts the x-position but it is pretty annoying on wide pages. Cheers, Johannes diff -r 1c41f9a73971 dw/fltkviewport.cc --- a/dw/fltkviewport.cc Sun Feb 03 21:13:11 2008 +0100 +++ b/dw/fltkviewport.cc Wed Feb 06 18:16:41 2008 +0100 @@ -292,11 +292,11 @@ int FltkViewport::handle (int event) return 1; case HomeKey: - scrollTo (0, 0); + scrollTo (scrollX, 0); return 1; case EndKey: - scrollTo (canvasWidth, canvasHeight); /* gets adjusted in scroll() */ + scrollTo (scrollX, canvasHeight); /* gets adjusted in scroll() */ return 1; } }

2 1

[PATCH]: Table::apportionRowSpan()
by onepoint＠starurchin.org Feb. 5, 2008

Feb. 5, 2008

OK, please ignore my previous attempt at reworking Dillo's ROWSPAN handling. I have a simple fix for the bugs I reported at http://starurchin.singularity/dillo/bugs/table_rowspan.html . This patch tweaks dw::Table::apportionRowSpan() to handle the special case where all the rows being spanned have zero height. This fixes the special cases that were breaking without changing the behaviour in any other case. (BTW, I still think there is a case for reworking Dillo's ROWSPAN algorithms along the lines I suggested, but it's nice to fix bugs without such efforts.) Regards, Jeremy Henty

2 4

[patch] fix size of select widgets
by Johannes.Hofmann＠gmx.de Feb. 5, 2008

Feb. 5, 2008

Here is a small patch to compute the size of select widgets similar to the way it is computed for text input widgets. The width is hardcoded to 10 * size of 'M' in the current font. Regards, Johannes PS: The colored widgets are nice! diff -r 68ee0a55704c dw/fltkui.cc --- a/dw/fltkui.cc Sat Feb 02 18:36:32 2008 +0100 +++ b/dw/fltkui.cc Sat Feb 02 19:20:16 2008 +0100 @@ -1048,10 +1048,21 @@ void FltkOptionMenuResource::widgetCallb void FltkOptionMenuResource::sizeRequest (core::Requisition *requisition) { - /** \bug Random values. */ - requisition->width = 100; - requisition->ascent = 18; - requisition->descent = 5; + if (style) { + FltkFont *font = (FltkFont*)style->font; + ::fltk::setfont(font->font,font->size); + requisition->width = + (int)::fltk::getwidth ("M", 1) * 10 + + 2 * RELIEF_X_THICKNESS; + requisition->ascent = + font->ascent + RELIEF_Y_THICKNESS; + requisition->descent = + font->descent + RELIEF_Y_THICKNESS; + } else { + requisition->width = 1; + requisition->ascent = 1; + requisition->descent = 0; + } }

2 4

an experiment in widget coloring (with code)
by place＠gobigwest.com Feb. 5, 2008

Feb. 5, 2008

With my color settings, my buttons were light grey with unreadable white labels. Well, that's no good. And standard gui widget colors scream "I'm using a Windows Office Productivity Suite!" to me. So here is something to play with. I currently have the widgets using background color and the labels/text either black or white. fltk_black to make black work right widget_colors.dillo to set backgroundColor in Style. widget_colors.dw where you set the widget colors.

3 16

a_Dialog_text_window() dimensions
by place＠gobigwest.com Feb. 3, 2008

Feb. 3, 2008

(speaking of my ancient computer... [it keeps not dying, so I keep not buying a new one]) a_Dialog_text_window() dimensions were recently increased to int wh = 600, ww = 650, bh = 30; but my display is small enough that this puts the close button below the bottom of the screen. Perhaps it should be limited by screen dimensions. Or something based on prefs.height and prefs.width...

2 1

a couple of patches: referer and image_off
by jcid＠dillo.org Feb. 2, 2008

Feb. 2, 2008

On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > In brief, using the same URI, the three options offer good > > privacy (because no new information is sent), and if we ever > > enable using the referring page, the old comments apply. > > Whew. > > See, I ran on the equivalent of "host" for > at least a year, and then have been using the > equivalent of "path" for at least a year, so > the idea that I had somehow been doing something > wrong was alarming :) :-) Well, in that case you can provide good advice on which is better as a default. -- Cheers Jorge.-

2 2

a couple of patches: referer and image_off
by jcid＠dillo.org Feb. 1, 2008

Feb. 1, 2008

Hi there, - Added a text placeholder: "[IMG]" for img_off mode. - Added a http_referer preference. See details in dillorc2. This couple plays well together. When in img_off mode, non loaded images will show "[IMG]" (or original alt text), and the partial referer helps with getting images from sites that don't allow external sources. >From the updated dillorc2: # Set the HTTP Referer information (WARNING: affects privacy) * # We use the same URI, not the refering page (to avoid cross-site tracking). # none : No referer at all (full privacy). # host : Default value. Send same URI's hostname (no sensible info is sent). # path : same URI is sent (NO PRIVACY). http_referer=host Note: please read the "*"-marked line twice. ;) -- Cheers Jorge.-

2 4

Various minor patches
by tmseck-lists＠netcologne.de Jan. 31, 2008

Jan. 31, 2008

All, I am very glad to see that dillo-fltk has now gained some momentum. While looking at it on FreeBSD (6.2) I came across some minor problems, patches for which are attached: 1) detect_libiconv.diff src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am. 2) src-colors.h.diff I needed to include <stdint.h> or <inttypes.h> in order to have int32_t properly defined. I decided to wrap this include in a hopefully portable and correct way by instrumenting config.h. 3) src-dns.c.diff On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard. Otherwise dillo-fltk looks really promising -- keep up the good work! Best regards, -- Thomas-Martin Seck current dillo and FLTK port maintainer on FreeBSD

4 22

[PATCH]: improved ROWSPAN handling
by onepoint＠starurchin.org Jan. 31, 2008

Jan. 31, 2008

Here's a page demonstrating some problems Dillo has when all the cells in a table have ROWSPAN > 1 . http://starurchin.org/dillo/bugs/table_rowspan.html The cause of these issues is that Dillo has (excuse me) a rather clumsy way of calculating the row heights once it has assigned column widths and calculated the cell heights. It first calculates row heights based on the cells with ROWSPAN = 1 , and then adds extra height to rows to accommodate cells with ROWSPAN > 1 . This algorithm gives poor results when no cells have ROWSPAN = 1 . It can add unnecessary vertical space (see example on the page). Worse, if there is no vertical padding in the table as well as no cells with ROWSPAN = 1 , the table has zero height after the first pass. The second pass can't cope with this (because it would be dividing by 0) so it does nothing, so the table still has no height when the layout is finished. This messes up the redisplaying of the contents and can create "dead" text that can't be selected or clicked. This patch fixes all these problems by rewriting the algorithm that calculates row heights. Nothing else in the layout code is changed. The new code scans all the cells once, top-down, and keeps track of the minimum height we must insert between the top of the table and the bottom of the cell. Once each cell is dealt with, the height assigned to its top will not change (because we work top-down) and the height assigned to its bottom can only increase, so by the end all cells have at least as much vertical height as they need. Then another pass tours the height constraints and writes the correct values into the cumHeights vector. Advantages of this patch: * Fixes the bugs noted above. * Assigns the minimal possible vertical height to the table (given the column widths that have already been assigned). * Treats all cells the same no matter what their ROWSPAN, so there are no special cases when no cells have ROWSPAN = 1 . * Doesn't do any division, so there are no special cases when the available padding is 0 . If this change is merged I'll submit a cleanup patch that removes the now-unused apportionRowSpan() method. This was a purely internal change, so I didn't need to update any docs. (Phew!) I need to look at the handling of ROWSPAN="0" attributes. Are these even legal? Regards, Jeremy Henty

2 2