- Dillo-dev - lists.mailman3.com

--local and redirection

by jcid＠dillo.org

On Sat, Dec 20, 2014 at 01:09:04AM +0000, eocene wrote: > Jorge wrote: > > On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote: > > > > > > I notice that redirection defeats --local. > > > You go to www.dillo.org and images aren't loaded. > > > You go to dillo.org, it redirects to www.dillo.org, and images are loaded. > > > > Oh, yes. > > > > Originally, --local was meant for local files only. To allow > > safe displaying of HTML email in sylpheed (IIRC). > > > > Now, from the console help given by dillo, it seems like it > > should work with non-local URLs too. It makes sense to me, > > although I haven't found a compelling use case for that. Maybe > > for opening news site without the images... > > > > Attached is a brief patch. Please test and send feedback. > > It appears to fix the case that I mentioned, but then I tried a local file like > > <head> > <meta http-equiv="refresh" content="0; url=http://example.com/"> > </head> > <body> > text > </body> > > and the redirection is followed. Please try the attached patch. -- Cheers Jorge.-

Dec. 20, 2014

--local and redirection

by eocene＠gmx.com

Jorge wrote: > On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote: > > > > I notice that redirection defeats --local. > > You go to www.dillo.org and images aren't loaded. > > You go to dillo.org, it redirects to www.dillo.org, and images are loaded. > > Oh, yes. > > Originally, --local was meant for local files only. To allow > safe displaying of HTML email in sylpheed (IIRC). > > Now, from the console help given by dillo, it seems like it > should work with non-local URLs too. It makes sense to me, > although I haven't found a compelling use case for that. Maybe > for opening news site without the images... > > Attached is a brief patch. Please test and send feedback. It appears to fix the case that I mentioned, but then I tried a local file like <head> <meta http-equiv="refresh" content="0; url=http://example.com/"> </head> <body> text </body> and the redirection is followed.

Dec. 20, 2014

--local and redirection

by jcid＠dillo.org

On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote: > > I notice that redirection defeats --local. > You go to www.dillo.org and images aren't loaded. > You go to dillo.org, it redirects to www.dillo.org, and images are loaded. Oh, yes. Originally, --local was meant for local files only. To allow safe displaying of HTML email in sylpheed (IIRC). Now, from the console help given by dillo, it seems like it should work with non-local URLs too. It makes sense to me, although I haven't found a compelling use case for that. Maybe for opening news site without the images... Attached is a brief patch. Please test and send feedback. -- Cheers Jorge.-

Dec. 19, 2014

here's 3.0.4.1 RC1

by diegel＠work.de

> http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 > md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 > > Here we expect feedback on the usual compile/run tests > on different platforms and if there're no issues it'll become final. > Compiles and runs with Irix 6.5 and fltk-1.3.3.

Dec. 17, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Wed, Dec 17, 2014 at 09:57:12AM -0300, Jorge Arellano Cid wrote: > On Tue, Dec 16, 2014 at 04:04:48PM +0100, v4hn wrote: > > On Tue, Dec 16, 2014 at 11:57:59AM -0300, Jorge Arellano Cid wrote: > > > This thread went silent. > > > > We're all waiting for your new RC :-) > > ok! > > http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 > md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 > > Here we expect feedback on the usual compile/run tests > on different platforms and if there're no issues it'll become final. On DragonFly BSD it runs fine with fltk-1.3.3. Cheers, Johannes

Dec. 17, 2014

here's 3.0.4.1 RC1

by frusen＠gungre.ch

<jcid at dillo.org> wrote: > http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 > md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 > > Here we expect feedback on the usual compile/run tests > on different platforms and if there're no issues it'll become final. Compiles and runs well on Dragora GNU/Linux-Libre 2.2 (i486 and x86_64) with FLTK 1.3.3.

Dec. 17, 2014

--local and redirection

by eocene＠gmx.com

I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.

Dec. 17, 2014

