- Dillo-dev - lists.mailman3.com

BUG: CCC corrupts memory when the Content-Type is wrong
by onepoint＠starurchin.org Dec. 6, 2007

Dec. 6, 2007

I am hoping that someone who understands Dillo's CCC better than I can point me in the right direction and save me some time debugging this. Dillo almost always crashes if the HTML contains the stumbleupon.com favicon link, ie.'<img src="http://www.stumbleupon.com/favicon.ico">'. (This is very annoying as it makes Dillo unusable for one of my favourite blogs.) If it doesn't crash right away then clicking Reload crashes it. Examining core dumps with gdb suggests that memory is being corrupted, and running dillo under valgrind shows that the CCC functions are reading, writing and freeing already freed memory. (Details attached.) A local HTTP server triggers the bug when it server returns a Content-Type of "text/plain; charset=iso-8859-1". If I change it to "image/x-icon" there is no corruption. Accessing the image directly via a "file:" URL does not trigger the bug. (Strangely, using a local HTTP server does not hit the bug until I open a second window on the page, although sometimes it crashes first time.) I'm attaching a summary of the invalid memory accesses that valgrind reported, and the entire valgrind log (which includes stack traces). Any suggestions for where I should start instrumenting the CCC to find out why it is prematurely freeing pointers? Jeremy Henty

2 4

[patch] fix crashes after panel size changes
by Johannes.Hofmann＠gmx.de Dec. 6, 2007

Dec. 6, 2007

Hello, now that was a weird bug! I was experiencing crashes when I had changed the panel size via the right mouse on the search button. The problem is that FltkWidgetView::prepareCreateFltkWidget() was calling fltk::Group::begin(). Therefore after visiting pages with forms, the newly created panel was getting a child of Main instead of TopGroup! Btw. did I mention that this fltk begin()/end() stuff is evil? One could expect that Group::replace() should disconnect the new widget properly from its old parent (if there is any). But that's not the case. I wrote a mail to fltk.general about this. So in the end Main still had a reference to the panel and once it was deleted -- bang. The patch below uses Group::add() directly in FltkWidgetView::addFltkWidget() instead of FltkWidgetView::prepareCreateFltkWidget(). Does anyone remember why FltkWidgetView::prepareCreateFltkWidget() was added in the first place? Cheers, Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -83,10 +83,6 @@ FltkColor::FltkColor (int color, core::s colors[SHADING_DARK] = shadeColor (color, SHADING_DARK) << 8; colors[SHADING_LIGHT] = shadeColor (color, SHADING_LIGHT) << 8; } -} - -void FltkView::prepareCreateFltkWidget () -{ } void FltkView::addFltkWidget (::fltk::Widget *widget, diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -40,7 +40,6 @@ public: public: virtual bool usesFltkWidgets () = 0; - virtual void prepareCreateFltkWidget (); virtual void addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); virtual void removeFltkWidget (::fltk::Widget *widget); diff --git a/dw/fltkui.cc b/dw/fltkui.cc --- a/dw/fltkui.cc +++ b/dw/fltkui.cc @@ -103,7 +103,6 @@ void FltkResource::attachView (FltkView ViewAndWidget *viewAndWidget = new ViewAndWidget(); viewAndWidget->view = view; - view->prepareCreateFltkWidget (); viewAndWidget->widget = createNewWidget (&allocation); viewAndWidget->view->addFltkWidget (viewAndWidget->widget, &allocation); viewsAndWidgets->append (viewAndWidget); diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -375,17 +375,12 @@ bool FltkWidgetView::usesFltkWidgets () return true; } - -void FltkWidgetView::prepareCreateFltkWidget () -{ - begin (); -} - void FltkWidgetView::addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation) { canvasWidgets->append (new TypedPointer < ::fltk::Widget> (widget)); allocateFltkWidget (widget, allocation); + add (widget); } void FltkWidgetView::removeFltkWidget (::fltk::Widget *widget) diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -82,7 +82,6 @@ public: int x, int y, int width, int height); bool usesFltkWidgets (); - void prepareCreateFltkWidget (); void addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); void removeFltkWidget (::fltk::Widget *widget); void allocateFltkWidget (::fltk::Widget *widget,

2 1

[patch] initialize mustQueueResize in Textblock constructor
by Johannes.Hofmann＠gmx.de Dec. 5, 2007

Dec. 5, 2007

Hello, this patch initializes mustQueueResize in the Textblock constructor. Valgrind was complaining about a jump depending on uninitialized memory. Cheers, Johannes diff --git a/dw/textblock.cc b/dw/textblock.cc --- a/dw/textblock.cc +++ b/dw/textblock.cc @@ -39,6 +39,7 @@ Textblock::Textblock (bool limitTextWidt line1Offset = 0; line1OffsetEff = 0; ignoreLine1OffsetSometimes = false; + mustQueueResize = false; /* * The initial sizes of lines and words should not be

2 1

[patch] add missing style->ref ()
by Johannes.Hofmann＠gmx.de Dec. 5, 2007

Dec. 5, 2007

Hello, the tiny patch below adds a missing style->ref() which was causing a lot of crashes on my system. cheers, Johannes diff --git a/dw/fltkui.cc b/dw/fltkui.cc --- a/dw/fltkui.cc +++ b/dw/fltkui.cc @@ -159,6 +159,7 @@ void FltkResource::setStyle (core::style this->style->unref (); this->style = style; + style->ref (); for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); it.hasNext(); ) {

2 1

[patch] partial redraws - updated
by Johannes.Hofmann＠gmx.de Dec. 4, 2007

Dec. 4, 2007

Hello, this patch fixes the problem pointed out by Sebastian regarding partial redraws and scrolling interference. It adds a new Region class that is implemented similarily as in dillo1 as a set of rectangles not containing each other. The conversion from canvas to view coordinates is now done at draw-time. Regards, Johannes PS: The code did not get as complex as I initially thought it would :-)

2 5

Re: patch: a _minuscule_ amount of cleaning up the header parsing code
by jcid＠dillo.org Dec. 3, 2007

Dec. 3, 2007

On Thu, Nov 29, 2007 at 03:08:12PM +0000, place wrote: > No change in behavior is intended. > Yes, that code is getting hard to understand. After a review, I wondered why Cache_parse_header() is dealing with the message body, when it should only parse the header, and why is it getting the (buf, bufsize) pair when it has the content in entry->Header. It looks that a cleaner way would be something like: (not tested, just pseudo-code) if (!(entry->Flags & CA_GotHeader)) { while ((len = Cache_get_header(entry, buf + start, buf_size - start))) { /* Let's scan, allocate, and set things according to header info */ Cache_parse_header(entry); if (entry->Flags & CA_GotHeader) { start += len; } else // Let the flow continue downward so the remaining // of the buffer is processed } return; } and to get rid of the: dbuf = a_Decode_process(entry->TransferDecoder, dbuf); dbuf = a_Decode_process(entry->ContentDecoder, dbuf); lines inside Cache_parse_header(). Please give it a try. -- Cheers Jorge.-

1 0

Re: charset conversion issues
by jcid＠dillo.org Nov. 28, 2007

Nov. 28, 2007

Hi, On Sat, Nov 24, 2007 at 10:50:18PM +0000, place wrote: > With rough code to look at. > No sense polishing up and completing what I have yet when you'll want changes... OK. > > > Charset in the meta tag. > My options seemed to be: > - Client->Callback returns information to cache. > Probably not supposed to happen. Too big of a change. Agreed. At least to postpone until other approaches prove messier. ;-) > - Reach the meta tag and undo/redo within html.cc. > Somewhat fragile. > Whatever I might come up with, some html out there would surely find a way > to outsmart me. This is the one I like most at first sight. Considering the charset can be given by HTTP or a META element: We can assume ASCII in the html text until the HEAD element is closed. If there's a charset in the META, then the decoder can be switched from null to the specified one. This approach has the advantage of working both when the charset comes via HTTP or META (<HEAD> content is ASCII). We can even add a text buffer for the HEAD element and append it to the whole HTML content if the offset is hard to set for the new decoder. Do the problems you found apply to this scheme too? > - Bail out and start again. > This is what I have now. In fact, not knowing at all what to do, I just > call a_Nav_cancel_expect() and a_Nav_push() right then and there. > Surprisingly, it functions instead of crashing, but I'm probably spilling > resources And Violating Principles. > (And, since a_Nav_push() isn't quite right for the situation even then, > I have to fix the nav stack ptr in Nav_cleanup()) > > > There's a dialog box to set the Content-Type for a page. If you change it > to text/plain, you get source in a proper window (with searching) instead > of the little fltk window. No line numbers, though. The idea of using Dillo for view source is interesting, i'm not sure though. Maybe a fltk widget (like an stripped-down editor as the one in FLTK's test/ directory) which gets utf-8 via a_Capi_get_utf8_data(Url) is also good. > > > Not wanting to mess with TypeDet and TypeHdr until finding out what you > think, I stuck in another one, TypeSet. I'd prefer to try to apply the second method (described above). > I'm directly calling a_Cache_[sg]et_content_type() from just wherever, > which may or may not be all right. Cache should be called from Capi only, but at this stage... > I knew that latin1 != UTF-8, but I was not thinking when I wrote > that Decode code. Must've been thinking about the Unicode code numbers. > FLTK has a workaround in it to deal with fools like me who send it latin1 > or cp1252, but better that I stop being foolish :) > > > I don't have Plain or View Source set up to decode yet. I don't know whether > the cache should know about decoding charsets. Or a Text base class or > something. > > > The real-type-matches-header-type code will have to learn to relax a bit, > now that html might contain all kinds of bytes... -- Cheers Jorge.-

2 1

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)
by jcid＠dillo.org Nov. 27, 2007

Nov. 27, 2007

On Mon, Nov 26, 2007 at 07:24:34PM +0000, place wrote: > > Yes. Send me this. > > All right. Attached. Committed. > > > > > 2) Chunked Transfer-Encoding running on top of (1) because I thought it might > > > help with gzip latency. It was a can-I-get-this-working-in-principle effort > > > and I will have to rewrite it now. Plus I need to actually read through the > > > http/1.1 spec (what I did was just based on a little web page that > > > summarized the main differences between 1.0 and 1.1 for me). > > > > Hmm, yes. Please rewrite it as simple/clean as possible, and with the SPEC > > in one hand. Once there, please send it. > > > > My experience is that code written to comply with the SPEC is easier > > to debug and polish (there're plenty of cases where wrong behaviour is on > > the server side, and thus we can be sure is not dillo). > > It sounds like somebody's indeed had his share of bitter experience with > being sent hacked-together patches :) I wasn't actually threatening to send > this version; just letting you know what's going on... Yes, you're right. 8-P > > The most annoying part so far was that 1.1 is supposedly able to send > "100 Continue" before you get the real stuff. I haven't seen one actually > do it yet, though. Maybe that's only if you're doing pipelining... > > Oh, and I just read about multiline headers. It wasn't really clear whether > this was new in 1.1, though. Did 1.0 have to handle it as well? Multiline headers?! sorry, I don't remember that off the top of my head. -- Cheers Jorge.-

