- Dillo-dev - lists.mailman3.com

[patch] partial redraws - updated

by Johannes.Hofmann＠gmx.de

On Mon, Dec 03, 2007 at 02:00:07PM -0300, Jorge Arellano Cid wrote: > On Sun, Dec 02, 2007 at 01:53:14PM +0100, Johannes Hofmann wrote: > > 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. > > Committed! Thanks. Attached is another patch that has some improvements to that code: * The case that multiple rectangles can be exactly combined to a larger one is quite likely (other than the comment in dillo1 suggests). It happens all the time, e.g. when an image is loaded piece by piece. The region code is improved to take advantage of this. * A minor bug also present in the dillo1 code is fixed: If a rectangle existing already in the region is contained in a newly added rectangle, we must not stop the loop. The new rectangle may contain other rectangles as well! * The actual drawing of a region now checks, whether a rectangle is actually visible at the moment. * The background is now cleared properly when doing a partial redraw. This fixes some screen corruption occuring when selecting / deselecting text. Cheers, Johannes > > > PS: The code did not get as complex as I initially thought > > it would :-) > > Great. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 4, 2007

[patch] partial redraws - updated

by jcid＠dillo.org

On Sun, Dec 02, 2007 at 01:53:14PM +0100, Johannes Hofmann wrote: > 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. Committed! > PS: The code did not get as complex as I initially thought > it would :-) Great. -- Cheers Jorge.-

Dec. 3, 2007

Re: patch: a _minuscule_ amount of cleaning up the header parsing code

by jcid＠dillo.org

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.-

Dec. 3, 2007

[patch] partial redraws - updated

by Johannes.Hofmann＠gmx.de

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 :-)

Dec. 2, 2007

Re: charset conversion issues

by place＠gobigwest.com

Jorge wrote: > > - 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? My original code worked a bit like this. It would set a flag to make Html_write_raw() quit early and go back up to Html_write() for re-decoding. (It would just restart from the beginning, though, and I would ignore the error messages about multiple heads and so on.) - At least the title tag has to be called again. - Maybe a future dillo that does things with javascript has already seen some and done things with it -- possibly involving literal strings -- by the time we reach meta. I don't know javascript, though, so I don't know whether that's an actual concern. I'm not quite sure what you're saying about the text buffer, though...

Nov. 28, 2007

Re: charset conversion issues

by jcid＠dillo.org

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.-

Nov. 28, 2007

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)

by jcid＠dillo.org

On Tue, Nov 27, 2007 at 12:25:13AM +0000, place wrote: > Jorge wrote: > > > 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. > > To answer my own question, the rfc says "HTTP/1.0 headers may be folded onto > multiple lines if each continuation line begins with a space or horizontal tab." > Doesn't look like Cache_parse_field() handles it, though. Must not have been > written with the spec in one hand. I've been through the SPEC lots of times... Even big browsers, like mozilla can't implement every bit of the SPECs (and they have big manpower). In dillo, there're lots of things that are not implemented, and I'm thankful of the people helping to push it forward. -- Cheers Jorge.-

Nov. 27, 2007

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)

by place＠gobigwest.com

Jorge wrote: > > 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. To answer my own question, the rfc says "HTTP/1.0 headers may be folded onto multiple lines if each continuation line begins with a space or horizontal tab." Doesn't look like Cache_parse_field() handles it, though. Must not have been written with the spec in one hand.

Nov. 27, 2007

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)

by jcid＠dillo.org

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.-

Nov. 27, 2007

Implemented a weighted apportionment algorithm for table rowspan.

by jcid＠dillo.org

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.-

Nov. 26, 2007

Implemented a weighted apportionment algorithm for table rowspan.

by jcid＠dillo.org

> > Everybody: please enjoy this patch, it was a lot of work! :-) > > if you find a URL where it helps, I'd appreciate some feedback. > > It helps on http://www.heise.de > With the patch the news start on top of the page - as they should. Great! heise.de is very popular. You made my day. > Thanks for your work on this! Most probably the major benefit will come out of the table rendering knowledge gained while working on it, but this time applied to colspanning. -- Cheers Jorge.-

