Search results for "plugin" - Dillo-dev

Feature Request

by jcid＠dillo.org

On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote: > me at swva wrote: >> >> I think I'm being unclear, in two ways. >> >>>> Just to check, I did this as root : >>>> >>>> [root@Hbsk2 btth]# rpm -q dillo >>>> dillo-0.8.6-7.fc9.i386 >>>> [root@Hbsk2 btth]# yum update dillo >> ^^^^^^^^^^^^^^^^ >>>> Loaded plugins: refresh-packagekit >>>> updates-newkey | 2.3 kB 00:00 >>>> updates | 2.6 kB 00:00 >>>> fedora | 2.4 kB 00:00 >>>> Setting up Update Process >>>> No Packages marked for Update >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> [root@Hbsk2 btth]# >> >> On Sat, 8 Nov 2008, Johannes Hofmann wrote: >> >>> dillo-0.8.6 is no longer supported and you should consider to >>> upgrade to dillo-2.0. >>> But nevertheless for me it also works with dillo-0.8.6. >> >> For those who run other OSs, what the emphasized lines mean is the >> 0.8.6 is what Fedora has, period. (I run F9, the latest release.) Any >> idea why it's so far behind?? I didn't realize 1.0 had become official, >> let alone 2.0 >> > > That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: > > 1) No one packed FLTK 2.x, check repository there's still 1.1.9. > 2) Because of (1) no Dillo 2. > > Although Fedora is usually fresh, in case of Dillo it's still on Dillo > 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) against > Dillo and Package Review for FLTK2, but be aware that having unstable > FLTK 2.x in Fedora might be quite fight. (Believe me I am Fedora > packager.) Dillo2 doesn't need an FLTK2 package installed! It can be statically linked in. One package, that's it. (this is the default BTW). Now, if distros need to also provide source packages by policy, then that's a different story. Please clarify me because I've read that complaint a few times, and don't yet know whether it's my fault not making the statical linking clear enough to packagers, or if there's a packaging policy issue I don't know of. :) -- Cheers Jorge.-

16 years

Future of dillo2

by Johannes.Hofmann＠gmx.de

Hi Sebastian, On Sun, May 04, 2008 at 08:30:32PM +0200, Sebastian Geerken wrote: > Hi, > > just if you were courious: I'm still living and will continue working > on dillo. That's fantastic! > > On Sun, Apr 20, Jorge Arellano Cid wrote: > > [...] > > We could: > > > > * Attract new developers with a dillo2 release, > > leveraging the excellent documentation that we have. > > We have: > > - extensive documentations on the critical parts of dillo, expecially > on Dw, > - a prototype for CSS, and > - some more documents and prototypes on future ideas, including > scripting and graphical plugins. > > These should be copied on the web sever, and there should be a > prominent note on the web site linking to a new delevolers' section. > (Since attracting developers has high priority, this is what a visitor > should notice first.) > > For those not listening to dillo-dev, it is important to know that > dillo is still an active project. > > > * Planning for CSS, floating objects and TABS. > > (this are important features to a nice browsing experience) > > Just FYI: I've started a bit on floats. Jorge, I once told you that it > would take a week; actually it is a bit more complicated, nevertheless > it is not a big job like CSS. > > > * Coordinate with FLTK2, DSL (Damn small linux) and other > > lightweight distros, Debian installer team, MINIX3, etc. > > Perhaps we can find there other "lightweight zealots". :-) > > Sebastian > > P.S. I'll soon review the changes regarding redrawing and related. > When working on floats, I noticed that the redraw optimization after > resizes does not work fully correctly, there are situations where only > a explicit redraw (e.g. hide and show window) makes size changes > visible. I've seen this too but can't reproduce it consistently. Cheers, Johannes > > P.P.S. In the doxygen documentation, there are two lists, > html/bug.html and html/todo.html (generated from the \bug and \todo > tags), with open issues. Furthermore, some problems are described in > html/fltk-problems.html. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

16 years, 6 months