RC2 feedback [Re: here's 3.0.4.1 RC1]

by eocene＠gmx.com

Jorge wrote: > On Tue, Dec 16, 2014 at 04:04:48PM +0100, v4hn wrote: > > On Tue, Dec 16, 2014 at 11:57:59AM -0300, Jorge Arellano Cid wrote: > > > This thread went silent. > > > > We're all waiting for your new RC :-) > > ok! > > http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 > md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 > > Here we expect feedback on the usual compile/run tests > on different platforms and if there're no issues it'll become final. Builds and runs fine on 32-bit debian with fltk svn updated to some point within the past few days. I notice that searching the web from the popup shows "dd" due to the recent fix, which isn't very descriptive, but of course I recognize that it can't really be both descriptive for the popup window search and brief for Location bar search at the same time -- and the meaning of dd would become clear as soon as a search is tried.

Dec. 17, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Wed, Dec 17, 2014 at 09:57:12AM -0300, Jorge Arellano Cid wrote: > http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 > md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 Compiles and runs fine on Lunar-Linux(which is pretty much a bash-scripted LFS) with fltk 1.3.3. Thank you! Looking forward to the release, v4hn

Dec. 17, 2014

here's 3.0.4.1 RC1

by sgeerken＠dillo.org

On Wed, Dec 17, 2014, Jorge Arellano Cid wrote: > On Tue, Dec 16, 2014 at 04:04:48PM +0100, v4hn wrote: > > On Tue, Dec 16, 2014 at 11:57:59AM -0300, Jorge Arellano Cid wrote: > > > This thread went silent. > > > > We're all waiting for your new RC :-) > > ok! > > http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 > md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 > > Here we expect feedback on the usual compile/run tests > on different platforms and if there're no issues it'll become final. Simple compile&run successful on Debian Wheezy, amd64. Sebastian

Dec. 17, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

On Tue, Dec 16, 2014 at 04:04:48PM +0100, v4hn wrote: > On Tue, Dec 16, 2014 at 11:57:59AM -0300, Jorge Arellano Cid wrote: > > This thread went silent. > > We're all waiting for your new RC :-) ok! http://www.dillo.org/download/dillo-3.0.4.1-rc2.tar.bz2 md5sum: 1afb3a8afacea5a4cbf2f68b9e26d534 Here we expect feedback on the usual compile/run tests on different platforms and if there're no issues it'll become final. -- Cheers Jorge.-

Dec. 17, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Tue, Dec 16, 2014 at 11:57:59AM -0300, Jorge Arellano Cid wrote: > This thread went silent. We're all waiting for your new RC :-) v4hn

Dec. 16, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

Hmmm.... This thread went silent. Looks like time to pack rc2. Any show stopper? -- Cheers Jorge.-

Dec. 16, 2014

Fwd: Dillo porting

by lullaby.techie＠gmail.com

Dear all, A very good day to all of you. We have read about Dillo very recently. Seems very interesting for us as we are looking into porting a rendering engine with HTML4 support to QNX 4.25 platform. Here are our first level queries after our basic analysis: 1. First of all, a direct question. Is Dillo supported in QNX 4.25? Understood that Dillo 1 was supported in QNX6 with some issues. Can we ask a question - Why do you stop giving support for QNX in your latest versions. 2. Does Dillo support HTML 4 and CSS 2.1? 3. Is it possible to port only the rendering engine part to QNX 4.25 and use our existing web browser in QNX 4.25 to use this rendering engine? 4. Could you please share your thoughts on porting of Dillo to QNX 4.25 as it is an old version of QNX OS with no pthread support and some other limitations. 5. Could you please share us the tips/tricks/steps for porting Dillo to a newer OS like QNX 4.25. Our device is x86 only. Looking forward to hear from you soon. Thanking you in advance, Lullaby

Dec. 16, 2014

here's 3.0.4.1 RC1

by eocene＠gmx.com

Jorge wrote: > @corvid: AFAICS it landed in the 3.0.4.1 branch as intended ;) > BTW, now the patch is mentioned in the ChangeLog, but not in the > splash screen (not sure what's better, no strong feeling either). Since the list of changes is so small, I'll go ahead and add it.

Dec. 10, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

On Mon, Dec 08, 2014 at 11:07:48PM -0300, Jorge Arellano Cid wrote: > Hi Sebastian, > > On Mon, Dec 08, 2014 at 12:40:48PM +0100, Sebastian Geerken wrote: > > On Mon, Dec 08, 2014, v4hn wrote: > > > On Mon, Dec 08, 2014 at 01:11:38AM +0100, Sebastian Geerken wrote: > > > > On Mon, Dec 08, 2014, v4hn wrote: > > > > > Talking about bugs... I just found out this version segfaults over here > > > > > if I enter any string containing a space character. For example entering > > > > > "foo bar" into the adress line and hitting enter segfaults over here. > > > > > Can anyone reproduce this? > > > > > > > > Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) > > > > This bug occurs already in release 3.0.4. > > > > > > Yes, setting search_url makes the bug disappear. Thanks for investigating! > > > > It seems that this change fixes it: > > > > ---------------------------------------------------------------------- > > diff -r 9aa37b81c609 src/prefs.c > > --- a/src/prefs.c Tue Dec 02 16:33:49 2014 +0100 > > +++ b/src/prefs.c Mon Dec 08 12:37:15 2014 +0100 > > @@ -18,7 +18,7 @@ > > #define PREFS_FONT_CURSIVE "URW Chancery L" > > #define PREFS_FONT_FANTASY "DejaVu Sans" /* TODO: find good default */ > > #define PREFS_FONT_MONOSPACE "DejaVu Sans Mono" > > -#define PREFS_SEARCH_URL "http://duckduckgo.com/lite/?kp=-1&q=%s" > > +#define PREFS_SEARCH_URL "dd http://duckduckgo.com/lite/?kp=-1&q=%s" > > #define PREFS_NO_PROXY "localhost 127.0.0.1" > > #define PREFS_SAVE_DIR "/tmp/" > > #define PREFS_HTTP_REFERER "host" > > @@ -82,7 +82,6 @@ > > prefs.save_dir = dStrdup(PREFS_SAVE_DIR); > > prefs.search_urls = dList_new(16); > > dList_append(prefs.search_urls, dStrdup(PREFS_SEARCH_URL)); > > - dList_append(prefs.search_urls, NULL); /* flags a default search URL */ > > prefs.search_url_idx = 0; > > prefs.show_back = TRUE; > > prefs.show_bookmarks = TRUE; > > ---------------------------------------------------------------------- > > > > Not committed yet, since I'm not sure about the rationale. > > I'd also add: > > diff -r 978377ed5605 src/uicmd.cc > --- a/src/uicmd.cc Mon Dec 08 15:32:25 2014 +0100 > +++ b/src/uicmd.cc Mon Dec 08 22:58:53 2014 -0300 > @@ -682,7 +682,7 @@ static char *UIcmd_find_search_str(const > for (p = 0; p < dList_length(prefs.search_urls); p++) { > const char *search = > (const char *)dList_nth_data(prefs.search_urls, p); > - if (strncasecmp(str, search, len) == 0) { > + if (search && strncasecmp(str, search, len) == 0) { > prefs.search_url_idx = p; > url = UIcmd_make_search_str(str + len + 1); > break; > > (which solves the problem alone), but the cleanups above look > OK to me since AFAICS: > > * dd as default prefix for the DDG URL is fine. > * the NULL flag item is not used anymore. > * dialog.cc explicitly adds the extra item for menu building (n_it+1), > so the decreased number of elements is safe. Committed. @corvid: AFAICS it landed in the 3.0.4.1 branch as intended ;) BTW, now the patch is mentioned in the ChangeLog, but not in the splash screen (not sure what's better, no strong feeling either). If there're no more issues with 3.0.4.1, we may pack rc2 after some feedback. -- Cheers Jorge.-