Nov. 26, 2007

DPI infrastructure patches (3rd try)

by jcid＠dillo.org

Hi Diego, On Mon, Nov 26, 2007 at 01:10:28AM +0100, Diego . wrote: > Excuse me the triple mail. I am very sorry for the problems this mail causes Yesterday I skimmed the incoming patches and the two dpi emails trying to find out why you sent a second one. AFAIS they're the same email. !? Now I'm puzzled. Why a third one? If you make slight modifications to the patches, or minor bug fixes, please explain it in the email. -- Cheers Jorge.- PS: No problem if you write to me in spanish.

Nov. 26, 2007

DPI infrastructure patches (3rd try)

by darkspirit5000＠gmail.com

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);

Nov. 26, 2007

Implemented a weighted apportionment algorithm for table rowspan.

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Nov 25, 2007 at 02:28:55PM -0300, Jorge Arellano Cid wrote: > 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. It helps on http://www.heise.de With the patch the news start on top of the page - as they should. Thanks for your work on this! Johannes

Nov. 25, 2007

Implemented a weighted apportionment algorithm for table rowspan.

by jcid＠dillo.org

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.-

Nov. 25, 2007

DPI infrastructure patches (2nd try)

by darkspirit5000＠gmail.com

Skipped content of type multipart/alternative

Nov. 24, 2007

Re: (and the space bar) Re: horizontal scrolling

by jcid＠dillo.org

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.-

Nov. 24, 2007

DPI infrastructure patches

by darkspirit5000＠gmail.com

Skipped content of type multipart/alternative

Nov. 24, 2007

Re: fullscreen/maximize question

by Johannes.Hofmann＠gmx.de

On Tue, Nov 20, 2007 at 08:11:48PM +0100, Sebastian Geerken wrote: > Hi, > > On Sun, Nov 18, Johannes Hofmann wrote: > > actually I would propose to use a PackedGroup and let fltk do > > all the resizing/repositioning. I have attached a patch to dillo2 > > and dw2 that does this. It's a bit radical, so I think it needs some > > discussion before it can be applied :-) > > As an answer to this and an other mail (Johannes?): hiding scrollbars > is actually intended, if they are not used. That is, e.g. a vertical > scrollbar should be invisible, when the text is short enough, and > this saved space should be used for the text. If the latter is not > the case, this is actually a bug. Yes, the hiding of the scrollbar when it is not needed is a feature. A very useful one :-) However I think view and layout should not care about scrollbars. Attached is a patch (a proof of concept only) that * moves scrollbar creation to ui.cc * uses a PackedGroup for TopGroup and lets this PackedGroup do the layout of Panel, Main, StatusBar _and_ the scrollbars. * a reference to the scrollbars is passed to FltkViewport so that it can adjust their sizes and hide()/show() them as needed. That way view and layout only need to be able to deal with size changes whether they are caused by the user that modifies the window size, or by TopGroup that rearranges things, because a scrollbar becomes visible or gets hidden. This would make all the scrollbar handling in layout unneccessary. But as I do not completely understand the current code for scrollbars in layout, I am probabely missing something... Johannes PS: As a side effect standard fltk replace() can be used again in UI::set_render_layout().

Nov. 21, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

Ooops test program was missing in my last mail. Here it comes: #include <stdio.h> #include <fltk/Window.h> #include <fltk/Widget.h> #include <fltk/Button.h> #include <fltk/run.h> #include <fltk/draw.h> #include <fltk/damage.h> using namespace fltk; Widget *test; class Test : public Widget { public: Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, _h) {}; void draw() { Rectangle rect(x(), y(), w(), h()); intersect_with_clip(rect); fprintf(stderr, "damage 0x%x clip %d %d %d %d\n", damage(), rect.x(), rect.y(), rect.w(), rect.h()); } }; void button_cb() { test->redraw(DAMAGE_SCROLL); test->redraw(Rectangle(10, 10, 10, 10)); } int main(int argc, char **argv) { Window *window = new Window(300, 180); window->begin(); test = new Test(20, 40, 260, 100); Button *b = new Button(0, 0, 60, 30, "redraw"); b->callback((Callback*) button_cb); window->end(); window->show(argc, argv); return run(); }