2 2

Implemented a weighted apportionment algorithm for table rowspan.
by jcid＠dillo.org Nov. 26, 2007

Nov. 26, 2007

On Mon, Nov 26, 2007 at 03:34:09PM +0000, place wrote: > > Everybody: please enjoy this patch, it was a lot of work! :-) > > if you find a URL where it helps, I'd appreciate some feedback. > > Hurray for better tables! Pages on the wunderground.com site fit together better > than they used to. Thanks for the feedback. (though I didn't find a "Short cell" message in the first clicks). > I currently have: > 1) I finally had the excuse to make decode into a proper filter. That is, > Dstr* as input as well as output. Yes. Send me this. > 2) Chunked Transfer-Encoding running on top of (1) because I thought it might > help with gzip latency. It was a can-I-get-this-working-in-principle effort > and I will have to rewrite it now. Plus I need to actually read through the > http/1.1 spec (what I did was just based on a little web page that > summarized the main differences between 1.0 and 1.1 for me). Hmm, yes. Please rewrite it as simple/clean as possible, and with the SPEC in one hand. Once there, please send it. My experience is that code written to comply with the SPEC is easier to debug and polish (there're plenty of cases where wrong behaviour is on the server side, and thus we can be sure is not dillo). -- Cheers Jorge.-

1 0

Implemented a weighted apportionment algorithm for table rowspan.
by jcid＠dillo.org Nov. 26, 2007

Nov. 26, 2007

Hi there, A new, weighted apportionment algorithm for table rowspans was committed. This wasn't implemented in dillo2, and the algorithm is different from the one in dillo1. This produces much better table rendering when rowspan is used (if there's no rowspan in the table, it's the same as before). You can notice the rowspan case in the Web because of a stdout message like this one: "Short cell 0, sumRows=66 ih=110" It is interesting to compare dillo2.old, dillo2.rowspan, dillo1 and firefox. You can use: http://www.dillo.org/test/rowspan.html Sebastian: I added some comments in rounding-errors.doc, explained the algorithm, including a formula. I also corrected an index in the previous section. Please check it in rounding-errors.html after re-running doxygen, or in the attached patch (already in CVS). Notes: * In the test page above, the last table in the second set shows "cellspacing" is not working. AFAIU this is not implemented and subject to another patch. * The vertical alignment of a cell content is not yet implemented in dillo2. That's why the cell content is aligned at the top instead of the middle (default, as firefox does). This is subject of another patch. * The same algorithm may be used for width apportionment. I'm not sure on this though. Sebastian: are you planning to work on this soon? If not, I can try to work on the above mentioned problems. Advice welcomed! Everybody: please enjoy this patch, it was a lot of work! :-) if you find a URL where it helps, I'd appreciate some feedback. -- Cheers Jorge.-

2 2

DPI infrastructure patches (3rd try)
by darkspirit5000＠gmail.com Nov. 26, 2007

Nov. 26, 2007

Excuse me the triple mail. I am very sorry for the problems this mail causes Hello and great work. Here i resend 2 patches related to DPI infrastructure. The first patch (dpid_services_support.diff) add the service concept to dpid (like docs sugest) so DPIs names are not related to services names asked by dillo, more than a DPI can serve a service and various DPIs can be installed to serve one service. The patch add new configuration lines in dpidrc, but can work without changes in dpidrc. (backward compatible) The lines in dpidrc have the form: service_name=ending_part_of_path_to_DPI User DPIs are preferred to system DPIs. Example: bookmarks=/bookmarks.dpi cookies=cookies/cookies.dpi downloads=downloads/downloads.dpi file=file/file.dpi ftp=ftp/ftp.filter.dpi https=https/https.filter.dpi data=datauri/datauri.filter.dpi hello=hello/hello.filter.dpi service names ending in '*' match a service asked by dillo starting with the text before the '*' and that not match other service names Example: car=car.dpi cab=cab.dpi ca*=a.dpi a.dpi is used only if dillo ask for a service that start with ca but is not car or cab To test the patch add next line to dpidrc: test=hello/hello.filter.dpi and use the url dpi:/test/ The second path (proto_services.diff) removes ad-hoc bindings for protocols DPIs in dillo. It uses services for protocols handled externaly (internal protocols: http and about; external: file, ftp, https and data). With this 2 features a protocol DPI (mms:, ed2k:, ...) can be programed without changes to dillo. The service names have the form proto.protocol_name. The lines below must be added to dpidrc and dpid need to be patched with first path (dpid_services_support.diff) so protocols works as before. (NOT backward compatible) proto.file=file/file.dpi proto.ftp=ftp/ftp.filter.dpi proto.https=https/https.filter.dpi proto.data=datauri/datauri.filter.dpi With the next line not handled protocols can return an error, a page to download new DPIs or search new protocol DPIs in dillo page using a DPI: proto.*=proto/unknown.filter.dpi This scrip mimics dillo operation #!/bin/sh # read dillo open url command read -d'>' dpip_tag echo "<dpi cmd='send_status_message' msg='ERROR: unsupported protocol' '>" I have rediscover the dpid bug (without and with pach) that ignore a DPI installed in user and system DPI_dirs at the same time. It is not solved so care about it. Diego. ----------- dpid_services_support.diff --------------------------------------------------------- diff -pru dillo2/dpid/dpid.c g/dpid/dpid.c --- dillo2/dpid/dpid.c 2007-10-14 02:09:40.000000000 +0200 +++ g/dpid/dpid.c 2007-11-24 18:19:36.000000000 +0100 @@ -23,6 +23,7 @@ #include <sys/stat.h> #include <sys/wait.h> #include <unistd.h> +#include <ctype.h> #include "dpid_common.h" #include "dpid.h" #include "dpi.h" @@ -138,6 +139,20 @@ void free_plugin_list(struct dp **dpi_at *dpi_attr_list_ptr = NULL; } +/*! Free memory used by the services list + */ +void free_services_list(Dlist *s_list) +{ + int i = 0; + struct service *s; + + for (i=0; i < dList_length(s_list) ; i++) { + s = dList_nth_data(s_list, i); + dFree(s->name); + } +// dList_free(s_list); +} + /*! \todo * Remove terminator and est_terminator unless we really want to clean up * on abnormal exit. @@ -409,6 +424,145 @@ int register_all(struct dp **attlist) return (snum); } +/* + * Compare two FileInfo pointers + * This function is used for sorting directories + */ +static int services_alpha_comp(const struct service *s1, const struct service *s2) +{ + int t; + + t=strcmp(s1->name, s2->name); + if (t>0) + return -1; + else if (t<0) + return 1; + + return 0; +} + +/*! Add services reading a dpidrc file + * each non empty or commented line has the form + * service = path_relative_to_dpidir + * \Return: + * \li Returns number of available services on success + * \li -1 on failure + */ +int fill_services_list(struct dp **attlist, int numdpis, Dlist *services_list) +{ + FILE *dpidrc_stream; + char *line = NULL; + int line_num = 0; + char *p; + char *service, *path; + int i; + struct service *s; + char *user_dpidir = NULL, *sys_dpidir = NULL, *dpidrc = NULL; + + user_dpidir = dStrconcat(dGethomedir(), "/", dotDILLO_DPI, NULL); + if (access(user_dpidir, F_OK) == -1) { + /* no dpis in user's space */ + dFree(user_dpidir); + user_dpidir = NULL; + } + dpidrc = dStrconcat(dGethomedir(), "/", dotDILLO_DPIDRC, NULL); + if (access(dpidrc, F_OK) == -1) { + dFree(dpidrc); + dpidrc = dStrdup(DPIDRC_SYS); + if (access(dpidrc, F_OK) == -1) { + dFree(dpidrc); + dpidrc = NULL; + } + } + if (!dpidrc || (sys_dpidir = get_dpi_dir(dpidrc)) == NULL) + sys_dpidir = NULL; + + if (!user_dpidir && !sys_dpidir) { + ERRMSG("fill_services_list", "Fatal error ", 0); + fprintf(stderr, "\n - Can't find the directory for dpis.\n"); + exit(1); + } + + if ((dpidrc_stream = fopen(dpidrc, "r")) == NULL) { + ERRMSG("fill_services_list", "popen failed", errno); + dFree(dpidrc); + dFree(sys_dpidir); + dFree(user_dpidir); + return (-1); + } + + /* dpidrc parser loop */ + while ((line = dGetline(dpidrc_stream)) != NULL) { + i++; + /* ignore start spaces, commented and empty lines */ + dStrstrip(line); + if (*line == '#' || *line == '\0') + continue; + + service = line; + if ((path = strchr(line, '=')) == NULL) { + printf("malformed line in %s at %d: \'=\' not found\n", dpidrc, line_num); + continue; + } + *path = '\0'; + path++; + + dStrstrip(service); + /* check that service name do not contains spaces */ + if (strchr(service, ' ') != NULL) { + printf("malformed line in %s at %d: service contains spaces\n", dpidrc, i); + continue; + } + if (strlen(service) < 2) { + printf("malformed line in %s at %d: service name too sort\n", dpidrc, i); + continue; + } + /* ignore dpi_dir silently */ + if (strcmp(service, "dpi_dir") == 0) + continue; + + dStrstrip(path); + /* process quotes */ + if (*path == '\"' || *path == '\'') { + p = strrchr(path + 1, *path); + if (p == NULL) { + printf("malformed line in %s at %d: unpaired \'%c\'\n", dpidrc, i, *path); + continue; + } else if (p[1] != '\0') { + printf("malformed line in %s at %d: garbage after \'%c\'\n", dpidrc, i, *path); + continue; + } + path++; + } + + s = dNew(struct service, 1); + /* init services list entry */ + s->name = dStrdup(service); + s->dp_index = -1; + + dList_append(services_list, s); + /* search the dpi for a service by its path */ + for (i = 0; i < numdpis; i++) + if ((p = strstr((*attlist)[i].path, path)) && *(p - 1) == '/' && + strlen(p) == strlen(path)) + break; + /* if the dpi exist bind service and dpi */ + if (i < numdpis) + s->dp_index = i; + dFree(line); + } + fclose(dpidrc_stream); + + dList_sort(services_list, (dCompareFunc)services_alpha_comp); + + dFree(dpidrc); + dFree(sys_dpidir); + dFree(user_dpidir); + + return (dList_length(services_list)); +} + + /*! Initialise the service request socket * \Return: * \li Number of sockets (1 == success) @@ -668,11 +822,13 @@ int register_all_cmd(char *sockdir) stop_active_dpis(dpi_attr_list, numdpis); rm_dpi_sockets(dpi_attr_list, numdpis); free_plugin_list(&dpi_attr_list, numdpis); + free_services_list(services_list); numdpis = 0; numsocks = 1; /* the srs socket */ FD_ZERO(&sock_set); FD_SET(srs, &sock_set); numdpis = register_all(&dpi_attr_list); + fill_services_list(&dpi_attr_list, numdpis, services_list); numsocks = init_all_dpi_sockets(dpi_attr_list, sockdir); return (numdpis); } @@ -697,6 +853,20 @@ char *get_message(int sock, char *dpi_ta return (msg); } +int service_match(const struct service *A, const char *B) +{ + int A_len, B_len, len; + + A_len = strlen(A->name); + B_len = strlen(B); + len = MAX (A_len, B_len); + + if (A->name[A_len - 1] == '*') + len = A_len - 1; + + return(dStrncasecmp(A->name, B, len)); +} + /*! * Send socket path that matches dpi_id to client */ @@ -705,12 +875,18 @@ void send_sockpath(int sock, char *dpi_t int i; char *dpi_id; char *d_cmd; + struct service *serv; dReturn_if_fail((dpi_id = get_message(sock, dpi_tag)) != NULL); - for (i = 0; i < numdpis; i++) - if (strstr(dpi_attr_list[i].id, dpi_id)) - break; + serv = dList_find_custom(services_list, dpi_id, (dCompareFunc)service_match); + + if (serv == NULL || (i = serv->dp_index) == -1) + for (i = 0; i < numdpis; i++) + if (!strncmp(dpi_attr_list[i].id, dpi_id, + dpi_attr_list[i].id - strchr(dpi_attr_list[i].id, '.'))) + break; + if (i < numdpis) { /* found */ if (access(dpi_attr_list[i].path, F_OK) == -1) { diff -pru dillo2/dpid/dpid.h g/dpid/dpid.h --- dillo2/dpid/dpid.h 2007-10-07 00:36:34.000000000 +0200 +++ g/dpid/dpid.h 2007-11-24 18:17:14.000000000 +0100 @@ -45,6 +45,13 @@ struct dp { int filter; }; +/*! bind dpi with service + */ +struct service { + char *name; + int dp_index; +}; + /*! Number of available plugins */ int numdpis; @@ -54,6 +61,9 @@ int numsocks; /*! State information for each plugin. */ struct dp *dpi_attr_list; +/*! service served for each plugin */ +Dlist *services_list; + /*! Set of sockets watched for connections */ fd_set sock_set; @@ -70,6 +80,8 @@ void free_dpi_attr(struct dp *dpi_attr); void free_plugin_list(struct dp **dpi_attr_list_ptr, int numdpis); +void free_services_list(Dlist *s_list); + enum file_type get_file_type(char *file_name); int get_dpi_attr(char *dpi_dir, char *service, struct dp *dpi_attr); @@ -78,6 +90,10 @@ int register_service(struct dp *dpi_attr int register_all(struct dp **attlist); +static int services_alpha_comp(const struct service *s1, const struct service *s2); + +int fill_services_list(struct dp **attlist, int numdpis, Dlist *services_list); + int init_srs_socket(char *sockdir); int init_dpi_socket(struct dp *dpi_attr, char *sockdir); @@ -98,6 +114,8 @@ int register_all_cmd(char *sockdir); char *get_message(int sock, char *dpi_tag); +int service_match(const struct service *A, const char *B); + void send_sockpath(int sock, char * dpi_tag, struct dp *dpi_attr_list); #endif diff -pru dillo2/dpid/main.c g/dpid/main.c --- dillo2/dpid/main.c 2007-10-07 00:36:34.000000000 +0200 +++ g/dpid/main.c 2007-11-24 18:17:14.000000000 +0100 @@ -228,6 +228,7 @@ int main(void) fd_set selected_set; dpi_attr_list = NULL; + services_list = NULL; //daemon(0,0); /* Use 0,1 for feedback */ /* todo: call setsid() ?? */ @@ -258,6 +259,11 @@ int main(void) exit(1); } + /* Init services list */ + services_list = dList_new(8); + /* And get server list */ + fill_services_list(&dpi_attr_list, numdpis, services_list); + /* Remove any sockets that may have been leftover from a crash */ cleanup(sockdir); /* Initialise sockets */ ---------- proto_services.diff ----------------------------------------- diff -pru dillo2/src/capi.c f/src/capi.c --- dillo2/src/capi.c 2007-11-17 15:18:37.000000000 +0100 +++ f/src/capi.c 2007-11-21 04:35:22.000000000 +0100 @@ -240,8 +240,12 @@ static int Capi_dpi_verify_request(Dillo static int Capi_url_uses_dpi(DilloUrl *url, char **server_ptr) { char *p, *server = NULL, *url_str = URL_STR(url); + Dstr *tmp; - if (dStrncasecmp(url_str, "dpi:/", 5) == 0) { + if ((dStrncasecmp(url_str, "http:", 5) == 0) || + (dStrncasecmp(url_str, "about:", 6) == 0)) { + /* Doing nothing returns 0 (url not uses dpi) and server = NULL */ + } else if (dStrncasecmp(url_str, "dpi:/", 5) == 0) { /* dpi prefix, get this server's name */ if ((p = strchr(url_str + 5, '/')) != NULL) { server = dStrndup(url_str + 5, (uint_t)(p - url_str - 5)); @@ -252,16 +256,11 @@ static int Capi_url_uses_dpi(DilloUrl *u dFree(server); server = dStrdup("bookmarks"); } - - } else if (dStrncasecmp(url_str, "ftp:/", 5) == 0) { - server = dStrdup("ftp"); - - } else if (dStrncasecmp(url_str, "https:/", 7) == 0) { - server = dStrdup("https"); - } else if (dStrncasecmp(url_str, "file:", 5) == 0) { - server = dStrdup("file"); - } else if (dStrncasecmp(url_str, "data:", 5) == 0) { - server = dStrdup("datauri"); + } else if ((p = strchr(url_str, ':')) != NULL) { + tmp = dStr_new("proto."); + dStr_append_l(tmp, url_str, p - url_str); + server = tmp->str; + dStr_free(tmp, 0); } return ((*server_ptr = server) ? 1 : 0);

2 1

DPI infrastructure patches (2nd try)
by darkspirit5000＠gmail.com Nov. 24, 2007

Nov. 24, 2007

Skipped content of type multipart/alternative

1 0

Re: (and the space bar) Re: horizontal scrolling
by jcid＠dillo.org Nov. 24, 2007

Nov. 24, 2007

Hi, On Fri, Nov 23, 2007 at 04:13:36PM +0000, place wrote: > Certain pages would exit when I hit space, so that list > in UI::handle() needs ' ' as well. I guess it was unhandled > and eventually found its way into the close_window_cb. > > An example of a page that would do it: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-July/000829.html > Maybe it had to do with clicking on a PRE. I don't know. Fixed in CVS (AFAIS). > PS Following the topic of that page, do you have any interest in a User-Agent > string preference in dillo? I made one for myself, but managed to become very > confused when I temporarily pretended to be firefox and google started sending > me these big, broken pages. Took me a while to remember why it was suddenly > doing this... Yes, that's the problem. I don't use User-Agent spoofing, but if somebody finds some good use for it, why not. -- Cheers Jorge.-

1 0

DPI infrastructure patches
by darkspirit5000＠gmail.com Nov. 24, 2007

Nov. 24, 2007

Skipped content of type multipart/alternative

1 0

Re: fullscreen/maximize question
by jcid＠dillo.org Nov. 21, 2007

Nov. 21, 2007

Hi there, Here's a funny thing that I'd like to make some tests on. In ui.cc:888 if you: - #if 0 + #if 1 for me, there's the following problem: > > If I start dillo as a small window, then hide the panel (using the old > > ctrl-find binding), then maximize the window, then unhide the panel with > > the same trick, I get a control panel slightly higher than what I started > > with. this happens to me with GNU/Linux and fltk2-r5975. but... On Sun, Nov 18, 2007 at 01:26:09PM +0000, place wrote: > > What FLTK2 version are you using? > > fltk-2.0.x-r5941 > > > > > If I undertood right, this doesn't happen to you. > > right. Does it happen to anyone else? -- Cheers Jorge.-

3 6

[patch] make partial redraw requests work
by Johannes.Hofmann＠gmx.de Nov. 21, 2007

Nov. 21, 2007

Hi, this patch adds set(), isEmpty(), and merge() methods to core::Rectangle. These methods are then used to maintain a rectangle that contains all screen areas for which a redraw was requested. When fltk really draws to the screen, the drawing is limited to this area. The most obvious improvement is visible on pages with very large images that take some time to load. While the image is loaded the rest of the page is no longer flickering - at least if there is no other stuff that requests complete redraws. Johannes diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -42,6 +42,7 @@ FltkViewBase::FltkViewBase (int x, int y canvasWidth = 1; canvasHeight = 1; bgColor = WHITE; + redrawArea.set (0, 0, 0, 0); } FltkViewBase::~FltkViewBase () @@ -50,9 +51,18 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { - Group::draw (); + int d = damage(); + ::fltk::Rectangle rect (x(), y(), w(), h()); - ::fltk::Rectangle rect (x(), y(), w(), h()); + //Group::draw (); + + if (d == DAMAGE_VALUE) { + ::fltk::push_clip( + translateCanvasXToViewX(redrawArea.x), + translateCanvasYToViewY(redrawArea.y), + redrawArea.width, + redrawArea.height); + } /* fltk-clipping seems not to use widget coordinates */ ::fltk::intersect_with_clip(rect); @@ -68,6 +78,12 @@ void FltkViewBase::draw () area.width = rect.w(); area.height = rect.h(); theLayout->expose (this, &area); + + if (d == DAMAGE_VALUE) { + ::fltk::pop_clip(); + } + + redrawArea.set (0, 0, 0, 0); } core::ButtonState getDwButtonState () @@ -223,9 +239,9 @@ void FltkViewBase::finishDrawing (core:: void FltkViewBase::queueDraw (core::Rectangle *area) { - /** \bug Inefficient */ + redrawArea.merge (area); - redraw (DAMAGE_EXPOSE); + redraw (DAMAGE_VALUE); } void FltkViewBase::queueDrawTotal () diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -14,6 +14,7 @@ class FltkViewBase: public FltkView, pub { private: int bgColor; + core::Rectangle redrawArea; protected: core::Layout *theLayout; diff --git a/dw/types.cc b/dw/types.cc --- a/dw/types.cc +++ b/dw/types.cc @@ -27,10 +27,7 @@ namespace core { Rectangle::Rectangle (int x, int y, int width, int height) { - this->x = x; - this->y = y; - this->width = width; - this->height = height; + set (x, y, width, height); } /** @@ -111,6 +108,35 @@ bool Rectangle::isPointWithin (int x, in x >= this->x && y >= this->y && x < this->x + width && y < this->y + height; } + +/** + * \brief Enlarge the rectangle so that it also includes otherRect. + * If a rectangle has zero size, it is ignored. + */ +void Rectangle::merge (Rectangle *otherRect) +{ + if (otherRect->isEmpty()) { + return; + } + + if (isEmpty()) { + x = otherRect->x; + y = otherRect->y; + width = otherRect->width; + height = otherRect->height; + return; + } + + width = ::misc::max(x + width, otherRect->x + otherRect->width); + height = ::misc::max(y + height, otherRect->y + otherRect->height); + + x = ::misc::min(x, otherRect->x); + y = ::misc::min(y, otherRect->y); + + width -= x; + height -= y; +} + // ---------------------------------------------------------------------- diff --git a/dw/types.hh b/dw/types.hh --- a/dw/types.hh +++ b/dw/types.hh @@ -68,9 +68,18 @@ public: inline Rectangle () { } Rectangle (int x, int y, int width, int height); + void set (int x, int y, int w, int h) { + this->x = x; + this->y = y; + this->width = w; + this->height = h; + } + bool intersectsWith (Rectangle *otherRect, Rectangle *dest); + void merge (Rectangle *otherRect); bool isSubsetOf (Rectangle *otherRect); bool isPointWithin (int x, int y); + bool isEmpty() {return width == 0 && height == 0;}; }; /**

3 8

Re: patch: images: working menu, deferred loading; page menu works
by jcid＠dillo.org Nov. 21, 2007

Nov. 21, 2007

Hi, On Mon, Oct 29, 2007 at 11:18:21PM +0000, place wrote: > (I could have sworn that I sent you a patch making the page menu work, > but since I didn't realize that it wasn't in the main tree until I > was preparing this patch, it's included here. I'll likely end > up separating it out as we go through the process of refining the rest > of this patch...) > > This has an extra argument in the link signals, as you recommended, > instead of the array of image handlers that my previous version used. > > I had to add an x_img to style. > > The link block stores the Image and the url until loading is requested. Great! I made an extensive revision of the patch and commited it with some minor changes (attached so you can review and sync more easily). Urbi et orbi, this patch set more or less is: - Added code for the image menu and hooked it to dw2 signals. - Hooked the page and link menus. - Added code for optional image loading (nice interface) very advanced! - Fixed the position of the Bug Meter popup menu. - Added an extra argument in the link signals - Aded an x_img camp to style (an image array index, like x_link). > Although there's no placeholder, if there's anything to click on, left click > loads instances of that image and middle click loads all images on the page. > The latter should probably be in the page menu instead. The patch is very advanced and here go my comments: Yes, a place holder is the next step (sometimes image size is provided as attributes in the IMG element, some others not; in which case we can use a standard size). Note that with the current patch, images that are also links are not working (i.e. clicking on them loads the image but doesn't follow the link). I understand that left-clicking to load an image is quite handy. Now, FLTK2 has a nice feature with popups and it's that they can remember a menuitem position. If we make the right click popup remember the "load image" item, the same easeness of user interface may be attained (you may look in the test/menu program inside fltk2 sources). I also agree that "load all images" naturally belongs to the page menu. BTW, with regard to the toggle button, in the past I thought of a toolbox icon with a popup holding things like: "Load images" // toggle item "Force my colors" // toggle item "Restrict width" // toggle item ... It looks lilke a good idea to me, but I don't know whether in practice this is as convenient as it looks. Comments welcomed. -- Cheers Jorge.-

3 6

Scrolling patch!
by bogus＠does.not.exist.com Nov. 21, 2007

Nov. 21, 2007

Hi there, Here's a patch I wanted to add since a long time. Remembering the scroll position in a page. At least for me, it improves web browsing a lot! The dw2 part of the patch is attached to this email, so Sebastian can look at a minor change that looks like a fix for a hidden bug in the code... The patch is complete in CVS. -- Cheers Jorge.-

4 7

Re: Cache_parse_header()
by jcid＠dillo.org Nov. 20, 2007

Nov. 20, 2007

On Mon, Nov 19, 2007 at 07:33:16PM +0000, place wrote: > for a while, I'd wondered how > > if (HdrLen < 12) { > /* Not enough info. */ > > } if (header[9] == '3' && header[10] == '0') { > > > is supposed to prevent anything -- this is just like with camp the other day -- > and now it occurs to me it's probably just missing the 'else'. Funny code, isn't it? 8-) Fixed. -- Cheers Jorge.-

1 0

patch: text search
by jcid＠dillo.org Nov. 19, 2007

Nov. 19, 2007

On Mon, Nov 19, 2007 at 07:08:38PM +0100, Johannes Hofmann wrote: > On Mon, Nov 19, 2007 at 03:01:08PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On Fri, Nov 16, 2007 at 04:22:01AM +0000, place wrote: > > > I'm not much of a drawing/gui person, but it's hard not being > > > able to search pages, so I gave it a try (attached). > > > > > > - If you hit ^Q on this window or the page source or page > > > bugs windows, dillo will crash because it assumes it's > > > closing a bw. > > > > Already fixed. > > > > > - I didn't want a title bar, and I didn't want it to be able > > > to outlive its bw, but I didn't know what to do about it. > > > > > > - If searching scrolls the window, highlighting isn't undone > > > properly. (If you search for something like "a", the last > > > instance on each line will remain highlighted) > > > > Well, my idea was to make the Find-text widget similar to what > > Firefox has (a row above the status bar that appears on request). > > With Enter bound to "search next", Shift-Enter to "search prev" > > and a few buttons/widgets for the usual "case insensitive" > > option & friends. > > > > As it was taking too much time (and I didn't find a way to do > > it either with or without Johannes patch), I decided to commit > > the patch "as is", and not to delay anymore. > > > > The above-status-bar widget solves some problems, for instance: > > > > - the dialog window covering the highlighted word. > > - dependencies (as including uicmd.hh and bw.hh from dialog) > > > > It looks like the FltkViewport is not behaving as a native FLTK > > widget and that either some ad-hoc bindings are required, or to > > make it behave as native FLTK, at least for parent Group resizes. > > > > BTW, formerly "full screen" was bound to Ctrl-F (which is the > > shortcut for find text), now it's bound to Ctrl-Space. > > Why? Because I haven't found how to detect and handle the > > double-click event, cleanly from the UI. :-) > > > > Any help is appreciatted! :) > > have you tried something like > > if (event == PUSH && event_clicks() >= 1) { > fprintf(stderr, "===> double click\n"); > } > > in UI::handle() already? Yes, lots of combinations of PUSH/RELEASE tests, return values, event_is_click(), event_clicks(), event_clicks(0)... I got confused bacause to get a RELEASE event you need to return non zero from PUSH, and then you can capture double-click from RELEASE, but that way fast clicks over Back or Forward buttons are seen as double-click. With other combinations, sometimes the event is not passed to the child widgets, etc. So I tried to cpture from PUSH alone... Finally, I thought that if after: ret = Window::handle(event); ret was zero, it was safe to make the PUSH/RELEASE dance, but, to my surprise, ret was non zero from double-click event though it wasn't handled. What I got, was a lot of ways to make it half-work. :-P but, maybe it's just me being tired. -- Cheers Jorge.-