Dec. 10, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

Hi Sebastian, On Mon, Dec 08, 2014 at 12:40:48PM +0100, Sebastian Geerken wrote: > On Mon, Dec 08, 2014, v4hn wrote: > > On Mon, Dec 08, 2014 at 01:11:38AM +0100, Sebastian Geerken wrote: > > > On Mon, Dec 08, 2014, v4hn wrote: > > > > Talking about bugs... I just found out this version segfaults over here > > > > if I enter any string containing a space character. For example entering > > > > "foo bar" into the adress line and hitting enter segfaults over here. > > > > Can anyone reproduce this? > > > > > > Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) > > > This bug occurs already in release 3.0.4. > > > > Yes, setting search_url makes the bug disappear. Thanks for investigating! > > It seems that this change fixes it: > > ---------------------------------------------------------------------- > diff -r 9aa37b81c609 src/prefs.c > --- a/src/prefs.c Tue Dec 02 16:33:49 2014 +0100 > +++ b/src/prefs.c Mon Dec 08 12:37:15 2014 +0100 > @@ -18,7 +18,7 @@ > #define PREFS_FONT_CURSIVE "URW Chancery L" > #define PREFS_FONT_FANTASY "DejaVu Sans" /* TODO: find good default */ > #define PREFS_FONT_MONOSPACE "DejaVu Sans Mono" > -#define PREFS_SEARCH_URL "http://duckduckgo.com/lite/?kp=-1&q=%s" > +#define PREFS_SEARCH_URL "dd http://duckduckgo.com/lite/?kp=-1&q=%s" > #define PREFS_NO_PROXY "localhost 127.0.0.1" > #define PREFS_SAVE_DIR "/tmp/" > #define PREFS_HTTP_REFERER "host" > @@ -82,7 +82,6 @@ > prefs.save_dir = dStrdup(PREFS_SAVE_DIR); > prefs.search_urls = dList_new(16); > dList_append(prefs.search_urls, dStrdup(PREFS_SEARCH_URL)); > - dList_append(prefs.search_urls, NULL); /* flags a default search URL */ > prefs.search_url_idx = 0; > prefs.show_back = TRUE; > prefs.show_bookmarks = TRUE; > ---------------------------------------------------------------------- > > Not committed yet, since I'm not sure about the rationale. I'd also add: diff -r 978377ed5605 src/uicmd.cc --- a/src/uicmd.cc Mon Dec 08 15:32:25 2014 +0100 +++ b/src/uicmd.cc Mon Dec 08 22:58:53 2014 -0300 @@ -682,7 +682,7 @@ static char *UIcmd_find_search_str(const for (p = 0; p < dList_length(prefs.search_urls); p++) { const char *search = (const char *)dList_nth_data(prefs.search_urls, p); - if (strncasecmp(str, search, len) == 0) { + if (search && strncasecmp(str, search, len) == 0) { prefs.search_url_idx = p; url = UIcmd_make_search_str(str + len + 1); break; (which solves the problem alone), but the cleanups above look OK to me since AFAICS: * dd as default prefix for the DDG URL is fine. * the NULL flag item is not used anymore. * dialog.cc explicitly adds the extra item for menu building (n_it+1), so the decreased number of elements is safe. -- Cheers Jorge.-

Dec. 9, 2014

here's 3.0.4.1 RC1

by eocene＠gmx.com

v4hn wrote: > On Mon, Dec 08, 2014 at 04:13:44PM +0100, Johannes Hofmann wrote: > > Cool. If somebody confirms, that it doesn't break setups that worked > > before, I will commit it tonight. > > I already confirmed that for one setup :) I haven't seen any breakage either...

Dec. 8, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Mon, Dec 08, 2014 at 04:13:44PM +0100, Johannes Hofmann wrote: > Cool. If somebody confirms, that it doesn't break setups that worked > before, I will commit it tonight. I already confirmed that for one setup :) v4hn

Dec. 8, 2014

here's 3.0.4.1 RC1

by johannes.hofmann＠gmx.de

On Mon, Dec 08, 2014 at 01:46:37PM +0100, Jan Diegelmann wrote: > Johannes Hofmann wrote: > > >I have a fix that works on my system so far: > > Works also for Irix. Thanks for your patch. Cool. If somebody confirms, that it doesn't break setups that worked before, I will commit it tonight. Cheers, Johannes

Dec. 8, 2014

here's 3.0.4.1 RC1

by diegel＠work.de

Johannes Hofmann wrote: > I have a fix that works on my system so far: Works also for Irix. Thanks for your patch.

Dec. 8, 2014

here's 3.0.4.1 RC1

by sgeerken＠dillo.org