Nov. 21, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

On Tue, Nov 20, 2007 at 08:11:35PM +0100, Sebastian Geerken wrote: > On Mon, Nov 19, Johannes Hofmann wrote: > > Hi Sebastian, > > > > this patch is obsolete, as fltk does all that for us: > > The void Widget::redraw(const Rectangle& r) > > method marks a rectangle for later redraw. See my followup mail > > for a much shorter patch that does the same thing. It's already in cvs. > > > > > > I will try to summarize how fltk handles redraws (as I have > > understood it so far): > > > > * Redraw requests from the program itself or from the outside > > (expose events) are accumulated by fltk and will result in a later > > call to the draw() methods of the various widgets. Information > > about what is to be drawn is passed via a bitmap that can be > > accessed using Widget::damage() and via the current clipping > > region. > > > > * A program can require redraws using > > void Widget::redraw(const Rectangle& r). In this case fltk > > ensures, that r will not be clipped during a subsequent draw(). > > > > * A program can require redraws using > > void Widget::redraw(uchar c). In this case fltk > > ensures, that at least the bits that are on in c will be turned on > > in the damage() bitmap during a subsequent draw(). > > This is actually a bit more complicated, as I remember. Indeed. fltk2 tries to be smarter here than fltk1 was. Not sure yet whether this is good or bad. The attached test program shows how in fltk2 a redraw(<flag>) and a redraw(<rectangle>) results in two separate drawing operations with different damage flags and clip rectangles set. > A widget > redraw is referred in canvas coordinates, but FLTK referres to > viewport coordinates. I once described this in a mail (unfortunately > not in the code), which I cannot find now, so here again an example: > > 1. A widget requests a redraw for the canvas region > (100, 100, 100 x 100) [x, y, w x h]. If the viewport position > is at (50, 50), this is translated to (50, 50, 100 x 100). > > Notice, that the drawing is not done immediately at this time. > > 2. The viewport is scrolled to (50, 100) (i.e. scrolled down 50px). > > 3. Now, the idle function is activated, and draws the region > (50, 50, 100 x 100). This is, since the viewport position has > changed, the canvas region (100, 150, 100 x 100). This means, > that the upper half of the originally requestet *canvas* > region is not drawn (it has been scrolled out of the original > viewport region, so to speak). > > So, Dw (or the FLTK part of Dw) has to do some work on its own. See > Dw_gtk_viewport_queue_draw in dw_gtk_viewport.c (old code) for > details. Do you think this is worth the effort? Why not just do a complete redraw whenever a partial redraw request and a scroll movement collide and must be dealt with within a single draw operation? Alternatively we could store the region that needs redraw separately in canvas coordinates and do the translation to viewport coordinates at draw time. No problem, but more complex code. Johannes > > I'm not currently aware of all implications of it, I'll have to take > another deeper look at the old code. > > Sebastian > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 21, 2007

Re: patch: images: working menu, deferred loading; page menu works

by place＠gobigwest.com

Jorge wrote: > 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). I made an image placeholder in place of a placeholder image... I'm not sure whether I offer this in jest or in earnest, but it's simple, anyway. And suffices for me.

Nov. 21, 2007

Scrolling patch!

by jcid＠dillo.org