1 0

patch: text search
by place＠gobigwest.com Nov. 19, 2007

Nov. 19, 2007

I'm not much of a drawing/gui person, but it's hard not being able to search pages, so I gave it a try (attached). - If you hit ^Q on this window or the page source or page bugs windows, dillo will crash because it assumes it's closing a bw. - I didn't want a title bar, and I didn't want it to be able to outlive its bw, but I didn't know what to do about it. - If searching scrolls the window, highlighting isn't undone properly. (If you search for something like "a", the last instance on each line will remain highlighted) *plays with it a bit more* Maybe it's good to have a title bar after all. It's easier to move out of the way than the 0.8.x one was...

3 8

[PATCH] improved image load button graphics
by onepoint＠starurchin.org Nov. 19, 2007

Nov. 19, 2007

I thought that the graphics for the image load toggle button looked rather scrappy, so I have made some new ones that I think are a little smarter. You can compare them at http://starurchin.org/dillo/img_load.html . The patch is appended here. Regards, Jeremy Henty Only in dillo2-cur/: Makefile Only in dillo2-cur/: Makefile.in Only in dillo2-cur/: aclocal.m4 Only in dillo2-cur/: autom4te.cache Only in dillo2-cur/: config.guess Only in dillo2-cur/: config.h Only in dillo2-cur/: config.log Only in dillo2-cur/: config.status Only in dillo2-cur/: config.sub Only in dillo2-cur/: configure Only in dillo2-cur/: d_size.h Only in dillo2-cur/: depcomp Only in dillo2-cur/dlib: .deps Only in dillo2-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpid: .deps Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpip: .deps Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/: install-sh Only in dillo2-cur/: missing Only in dillo2-cur/src: .deps Only in dillo2-cur/src/IO: .deps Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in diff -pru -- dillo2-ref/src/pixmaps.h dillo2-cur/src/pixmaps.h --- dillo2-ref/src/pixmaps.h 2007-11-03 09:30:39.000000000 +0000 +++ dillo2-cur/src/pixmaps.h 2007-11-18 14:49:51.000000000 +0000 @@ -1497,44 +1497,44 @@ static char * mini_ok_xpm[] = { /* XPM */ static char * imgload_on_xpm[] = { "15 15 2 1", -" c #00000000CF3C", -". c #FFFFFFFFFFFF", -" . . .........", -" . ... ..", -" . . ... ....", -" . ... .. .....", -" ..... . .. .", -"......... .. .", -".......... .", -"...............", -". ...........", -". . . .. ....", -". .. . ....", -". .. . . .....", -". . . .....", -"...............", -"..............."}; +" c #FFFFFFFFFFFF", +". c #00000000CF3C", +" ", +" ... . . .. ", +" . .. .. . . ", +" . . . . . ", +" . . . . . ", +" . . . . . ", +" ... . . .. ", +" ", +" .. . . ", +" . . .. . ", +" . . . . . ", +" . . . .. ", +" . . . . ", +" .. . . ", +" "}; /* XPM */ static char * imgload_off_xpm[] = { "15 15 2 1", -" c #CF3C00000000", -". c #FFFFFFFFFFFF", -" .. . .........", -" . .. ...", -" . . ......", -" . . . . .. ..", -" . ... .. ..", -" ........ ..", -"...............", -"...............", -"...............", -" .. . ....", -" . .. ..", -" . . .... .....", -" . . ...", -" .. ... ...", -".... .... ....."}; +" c #FFFFFFFFFFFF", +". c #CF3C00000000", +" ", +" ... . . .. ", +" . .. .. . . ", +" . . . . . ", +" . . . . . ", +" . . . . . ", +" ... . . .. ", +" ", +" .. ... ... ", +" . . . . ", +" . . ... ... ", +" . . . . ", +" . . . . ", +" .. . . ", +" "}; /* XPM */ static char *left_i_xpm[] = { Only in dillo2-cur/: stamp-h1

