- Dillo-dev - lists.mailman3.com

compilation error in fltkflatview.cc
by csoren＠isd.net 02 Sep '13

02 Sep '13

Greets all, As I've mentioned previously I'm trying to compile dillo-3.0.3 on Silicon Graphics using the SGI MIPSpro compiler. I'm doing this for a large group of SGI users who reside at nekochan.net. The compilation fails in line 884 in fltkflatview.cc: ---------- cc-3168 CC: ERROR File = fltkui.cc, Line = 884 A name followed by "::" must be a class or namespace name. bool FltkToggleButtonResource<I>::FltkToggleButtonResource::isActivated () ^ cc-1443 CC: ERROR File = fltkui.cc, Line = 884 "dw::fltk::ui::FltkToggleButtonResource<I>::FltkToggleButtonResource" is not a class template. bool FltkToggleButtonResource<I>::FltkToggleButtonResource::isActivated () ^ 2 errors detected in the compilation of "fltkflatview.cc". ---------- I suspect it needs a 'using namespace' or somesuch here, thoughts? Thanks a bunch!

2 1

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c
by jgaffney＠lawrenceville.org 31 Aug '13

31 Aug '13

Jorge Arellano Cid <jcid at dillo.org> writes: > Hi Johannes, JG: > [...] > The attached program is a stress test for SIGCHLD. The idea is to > find a formula that works well even in such cases. IIRC both of you > have access to BSD machines so please test it there. > > The program spawns 255 children which sleep 5 seconds and > terminate generating a SIGCHLD avalanche, which should be handled > cleanly. It works OK in Debian. [...] 1) OpenBSD is very strict about compliance with standards, so that, whereas on my (and I believe most if not all) Linux systems wait.h occurs redundantly in /usr/include/ and /usr/include/sys, on OpenBSD wait.h is solely in /usr/include/sys and your code will not compile unless the `#include<wait.h>' line is removed. Then `gcc -W -Wall' compiles it without complaint. 2) OpenSBD is not so extravagant with the resources allocated to unprivileged users (max 128 processes). But spawning 64 rather than 256 children the test is passed with the expected behavior on OpenBSD 5.2 GENERIC.MP#368 amd64. The OpenBSD 5.2 ports include Dillo 2.2 and FLTK2, but I just recently compiled FLTK 1.3.2 and Dillo 3.0.3 from their unmodified source on that machine without (IIRC) any errors. If you were curious more generally to see how they are modifying the Dillo source, the OpenBSD patches for Dillo 3.0.3 (the version currently in ports for OpenBSD 5.3) may be found at http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/

2 1

Proposed Patch for Zombies Left by Dpi_start_dpid() in dpi.c
by jgaffney＠lawrenceville.org 29 Aug '13

29 Aug '13

Johannes Hofmann <Johannes.Hofmann at gmx.de> writes: > Hi JG, > > On Tue, Aug 27, 2013 at 03:15:14PM -0400, JG wrote: >> It seems that the dpid children forked by Dpi_start_dpid() in dpi.c >> are not reaped when they terminate themselves after a period of >> inactivity while the parent dillo process is still running. The patch >> below is simply to reap these zombies. The SIGCHLD handler should >> probably do more, but I am not yet familiar enough with Dillo to know >> what. >> >> I believe this patch adheres to the Dillo rules of coding style, but >> am new to the list and a novice at Dillo patching. And hence also >> apologies to Jorge for this duplication of a previous communication by >> private email (although with one small change to get the patch to >> compile under OpenBSD as well as Linux). > > I can reproduce the issue here by killing dpid manually. > For me the following also fixes it: > > diff -r 659dc205c377 src/dillo.cc > --- a/src/dillo.cc Wed Aug 21 11:42:38 2013 +0200 > +++ b/src/dillo.cc Wed Aug 28 19:48:10 2013 +0200 > @@ -329,6 +329,7 @@ > > // Some OSes exit dillo without this (not GNU/Linux). > signal(SIGPIPE, SIG_IGN); > + signal(SIGCHLD, SIG_IGN); > > /* Handle command line options */ > opt_argv = dNew0(char*, numOptions(Options) + 1); > > Can you please check whether it works for you too? It would have the > advantage that we have all signal related stuff in one place. > > Cheers, > Johannes Thank you: your solution is of course not only correct but far simpler and better. (Though I thought that in general sigaction() is to be preferred to signal()?)

1 0

allow_white_bg
by sgeerken＠dillo.org 21 Aug '13

21 Aug '13

Hi! It seems that I'm getting old that I tried to set the option "allow_white_bg" to "false"; to find out that the replacement color is hardcoded! If I haven't missed something, and noone objets, I'll add a prefs variable "white_bg_replacement". BTW: is there a reason that there is still a prefs variable "bg_color", while fonts (the actual fonts, not the font classes) are now defined by CSS? Sebastian

2 3

Search from address bar
by aki.helin＠iki.fi 23 Jul '13

23 Jul '13