On Mon, Dec 08, 2014, v4hn wrote: > On Mon, Dec 08, 2014 at 01:11:38AM +0100, Sebastian Geerken wrote: > > On Mon, Dec 08, 2014, v4hn wrote: > > > Talking about bugs... I just found out this version segfaults over here > > > if I enter any string containing a space character. For example entering > > > "foo bar" into the adress line and hitting enter segfaults over here. > > > Can anyone reproduce this? > > > > Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) > > This bug occurs already in release 3.0.4. > > Yes, setting search_url makes the bug disappear. Thanks for investigating! It seems that this change fixes it: ---------------------------------------------------------------------- diff -r 9aa37b81c609 src/prefs.c --- a/src/prefs.c Tue Dec 02 16:33:49 2014 +0100 +++ b/src/prefs.c Mon Dec 08 12:37:15 2014 +0100 @@ -18,7 +18,7 @@ #define PREFS_FONT_CURSIVE "URW Chancery L" #define PREFS_FONT_FANTASY "DejaVu Sans" /* TODO: find good default */ #define PREFS_FONT_MONOSPACE "DejaVu Sans Mono" -#define PREFS_SEARCH_URL "http://duckduckgo.com/lite/?kp=-1&q=%s" +#define PREFS_SEARCH_URL "dd http://duckduckgo.com/lite/?kp=-1&q=%s" #define PREFS_NO_PROXY "localhost 127.0.0.1" #define PREFS_SAVE_DIR "/tmp/" #define PREFS_HTTP_REFERER "host" @@ -82,7 +82,6 @@ prefs.save_dir = dStrdup(PREFS_SAVE_DIR); prefs.search_urls = dList_new(16); dList_append(prefs.search_urls, dStrdup(PREFS_SEARCH_URL)); - dList_append(prefs.search_urls, NULL); /* flags a default search URL */ prefs.search_url_idx = 0; prefs.show_back = TRUE; prefs.show_bookmarks = TRUE; ---------------------------------------------------------------------- Not committed yet, since I'm not sure about the rationale. Sebastian

Dec. 8, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Mon, Dec 08, 2014 at 01:11:38AM +0100, Sebastian Geerken wrote: > On Mon, Dec 08, 2014, v4hn wrote: > > Talking about bugs... I just found out this version segfaults over here > > if I enter any string containing a space character. For example entering > > "foo bar" into the adress line and hitting enter segfaults over here. > > Can anyone reproduce this? > > Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) > This bug occurs already in release 3.0.4. Yes, setting search_url makes the bug disappear. Thanks for investigating! v4hn

Dec. 8, 2014

here's 3.0.4.1 RC1

by sgeerken＠dillo.org

On Mon, Dec 08, 2014, v4hn wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > Talking about bugs... I just found out this version segfaults over here > if I enter any string containing a space character. For example entering > "foo bar" into the adress line and hitting enter segfaults over here. > Can anyone reproduce this? Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) This bug occurs already in release 3.0.4. Segfault is in UIcmd_find_search_str, with these values: (gdb) p dList_length(prefs.search_urls) $1 = 2 (gdb) p (char*)dList_nth_data(prefs.search_urls, 0) $2 = 0x710f40 "http://duckduckgo.com/lite/?kp=-1&q=%s" (gdb) p (char*)dList_nth_data(prefs.search_urls, 1) $3 = 0x0 Sebastian

Dec. 8, 2014

here's 3.0.4.1 RC1

by higuita7＠yahoo.co.uk

Hi On Mon, 8 Dec 2014 00:28:08 +0100, v4hn <me at v4hn.de> wrote: > Talking about bugs... I just found out this version segfaults over here > if I enter any string containing a space character. For example entering > "foo bar" into the adress line and hitting enter segfaults over here. > Can anyone reproduce this? Works fine here, linux 64bit, fltk 1.3.3 higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Dec. 8, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > make sure that everything is all right, so: > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 Talking about bugs... I just found out this version segfaults over here if I enter any string containing a space character. For example entering "foo bar" into the adress line and hitting enter segfaults over here. Can anyone reproduce this? v4hn

Dec. 7, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Sun, Dec 07, 2014 at 06:36:02PM +0100, Johannes Hofmann wrote: > Could you please grep for NET_SUPPORTING in your dwm sources? > In current dwm tip _NET_SUPPORTING_WM_CHECK is no longer set and > this seems to cause ewmh_supported() to return 0 in my case. That flag doesn't exist over here in my code as well: $ grep -r _NET dwm.1:.B xprop -root -f _NET_WM_NAME 32a -set _NET_WM_NAME LG3D dwm.c: setfullscreen(c, (cme->data.l[0] == 1 /* _NET_WM_STATE_ADD dwm.c: || (cme->data.l[0] == 2 /* _NET_WM_STATE_TOGGL dwm.c: netatom[NetActiveWindow] = XInternAtom(dpy, "_NET_ACTIVE_WINDOW", False); dwm.c: netatom[NetSupported] = XInternAtom(dpy, "_NET_SUPPORTED", False); dwm.c: netatom[NetWMName] = XInternAtom(dpy, "_NET_WM_NAME", False); dwm.c: netatom[NetWMState] = XInternAtom(dpy, "_NET_WM_STATE", False); dwm.c: netatom[NetWMFullscreen] = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", Fals dwm.c: netatom[NetWMWindowType] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE", False); dwm.c: netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE_DIALO dwm.c: netatom[NetClientList] = XInternAtom(dpy, "_NET_CLIENT_LIST", False); On Sun, Dec 07, 2014 at 09:23:40PM +0100, Johannes Hofmann wrote: > I have a fix that works on my system so far: > > diff -r 72f0e7ccccc9 src/uicmd.cc > --- a/src/uicmd.cc Thu Nov 27 19:20:33 2014 +0000 > +++ b/src/uicmd.cc Sun Dec 07 21:20:08 2014 +0100 > @@ -551,10 +551,10 @@ > win->box(FL_NO_BOX); > CustTabs *DilloTabs = new CustTabs(ww, wh, 16); > win->end(); > + win->resizable(DilloTabs->wizard()); > > int focus = 1; > new_bw = UIcmd_tab_new(DilloTabs, old_ui, focus); > - win->resizable(DilloTabs->wizard()); > win->show(); > > if (old_bw == NULL && prefs.xpos >= 0 && prefs.ypos >= 0) { That looks like a painful debugging experience... > Please give it a try and report back if it breaks anything. Didn't break anything over here. It still works just as great as it did before. :-) v4hn

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