Hi, On Wed, Oct 24, 2007 at 05:27:42PM -0300, Jorge Arellano Cid wrote: > On Mon, Oct 22, 2007 at 07:12:28PM -0300, Jorge Arellano Cid wrote: > > Hi > > > > I see this in two parts: > > > > 1.- Remembering the scroll position in each bw's nav_stack > > 2.- Making fragments push a new page (and not just jump like now). > > > > Number 1.- is cooking here... :-) > > Number 1.- is commited! Number 2.- is committed! -- Cheers Jorge.-

Nov. 21, 2007

[patch] make partial redraw requests work

by sgeerken＠dillo.org

On Mon, Nov 19, Johannes Hofmann wrote: > Hi Sebastian, > > this patch is obsolete, as fltk does all that for us: > The void Widget::redraw(const Rectangle& r) > method marks a rectangle for later redraw. See my followup mail > for a much shorter patch that does the same thing. It's already in cvs. > > > I will try to summarize how fltk handles redraws (as I have > understood it so far): > > * Redraw requests from the program itself or from the outside > (expose events) are accumulated by fltk and will result in a later > call to the draw() methods of the various widgets. Information > about what is to be drawn is passed via a bitmap that can be > accessed using Widget::damage() and via the current clipping > region. > > * A program can require redraws using > void Widget::redraw(const Rectangle& r). In this case fltk > ensures, that r will not be clipped during a subsequent draw(). > > * A program can require redraws using > void Widget::redraw(uchar c). In this case fltk > ensures, that at least the bits that are on in c will be turned on > in the damage() bitmap during a subsequent draw(). This is actually a bit more complicated, as I remember. A widget redraw is referred in canvas coordinates, but FLTK referres to viewport coordinates. I once described this in a mail (unfortunately not in the code), which I cannot find now, so here again an example: 1. A widget requests a redraw for the canvas region (100, 100, 100 x 100) [x, y, w x h]. If the viewport position is at (50, 50), this is translated to (50, 50, 100 x 100). Notice, that the drawing is not done immediately at this time. 2. The viewport is scrolled to (50, 100) (i.e. scrolled down 50px). 3. Now, the idle function is activated, and draws the region (50, 50, 100 x 100). This is, since the viewport position has changed, the canvas region (100, 150, 100 x 100). This means, that the upper half of the originally requestet *canvas* region is not drawn (it has been scrolled out of the original viewport region, so to speak). So, Dw (or the FLTK part of Dw) has to do some work on its own. See Dw_gtk_viewport_queue_draw in dw_gtk_viewport.c (old code) for details. I'm not currently aware of all implications of it, I'll have to take another deeper look at the old code. Sebastian

Nov. 20, 2007

Re: fullscreen/maximize question

by sgeerken＠dillo.org

Hi, On Sun, Nov 18, Johannes Hofmann wrote: > actually I would propose to use a PackedGroup and let fltk do > all the resizing/repositioning. I have attached a patch to dillo2 > and dw2 that does this. It's a bit radical, so I think it needs some > discussion before it can be applied :-) As an answer to this and an other mail (Johannes?): hiding scrollbars is actually intended, if they are not used. That is, e.g. a vertical scrollbar should be invisible, when the text is short enough, and this saved space should be used for the text. If the latter is not the case, this is actually a bug. (More on this later.) Sebastian

Nov. 20, 2007

Re: Cache_parse_header()

by jcid＠dillo.org

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.-

Nov. 20, 2007

patch: text search

by jcid＠dillo.org

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.-

Nov. 19, 2007

patch: text search

by jcid＠dillo.org

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! :) -- Cheers Jorge.-

Nov. 19, 2007

[PATCH] improved image load button graphics

by jcid＠dillo.org

On Mon, Nov 19, 2007 at 08:31:08AM +0000, Jeremy Henty wrote: > On Sun, Nov 18, 2007 at 05:39:33PM +0000, place wrote: > > Jeremy wrote: > > > 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. > > > > Good, I was hoping that somebody would fix the ugly thing that I drew :) > > I glad to see my criticism was taken in good spirit. Mind you, Jorge > hasn't committed it yet, maybe he prefers it ugly? :) Committed. -- Cheers Jorge.-