3 3

duplicate enter/leave notification
by place＠gobigwest.com Nov. 19, 2007

Nov. 19, 2007

If I have an xterm or something overlapping an image, when I move the pointer between the two, I get two enters or two leaves. A gdb backtrace on entry showed that Layout::enterNotify() first notifies the image by way of moveToWidgetAtPoint -> moveToWidget, and then comes back and notifies it "personally".

1 0

Re: patch: copy image/link location
by jcid＠dillo.org Nov. 18, 2007

Nov. 18, 2007

On Sun, Nov 18, 2007 at 06:46:51PM +0000, place wrote: > patch: copy image/link location Committed. -- Cheers Jorge.-

1 0

on copy and paste
by place＠gobigwest.com Nov. 18, 2007

Nov. 18, 2007

The bottom of dw/selection.cc goes: /** \todo Actual Selection is platform dependant. */ printf ("Selected text:\n"); printf ("--------------------------------------------------\n"); printf (strbuf.getChars ()); printf ("\n--------------------------------------------------\n"); Now, suppose we violate the principles of dw, sticking #include <fltk/events.h> in the top of the file, and put const char *buf = strbuf.getChars(); fltk::copy(buf, strlen(buf), false); in place of the above printf()s. Works. So if anyone knows the structure of dw well enough to know how to go about making a proper little platform-independent interface, there's nothing difficult here in principle...

