Search results for "plugin" - Dillo-dev

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

May 6, 2008

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

Oct. 10, 2008

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.

June 19, 2024

--xid option

by Johannes.Hofmann＠gmx.de

On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > > used to embed dillo into the claws mailer. > > > > > The right way to do this would probabely be to implement the > > > > > complete XEMBED protocol which is also mentioned in > > > > > doc/fltk-problems.doc. > > > > > However a simple XReparentWindow() seems to work more or less here. > > > > > Please test. > > > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > > e.g. hg add xembed.hh xembed.cc > > > > > > Oh yes. Should be fixed now. > > > Btw. I managed to install the claws mail client including the dillo > > > plugin and it seems to work fine now with dillo2. That's why I just > > > committed the xembed stuff. > > > > This is very good. > > > > I'll have to dig for the sylpheed contact to let them know. > > Does anybody here know the email? > > I already contacted them on irc (#claws on freenode). > It would be good if this get's some testing as there seems to be > some interaction with the WM in use. I now tested it successful > on dwm, twm, and fvwm. > Also there are probabely more elegant ways to do it, but > for now I think it's better than nothing. More testing showed that the current implementation has severe problems. The thing is that the window manager that I use (dwm) is one of the few non-reparenting WMs. Most others reparent new windows and that can create races with the reparentin we do. There also seems to be a problem with keyboard events in that case. Is there anyone on the list with in-depth X11 knowledge who could help with the xembed stuff? Cheers, Johannes > > Cheers, > Johannes

May 26, 2009

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

FreeHG performance

by dillo-dev＠toykeeper.net

* Jeremy Henty <onepoint(a)starurchin.org> wrote: > Looks good, but I think Dillo would have to migrate > away from Mercurial to use it. After using hg for the past couple years and bzr for about a year, I've found bzr to be an upgrade. I still use both on a regular basis, but no longer choose hg for any new projects. The main differences to be aware of are: - Branches are directories instead of labels. Each directory has only one "head", and you switch between branches with "cd". Merging is done like "cd trunk ; bzr merge ../my-bugfix". - There are a lot of plugins available to extend functionality in various ways. A couple I recommend are bzr-gtk ("bzr vis" is a nice way to browse history) and bzr-bisect (helps isolate where bugs were introduced). - It has a concept of a main line of development, and meaningful version numbers. Merges are always explicit, even when hg would merge in-line. This makes feature branches more useful. That last one probably requires a little more explanation. Say you branch from trunk at r100 to add a feature. It requires some major changes, so you break everything while refactoring and spend a few revisions getting it all working again. It takes 10 revisions total. So, you send the changes upstream. They like it. They merge it... And nobody else checked anything in while you were working. Now (in hg) trunk is at r110, with your new feature. And the revision graph ends up being a straight line, so there's no evidence a merge occurred. If anyone tries to use r101 through r109, they'll find that it's all broken. The way bzr handles it is you submit 10 revisions, and when merged, trunk bumps up to r101. The revision graph shows a branch off to the side with 10 changes (r100.1.1 through r100.1.10) and a merge at the end (r101), and the trunk contains only non-broken versions. It makes more sense to me. > They use bzr, and although they integrate with some other > VCSs, mercurial isn't one of them. It's a one-time conversion, instead of the two-way conduit they support for subversion. I tried it just now (using bzr-fastimport) and it worked. The new branch is in my "junk" folder (launchpad equivalent of /tmp/) if anyone wants to try it: bzr branch lp:~toykeeper/+junk/dillo Personally, the main thing I find annoying about bzr is that it's not the easiest thing to type. I use "alias b=bzr" in my shell to fix that. -- Scott

Feb. 5, 2009

Feature Request

by akemnade＠tzi.de

On Sun, 9 Nov 2008 09:38:11 +0100 Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Sat, Nov 08, 2008 at 04:40:01PM -0500, 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 > > > >> If you enter "google.com" in the location bar and hit return > >> it doesn't go to google? > > > > It does indeed. I'm putting this badly. > > > > I run Alpine 2.0; it is set to launch the default browser, which is > > dillo -- and URLs in emails are what I use a default browser for. > > > > Does this mean something in my Alpine settings (and my Pine 4.64 > > settings, which it took over) is wrong? My Fedora default browser setting > > is simply "dillo %s"; my Alpine setting is something I'll have to dig > > for, as it's buried way deep. > > I don't know what Alpine exactly does, but if I do > dillo google.com > on the command line, it works fine with both dillo 2.0 and 0.8.6. > The interesting question here is which 0.8.6? the official one or the inofficial dillo-i18n one? At least debian does not ship the official one. If that's about the dillo-i18n stuff (and not reproducable with official dillo), then the problem should go to the corresponding team. Greetings Andreas Kemnade

Nov. 9, 2008

Feature Request

by newman.x＠gmail.com

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.) Feel free to use mines with SSL enabled (no guarantee at all), both F10. http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/dillo/dillo-2.0-1.i386.rpm http://www.stud.fit.vutbr.cz/~xnowak01/Fedora/fltk/fltk2-2.0.x.r6403-0.1.i3… But you'll probably have more luck with those: http://www.hyperborea.org/software/dillo/rpms/ Enjoy. >> If you enter "google.com" in the location bar and hit return >> it doesn't go to google? > > It does indeed. I'm putting this badly. > > I run Alpine 2.0; it is set to launch the default browser, which is > dillo -- and URLs in emails are what I use a default browser for. > > Does this mean something in my Alpine settings (and my Pine 4.64 > settings, which it took over) is wrong? My Fedora default browser > setting is simply "dillo %s"; my Alpine setting is something I'll have > to dig for, as it's buried way deep. > Might be here interesting whether Dillo2 cooperates nicely with alpine, let us know. Michal