Nov. 19, 2007

Re: fullscreen/maximize question

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Nov 18, 2007 at 11:37:45PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sun, Nov 18, 2007 at 10:50:59PM +0100, Johannes Hofmann wrote: > > Hi, > > > > actually I would propose to use a PackedGroup and let fltk do > > all the resizing/repositioning. I have attached a patch to dillo2 > > and dw2 that does this. It's a bit radical, so I think it needs some > > discussion before it can be applied :-) > > For me this is very good. I remember long ago coding the UI with > a less predictable FLTK2; once a way for it to work as desired was > found, that was it. > > If a simpler approach works today, great. > > It even solves some problems where current scrollbars don't appear. > If Sebastian agrees on having them this way, great (maybe there's a need > of finer control though, I don't know). The problem might be that the scrollbars are currently children of TopGroup and not of FltkViewport. They are created in the FltkViewport constructor but never added to the FltkViewport widget. Instead they get added to TopGroup (accidentally?) because of TopGroup->begin() in void set_render_layout_begin(). Is this intended? If yes, they would need to be replaced too. I really prefer direct calls to add() instead of this begin()/end() stuff. It makes things much clearer. Cheers, Johannes > > Sebastian? > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 19, 2007

[patch] make partial redraw requests work

by Johannes.Hofmann＠gmx.de

Hi Sebastian, this patch is obsolete, as fltk does all that for us: The void Widget::redraw(const Rectangle& r) method marks a rectangle for later redraw. See my followup mail for a much shorter patch that does the same thing. It's already in cvs. I will try to summarize how fltk handles redraws (as I have understood it so far): * Redraw requests from the program itself or from the outside (expose events) are accumulated by fltk and will result in a later call to the draw() methods of the various widgets. Information about what is to be drawn is passed via a bitmap that can be accessed using Widget::damage() and via the current clipping region. * A program can require redraws using void Widget::redraw(const Rectangle& r). In this case fltk ensures, that r will not be clipped during a subsequent draw(). * A program can require redraws using void Widget::redraw(uchar c). In this case fltk ensures, that at least the bits that are on in c will be turned on in the damage() bitmap during a subsequent draw(). This pretty simple mechanism is used by fltk code itself to avoid unnecessary redraws. Here are some examples: * The void Group::draw_child(Widget& w) method looks at the current clip region and returns immediately if w is clipped. * If a widget notices that it needs redrawing (e.g. a button that has been pushed) it will set a flag in its own damage() bitmap and then call redraw(DAMAGE_CHILD). If then at drawing time just the DAMAGE_CHILD bit is on in the global damage() bitmap, Group calls the draw() methods of all those child widgets that have indicated that they need a redraw in their on damage() bitmap. All other widgets will not redraw. * ScrollGroup uses the DAMAGE_SCROLL bit in damage() to indicate that a redraw is necessary because of a scroll movement. If this is the only bit in damage() at drawing time, an optimized aproach is used for redrawing: The part of the screen that was already visible before the scroll movement will be copied to the new position and only the rest is actually redrawn. Some of these methods are already used in the current cvs-version of dw2: * void FltkViewBase::draw () only calls theLayout->expose () for the not clipped area. * If just DAMAGE_CHILD is on in damage(), FltkViewBase::draw () lets Group::draw() draw those child widgets that have requested a redraw. * void FltkViewBase::queueDraw (core::Rectangle *area) uses void Widget::redraw(const Rectangle& r) to request redrawing only for a specific area. * void FltkViewport::draw () uses the same mechanism as ScrollGroup to optimize redraws that are necessary because of scroll movements. Cheers, Johannes On Sun, Nov 18, 2007 at 09:22:43PM +0100, Sebastian Geerken wrote: > Hi Johannes, > > I'm glad that someone is dealing with this problem. I'll write more > about it, here just some first remarks, after only taking a glance at > this and other patches. > > On Fri, Nov 09, Johannes Hofmann wrote: > > 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. > > You may take a look at the old implementation (gtk-based, somewhere > in dw_viewport.c), combining the areas of different redraw requests > is already implemented there. Perhaps it is better to adopt the old > code, which has been working for a while. > > Some notes on the general problem. There are several cases when areas > are to be redrawn, I hope this list is complete: > > 1. to react on expose events, > 2. if a widget redraws itself, and > 3. when scrolling. > > Regarding the problem, how to restrict drawing to a minimum, case 1 > is probably neglectable, since the number of expose events is > mostly rather small (only when moving windows, changing there order > etc.). It seems that the following code: > > > + ::fltk::Rectangle rect (x(), y(), w(), h()); > > + if (d == DAMAGE_VALUE) { > > may be used to distinguish it from the critical cases 2 and 3. For > case 1, still the whole viewport is drawn, optimization should be > secondary. > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 19, 2007