Hi, I have a fix that works on my system so far: diff -r 72f0e7ccccc9 src/uicmd.cc --- a/src/uicmd.cc Thu Nov 27 19:20:33 2014 +0000 +++ b/src/uicmd.cc Sun Dec 07 21:20:08 2014 +0100 @@ -551,10 +551,10 @@ win->box(FL_NO_BOX); CustTabs *DilloTabs = new CustTabs(ww, wh, 16); win->end(); + win->resizable(DilloTabs->wizard()); int focus = 1; new_bw = UIcmd_tab_new(DilloTabs, old_ui, focus); - win->resizable(DilloTabs->wizard()); win->show(); if (old_bw == NULL && prefs.xpos >= 0 && prefs.ypos >= 0) { Please give it a try and report back if it breaks anything. Cheers, Johannes PS: The problem was that some code in UIcmd_tab_new() is triggering Fl_X::sendxjunk() and if at that moment no resizable is set, the window get's marked as fixed size. On Sun, Dec 07, 2014 at 06:36:02PM +0100, Johannes Hofmann wrote: > On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > > On Sat, Dec 06, 2014 at 11:17:36AM +0100, Johannes Hofmann wrote: > > > I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux > > > and X11-forwarded to my DragonFly box. > > > Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the > > > output of xprop for the dillo window. I get: > > > > > > WM_STATE(WM_STATE): > > > window state: Normal > > > icon window: 0x0 > > > _NET_WM_ICON(CARDINAL) = > > > WM_HINTS(WM_HINTS): > > > Client accepts input or input focus: True > > > XdndAware(ATOM) = ATOM > > > WM_CLASS(STRING) = "dillo", "Dillo" > > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > > program specified minimum size: 780 by 580 > > > program specified maximum size: 780 by 580 > > > window gravity: Static > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > For me it's: > > > > > $ xprop > > > WM_STATE(WM_STATE): > > > window state: Normal > > > icon window: 0x0 > > > _NET_WM_ICON(CARDINAL) = > > > WM_HINTS(WM_HINTS): > > > Client accepts input or input focus: True > > > XdndAware(ATOM) = ATOM > > > WM_CLASS(STRING) = "dillo", "Dillo" > > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > > program specified minimum size: 100 by 101 > > > window gravity: Static > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > So yes, I see more realistic/useful size hints over here. > > > > In case this is relevant, I'm not actually running the latest master > > of dwm over here, but 7edc59631193813cf4d64030f8864de36b193cfc with custom patches. > > I didn't get around to update the patches yet. > > Could you please grep for NET_SUPPORTING in your dwm sources? > In current dwm tip _NET_SUPPORTING_WM_CHECK is no longer set and > this seems to cause ewmh_supported() to return 0 in my case. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Sun, Dec 07, 2014 at 04:08:30PM +0000, eocene wrote: > Johannes wrote: > > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > > make sure that everything is all right, so: > > > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > > > > shouldn't Jorge's dicache fixes also be included? > > At the time, I thought of keeping the set of changes exceedingly minimal > and exceedingly safe because it was something quick to respond to 1.3.3. Ok, sounds reasonable. > Now that this is taking a little more time, the line could be drawn > differently. Let's focus on fixing the remaining issue with 3.0.4.1 fist. Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > On Sat, Dec 06, 2014 at 11:17:36AM +0100, Johannes Hofmann wrote: > > I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux > > and X11-forwarded to my DragonFly box. > > Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the > > output of xprop for the dillo window. I get: > > > > WM_STATE(WM_STATE): > > window state: Normal > > icon window: 0x0 > > _NET_WM_ICON(CARDINAL) = > > WM_HINTS(WM_HINTS): > > Client accepts input or input focus: True > > XdndAware(ATOM) = ATOM > > WM_CLASS(STRING) = "dillo", "Dillo" > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified minimum size: 780 by 580 > > program specified maximum size: 780 by 580 > > window gravity: Static > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > For me it's: > > > $ xprop > > WM_STATE(WM_STATE): > > window state: Normal > > icon window: 0x0 > > _NET_WM_ICON(CARDINAL) = > > WM_HINTS(WM_HINTS): > > Client accepts input or input focus: True > > XdndAware(ATOM) = ATOM > > WM_CLASS(STRING) = "dillo", "Dillo" > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified minimum size: 100 by 101 > > window gravity: Static > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > So yes, I see more realistic/useful size hints over here. > > In case this is relevant, I'm not actually running the latest master > of dwm over here, but 7edc59631193813cf4d64030f8864de36b193cfc with custom patches. > I didn't get around to update the patches yet. Could you please grep for NET_SUPPORTING in your dwm sources? In current dwm tip _NET_SUPPORTING_WM_CHECK is no longer set and this seems to cause ewmh_supported() to return 0 in my case. Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

On Sun, Dec 07, 2014 at 01:07:00PM +0100, Johannes Hofmann wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > shouldn't Jorge's dicache fixes also be included? I'd prefer not to include them this time, and issue just a compilation fix release for fltk-1.3.3 (which is not yet even in Debian's experimental), so we can focus on making dillo GROWS into "releaseable" state. ;) I'd also like to have the dwm-detected bug tackled before the release. It looks like a problem in fltk-1.3.3 (from Johannes' tests); we may need to contact the FLTK team at some point. -- Cheers Jorge.-