Re: [Dillo-dev] Another delay for 0.7.3 :(

by Jorge Arellano Cid

Hi, > On Thu, Jul 17, Jorge Arellano Cid wrote: > > I just came across this site: > > > > http://lpr.sourceforge.net/ > > > > It has some problems rendering the leftmost column. When > > downloaded at slow speeds it sometimes ends being too wide (twice > > as much as required, and sometimes less). > > I just committed a fix. Please test it, I'll also look at it again > tomorrow. > > Sebastian Today I was just preparing the details for uploading the tarball with a view to make the official announcement on Thursday (to allow for .rpm, .deb, etc be updated), when the following site showed the same bug: http://www.icewalkers.com/search.php With a dialup, it is easy to reproduce. Broadband will make it harder (you may try while downloading another file). Finally a: 'wget -kp ...' and viewing it from the local files (with the added delay of HD access also works sometimes). This adds another delay... :( The good news is that the 0.8.0-pre tarball is ready (I just finished a non-polished but functional ftp plugin, also added a hello.dpi example, and wrote a seven pages doc file Dpid.txt). As you know, I was wishing to make it available after 0.7.3, but most probably I'll have to upload this tarballs soon. Ah, with all this release overhead I haven't had the time for answering some interesting issues. I hope to have more time after the release: Johan H. : Yes, you convinced me! :), and I gave it some extra thought please be patient. I'll write back. Frank : A review of the tabs patch is still pending. Counting dillo users: I have an idea, stay tunned! "Nirvana" Focus: I have an answer from Owen Taylor. Interesting. User agent ID: I gave it a nother review (It had being brought by Damien a long time ago). As then, I digged the http specs and pondered the seccurity concerns and kept more inclined to not providing OS info. GTK+2 : It'd be very interesting to know how much overhead it adds: is it slower?, how much bigger? etc. Please note that one of the main causes for GTK+ being very slow, is GTK+ themes (but they can be avoided!). If someone has these answers, or pointer to docs. it'd be very interesting to follow the thread. Cheers Jorge.-

21 years, 3 months

non released unfinished code

by Diego .

Hello. I agree (in the general discussion) that it is a bad idea to keep closed the dillo FLTK code. (I reserve other opinions for other mail) This mail is only because i have some unfinished code for dillo and want to open/show/give to the rest of the list. I have a Dillo PlugIn that add tabs to dillo. The plug in is a GTK 1.2 app and a DPI at the same time. I do not known GTK 1.2 and do not have time to learn it. I was waiting for the FLTK dillo to program a FLTK version, but now i think that it is better to show bad programed unfinished code instead of wait. Try to run it before watch the code (based on a notebook GTK 1.2example) I hope that some GTK programer can finish it. How do it work: Now dillo can be embedded in other program. This is used by sylpheed for example. The app create a especial gtk widget get its xid and run dillo like that: $ dillo -x xid(this is a number) Then that dillo will appear in the gkt widget and not in a window. With a few changes dillo can ask the xid to a DPI when it want to open a new window. The DPI is a GTK window with a notebook widget. Each time dillo ask it for a xid the DPI adds a new tab and pass its xid to dillo and dillo appear in the tab. Instructions to test it: download the patch attached to this mail (tabs_dpi.diff) get the last dillo cvs (if asked for a password, press ENTER) $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo change to the dillo cvs directory and apply the patch $ cd dillo $ patch -p1 < ../tabs_dpi.diff generate configure, configure code and compile it $ ./autogen.sh && ./configure --disable-dlgui && make install the tabs dpi and optionaly the patched dillo # make install run the patched dillo comanding it to ask the xid and with a given size (only to see the dillo window entirely) $ dillo -x ask -g 700x500 To open a new tab use midle click on a link or the menu file->new browser To close a tab use the remove page button or the menu file->close window Excuse me my english and please test and tell what you think about this. Diego.

17 years, 7 months

patch: close windows from menubar

by jcid＠dillo.org

On Fri, Oct 10, 2008 at 04:13:01PM +0200, Johannes Hofmann wrote: > On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote: > > > On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote: > > > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > > > > > > > ... why would you want dillo1 and dillo2 at the same time. > > > > > > > > I don't know. But when you start saying "No-one could *possibly* want > > > > to do that, so let's stop supporting it" then you are riding for a > > > > fall. Why make ourselves hostages to fortune? Why not make *sure* we > > > > avoid the problem rather than gambling that we've second-guessed our > > > > entire user base? Murphy's law applies, so play it safe unless > > > > there's a compelling reason not to. > > > > > > You are adding the overhead of changing user behavior though. The claws > > > backend might be a good reason, frankly it is the only one I see so far. > > > > OK, just checked Debian and Ubuntu and both have the dillo > > viewer plugin for sylpheed with a dependency on the plain "dillo" > > package. > > > > Looking around in the FLTK docs, there's this function: > > > > CreatedWindow::set_xid() > > > > It looks promising. Unfortunately I haven't found a full > > code example to make it work. > > > > If somebody knows how to use it, it'd be simple to make a "drop > > in" replacement for dillo1, and avoid the problems discussed in > > this thread. > > I think it's supposed to work more or less like in attached test program. > When called with a (decimal) window id (from xlsclients) it draws a small > but visible frame on that window. > I don't know why it doesn't work correctly. Probabely some more > setup necessary... Dejan L. sent me this code as an example: http://www.dillo.org/test/gnash.cc ufortunately I can't get to make something that works with it. -- Cheers Jorge.-

16 years, 1 month

Re: Option to define external link handler

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > The solution with the new design would involve: > > 1) Open a "gemini:" link > 2) The request is routed to the gemini: dpi handler (like now) > 3) The gemini plugin returns the .gmi file as-is as an HTTP response, > instead of converting it to HTML > 4) The .gmi mime type matches a rewrite rule and is rewritten into HTML > in the SED node. > > Now, if we open a .gmi via HTTP: > > 1) Open a "https:" link > 2) The request is routed to the usual HTTP/IO/TLS chain > 3) The HTTP server returns the .gmi file as-is as an HTTP response. > 4) The .gmi mime type matches a rewrite rule, and is rewritten into HTML > in the SED node. > > Notice that the HTTP content can be compressed. So, for example, this > simple rewrite script: > > #!/bin/sh > sed 's_www.youtube.com_inv.vern.cc_g' > > Would only work well in the SED node *after* the HTTP content is > uncompressed and the headers removed. The rewrite rules should indicate > in which position of the chain they apply. This mechanism might suit an idea I've had to do remote downscaling of extremely large images, which are increasingly being included in web pages. The script would send a list of URLs in all <img> tags within the HTML to a remote server (eg. on a VPS), or ideally just the ones for large image files, then rewrite the URLs in the HTML to point to the remote server where the converted images are available over HTTP/S. Or a deeper approach would be to apply the same approach as this rewrite engine to binary content as well, and have Dillo do it transparently via 'rewrite'/convert rules for image MIME types. Then the HTML would stay the same and Dillo would trigger a command that requested a downscaled image from the converter server instead of the original image's server. That would be more elegant, but expands the scope of your proposed system a little. Maybe since it still requires a remote Web server this problem would be better solved via a Web proxy (I did look into Squid before, but drowned in confusing documentation). But I just thought I'd mention it as an example of a more complex usage for this proposed rewrite system.