[PATCH] improved image load button graphics

by onepoint＠starurchin.org

On Sun, Nov 18, 2007 at 05:39:33PM +0000, place wrote: > Jeremy wrote: > > 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. > > Good, I was hoping that somebody would fix the ugly thing that I drew :) I glad to see my criticism was taken in good spirit. Mind you, Jorge hasn't committed it yet, maybe he prefers it ugly? :) Jeremy Henty

Nov. 19, 2007

duplicate enter/leave notification

by place＠gobigwest.com

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".

Nov. 19, 2007

Re: fullscreen/maximize question

by jcid＠dillo.org

Hi, On Sun, Nov 18, 2007 at 10:50:59PM +0100, Johannes Hofmann wrote: > Hi, > > actually I would propose to use a PackedGroup and let fltk do > all the resizing/repositioning. I have attached a patch to dillo2 > and dw2 that does this. It's a bit radical, so I think it needs some > discussion before it can be applied :-) For me this is very good. I remember long ago coding the UI with a less predictable FLTK2; once a way for it to work as desired was found, that was it. If a simpler approach works today, great. It even solves some problems where current scrollbars don't appear. If Sebastian agrees on having them this way, great (maybe there's a need of finer control though, I don't know). Sebastian? -- Cheers Jorge.-

Nov. 19, 2007

Re: fullscreen/maximize question

by Johannes.Hofmann＠gmx.de

Hi, actually I would propose to use a PackedGroup and let fltk do all the resizing/repositioning. I have attached a patch to dillo2 and dw2 that does this. It's a bit radical, so I think it needs some discussion before it can be applied :-) Cheers, Johannes On Sun, Nov 18, 2007 at 02:11:27PM -0300, Jorge Arellano Cid wrote: > 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.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 18, 2007

[patch] make partial redraw requests work

by sgeerken＠dillo.org

Hi Johannes, I'm glad that someone is dealing with this problem. I'll write more about it, here just some first remarks, after only taking a glance at this and other patches. On Fri, Nov 09, Johannes Hofmann wrote: > 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. You may take a look at the old implementation (gtk-based, somewhere in dw_viewport.c), combining the areas of different redraw requests is already implemented there. Perhaps it is better to adopt the old code, which has been working for a while. Some notes on the general problem. There are several cases when areas are to be redrawn, I hope this list is complete: 1. to react on expose events, 2. if a widget redraws itself, and 3. when scrolling. Regarding the problem, how to restrict drawing to a minimum, case 1 is probably neglectable, since the number of expose events is mostly rather small (only when moving windows, changing there order etc.). It seems that the following code: > + ::fltk::Rectangle rect (x(), y(), w(), h()); > + if (d == DAMAGE_VALUE) { may be used to distinguish it from the critical cases 2 and 3. For case 1, still the whole viewport is drawn, optimization should be secondary. Sebastian

Nov. 18, 2007

Re: patch: copy image/link location

by jcid＠dillo.org

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

Nov. 18, 2007

Re: fullscreen/maximize question

by Johannes.Hofmann＠gmx.de

On Sun, Nov 18, 2007 at 02:11:27PM -0300, Jorge Arellano Cid wrote: > 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? Yes, I'm seeing this too. Did not know about this old ctrl-find binding until now. Nice, I really like the fullscreen mode. Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 18, 2007

on copy and paste

by place＠gobigwest.com

Sebastian wrote: > Well, a clean solution is rather simple: this is exactly, what > dw::core::Platform is for. A patch is attached below (also > in CVS). Oh, the solution was right under my nose all along and I didn't notice it... I should stop fixing things myself and just make requests on the list :)

Nov. 18, 2007

[PATCH] improved image load button graphics

by place＠gobigwest.com

Jeremy wrote: > 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. Good, I was hoping that somebody would fix the ugly thing that I drew :)