Dec. 7, 2014

here's 3.0.4.1 RC1

by eocene＠gmx.com

Johannes wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > shouldn't Jorge's dicache fixes also be included? At the time, I thought of keeping the set of changes exceedingly minimal and exceedingly safe because it was something quick to respond to 1.3.3. Now that this is taking a little more time, the line could be drawn differently.

Dec. 7, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Sun, Dec 07, 2014 at 12:48:06PM +0100, Johannes Hofmann wrote: > Interestingly if I comment out the following code that was > introduced in fltk-1.3.3 things work as expected for me: > > --- src/Fl.cxx.orig 2014-12-07 12:27:31.291453000 +0100 > +++ src/Fl.cxx 2014-12-07 12:44:14.991338000 +0100 > @@ -962,6 +962,7 @@ > if (x) x->set_key_window(); > } > #elif defined(USE_X11) > + /* > if (fl_xfocus != win) { > Fl_X *x = Fl_X::i(win); > if (!Fl_X::ewmh_supported()) > @@ -969,6 +970,8 @@ > else if (x) // New WMs use the NETWM attribute: > Fl_X::activate_window(x->xid); > } > + */ > + fprintf(stderr, "====> Fl_X::ewmh_supported() -> %d\n", Fl_X::ewmh_supported()); > #endif > fl_xfocus = win; > } > > > The fprintf line gives: > ====> Fl_X::ewmh_supported() -> 0 > on my system. > Could you try the above patch to fltk-1.3.3 on you system too and report > what Fl_X::ewmh_supported() returns on your system? ====> Fl_X::ewmh_supported() -> 1 So the problem only exists with fltk's handling of non-ewmh capable setups? v4hn

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > make sure that everything is all right, so: > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > shouldn't Jorge's dicache fixes also be included? Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Sun, Dec 07, 2014 at 12:15:02PM +0100, v4hn wrote: > On Sun, Dec 07, 2014 at 11:55:43AM +0100, Johannes Hofmann wrote: > > On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > > > For me it's: > > > > > > > $ xprop > > > > WM_STATE(WM_STATE): > > > > window state: Normal > > > > icon window: 0x0 > > > > _NET_WM_ICON(CARDINAL) = > > > > WM_HINTS(WM_HINTS): > > > > Client accepts input or input focus: True > > > > XdndAware(ATOM) = ATOM > > > > WM_CLASS(STRING) = "dillo", "Dillo" > > > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > > > program specified minimum size: 100 by 101 > > > > window gravity: Static > > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > > > So yes, I see more realistic/useful size hints over here. > > > > very odd. Are you 100% sure your dillo version is linked with > > fltk-1.3.3 and not fltk-1.3.2? Do you maybe still have fltk-1.3.2 > > headers or libs somewhere on your system? > > I'm 100% sure I have only fltk 1.3.3 around. Also if I try to build dillo-3.0.4 > on this machine I get the oldfocus symbol error which is fixed in 3.0.4.1. > > > Are you using a prebuilt fltk-1.3.3 or did you compile from source? > > I'm running Lunar-Linux which builds everything from source. > The build instructions for fltk can be found here: > https://github.com/lunar-linux/moonbase-other/tree/master/libs/fltk > > Dillo's instructions are available here: > https://github.com/lunar-linux/moonbase-other/tree/master/web/dillo > The only thing I changed in there is the version number and checksum. Ok, thanks. Interestingly if I comment out the following code that was introduced in fltk-1.3.3 things work as expected for me: --- src/Fl.cxx.orig 2014-12-07 12:27:31.291453000 +0100 +++ src/Fl.cxx 2014-12-07 12:44:14.991338000 +0100 @@ -962,6 +962,7 @@ if (x) x->set_key_window(); } #elif defined(USE_X11) + /* if (fl_xfocus != win) { Fl_X *x = Fl_X::i(win); if (!Fl_X::ewmh_supported()) @@ -969,6 +970,8 @@ else if (x) // New WMs use the NETWM attribute: Fl_X::activate_window(x->xid); } + */ + fprintf(stderr, "====> Fl_X::ewmh_supported() -> %d\n", Fl_X::ewmh_supported()); #endif fl_xfocus = win; } The fprintf line gives: ====> Fl_X::ewmh_supported() -> 0 on my system. Could you try the above patch to fltk-1.3.3 on you system too and report what Fl_X::ewmh_supported() returns on your system? Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Sun, Dec 07, 2014 at 11:55:43AM +0100, Johannes Hofmann wrote: > On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > > For me it's: > > > > > $ xprop > > > WM_STATE(WM_STATE): > > > window state: Normal > > > icon window: 0x0 > > > _NET_WM_ICON(CARDINAL) = > > > WM_HINTS(WM_HINTS): > > > Client accepts input or input focus: True > > > XdndAware(ATOM) = ATOM > > > WM_CLASS(STRING) = "dillo", "Dillo" > > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > > program specified minimum size: 100 by 101 > > > window gravity: Static > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > So yes, I see more realistic/useful size hints over here. > > very odd. Are you 100% sure your dillo version is linked with > fltk-1.3.3 and not fltk-1.3.2? Do you maybe still have fltk-1.3.2 > headers or libs somewhere on your system? I'm 100% sure I have only fltk 1.3.3 around. Also if I try to build dillo-3.0.4 on this machine I get the oldfocus symbol error which is fixed in 3.0.4.1. > Are you using a prebuilt fltk-1.3.3 or did you compile from source? I'm running Lunar-Linux which builds everything from source. The build instructions for fltk can be found here: https://github.com/lunar-linux/moonbase-other/tree/master/libs/fltk Dillo's instructions are available here: https://github.com/lunar-linux/moonbase-other/tree/master/web/dillo The only thing I changed in there is the version number and checksum. v4hn

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > On Sat, Dec 06, 2014 at 11:17:36AM +0100, Johannes Hofmann wrote: > > I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux > > and X11-forwarded to my DragonFly box. > > Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the > > output of xprop for the dillo window. I get: > > > > WM_STATE(WM_STATE): > > window state: Normal > > icon window: 0x0 > > _NET_WM_ICON(CARDINAL) = > > WM_HINTS(WM_HINTS): > > Client accepts input or input focus: True > > XdndAware(ATOM) = ATOM > > WM_CLASS(STRING) = "dillo", "Dillo" > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified minimum size: 780 by 580 > > program specified maximum size: 780 by 580 > > window gravity: Static > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > For me it's: > > > $ xprop > > WM_STATE(WM_STATE): > > window state: Normal > > icon window: 0x0 > > _NET_WM_ICON(CARDINAL) = > > WM_HINTS(WM_HINTS): > > Client accepts input or input focus: True > > XdndAware(ATOM) = ATOM > > WM_CLASS(STRING) = "dillo", "Dillo" > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified minimum size: 100 by 101 > > window gravity: Static > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > So yes, I see more realistic/useful size hints over here. very odd. Are you 100% sure your dillo version is linked with fltk-1.3.3 and not fltk-1.3.2? Do you maybe still have fltk-1.3.2 headers or libs somewhere on your system? Are you using a prebuilt fltk-1.3.3 or did you compile from source? Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Sat, Dec 06, 2014 at 11:17:36AM +0100, Johannes Hofmann wrote: > I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux > and X11-forwarded to my DragonFly box. > Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the > output of xprop for the dillo window. I get: > > WM_STATE(WM_STATE): > window state: Normal > icon window: 0x0 > _NET_WM_ICON(CARDINAL) = > WM_HINTS(WM_HINTS): > Client accepts input or input focus: True > XdndAware(ATOM) = ATOM > WM_CLASS(STRING) = "dillo", "Dillo" > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 > WM_NORMAL_HINTS(WM_SIZE_HINTS): > program specified minimum size: 780 by 580 > program specified maximum size: 780 by 580 > window gravity: Static > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" For me it's: > $ xprop > WM_STATE(WM_STATE): > window state: Normal > icon window: 0x0 > _NET_WM_ICON(CARDINAL) = > WM_HINTS(WM_HINTS): > Client accepts input or input focus: True > XdndAware(ATOM) = ATOM > WM_CLASS(STRING) = "dillo", "Dillo" > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > WM_NORMAL_HINTS(WM_SIZE_HINTS): > program specified minimum size: 100 by 101 > window gravity: Static > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" So yes, I see more realistic/useful size hints over here. In case this is relevant, I'm not actually running the latest master of dwm over here, but 7edc59631193813cf4d64030f8864de36b193cfc with custom patches. I didn't get around to update the patches yet. v4hn