Nov. 8, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > > is not in the default linker path, making the build abort. Add > > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > but it turned out that the problem was caused by a libiconv > > > > package that was no longer needed. The iconv stuff is now handled > > > > in libc on DragonFly... > > > > > > I have attached the log. Seems like the function signature differs > > > on OpenBSD a bit. The testcase modified as such that it includes > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > it manually. > > > > > > I don't know what happens here... > > > > > > Kind regards, > > > > Does it fail with current CVS? > > Sorry, from the log it's clear it doesn't. > > This page seems to have good info: > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > (my understanding of German is barely for survival. ;). > Yes it does describe my problem, but how do we fix this in a portable way? -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

Re: [SCRIPT] Run Dillo with a random user agent

by Rodrigo Arias

Hi Alex, On Tue, Jul 09, 2024 at 12:31:29PM +0200, a1ex(a)dismail.de wrote: >On Mon, 8 Jul 2024 14:50:08 +0200 ><a1ex(a)dismail.de> wrote: > >> Hi list, >> >> Here is a simple script which runs Dillo with a random user agent on >> each run. I've been using it for a long time with no issues. It would >> be interesting to have similar functionality built-in to Dillo at some >> point, at least for me. >> >> ... Thanks!, I think is a good idea to reduce fingerprinting in Dillo. Have you considered also removing the user agent header completely? I work under the assumption that each Dillo user is uniquely identifiable based on non-JS enabled, other HTTP headers, TLS behavior, TCP and network timing leaked details, unless I have evidence that suggests otherwise. I don't think the web is designed to keep users anonymous and there is only so much we can do. However, I would appreciate efforts towards reducing the fingerprinting information we are leaking. It would be nice to be able to measure it somehow, but I only find JS enabled fingerprinting estimation tests online. >Just to add to this, have you considered the idea of a user agent >switcher in Dillo? It would be neat to be able to choose from different >profiles and have them applied in real-time without having to restart >the browser. For example, the profiles could be something like: > >'Default', 'Desktop', 'Mobile', 'Random' I thought about something like this but for the CSS media selector, not so much for the user agent. I'm not sure if switching the user agent among desktop/mobile would have a measurable effect on the page content. If you want to reduce information leaked by Dillo that can identify a user, I think a good strategy is first to make a service that can measure this information among Dillo users and show the differences it can find among users, much like the EFF does[1]. Maybe we can work with the EFF to improve the support for non-JS browsers, so we can benefit from their pool of users to estimate uniqueness. [1]: https://coveryourtracks.eff.org/ We can also make it cooperate with a Dillo plugin that can have access to network TCP packets and timing information on both ends to emulate an state actor, so we can estimate how much information is being leaked and how much we are reducing it. This is probably something that we may want to bring up to the Tor team to see which strategies the did for the Tor Browser and which ones we can apply to Dillo. See also: https://github.com/dillo-browser/dillo/issues/135 Best, Rodrigo.

July 13, 2024

Dillo-dev search results for query "plugin"