Nov. 18, 2007

on copy and paste

by sgeerken＠dillo.org

To start with a simple one ... On Sun, Nov 18, place wrote: > 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.. Well, a clean solution is rather simple: this is exactly, what dw::core::Platform is for. A patch is attached below (also in CVS). Sebastian ---------- Index: dw/fltkplatform.cc =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/fltkplatform.cc,v retrieving revision 1.2 diff -u -r1.2 fltkplatform.cc --- dw/fltkplatform.cc 17 Nov 2007 16:15:13 -0000 1.2 +++ dw/fltkplatform.cc 18 Nov 2007 17:16:51 -0000 @@ -24,6 +24,7 @@ #include <fltk/draw.h> #include <fltk/run.h> +#include <fltk/events.h> #include <stdio.h> namespace dw { @@ -379,6 +380,10 @@ return new FltkColor(color, core::style::Color::TYPE_SHADED); } +void FltkPlatform::copySelection(const char *text) +{ + fltk::copy(text, strlen(text), false); +} core::Imgbuf *FltkPlatform::createImgbuf (core::Imgbuf::Type type, int width, int height) Index: dw/fltkplatform.hh =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/fltkplatform.hh,v retrieving revision 1.2 diff -u -r1.2 fltkplatform.hh --- dw/fltkplatform.hh 17 Nov 2007 16:15:13 -0000 1.2 +++ dw/fltkplatform.hh 18 Nov 2007 17:16:52 -0000 @@ -157,6 +157,8 @@ core::Imgbuf *createImgbuf (core::Imgbuf::Type type, int width, int height); + void copySelection(const char *text); + core::ui::ResourceFactory *getResourceFactory (); void attachResource (ui::FltkResource *resource); Index: dw/layout.cc =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/layout.cc,v retrieving revision 1.4 diff -u -r1.4 layout.cc --- dw/layout.cc 13 Nov 2007 13:57:32 -0000 1.4 +++ dw/layout.cc 18 Nov 2007 17:16:52 -0000 @@ -101,6 +101,8 @@ DBG_OBJ_ASSOC (&selection, this); platform->setLayout (this); + + selectionState.setLayout(this); } Layout::~Layout () Index: dw/layout.hh =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/layout.hh,v retrieving revision 1.2 diff -u -r1.2 layout.hh --- dw/layout.hh 19 Oct 2007 22:10:13 -0000 1.2 +++ dw/layout.hh 18 Nov 2007 17:16:52 -0000 @@ -223,6 +223,11 @@ return platform->createImgbuf (type, width, height); } + inline void copySelection(const char *text) + { + platform->copySelection(text); + } + inline ui::ResourceFactory *getResourceFactory () { return platform->getResourceFactory (); Index: dw/platform.hh =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/platform.hh,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 platform.hh --- dw/platform.hh 6 Oct 2007 22:03:01 -0000 1.1.1.1 +++ dw/platform.hh 18 Nov 2007 17:16:52 -0000 @@ -188,6 +188,11 @@ virtual Imgbuf *createImgbuf (Imgbuf::Type type, int width, int height) = 0; /** + * \brief Copy selected text (0-terminated). + */ + virtual void copySelection(const char *text) = 0; + + /** * ... */ virtual ui::ResourceFactory *getResourceFactory () = 0; Index: dw/selection.cc =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/selection.cc,v retrieving revision 1.3 diff -u -r1.3 selection.cc --- dw/selection.cc 1 Nov 2007 15:00:04 -0000 1.3 +++ dw/selection.cc 18 Nov 2007 17:16:52 -0000 @@ -44,6 +44,8 @@ SelectionState::SelectionState () { + layout = NULL; + selectionState = NONE; from = NULL; to = NULL; @@ -493,12 +495,7 @@ delete i; } - /** \todo Actual Selection is platform dependant. */ - - printf ("Selected text:\n"); - printf ("--------------------------------------------------\n"); - printf (strbuf.getChars ()); - printf ("\n--------------------------------------------------\n"); + layout->copySelection(strbuf.getChars()); } } Index: dw/selection.hh =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/selection.hh,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 selection.hh --- dw/selection.hh 6 Oct 2007 22:03:01 -0000 1.1.1.1 +++ dw/selection.hh 18 Nov 2007 17:16:52 -0000 @@ -209,6 +209,8 @@ DoubleClickEmitter doubleClickEmitter; + Layout *layout; + // selection enum { NONE, @@ -248,6 +250,7 @@ SelectionState (); ~SelectionState (); + inline void setLayout (Layout *layout) { this->layout = layout; } void reset (); inline void connectDoubleClick (DoubleClickReceiver *receiver) { doubleClickEmitter.connectDoubleClick (receiver); }