Dec. 6, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Dec 05, 2014 at 04:18:12PM -0300, Jorge Arellano Cid wrote: > On Fri, Dec 05, 2014 at 03:08:05PM +0100, Jan Diegelmann wrote: > > Johannes Hofmann wrote: > > > > >I had it originally tested with fltk-1.3.2 from ports, but now I > > >tried with fltk-1.3.3 and it somehow doesn't play nice with dwm > > >anymore. It start's and runs ok, but is not getting organized in > > >tiled mode and the window can't be resized. Example apps from > > >fltk-1.3.3 work ok though. > > > > I see the same problem resizing the window in Irix with fltk-1.3.3. > > OK, so it works on Linux and has problem with dwm on Irix and > DragonFly BSD. I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux and X11-forwarded to my DragonFly box. Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the output of xprop for the dillo window. I get: WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_ICON(CARDINAL) = WM_HINTS(WM_HINTS): Client accepts input or input focus: True XdndAware(ATOM) = ATOM WM_CLASS(STRING) = "dillo", "Dillo" _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 780 by 580 program specified maximum size: 780 by 580 window gravity: Static WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" I suspect the program specified minimum/maximum size to be the problem. Cheers, Johannes

Dec. 6, 2014

here's 3.0.4.1 RC1

by diegel＠work.de

> OK, so it works on Linux and has problem with dwm on Irix and > DragonFly BSD. Irix window manager is 4Dwm, an enhanced version of mwm. > So here a couple of suggestions: > > 1) How does dillo work with another WM in your OS? I tried twm, with no difference. > 2) How does dillo work when commenting out patches 3976 and > 3969? Please use the attached patch. I used the attached patch: still the same behavior.