4 months, 4 weeks

Re: [Dillo-dev]why use "ccc chain" instead of calling the function directly?

by Lei Jin

Thank you for your detail explanation. I am still confused. Would you provide an example such as the situation of the two threads doing network job(what happens when using threads and mutexes and when using CCC chain)? Maybe it will help to understand. Jorge Arellano Cid <jcid(a)dillo.org> wrote: On Sat, 3 Apr 2004, [gb2312] Lei Jin wrote: > Use "ccc chain" mechanism makes the code seeming uniform. But > it cause the source code difficult to understand because lots > of indirect function call and variety of parameters. The other way is to use threads and mutexes (much more complex and a bit slower too). > I wonder whether we can call the target function directly > instead of using "ccc chain", but I do not know if there is > difference between these two methods ??? The CCC is not just a way of making function calls, is a theory that allows for implementing non-preemptive parallelism without threads or forks. All the networking and error control in Dillo is driven by these pseudo-threads each shaped as a dynamic CCC. There can be even hundreds of them running at the same time (depending on the page, and on how many pages are loading in the background). Each thread doing network jobs can linger for a long time (generally measured in seconds, depending on latency, network load, size of the transfer, bandwidth etc) --that explains the need for a parallel approach--, now, each one of those threads needs independent error control and recovery, and it may have several steps to perform, so it also has to keep track of its state. That's the job of the CCC. It looks like contrived complexity, for sure, but that's mainly because people don't even start to realize that it handles parallelism in a single address space. This is a bit of my fault, I created the theory while working on Dillo, but I've never had the time to write it down and present it in abstract. Priorities always stood in the way. To my relief, it has worked rock solid, flexible enough to even account for plugins, and has needed low maintenance. Beleieve it or not, when things arrive to this state, the Jargon file regards them as "Deep magic". Cheers Jorge.- _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev --------------------------------- Do You Yahoo!? 惠普TT游戏剧，玩游戏，中大奖！

