Merry Christmas! I've got presents :-)
Specifically, the latest round of patches: http://dillo-win32.sourceforge.net/dillo/patches.php The biggest changes are the preferences dialog and the libcurl-based downloader, which removes Dillo's dependency on wget and allows it to function as a completely self-contained executable. (By default it's disabled, and Dillo continues to use the old downloads DPI.) There are also various smaller fixes, including a slightly-reworked DNS patch. With static linking and UPX compression, I've got the Windows binary down to a single 1.2MB executable: http://dillo-win32.sourceforge.net/files/dillo.exe Just thought I'd share in case anyone was interested. ~Benjamin
Benjamin wrote:
The biggest changes are the preferences dialog and the libcurl-based downloader, which removes Dillo's dependency on wget and allows it to function as a completely self-contained executable. (By default it's disabled, and Dillo continues to use the old downloads DPI.)
Wow! Naturally one begins to wonder about having such features in the real dillo :)
On Sun, Dec 26, 2010 at 11:16 PM, corvid <corvid@lavabit.com> wrote:
Wow!
Naturally one begins to wonder about having such features in the real dillo :)
If you think it's ready, I'm good to merge :-) On Sun, Dec 26, 2010 at 11:17 PM, corvid <corvid@lavabit.com> wrote:
BTW, I was looking through prefgui... Are you leaking memory in apply()?
I should hope not, but there's a chance -- which lines were you thinking of? I based that code on prefs.c, which does a couple funny-looking things like dStrdup'ing string constants. ~Benjamin
Merry Christmas and nice present :)
From: obeythepenguin@gmail.com Date: Mon, 27 Dec 2010 00:58:00 -0500 Subject: Re: [Dillo-dev] Merry Christmas! I've got presents :-) To: dillo-dev@dillo.org
On Sun, Dec 26, 2010 at 11:16 PM, corvid <corvid@lavabit.com> wrote:
Wow!
Naturally one begins to wonder about having such features in the real dillo :)
If you think it's ready, I'm good to merge :-)
On Sun, Dec 26, 2010 at 11:17 PM, corvid <corvid@lavabit.com> wrote:
BTW, I was looking through prefgui... Are you leaking memory in apply()?
I should hope not, but there's a chance -- which lines were you thinking of? I based that code on prefs.c, which does a couple funny-looking things like dStrdup'ing string constants.
~Benjamin
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Benjamin wrote:
On Sun, Dec 26, 2010 at 11:17 PM, corvid <corvid@lavabit.com> wrote:
BTW, I was looking through prefgui... Are you leaking memory in apply()?
I should hope not, but there's a chance -- which lines were you thinking of? I based that code on prefs.c, which does a couple funny-looking things like dStrdup'ing string constants.
In PrefsParser::parseOption(), when a string or url is changed from its initial value, there's a dFree() or a_Url_free() of the previous value. I didn't notice such freeing in prefsgui.
On Mon, 27 Dec 2010 11:45:39 -0500, corvid <corvid@lavabit.com> wrote:
In PrefsParser::parseOption(), when a string or url is changed from its initial value, there's a dFree() or a_Url_free() of the previous value. I didn't notice such freeing in prefsgui.
Hmm, now that you mention it, that could be a bit of a problem. :-) I've fixed the patch, and while I was at it, I also stopped prefsgui from hard-coding the default user agent string. Oh, and I fixed the paths patch to properly support Windows 9x, since that one was bugging me a while, and updated the dillo.exe binary + installer on SourceForge. ~Benjamin
BTW, I was curious why it handles a subset of the prefs. Are the others not interesting on windows?
On Mon, 27 Dec 2010 13:26:36 -0500, corvid <corvid@lavabit.com> wrote:
BTW, I was curious why it handles a subset of the prefs. Are the others not interesting on windows?
Those are the preferences that struck me personally as most interesting. I didn't implement absolutely everything, because I wanted to keep it fairly simple and user-friendly. In particular: - I didn't do the geometry and show_* options, to avoid cluttering the prefs interface. - I didn't do w3c_plus_heuristics and most of the advanced network options (http_max_conns, etc.), because I don't think most users would understand/need them. I am considering an "Advanced" tab for these options, though. - I didn't do enterpress_forces_submit and middle_click_drags_page, again because I'm not sure how many users would understand/need them. - I didn't do font_max_size, because it can be automatically calculated, and because I think font_min_size is more interesting. Plenty of people have trouble reading very small fonts, while excessively large fonts are uncommon and a minor annoyance at best. - I moved a bunch of options around (compared to the example dillorc) and used the "negated" allow_white_bg because it seemed more logical to me, and more closely resembles the way other browsers do things. Keep in mind, I'm largely targeting "mere mortals" here -- more advanced users, particularly on Unix, are likely to know about and use dillorc directly. But at some point, I'll probably make it at least save the other options, so users can set those manually and still use the prefs gui for everything else. ~Benjamin
On Mon, Dec 27, 2010 at 04:16:13AM +0000, corvid wrote:
Benjamin wrote:
The biggest changes are the preferences dialog and the libcurl-based downloader, which removes Dillo's dependency on wget and allows it to function as a completely self-contained executable. (By default it's disabled, and Dillo continues to use the old downloads DPI.)
Naturally one begins to wonder about having such features in the real dillo :)
I like the libcurl-based downloader. Curl seems to be pretty mature and stable these days. Regards, Jeremy Henty
Jeremy wrote:
On Mon, Dec 27, 2010 at 04:16:13AM +0000, corvid wrote:
Benjamin wrote:
The biggest changes are the preferences dialog and the libcurl-based downloader, which removes Dillo's dependency on wget and allows it to function as a completely self-contained executable. (By default it's disabled, and Dillo continues to use the old downloads DPI.)
Naturally one begins to wonder about having such features in the real dillo :)
I like the libcurl-based downloader. Curl seems to be pretty mature and stable these days.
If we had our own downloader, 1) Downloads would be rejected less often when servers wouldn't see Wget in the user agent string anymore. 2) Maybe the matter of proxies would be a bit less tangled. I wonder whether libcurl makes it simple to retry and continue partial downloads. (I wish dillo itself had some ability to do that, but I don't want to battle with CCC.)
On Mon, 27 Dec 2010 15:02:19 -0500, corvid <corvid@lavabit.com> wrote:
If we had our own downloader, 1) Downloads would be rejected less often when servers wouldn't see Wget in the user agent string anymore.
Admittedly, there is wget's --user-agent option, though that doesn't resolve the overall ugliness of dependency on an external program. That reminds me, I should have it use prefs.http_user_agent rather than the hard-coded string, since that can be overridden and it would look funny having two different user agents. My own builds use a Mozilla/4.0 agent, which is ugly but makes sites like Google behave a little better.
2) Maybe the matter of proxies would be a bit less tangled.
Libcurl obeys $http_proxy, but not prefs.http_proxy (yet). I don't think curl accepts the full URL_STR, so it would have to set the host, port, etc. from the individual DilloUrl fields.
I wonder whether libcurl makes it simple to retry and continue partial downloads. (I wish dillo itself had some ability to do that, but I don't want to battle with CCC.)
Judging from [1], it looks pretty simple: open the file in append mode, and set CURLOPT_RESUME_FROM to the number of bytes already downloaded. Shall I go ahead and add it in? [1] http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ~Benjamin
participants (4)
-
corvid＠lavabit.com -
cs_bittin＠msn.com -
obeythepenguin＠gmail.com -
onepoint＠starurchin.org