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
Hi, 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:
Yes, thanks a lot. Just checked the diff, compiled and run. AFAIS, it's OK. @all, please compile/run rc1 and report how it went. When there's feedback from the main platforms (GNU/Linux already OK), I'll add the release date, signature and upload to the site, so the rest of the release can proceed. -- Cheers Jorge.-
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)
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.-
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)
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:
Builds and runs nicely on DragonFly BSD. Cheers, Johannes
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:
Builds and runs nicely on DragonFly BSD.
Good. With fltk-1.3.3 or fltk-1.3.2? -- Cheers Jorge.-
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:
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
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
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.
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.-
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.
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
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
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
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
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
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
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
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
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
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
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:
shouldn't Jorge's dicache fixes also be included? Cheers, Johannes
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:
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.
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:
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
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:
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.-
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:
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
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
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:
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
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
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
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.-
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.-
Hmmm.... This thread went silent. Looks like time to pack rc2. Any show stopper? -- Cheers Jorge.-
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.-
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
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
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.
<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.
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
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.
Hi, Here goes rc3: http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76 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.-
On Mo, Dez 22, 2014, Jorge Arellano Cid wrote:
Here goes rc3:
http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76
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 and run works without problems on Debian Wheezy (amd64). Sebastian PS: What about giving the development version a version number which is easily recognizable, e. g. "3.1-dev", and remove the "-dev" shortly before a release? I'm normally running the version from the main repo, which greets me with "Welcome to Dillo 3.0.4", which is not quite correct.
Sebastian wrote:
PS: What about giving the development version a version number which is easily recognizable, e. g. "3.1-dev", and remove the "-dev" shortly before a release? I'm normally running the version from the main repo, which greets me with "Welcome to Dillo 3.0.4", which is not quite correct.
Sounds reasonable to me.
On Wed, Dec 24, 2014 at 08:58:55PM +0000, eocene wrote:
Sebastian wrote:
PS: What about giving the development version a version number which is easily recognizable, e. g. "3.1-dev", and remove the "-dev" shortly before a release? I'm normally running the version from the main repo, which greets me with "Welcome to Dillo 3.0.4", which is not quite correct.
Sounds reasonable to me.
Me too. +1 -- Cheers Jorge.-
On Mi, Dez 24, 2014, Jorge Arellano Cid wrote:
On Wed, Dec 24, 2014 at 08:58:55PM +0000, eocene wrote:
Sebastian wrote:
PS: What about giving the development version a version number which is easily recognizable, e. g. "3.1-dev", and remove the "-dev" shortly before a release? I'm normally running the version from the main repo, which greets me with "Welcome to Dillo 3.0.4", which is not quite correct.
Sounds reasonable to me.
Me too. +1
Done. (BTW, it was 3.0.4.1 after the merge.) Sebastian
Hi, On Mon, Dec 22, 2014 at 11:49:51AM -0300, Jorge Arellano Cid wrote:
http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76
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 works fine when being built as Debian package on amd64 against FLTK 1.3.2. 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)
Jorge wrote:
Here goes rc3:
http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76
Here we expect feedback on the usual compile/run tests on different platforms and if there're no issues it'll become final.
I see your fix in there, but none of the ChangeLog/splash/etc. changes that I made afterward.
On Mon, Dec 22, 2014 at 03:41:34PM +0000, eocene wrote:
Jorge wrote:
Here goes rc3:
http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76
Here we expect feedback on the usual compile/run tests on different platforms and if there're no issues it'll become final.
I see your fix in there, but none of the ChangeLog/splash/etc. changes that I made afterward.
Ooops! (sorry) Here goes rc4: http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a Same song... ;) -- Cheers Jorge.-
On Mon, Dec 22, 2014, Jorge Arellano Cid wrote:
On Mon, Dec 22, 2014 at 03:41:34PM +0000, eocene wrote:
Jorge wrote:
Here goes rc3:
http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76
Here we expect feedback on the usual compile/run tests on different platforms and if there're no issues it'll become final.
I see your fix in there, but none of the ChangeLog/splash/etc. changes that I made afterward.
Ooops! (sorry)
Here goes rc4:
http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a
Same song... ;)
No problems here. I assume that noone really expected something else ... Sebastian
Sebastian wrote:
On Mon, Dec 22, 2014, Jorge Arellano Cid wrote:
Here goes rc4:
http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a
Same song... ;)
No problems here. I assume that noone really expected something else ...
Everything seems good for me, too.
Hi
Same song... ;)
I found that shift+arrows in the url bar is doing nothing instead of selecting the text. Ctrl+shift+arrows work fine. Thanks 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
On Mon, Dec 22, 2014 at 11:44:44PM +0000, higuita wrote:
Hi
Same song... ;)
I found that shift+arrows in the url bar is doing nothing instead of selecting the text. Ctrl+shift+arrows work fine.
Same as 3.0.4, not a show stopper. BTW, if there're no more reports/bugs today, it will become 3.0.4.1 final tomorrow. -- Cheers Jorge.-
On Tue, Dec 23, 2014 at 08:41:43PM +0000, eocene wrote:
Jorge wrote:
it will become 3.0.4.1 final tomorrow.
Is freecode still alive enough for you to send out announcements? I'm guessing it isn't.
AFAIK, out of business. The keep the DB but no more updates. It looks like we'll only have to add a note in the web site, besides the announcement to dillo-dev. BTW, Axel (from Debian) and v4hn (from Lunar) have both been following the release process. -- Cheers Jorge.-
Hi, On Tue, Dec 23, 2014 at 07:22:19PM -0300, Jorge Arellano Cid wrote:
On Tue, Dec 23, 2014 at 08:41:43PM +0000, eocene wrote:
Jorge wrote:
it will become 3.0.4.1 final tomorrow.
Is freecode still alive enough for you to send out announcements? I'm guessing it isn't.
AFAIK, out of business. The keep the DB but no more updates.
Yeah, their website is frozen for historical purpose. But it's dead. (Well, probably more undead, but who cares...)
It looks like we'll only have to add a note in the web site, besides the announcement to dillo-dev.
3.0.4.1 final builds and works fine here as package on Debian Unstable, amd64, FLTK 1.3.2. 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)
On Mon, Dec 22, 2014 at 03:12:53PM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 22, 2014 at 03:41:34PM +0000, eocene wrote:
Jorge wrote:
Here goes rc3:
http://www.dillo.org/download/dillo-3.0.4.1-rc3.tar.bz2 md5sum: 7c24aed85b4c39e41e28287503f29d76
Here we expect feedback on the usual compile/run tests on different platforms and if there're no issues it'll become final.
I see your fix in there, but none of the ChangeLog/splash/etc. changes that I made afterward.
Ooops! (sorry)
Here goes rc4:
http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a
Same song... ;)
No problems for me. Cheers, Johannes
On Tue, Dec 23, 2014 at 08:00:05PM +0100, Johannes Hofmann wrote:
On Mon, Dec 22, 2014 at 03:12:53PM -0300, Jorge Arellano Cid wrote:
[...] Ooops! (sorry)
Here goes rc4:
http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a
Same song... ;)
No problems for me.
OK, now there's an official dillo-3.0.4.1 tarball made from rc4, plus release dates in the splash page and Changelog. Please get it from: http://www.dillo.org/download/ And send feedback on compile/run tests so we can update the web site and finally announce it as dillo-3.0.4.1 final. TIA. -- Cheers Jorge.-
On Mi, Dez 24, 2014, Jorge Arellano Cid wrote:
On Tue, Dec 23, 2014 at 08:00:05PM +0100, Johannes Hofmann wrote:
On Mon, Dec 22, 2014 at 03:12:53PM -0300, Jorge Arellano Cid wrote:
[...] Ooops! (sorry)
Here goes rc4:
http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a
Same song... ;)
No problems for me.
OK, now there's an official dillo-3.0.4.1 tarball made from rc4, plus release dates in the splash page and Changelog.
Please get it from:
http://www.dillo.org/download/
And send feedback on compile/run tests so we can update the web site and finally announce it as dillo-3.0.4.1 final.
TIA.
No problems here. Sebastian
On Wed, Dec 24, 2014 at 10:15:09AM -0300, Jorge Arellano Cid wrote:
OK, now there's an official dillo-3.0.4.1 tarball made from rc4, plus release dates in the splash page and Changelog.
Please get it from:
http://www.dillo.org/download/
And send feedback on compile/run tests so we can update the web site and finally announce it as dillo-3.0.4.1 final.
Thanks, works great! v4hn
On Wed, Dec 24, 2014 at 10:15:09AM -0300, Jorge Arellano Cid wrote:
On Tue, Dec 23, 2014 at 08:00:05PM +0100, Johannes Hofmann wrote:
On Mon, Dec 22, 2014 at 03:12:53PM -0300, Jorge Arellano Cid wrote:
[...] Ooops! (sorry)
Here goes rc4:
http://www.dillo.org/download/dillo-3.0.4.1-rc4.tar.bz2 md5sum: ed445fa2ac58d6262d82afbceba2810a
Same song... ;)
No problems for me.
OK, now there's an official dillo-3.0.4.1 tarball made from rc4, plus release dates in the splash page and Changelog.
Please get it from:
http://www.dillo.org/download/
And send feedback on compile/run tests so we can update the web site and finally announce it as dillo-3.0.4.1 final.
TIA.
FWIW, although the NEWS file was updated in the repo after releasing the tarball, we'll keep the same tarball (it's just a minor glitch after all). Thanks to all that helped in the release process. Merry Christmas! -- Cheers Jorge.-
On Wed, Dec 24, 2014 at 10:15:09AM -0300, Jorge Arellano Cid wrote:
OK, now there's an official dillo-3.0.4.1 tarball made from rc4, plus release dates in the splash page and Changelog.
Please get it from:
http://www.dillo.org/download/
And send feedback on compile/run tests so we can update the web site and finally announce it as dillo-3.0.4.1 final.
TIA.
@corvid: please update the front page News when you have the time. -- Cheers Jorge.-
Jorge wrote:
On Mon, Dec 08, 2014 at 12:40:48PM +0100, Sebastian Geerken wrote:
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.
I was thinking how I would prefer it if the built-in "dd" item would go away when I have search URLs in dillorc. Looking at prefsparser.cc, there's if (dList_length(lp) == 2 && !dList_nth_data(lp, 1)) { /* override the default */ void *data = dList_nth_data(lp, 0); dList_remove(lp, data); dList_remove(lp, NULL); dFree(data); } ...so I guess the NULL item was doing something.
participants (10)
-
abe＠deuxchevaux.org -
diegel＠work.de -
eocene＠gmx.com -
frusen＠gungre.ch -
higuita7＠yahoo.co.uk -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
me＠v4hn.de -
sgeerken＠dillo.org