Dec. 5, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

On Fri, Dec 05, 2014 at 03:08:05PM +0100, Jan Diegelmann wrote: > Johannes Hofmann wrote: > > >I had it originally tested with fltk-1.3.2 from ports, but now I > >tried with fltk-1.3.3 and it somehow doesn't play nice with dwm > >anymore. It start's and runs ok, but is not getting organized in > >tiled mode and the window can't be resized. Example apps from > >fltk-1.3.3 work ok though. > > I see the same problem resizing the window in Irix with fltk-1.3.3. OK, so it works on Linux and has problem with dwm on Irix and DragonFly BSD. I didn't find anything suspicious in fltk's Changelog [1] ... So here a couple of suggestions: 1) How does dillo work with another WM in your OS? 2) How does dillo work when commenting out patches 3976 and 3969? Please use the attached patch. [1] http://www.fltk.org/articles.php?L1392 -- Cheers Jorge.-

Dec. 5, 2014

here's 3.0.4.1 RC1

by diegel＠work.de

Johannes Hofmann wrote: > I had it originally tested with fltk-1.3.2 from ports, but now I > tried with fltk-1.3.3 and it somehow doesn't play nice with dwm > anymore. It start's and runs ok, but is not getting organized in > tiled mode and the window can't be resized. Example apps from > fltk-1.3.3 work ok though. I see the same problem resizing the window in Irix with fltk-1.3.3.

Dec. 5, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Thu, Dec 04, 2014 at 10:27:07PM +0100, Johannes Hofmann wrote: > On Thu, Dec 04, 2014 at 09:36:40AM -0300, Jorge Arellano Cid wrote: > > On Wed, Dec 03, 2014 at 07:47:50PM +0100, Johannes Hofmann wrote: > > > Builds and runs nicely on DragonFly BSD. > > > > With fltk-1.3.3 or fltk-1.3.2? > > I had it originally tested with fltk-1.3.2 from ports, but now I > tried with fltk-1.3.3 and it somehow doesn't play nice with dwm > anymore. It start's and runs ok, but is not getting organized in > tiled mode and the window can't be resized. Example apps from > fltk-1.3.3 work ok though. I use the rc with Lunar-Linux, fltk-1.3.3 and dwm since yesterday and everything seems to be fine. I can't reproduce the bugs you mention over here, so it might be something specific to your machine or DragonFly BSD... v4hn

Dec. 4, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Dec 04, 2014 at 09:36:40AM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Wed, Dec 03, 2014 at 07:47:50PM +0100, Johannes Hofmann wrote: > > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > > make sure that everything is all right, so: > > > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > Builds and runs nicely on DragonFly BSD. > > Good. > > With fltk-1.3.3 or fltk-1.3.2? I had it originally tested with fltk-1.3.2 from ports, but now I tried with fltk-1.3.3 and it somehow doesn't play nice with dwm anymore. It start's and runs ok, but is not getting organized in tiled mode and the window can't be resized. Example apps from fltk-1.3.3 work ok though. Cheers, Johannes

Dec. 4, 2014

here's 3.0.4.1 RC1

by abe＠deuxchevaux.org

Hi, On Thu, Dec 04, 2014 at 09:35:22AM -0300, Jorge Arellano Cid wrote: > > Builds fine in the Debian package on amd64 (i.e. Linux x86_64) It also runs fine there. > > as well as kfreebsd-amd64 (Debian GNU/kFreeBSD on x86_64). Didn't check if it runs on that platform as I built it inside a remote chroot where I can't easily do X forwarding. > BTW, are you using fltk-1.3.3 or fltk-1.3.2? Sorry, forgot to mention (but checked it): Since Debian is currently in the freeze for the upcoming stable release, it still has 1.3.2. I also checked, but 1.3.3 is not yet in Debian Experimental (which would be the place to put a new upstream release during the freeze). Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Dec. 4, 2014

[sfisher@SDF.ORG: Dillo3 on NetBSD]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Dec. 4, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

Hi Johannes, On Wed, Dec 03, 2014 at 07:47:50PM +0100, Johannes Hofmann wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > Builds and runs nicely on DragonFly BSD. Good. With fltk-1.3.3 or fltk-1.3.2? -- Cheers Jorge.-

Dec. 4, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

On Wed, Dec 03, 2014 at 07:37:41PM +0100, Axel Beckert wrote: > Hi, > > On Wed, Dec 03, 2014 at 12:30:20PM -0300, Jorge Arellano Cid wrote: > > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > > make sure that everything is all right, so: > > > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > [...] > > @all, please compile/run rc1 and report how it went. > > Builds fine in the Debian package on amd64 (i.e. Linux x86_64) as well > as kfreebsd-amd64 (Debian GNU/kFreeBSD on x86_64). Thanks. BTW, are you using fltk-1.3.3 or fltk-1.3.2? -- Cheers Jorge.-

Dec. 4, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > make sure that everything is all right, so: > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 Builds and runs nicely on DragonFly BSD. Cheers, Johannes

Dec. 3, 2014

here's 3.0.4.1 RC1

by abe＠deuxchevaux.org

Hi, On Wed, Dec 03, 2014 at 12:30:20PM -0300, Jorge Arellano Cid wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 [...] > @all, please compile/run rc1 and report how it went. Builds fine in the Debian package on amd64 (i.e. Linux x86_64) as well as kfreebsd-amd64 (Debian GNU/kFreeBSD on x86_64). Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Dec. 3, 2014