2 2

[PATCH] Ctrl-R reloads
by onepoint＠starurchin.org Nov. 18, 2007

Nov. 18, 2007

This patch amkes Ctrl-R reload the page. Just like Dillo Classic! Regards, Jeremy Henty Only in dillo2-cur/: Makefile Only in dillo2-cur/: Makefile.in Only in dillo2-cur/: aclocal.m4 Only in dillo2-cur/: autom4te.cache Only in dillo2-cur/: config.guess Only in dillo2-cur/: config.h Only in dillo2-cur/: config.log Only in dillo2-cur/: config.status Only in dillo2-cur/: config.sub Only in dillo2-cur/: configure Only in dillo2-cur/: d_size.h Only in dillo2-cur/: depcomp Only in dillo2-cur/dlib: .deps Only in dillo2-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpid: .deps Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpip: .deps Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/: install-sh Only in dillo2-cur/: missing Only in dillo2-cur/src: .deps Only in dillo2-cur/src/IO: .deps Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in Only in dillo2-ref/src: html.cc.orig diff -pru -- dillo2-ref/src/ui.cc dillo2-cur/src/ui.cc --- dillo2-ref/src/ui.cc 2007-11-18 07:36:55.000000000 +0000 +++ dillo2-cur/src/ui.cc 2007-11-18 08:10:08.000000000 +0000 @@ -56,7 +56,8 @@ public: }; /* - * Disable: UpKey, DownKey, PageUpKey, PageDownKey and CTRL+{o,HomeKey,EndKey} + * Disable: UpKey, DownKey, PageUpKey, PageDownKey and + * CTRL+{o,r,HomeKey,EndKey} */ int NewInput::handle(int e) { @@ -64,7 +65,7 @@ int NewInput::handle(int e) bool ctrl = event_state(CTRL); _MSG("NewInput::handle event=%d", e); - if (ctrl && (k == 'o' || k == HomeKey || k == EndKey)) + if (ctrl && (k == 'o' || k == 'r' || k == HomeKey || k == EndKey)) return 0; if ((e == KEY || e == KEYUP) && k == UpKey || k == DownKey || k == PageUpKey || k == PageDownKey) { @@ -666,6 +667,9 @@ int UI::handle(int event) } else if (event_key() == 'q') { a_UIcmd_close_bw(user_data()); ret = 1; + } else if (event_key() == 'r') { + a_UIcmd_reload(user_data()); + ret = 1; } else if (event_key() == 's') { a_UIcmd_search_dialog(user_data()); ret = 1; Only in dillo2-cur/: stamp-h1

2 1

Re: patch: base url page menu
by jcid＠dillo.org Nov. 18, 2007

Nov. 18, 2007

On Mon, Nov 12, 2007 at 04:59:34PM +0000, place wrote: > Considering how all of the arguments are bw, do you think > the control should go html -> bw -> uicmd -> menu? The "Load images" via page menu patch was committed. I also made a big cleanup of html.hh. It was exporting data no module besides html.cc was using. With regard to your question, currently we have this dependency graph: ,-------------> menu | ^ -----> timeout | | / | v / | ui <-----> uicmd <-----> nav | ^ ^ \ | | / | \ | | / v \ v '-> html ----' bw ----> dialog ^ | form I don't like the double relation between "html" and "menu". It could be "html" calling "menu" only. For instance if we implement setting a callback function in menu's API for "Load Images". Maybe there's a better way, and I'm not sure, but a least the committed cleanup makes it look much cleaner. ;-) BTW, I also added premliminar activate/deactivate to this menu item. -- Cheers Jorge.-

2 3

Re: space bar to page
by jcid＠dillo.org Nov. 17, 2007

Nov. 17, 2007

On Tue, Nov 13, 2007 at 10:18:48PM +0000, place wrote: > I like hitting the space bar to page down. I've been carrying this code > along for a couple of weeks now, and the take_focus() hasn't caused anything > horrible to happen yet, so far as I can tell, anyway... + Added shortcuts: PgDn=Spc PgUp=b Back=BackSpace|, Forw=Shift+Backspace|. Committed. -- Cheers Jorge.-

1 0

[patch] avoid complete redraws for child widget updates
by Johannes.Hofmann＠gmx.de Nov. 17, 2007

Nov. 17, 2007

Hello, here comes a patch that avoids complete redrawing if only a child widget (button or form input) requests redrawing. I don't really like the fact, that fltk widgets are sometimes drawn via Group::draw() and sometimes via theLayout->expose(), but this is already the case without my patch, so I just leave it as it is for now. In the long run, I would propose to add a mechanism similar to fltk DAMAGE_CHILD to dw. To test go to google and type in some text. Cheers, Johannes

2 1

[PATCH]: fix occasional segfault in dw::Table::reallocChildren
by onepoint＠starurchin.org Nov. 17, 2007

Nov. 17, 2007

This patch fixes an occasional segfault when adding columns to a table that contains cells that span multiple rows or columns. This was reported to the list last month by Matthias Franz. I've been bitten by this on several web sites (see the details below), so it's a useful fix. Regards, Jeremy Henty Only in dw2-cur/: Makefile Only in dw2-cur/: Makefile.in Only in dw2-cur/: aclocal.m4 Only in dw2-cur/: autom4te.cache Only in dw2-cur/: config.guess Only in dw2-cur/: config.log Only in dw2-cur/: config.status Only in dw2-cur/: config.sub Only in dw2-cur/: configure Only in dw2-cur/: depcomp Only in dw2-cur/doc: Makefile Only in dw2-cur/doc: Makefile.in Only in dw2-cur/dw: .deps Only in dw2-cur/dw: Makefile Only in dw2-cur/dw: Makefile.in diff -pru -- dw2-ref/dw/table.cc dw2-cur/dw/table.cc --- dw2-ref/dw/table.cc 2007-10-06 23:03:01.000000000 +0100 +++ dw2-cur/dw/table.cc 2007-11-16 13:02:59.000000000 +0000 @@ -357,7 +357,7 @@ void Table::reallocChildren (int newNumC break; case Child::SPAN_SPACE: if (children->get(children->get(n)->spanSpace.startRow - * newNumCols + + * numCols + children->get(n)->spanSpace.startCol) ->cell.colspanOrig == 0) { colspan0Col = children->get(n)->spanSpace.startCol; Only in dw2-cur/: install-sh Only in dw2-cur/lout: .deps Only in dw2-cur/lout: Makefile Only in dw2-cur/lout: Makefile.in Only in dw2-cur/: missing Only in dw2-cur/test: .deps Only in dw2-cur/test: Makefile Only in dw2-cur/test: Makefile.in Analysis of the bug: A dillo table stores its children in a single vector that is the concatenation of the rows. This means that when the number of columns increases the contents of the vector must be rearranged. The code does this in place, starting at the end and working backwards. When the code reaches a point that corresponds to a multi-row/column cell, it finds a placeholder that stores the row/column of the actual cell. The important point is that the actual cell is stored in the vector *before* any placeholders that refer to it. Therefore the cell has not yet been moved when the code reaches the placeholder (because it works backwards from the end). The code must calculate the index of the actual cell from the row/column in the placeholder based on the *old* number of columns. Unfortunately the code uses the *new* number of columns, so it may retrieve a cell from the wrong place. Sometimes it retrieves a NULL and segfaults when it tries to dereference it. Test cases: <html><head></head><body><table><tbody> <tr><td colspan="2"></td></tr> <tr><td rowspan="2"></td></tr> <tr><td colspan="2"></td></tr> </tbody></table></body></html> [NB: the next one is from Matthias Franz.] <html> <table> <tr></tr> <tr><td colspan="3"></td></tr> <td colspan="3"> </table> </html> Online pages that trigger the bug: <a href="http://legacyeditorial.gettyimages.com/source/search/details_pop.aspx?iid=7…"> <a href="http://www.eweek.com/article2/0,1759,2216435,00.asp"> <a href="http://www.possible-area.org/bad_timing161107.php"> <a href="http://www.eweek.com/article2/0,1895,2216978,00.asp"> <a href="http://www.nostalgia.com/nf_moreinfo.html?sku=10576">

2 1

[patch] delete the phantom widgets
by Johannes.Hofmann＠gmx.de Nov. 15, 2007

Nov. 15, 2007

Hello, here is a patch to really delete the fltk widgets when we leave a page. I hope there are no references to the deleted widgets left, but I'm not 100% sure, so please test it carefully. Also if someone has an idea for a more elegant implementation of FltkWidgetView::removeFltkWidget(), that would be great. Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -90,6 +90,10 @@ void FltkView::prepareCreateFltkWidget ( void FltkView::addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation) +{ +} + +void FltkView::removeFltkWidget (::fltk::Widget *widget) { } diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -43,6 +43,7 @@ public: virtual void prepareCreateFltkWidget (); virtual void addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); + virtual void removeFltkWidget (::fltk::Widget *widget); virtual void allocateFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); virtual void drawFltkWidget (::fltk::Widget *widget, core::Rectangle *area); diff --git a/dw/fltkui.cc b/dw/fltkui.cc --- a/dw/fltkui.cc +++ b/dw/fltkui.cc @@ -77,6 +77,21 @@ FltkResource::~FltkResource () FltkResource::~FltkResource () { platform->detachResource (this); + for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); + it.hasNext(); ) { + ViewAndWidget *viewAndWidget = it.getNext (); + + if (viewAndWidget->widget) { + if (viewAndWidget->view) { + viewAndWidget->view->removeFltkWidget(viewAndWidget->widget); + } + if (viewAndWidget->widget->parent()) { + viewAndWidget->widget->parent()->remove(viewAndWidget->widget); + } + delete viewAndWidget->widget; + } + + } delete viewsAndWidgets; if(style) style->unref (); diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -364,6 +364,19 @@ void FltkWidgetView::addFltkWidget (::fl allocateFltkWidget (widget, allocation); } +void FltkWidgetView::removeFltkWidget (::fltk::Widget *widget) +{ + for(Iterator <TypedPointer < ::fltk::Widget> > it + = canvasWidgets->iterator (); + it.hasNext (); ) { + TypedPointer < ::fltk::Widget> *wp = it.getNext(); + + if (widget == wp->getTypedValue ()) { + canvasWidgets->remove(wp); + } + } +} + void FltkWidgetView::allocateFltkWidget (::fltk::Widget *widget, core::Allocation *allocation) { diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -83,6 +83,7 @@ public: bool usesFltkWidgets (); void prepareCreateFltkWidget (); void addFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); + void removeFltkWidget (::fltk::Widget *widget); void allocateFltkWidget (::fltk::Widget *widget, core::Allocation *allocation); void drawFltkWidget (::fltk::Widget *widget, core::Rectangle *area);

1 0

Re: Accept-Encoding: gzip
by jcid＠dillo.org Nov. 14, 2007

Nov. 14, 2007

Hi, [gzip decoder] On Mon, Nov 12, 2007 at 02:52:43PM +0000, place wrote: > Hmm, how unfortunate. It had been working just fine for me, though I took it > out yesterday so that I could have a clean tree... I wonder whether > we're constantly going to see timing problems or something, where the > people with fast machines write things that work on fast machines and > the person with a slow machine will write things that work on a slow machine. Good news! Committed. I found a workaround for the segfault and decided to commit to allow further investigation and polishing from in-CVS code. It doesn't look like a race condition, but a problem of handling redirections and the null_decoder in cache.c (redirections is a somewhat ad-hoc code, not well designed yet). Attached goes a page to reproduce the segfault (without the patch in CVS). For instance: 1- save the attached page in /tmp 2- dillo-fltk /tmp 3- click on the page 4- go back 5- go forward (segfault) // you may need to repeat this 4 and 5 BTW, the workaround is mainly: - dStr_append_l(entry->Data, buf, (int)buf_size); + /* Assert we have a Decoder. + * BUG: this is a workaround, more study and a proper design + * for handling redirects is required */ + if (entry->Decoder != NULL) { + decodedBuf = a_Decode_process(entry->Decoder, buf, buf_size); + dStr_append_l(entry->Data, decodedBuf->str, decodedBuf->len); + dStr_free(decodedBuf, 1); + } else { + dStr_append_l(entry->Data, buf, buf_size); + } With regard to: // Doesn't work. I could make TotalSize into something like BytesRemaining, // seeing whether it goes precisely to 0. I'd prefer TransferSize (this is the whole http transfer size minus the Header length --i.e. Content-Length). With regard to the iconv decoder: Please note that we may still need the original data, to be able to save verbatim. This is, if the original page is encoded in latin2 (with a <meta http-equiv charset line in the source), and it is saved translated to UTF-8 we have two problems (the misleading "meta" and that the user will get a page that's not a verbatim copy of the original). One way to solve this is to re-encode into the original charset at save time. This is not 8bit clean but could work most of the time. Another way is to keep a copy of the verbatim data. In this case we're 8bit clean and it would only take more memory when the original is not UTF-8. I *feel* 8bit clean is the correct path, and here there're lots of ways to optimize. For instance, with UTF-8 pages we don't need an extra buffer. For pages that need one, we can deallocate the UTF-8 encoded one when leaving the page (and re-create it if the page is visited again). This is just some food for thought. -- Cheers Jorge.-

3 5

Re: patch: TransferSize
by jcid＠dillo.org Nov. 14, 2007

Nov. 14, 2007

On Tue, Nov 13, 2007 at 09:07:48PM +0000, place wrote: > > I'd prefer TransferSize (this is the whole http transfer size minus the > > Header length --i.e. Content-Length). > Committed with some minor changes: s/TotalSize/ExpectedSize/g e.g.: + int ExpectedSize; /* Goal size of the HTTP transfer (0 if unknown)*/ + int TransferSize; /* Actual length of the HTTP transfer */ I also decided to remove this line: entry->Flags |= CA_GotData; entry->Flags &= ~CA_Stopped; /* it may catch up! */ - entry->TotalSize = entry->Data->len; if (entry->Decoder) { a_Decode_free(entry->Decoder); ... and now the transfer-size mismatch messages, shed more light on the redirection bug! For instance if you take the same "mm1.html" test case, going back and forward, it's clear that the image is being reloaded, but the HTTP header is not re-parsed. This is a problem with the cache_null_client. I haven't investigated it further, but this hint should be enough. -- Cheers Jorge.-

1 0

forms related segfault
by Johannes.Hofmann＠gmx.de Nov. 13, 2007

Nov. 13, 2007

Hello, when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault: Program received signal SIGSEGV, Segmentation fault. loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 93 inline Iterator iterator() { Iterator it(createIterator()); return it; } (gdb) bt #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 #1 0x08084367 in dw::core::ui::Resource::ActivateEmitter::emitActivate ( this=0x28661208, resource=0x28661200) at ui.cc:109 #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at Widget.h:125 #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at Input.cxx:1267 #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, r=@0xbfbff414) at Input.cxx:1469 #5 0x080ac66b in fltk::Input::handle (this=0x28661280, event=8) at Input.cxx:1384 #6 0x080dfac2 in fltk::Widget::send (this=0x28661280, event=8) at Widget.cxx:805 #7 0x080be6dd in fltk::handle (event=8, window=0x28540000) at run.cxx:1287 #8 0x080c4bf4 in fltk::handle () at run.cxx:1947 #9 0x080c4c38 in do_queued_events () at run.cxx:396 #10 0x080c4f52 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #11 0x080c4fed in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #12 0x080c5104 in fltk::run () at run.cxx:393 #13 0x0804e714 in main (argc=Error accessing memory address 0x0: Bad address. ) at dillo.cc:107 I think it has to do with the input form of the previous page somehow still being activ. Jorge, do you know what happens to the fltk widgets like buttons or inputs, when a new page gets loaded? Are the deleted, and if so where in the code does this happen? Cheers, Johannes

3 12

Re: is the visited_color pref somehow deprecated?
by jcid＠dillo.org Nov. 13, 2007

Nov. 13, 2007

On Sun, Nov 11, 2007 at 05:04:59PM +0000, place wrote: > dillorc2 doesn't list it, but if you have force_my_colors set and you > don't know to add visited_color to the rc, you get stuck with purple, > which is not optimal on a black background... No it's not deprecated. I tried to add the working options in dillorc2 only. Patch is welcomed! :-) -- Cheers Jorge.-

2 2

Re: image loading from menus
by jcid＠dillo.org Nov. 12, 2007

Nov. 12, 2007

On Sun, Nov 11, 2007 at 01:05:30AM +0000, place wrote: > > > The right-click menus. I am giving them the linkblock ptr via > > > a_UIcmd_*_popup so that they can call Html_load_images > > > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > > > if that's the right way to route it.) > > > > After some study and a reimplentation of plain.cc with classes > > (getting rid of its linkblock and hooking a callback for memory > > handling), it looks simpler and better. It looks like the same > > may be done with html.cc. > > Has the new html.cc made my problem go away? So far as I can tell, > things will be the same: a_UIcmd_page_popup() will need a DilloHtml*, > so uicmd.hh will include html.hh. When IO/http.c includes uicmd.hh, > it will see #include "dw/core.hh" and #include "lout/misc.hh" in html.hh, > and it will not compile. You can use a void* inside the bw structure (as with render_layout). It may end being a list in the future. For instance, if we ever implement frames, this list could contain the DilloHtml objects for each component URL, of a framed page. The design is not clear yet, but this is one way to implement it. -- Cheers Jorge.-

2 2

Re: patch: save filename/dir
by jcid＠dillo.org Nov. 11, 2007

Nov. 11, 2007

On Sat, Nov 10, 2007 at 11:09:26PM +0000, place wrote: > When I went to save a file, the suggested filename still had the > anchor suffix. Saw from my old tree that URL_PATH() was what I wanted. > Changed that. > > Since I was right there already and there was a comment about a > save dir pref, I added one to prefs.*. > Committed! -- Cheers Jorge.-

1 0

[patch] fix bug in new scrolling code
by Johannes.Hofmann＠gmx.de Nov. 10, 2007

Nov. 10, 2007

Hi, when scrolling using the down arrow key I saw occasionally screen corruptions. The patch below fixes this for me. BTW. the following little program helped me debugging this and might be useful for others with too fast machines. It hogs the CPU, so dillo redraws are much slower and easier to follow: int main(int argc, char **argv) { for (;;); } Cheers, Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -311,8 +311,11 @@ void FltkViewport::scroll (int dx, int d { int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; - int oldScrollX = scrollX; - int oldScrollY = scrollY; + /* multiple calls to scroll can happen before a redraw occurs. + * scrollDX / scrollDY can therefore be non-zero here. + */ + int oldScrollX = scrollX - scrollDX; + int oldScrollY = scrollY - scrollDY; if (dx == 0 && dy == 0) { return;

2 1

[patch] enable partial image drawing
by Johannes.Hofmann＠gmx.de Nov. 9, 2007

Nov. 9, 2007

Hi, here is a first patch to reduce redrawing in dillo-fltk. It just enables code that already existed but was commented out and allows drawing of parts of an image only. I added some additional checks. With these checks I did not see any negative effects. Cheers, Johannes diff --git a/dw/fltkimgbuf.cc b/dw/fltkimgbuf.cc --- a/dw/fltkimgbuf.cc +++ b/dw/fltkimgbuf.cc @@ -334,7 +334,19 @@ void FltkImgbuf::draw (::fltk::Widget *t // xRoot, x, yRoot, y, width, height, this->width, this->height); //{ -#if 0 +#if 1 + if (x > this->width || y > this->height) { + return; + } + + if (x + width > this->width) { + width = this->width - x; + } + + if (y + height > this->height) { + height = this->height - y; + } + // almost OK for rows. For some unknown reason it trims the bottom and // rightmost parts when scrolling. ::fltk::Rectangle rect (xRoot + x, yRoot + y, width, height);

2 1

Re: new browser windows slower than first one
by jcid＠dillo.org Nov. 9, 2007

Nov. 9, 2007

Hi, On Fri, Nov 09, 2007 at 08:59:22PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Nov 07, 2007 at 06:56:22PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Wed, Nov 07, 2007 at 09:46:25PM +0100, Johannes Hofmann wrote: > > *snip* > > > > > > The last point is more difficult to improve. For example think of a > > > long page containing just text. Every time a new chunk comes in over > > > the net, dillo creates a redraw request for the whole screen, > > > even though there is already enough text to fill the screen so > > > that the new data does not actually change the layout of the part > > > that is currently visible. > > > > > > But how can we know, whether new data changes the layout of the > > > currently visible part or not? > > > > Please excuse me if I'm naive on this subject (it's not my main > > area of expertise). > > > > I think that if the visible widgets don't change their size, > > and the just-added widgets are out of sight, we can delay the > > redraw (maybe setting a damage flag or whatever it is that works > > on the out-of-sight widgets), and not request a full redraw. > > I think we would not even need to mark them. They get redrawn > anyway when they come back in sight. Great. > I see one problem however. > Many pages just consist of one large textblock. And part of this > textblock is obviously visible while loading the page. > But with every chunk of data from the net the size of this textblock > will change and we would redraw it, even though the part of it that > is visible did not change. > I think we need a solution for this common case. Yes, it's true. > I already thought > about checking whether something changed at a word by word level, > but this feels a bit like overkill. But it could work. Let's say we keep the convas coordinate of the last line in a textblock in a state variable of the object instance. If that line is out of sight we can leave: mustQueueResize = false and be more careful about calling Textblock::flush(). > > If that approach is too complex to implement, then maybe it's > > not worth the effort. > > > > What do you think? > > Maybe. The actual redraws are done when fltk is idle otherwise. > So many redraw request are collapsed into one already. > > However redraws are much more expensive with antialiased text than > they were in dillo1, so we should at least try to reduce them. I agree, and it looks like the right thing to do. > > > The only rather simple improvement I can think of is that we could > > > use the image sizes provided in the <img/> tags and only issue a > > > Layout::queueResize() if the image proves to be of a different size. > > > Currently there is a Layout::queueResize() for every image as it > > > gets loaded. > > > > A simple way to throttle redraws is to make it in the html > > parser, and parse at let's say at 3 seconds intervals and at EOF. > > I've done that before on prototypes. > > Yes, but I actually like dillos behaviour to show incoming content > immediately in contrast to firefox and friends. Me too. ;) -- Cheers Jorge.-

1 0

some more bugs
by matthias.franz＠ujf-grenoble.fr Nov. 8, 2007

Nov. 8, 2007

Hi everybody, here are some more bugs I've discovered. (I'm sorry that testing usually leads to postings about problems ... Thanks to all who have volunteered to fix them so far!) - The tag <hr> does not produce a horizontal line, but only a small dot. - Pressing "@" anytime quits Dillo immediately. (I guess that was made on purpose during development.) - The bookmark page looks very funny. The columns for the sections and the bookmarks are much to narrow and together use only about one third of the window width. - A problem which is already present in the fltk2 program test/input: Pressing a dead key and then a letter (e.g., "^" and "o") works fine. Pressing a dead key followed by space only sometimes gives the accent (as it should) and sometimes just a space. What you get seems to be random; it changes even while the program is running. I understand that fltk2 processes dead keys on its own. For us, it would probably be easier if the keyboard was used in a "cooked" mode based on the X keyboard settings. Cheers, -- Matthias Franz

3 5

PATCH: adds the ' entity
by onepoint＠starurchin.org Nov. 7, 2007

Nov. 7, 2007

Is it dillo's policy to include *only* HTML 4.01 entities. If not, here's a patch to add the ' entity, which appears all over the place despite not being official HTML 4.01. Regards, Jeremy Henty Only in dillo2: CVS Only in dillo2-cur: Makefile Only in dillo2-cur: Makefile.in Only in dillo2-cur: aclocal.m4 Only in dillo2-cur: autom4te.cache Only in dillo2-cur: config.guess Only in dillo2-cur: config.h Only in dillo2-cur: config.log Only in dillo2-cur: config.status Only in dillo2-cur: config.sub Only in dillo2-cur: configure Only in dillo2-cur: d_size.h Only in dillo2-cur: depcomp Only in dillo2-cur/dlib: .deps Only in dillo2/dlib: CVS Only in dillo2-cur/dlib: Makefile Only in dillo2-cur/dlib: Makefile.in Only in dillo2-cur/dlib: dlib.o Only in dillo2-cur/dlib: libDlib.a Only in dillo2/doc: CVS Only in dillo2-cur/doc: Makefile Only in dillo2-cur/doc: Makefile.in Only in dillo2-cur/dpi: .deps Only in dillo2/dpi: CVS Only in dillo2-cur/dpi: Makefile Only in dillo2-cur/dpi: Makefile.in Only in dillo2-cur/dpi: bookmarks.dpi Only in dillo2-cur/dpi: bookmarks.o Only in dillo2-cur/dpi: cookies.dpi Only in dillo2-cur/dpi: cookies.o Only in dillo2-cur/dpi: datauri.filter.dpi Only in dillo2-cur/dpi: datauri.o Only in dillo2-cur/dpi: downloads.dpi Only in dillo2-cur/dpi: downloads.o Only in dillo2-cur/dpi: dpiutil.o Only in dillo2-cur/dpi: file.dpi Only in dillo2-cur/dpi: file.o Only in dillo2-cur/dpi: ftp.filter.dpi Only in dillo2-cur/dpi: ftp.o Only in dillo2-cur/dpi: hello.filter.dpi Only in dillo2-cur/dpi: hello.o Only in dillo2-cur/dpi: https.filter.dpi Only in dillo2-cur/dpi: https.o Only in dillo2-cur/dpid: .deps Only in dillo2/dpid: CVS Only in dillo2-cur/dpid: Makefile Only in dillo2-cur/dpid: Makefile.in Only in dillo2-cur/dpid: dpi.o Only in dillo2-cur/dpid: dpi_service.o Only in dillo2-cur/dpid: dpi_socket_dir.o Only in dillo2-cur/dpid: dpid Only in dillo2-cur/dpid: dpid.o Only in dillo2-cur/dpid: dpid_common.o Only in dillo2-cur/dpid: main.o Only in dillo2-cur/dpid: misc_new.o Only in dillo2-cur/dpip: .deps Only in dillo2/dpip: CVS Only in dillo2-cur/dpip: Makefile Only in dillo2-cur/dpip: Makefile.in Only in dillo2-cur/dpip: dpip.o Only in dillo2-cur/dpip: libDpip.a Only in dillo2-cur: install-sh Only in dillo2-cur: missing Only in dillo2-cur/src: .deps Only in dillo2/src: CVS Only in dillo2-cur/src/IO: .deps Only in dillo2/src/IO: CVS Only in dillo2-cur/src/IO: IO.o Only in dillo2-cur/src/IO: Makefile Only in dillo2-cur/src/IO: Makefile.in Only in dillo2-cur/src/IO: about.o Only in dillo2-cur/src/IO: dpi.o Only in dillo2-cur/src/IO: http.o Only in dillo2-cur/src/IO: iowatch.o Only in dillo2-cur/src/IO: libDiof.a Only in dillo2-cur/src/IO: mime.o Only in dillo2-cur/src/IO: proto.o Only in dillo2-cur/src: Makefile Only in dillo2-cur/src: Makefile.in Only in dillo2-cur/src: bitvec.o Only in dillo2-cur/src: bookmark.o Only in dillo2-cur/src: bw.o Only in dillo2-cur/src: cache.o Only in dillo2-cur/src: capi.o Only in dillo2-cur/src: chain.o Only in dillo2-cur/src: colors.o Only in dillo2-cur/src: cookies.o Only in dillo2-cur/src: dialog.o Only in dillo2-cur/src: dicache.o Only in dillo2-cur/src: dillo-fltk Only in dillo2-cur/src: dillo.o Only in dillo2-cur/src: dir.o Only in dillo2-cur/src: dns.o Only in dillo2-cur/src: dpiapi.o Only in dillo2-cur/src: form.o Only in dillo2-cur/src: gif.o Only in dillo2-cur/src: history.o diff -pru -- dillo2/src/html.cc dillo2-cur/src/html.cc --- dillo2/src/html.cc 2007-11-03 22:16:26.000000000 +0000 +++ dillo2-cur/src/html.cc 2007-11-04 08:44:02.000000000 +0000 @@ -814,7 +814,7 @@ typedef struct { int isocode; } Ent_t; -#define NumEnt 252 +#define NumEnt 253 static const Ent_t Entities[NumEnt] = { {"AElig",0306}, {"Aacute",0301}, {"Acirc",0302}, {"Agrave",0300}, {"Alpha",01621},{"Aring",0305}, {"Atilde",0303}, {"Auml",0304}, @@ -833,7 +833,9 @@ static const Ent_t Entities[NumEnt] = { {"Yacute",0335},{"Yuml",0570}, {"Zeta",01626}, {"aacute",0341}, {"acirc",0342}, {"acute",0264}, {"aelig",0346}, {"agrave",0340}, {"alefsym",020465},{"alpha",01661},{"amp",38}, {"and",021047}, - {"ang",021040}, {"aring",0345}, {"asymp",021110},{"atilde",0343}, + {"ang",021040}, + {"apos",39}, /* not in HTML 4.01 */ + {"aring",0345}, {"asymp",021110},{"atilde",0343}, {"auml",0344}, {"bdquo",020036},{"beta",01662}, {"brvbar",0246}, {"bull",020042},{"cap",021051}, {"ccedil",0347}, {"cedil",0270}, {"cent",0242}, {"chi",01707}, {"circ",01306}, {"clubs",023143}, Only in dillo2-cur/src: html.o Only in dillo2-cur/src: image.o Only in dillo2-cur/src: jpeg.o Only in dillo2-cur/src: klist.o Only in dillo2-cur/src: menu.o Only in dillo2-cur/src: misc.o Only in dillo2-cur/src: nav.o Only in dillo2-cur/src: plain.o Only in dillo2-cur/src: png.o Only in dillo2-cur/src: prefs.o Only in dillo2-cur/src: timeout.o Only in dillo2-cur/src: ui.o Only in dillo2-cur/src: uicmd.o Only in dillo2-cur/src: url.o Only in dillo2-cur/src: web.o Only in dillo2-cur: stamp-h1

2 3

new browser windows slower than first one
by Johannes.Hofmann＠gmx.de Nov. 7, 2007

Nov. 7, 2007

Hello, just noticed a scroll performance-related problem: When I create many browser windows (e.g. using the middle mouse button), srolling in these created windows causes more Xorg CPU usage than in the first one. Maybe, scrolling in the new windows causes redraws from the old ones? Johannes

5 13

Re: Accept-Encoding: gzip
by jcid＠dillo.org Nov. 7, 2007

Nov. 7, 2007

Hi, On Mon, Nov 05, 2007 at 10:46:09PM +0000, place wrote: > What would you think of something like the code I have attached? I'd like to have gzip decoding in dillo2. > I had looked at the gzip portion of the i18n patch, just intending to put it > in my own copy, but it was unsatisfactory in some ways, so I ended up > changing the whole thing and this was the result. It looks quite advanced and that giving it a second pass on simplicity/elegance it'd be ready. > > Bad: 1. I stuck an awful lot of things into CacheEntry_t. Yes. IMO, having only: Dstr *EncodedData; char *Encoding; added to CacheEntry_t is cleaner. (we can add a Dstr_get_size() if necessary). > 2. During the downloading/decoding process, there is Data and > DecodedData. It gets fixed up afterward, but it means that things like > trying to view source during downloading does not work. I imagine the > fix being something like changing Data to RawData, DecodedData to Data, > freeing RawData after download is complete, and looking at all of the > current references to Data to figure out which of those they should > use. But I'll leave that for after I find out what you think of what I > have so far. From a design point of view, I'd prefer the decoding functions in a separate source file, that way, new decoders may be added easily and decoding complexity gets out of the cache part (the decoding internal state moves from the Cache entry to the decoding module, and decoding functions can be reused or extended). If we think of decoding as one part in a pipeline, null-decoding is what we have now, and gzip-decoding what we'd make for gzip. That way we can keep only one path for the data stream, and null-decode or gzip-decode into 'Data' when we need it. This solves the problem of using 'Data' while decoding naturally, because it is perceived as it always was (new-bytes from a stream), the only difference being they now come pushed from a decoder instead of the net (quite transparent). > Good: 1. Faster! > > 2. Faster! Yes. I can't wait to try it under a telephone line modem next week. :-) BTW, do you plan to make the linkblock/callback patch for html.cc (analog to plain.cc) or do you prefer me to work on it? -- Cheers Jorge.-

1 0

New CVS repository and patches
by bogus＠does.not.exist.com Nov. 6, 2007

Nov. 6, 2007

Hi There! Once again, thanks for the patches and keep them flowing. The new CVS repository is up and updated with the patches: e.g. (with "-cur" terminated directories being the working directories) alias dcvs='cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo' dcvs co dillo2 dcvs co dw2 cp -r dillo2 dillo2-cur cp -r dw2 dw2-cur ln -s dw2-cur dw-testbed find dw2-cur -name CVS -exec rm \{\} \; find dillo2-cur -name CVS -exec rm \{\} \; cd dw2-cur ./autogen.sh make cd ../dillo2-cur ./autogen.sh make Here follow my comments on the patches. Please test this CVS code and send feedback: > [Johannes wrote] > * the namespace "signal" in dw-testbed/lout/signal.hh conflicts with > the declaration in /usr/include/sys/signal.h: > __sighandler_t *signal (int, __sighandler_t *); > I renamed the namespace to loutsignal. Johannes: please send me the patch for this. > [Vincent wrote (va_list issue)] > Sure, though i'm not at all sure this is the correct way to fix this > issue. Vincent: AFAIS, the problem is looping without the va_copy, so the patch is OK. Anyway, please test the CVS code and tell us how it works. > [Andreas wrote] > Ok, then I got it to compile finally for my ipaq with familar 0.8.4 on it. > I runs with X-forwarding so that I get the window on my notebook display. > But it segfaults without x forwarding: Andreas: please let us know the procedure when you have cleaned it up. > [Alexander wrote (strndup)] > Hm, right. I had used malloc() in my replacement function, but with > calloc() it is indeed unnecessary. > > I have wrapped this in autoconf, see attached patch. I also made > autoconf in dillo and dw-testbed check for the path to the perl binary > and substitute it in dpidc and Doxyfile, respectively, see other patch. > Actually, these patches can't simply be applied: first, > dillo-f15/dpid/dpidc and dw-testbed-0.0.43j/Doxyfile have to be moved > to *.in. Alexander: as strndup is a GNU extension, and we have kept the code as portable as possible, I just added the wrapper for it based on the patch. With regard to Perl, I'd like to get rid of that dependence either with bash (if possible) or C. BTW, if Sebastian agrees it may also be a good idea to use Dlib in dw2. That way those problems could be layered down... > [Johannes wrote] > here is a new version of dillo-fltk scroll performance > improvements. This patch is against vanilla dillo-fltk. > > New in this patch: > > * Hotkey bindings for arrow keys, Home- and EndKey. > This only works when the focus is on the > display area. > > * Only unclipped area is exposed which improves performance on > large pages (e.g. http://www.w3.org/TR/xslt) > > * Limit scrolling to reasonable values. It improves not only performance on large pages but also avoids overlapped rendering. Applied. > [Matthias wrote] > Fine! Only using the arrow keys is quite slow and consumes all CPU time > on my machine. In contrast, srolling with the old Dillo was quick and > produced almost no CPU load. > > A question: Would it be difficult to add mouse wheel support as well? > On my machine that does not work. (Or is thia a configuration issue > regarding FLTK?) Dillo1 didn't render antialiased text, and was heavily optimized. The optimization phase of rendering in dillo2 has just started (thanks Johannes :). I hope we can tune it to a dillo1 similar CPU-consumtion. > [Matthias wrote] > Compilation on Debian Etch worked well. I had to use the "--x-includes" > and "--x-libraries" options when configuring FLTK, and the test glpuzzle > did not compile. I'm also using Etch here and didn't need those options. I also have a running glpuzzle. The CPU, hogs when scrolling on vanilla but not with the scrolling patch, and entities work. I also don't experience CPU-hogs from the over-link-quick-switch-from arrow-to-hand test. Maybe this is related to something not installed or not configured in your machine... (This system has: x11proto-gl-dev, freeglut3, freeglut3-dev, libxft2, libxft2-dev, libgl1-mesa-{dev,dri,glx} among others that I don't know whether relevant or not! ;). BTW, I'm testing on a fast machine. It will be interesting to see what the old one produces. > [Johannes wrote] > Mouse wheel is a matter of binding. Place your mouse pointer over the > scroll bar and use the mouse wheel (it needs to be bound to the viewport). > > It is slow, because the default linesize (the amount a scrollbar > scrolls when pushing on the arrow is 1. I could change that, but > what would be a reasonable value? The height of a word in normal text (i.e. line height). We know the font and font factor from dillorc2 (or defaults). This number is a good candidate. ---------------- Side Note to all: Have you right-clicked over the search button? :-) -- Cheers Jorge.-

5 10

Crashes on OpenBSD
by Christian.Kellermann＠nefkom.net Nov. 5, 2007

Nov. 5, 2007

Skipped content of type multipart/mixed

3 8

dillo hogs during text selection
by matthias.franz＠ujf-grenoble.fr Nov. 5, 2007

Nov. 5, 2007

Hi, I have observed that dillo2 may hog during text selection. For example, take the page http://www-fourier.ujf-grenoble.fr/~franz/convex/doc/current/ . Go to some place in the table of contents, press the left mouse button and move the cursor around quickly so that the selected text changes all the time. After less a second, dillo becomes unresponsive and consumes all CPU time. This page also shows two additional issues: - There is no spacing between list items when the second item has less indentation than the first. (Look at the lines "mat - matrices" and "Types for affine ...".) - When the window size is increased, the vertical scroll bar suddenly disappears at a certain width and reappears below that width. (On my screen, this happens between 835 to 836 pixels.) In fact, the scroll bar is still there in the sense that line breaking leaves enough space for the bar. (I have reported this issue already before.) Cheers, -- Matthias Franz

1 0

Quick question about font_factor in dillorc2
by onepoint＠starurchin.org Nov. 5, 2007

Nov. 5, 2007

Just out of interest, is there any reason why the default dillorc2 sets font_factor to 1.5? It seems unreasonably large to me, and I personally much prefer to comment it out. Anyone else have feelings one way or the other? Regards, Jeremy Henty

2 3

Re: patch: hiding widgets
by jcid＠dillo.org Nov. 5, 2007

Nov. 5, 2007

On Sun, Nov 04, 2007 at 01:03:51AM +0000, place wrote: > I made this customize() pretty much a copy of the 0.8.x customize(). Commited. > In testing, I saw that playing with the panel_cb a lot makes things crashy > (that is, equally crashy with and without this code). Is that general area > of the UI permanent enough for there to be any point in taking notice of it? The idea was to test on-the-fly resizing. Hoping for FLTK2-savvy guys to come later with some advice on how its done. -- Cheers Jorge.-

1 0

Re: image loading from menus
by jcid＠dillo.org Nov. 4, 2007

Nov. 4, 2007

Hi, On Fri, Nov 02, 2007 at 02:32:49PM +0000, place wrote: > > > Now I have to send a linkblock ptr around. > > > > Where, what are you working on? > > Please give me more background. > > The right-click menus. I am giving them the linkblock ptr via > a_UIcmd_*_popup so that they can call Html_load_images > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > if that's the right way to route it.) After some study and a reimplentation of plain.cc with classes (getting rid of its linkblock and hooking a callback for memory handling), it looks simpler and better. It looks like the same may be done with html.cc. Please check out the CVS. Comments are welcomed. Although the patch is already in CVS, I'm attaching the dw2 patch text so Sebastian can review it easily when he has time. -- Cheers Jorge.-

2 2