Nov. 18, 2007

[PATCH] improved image load button graphics

by onepoint＠starurchin.org

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

Nov. 18, 2007

Re: fullscreen/maximize question

by jcid＠dillo.org

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.-

Nov. 18, 2007

[PATCH] Ctrl-R reloads

by jcid＠dillo.org

On Sun, Nov 18, 2007 at 08:53:30AM +0000, Jeremy Henty wrote: > > This patch amkes Ctrl-R reload the page. Just like Dillo Classic! Committed. -- Cheers Jorge.-

Nov. 18, 2007

on copy and paste

by place＠gobigwest.com

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...

Nov. 18, 2007

[PATCH] Ctrl-R reloads

by onepoint＠starurchin.org

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

Nov. 18, 2007

Re: patch: base url page menu

by place＠gobigwest.com

Jorge wrote: > 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". I'm wondering whether the image list should live in the bw or something. Now that we keep a list of images around, reload should be able to do a proper full reload...

Nov. 18, 2007

Re: space bar to page

by jcid＠dillo.org

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.-

Nov. 17, 2007

patch: text search

by jcid＠dillo.org

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). Good, I'm giving it a review. > - 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. Fixed in CVS. Funny how Ctrl+n from a search window produced a small dialog-sized 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... Checking patch now... -- Cheers Jorge.-

Nov. 17, 2007

Re: patch: base url page menu

by jcid＠dillo.org

On Wed, Nov 14, 2007 at 11:18:17PM +0000, place wrote: > Jorge wrote: > > The "Load images" via page menu patch was committed. > > Are you seeing the menus popping up with the load images option > under the pointer? What I get looks suspiciously like the previous > option clicked plus the height of the control panel. > *resizes control panel* > Yes, _very_ suspiciously. I'm experiencing the same as you. With the offset being exactly the panel height. No problem at all when the whole panel is hidden. It's possible to workaround by adding an offset inside the a_Menu_*_popup functions, but probably the proper solution is to get the event in window coordinates instead of viewport-based ones. AFAIU the popup offset is OK with pure-fltk2 widgets, so maybe there's a problem in how FLTK2 perceives the viewport or the panel... I haven't investigated further along these lines though... -- Cheers Jorge.-

Nov. 17, 2007