20 years, 7 months

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

16 years, 11 months

Re: [Dillo-dev] 0.6% of people uses Dillo (poll said)

by Diego .

I sorry the delay in the reply. I was out a week for vacation (1000Km from my home). 2007/8/29, <>: > > Hi Diego, > > On Sat, Aug 25, 2007 at 03:28:55AM +0200, Diego . wrote: > > DesktopLinux.com has published the results of its anual (desktop)linux > poll. > > The interesting thing is in the 3rd question: Which web browsers do you > > frequently use on your Linux desktop(s)? > > > > > http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=archive&id=08132… > > > > The interesting thing is that a frozen project have enough users to win > over > > 3 fully developed browsers :) (optimistic without cure) > > Yoou made more than my day with that! I rejoice for you. > Are there news about dillo development? > > Yes there're. > > It is soothing to see your optimism and hopes for Dillo. > Sometimes we think with Sebastian that releasing the code may not > make a difference after all because we currently have no time to > devote, and if people don't develop themselves, there the code > will remain. I think that a change will happend, but to un-freeze a proyect need a lot of work. I hoppe that other people will help with it. First is to communicate the un-freeze then a delay will happend until people known and other for the people to make changes(patchs). I remember that a question was made in the list about a GTK2 dillo version so it can be included in the (graphical) debian installer (as a d-i plugin i think) to read the docs. Surely a static linked FLTK version can be very attractive to d-i people. Don't read us wrong, the decision to open the code is already > made, and BTW, Sebastian did an sterling job of documenting the > internals of Dw, so once it's out there, studying time starts, > and development should follow naturally. > > I wish you or somebody else in this list could take care of > patch reviewing, web site updating and that kind of tasks. > Anyone? I want to take care of patch reviewing with the condition that other person review my patchs. Please give me some orientation or guidelines. Some details remain, and I hope before September ends, the > fltk2 version of Dillo to be online. That is a very good news! -- > Cheers > Jorge.- Diego.

17 years, 2 months

Release candidate 1

by Jorge Arellano Cid

Hi there! Finally, after a lot of work, the first release candidate tarball for dillo-0.7.0 is ready. The idea is to test this tarball and if it has no problems, the 0.7.0 release will be made of it (with only minor or cosmetical changes). Once again, I'm specially interested on non GNU/Linux platforms testing (bacause I already tested GNU/Linux). ------------------- Summary of changes: + Included the bookmarks server code inside the main tree (no separate tarball now, it all builds at once) + Added a workaround for nanosleep on Solaris in configure.in + Added a new icon for bookmarks and set ALT+B or ; as shortcuts. (there's also the option of hiding the icon from dillorc). + Made a new splash screen (contents and design). + Made a custom D_SUN_LEN definition to avoid inconsistencies with SUN_LEN, also switched memory clearing to sizeof and defined AF_LOCAL when not present. + Made ~/.dillorc/ have precedence over PATH when searching for plugins. + Added a SIGCHLD handler to avoid zombies when the dpi server is killed manually before dillo exits. + Bound find text to /. Now it works with CTRL+F or / + Added an icon for bookmarks. + Image tooltip now works with "title" instead of "alt". (had mistankenly switched to "text" before...) bm_srv12: + Made the convertion (import) from the old bookmarks format automatic. + Made it work when there's no bm.txt file present, and also when there's a zero sized bm.txt. + Fixed some Solaris compatibility glitches. + Fixed SUN_LEN issues. ------------------- The test emphasis should be on the new features. Please remember first to remove the bookmarks server binary from your ~/.dillo/ directory and killing the server if running, before testing. Now, a simple: ./configure make make install-strip should build and install everything right (it works here!) The plan is to make the official release this Sunday or early on Monday. Please send your feedback to this list. I'll be updating the site in the meanwhile, so please focus on the tarball. Last but not the least, the splash screen includes a link to the text version of an interview I gave to tux.cl magazine. The original is in spanish so I made a quick translation to english so everyone can read it. If you are knowledgeable in english grammar please read/correct it and send me the diffs. That'd be, as always, highly appreciated. Thanks a lot and I'll be expecting your feedback! Jorge.- PS: For those that read this far, here's the tarball: http://dillo.auriga.wearlab.de/dillo-0.7.0-rc1.tar.gz :-)

21 years, 9 months

Dillo-dev search results for query "plugin"