Hi, Currently when using a window manager where focus follows mouse, making a search usually requires you to reach for the mouse. One way to avoid this would be to allow using search engine(s) directly from the address bar. Searches would have to be differentiated somehow from URLs. Dillo already has a customizable list of engines in preferences, so one natural solution would be to interpret url strings which start with the name of a search engine as searches to be performed using it, so that e.g. 'wikipedia slartibartfast', 'google foo' and 'weather oulu' do what you would expect. Below is a quick patch I've used to do this for a while, should anyone else find this feature useful. diff -r 91fdbc0feb68 src/uicmd.cc --- a/src/uicmd.cc Sun Jun 16 21:23:19 2013 +0200 +++ b/src/uicmd.cc Mon Jun 17 15:00:05 2013 +0300 @@ -70,6 +70,7 @@ */ static BrowserWindow *UIcmd_tab_new(CustTabs *tabs, UI *old_ui, int focus); static void close_tab_btn_cb (Fl_Widget *w, void *cb_data); +static char *UIcmd_make_search_str(const char *str); //---------------------------------------------------------------------------- @@ -649,6 +650,27 @@ } /* + * Return a search string of the suffix if str is prefixed by the first word of a search engine name + */ +static char *UIcmd_find_search_str(const char *str) +{ + int end = dList_length(prefs.search_urls); + int p = 0; + char *url = NULL; + while (p < end && !url) { + char *search = (char *)dList_nth_data(prefs.search_urls,p); + int len = strcspn(search, " "); + int res = strncasecmp(str, search, len); + if (res == 0 && (str[len] == 0 || str[len] == ' ')) { + prefs.search_url_idx = p; + url = UIcmd_make_search_str(str + len); + } + p++; + } + return url; +} + +/* * Open a new URL in the given browser window. * * our custom "file:" URIs are normalized here too. @@ -656,10 +678,14 @@ void a_UIcmd_open_urlstr(void *vbw, const char *urlstr) { char *new_urlstr; + char *search_urlstr = NULL; DilloUrl *url; int ch; BrowserWindow *bw = (BrowserWindow*)vbw; + if ((search_urlstr = UIcmd_find_search_str(urlstr))) { + urlstr = search_urlstr; + } if (urlstr && *urlstr) { /* Filter URL string */ new_urlstr = a_Url_string_strip_delimiters(urlstr); @@ -680,6 +706,8 @@ url = a_Url_new(new_urlstr, NULL); } dFree(new_urlstr); + if (search_urlstr) + dFree(search_urlstr); if (url) { a_UIcmd_open_url(bw, url); -- Aki Helin

6 17

line wrapping
by corvid＠lavabit.com 02 Jul '13

02 Jul '13

I noticed that lines aren't wrapping for me with http://www.dillo.org/FAQ.html . hg bisect says that it started with: changeset: 2838:b2b239eb45b9 summary: Fixed problem with hyphenation.

4 8

Rendering problem?
by jcid＠dillo.org 24 Jun '13

24 Jun '13

Hi there, James Gholston wrote this: As I dig around unsuccessfully for a type of information, I look at your FAQ and realize the next person might be helped by it being available there. Q: I am trying to develop a web site to be highly compatible with Dillo. Where can I find information on optimization? In my specific case I'm directing Dillo to my HTML 3.2 theme, and Dillo has the highest market share of what I'm sending to it. Complete with a <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> declaration. I have a graphical 'bookmark' in a <TD> element defined both as background="" and as a CSS1 background (nested table layout similar to what I'm using for MSIE 5.5 through 8). Neither works with my copy of Dillo 3 (I just get the solid black fallback color), so I'm assuming it's not working for any other Dillo user. If there are additional Dillo tweaks listed somewhere I didn't think to hunt for I could also try to apply them. Unless I'm testing to see what one of my nine other themes looks like in Dillo at the time, you can gawk at what I'm doing at http://test.moonsociety.org if you want to. Other browsers I'm sending to HTML 3.2 are Netscape 3 and 4, MSIE 3 through 5, and any otherwise unidentifiable browser claiming to be Mozilla 4.0. My other themes look significantly different than the HTML 3.2 theme. Thank you for your time and work on the most available small graphical browser. James Gholston -- Cheers Jorge.-

1 0

[jamesg@dimensionality.com: I have an addition to the Dillo FAQ]
by jcid＠dillo.org 24 Jun '13

24 Jun '13

-- Cheers Jorge.-

1 0

Can't compile Dillo 3.0.3
by Johannes.Hofmann＠gmx.de 24 Jun '13

24 Jun '13

Hi August, On Fri, May 10, 2013 at 11:33:13AM +0200, August Karlstrom wrote: > I'm trying to compile Dillo 3.0.3 but I get an error from the linker saying: > > /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' > /usr/bin/ld: note: 'XSync' is defined in DSO > /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker > command line > > How do I add -lX11 to the linker command line? I have tried > > $ LDLIBS=-lX11 make > > but it makes no difference. My OS is Lubuntu 13.04. Could you please post the linker command line? You could try export LDFLAGS=-lX11 and then run configure;make again. Please let us know how this works. It might be that we are missing an explicit -lX11 somewhere and rely on fltkconfig --ldflags to add it - which may not be sufficient in some cases. Cheers, Johannes

7 25

Image Scaling
by sgeerken＠dillo.org 17 Jun '13

17 Jun '13

Hi! I've just push some changes for a better image scaling. See these two examples for the effect: - http://www.dillo.org/~sgeerken/grid.html - http://www.dillo.org/~sgeerken/tenniel.html I'm not completely sure about the side-effects. It should be slightly slower (see comment: it can be improved), and it will not work with other that RGB and RGBA data (for the case that Imgbuf is used for other representations). The old code is still there; just look at FltkImgbuf::scaleRow. Sebastian

3 7