- Dillo-dev - lists.mailman3.com

Re: FLTK 1.3.0 RC 1 released!

by jcid＠dillo.org

On Mon, Dec 27, 2010 at 05:45:20PM -0900, rogerx.oss(a)gmail.com wrote: > Dunno about the *other* distros, but Gentoo has several versions of FLTK > available including 2.0_pre branch. And, somebody has volunteered a > FLTK-1.3_rc1 ebuild on bugs.gentoo.org. > > Dillo is extremely important on all my platforms as I use Intel P3 CPU's. That's soothing to hear. > Using any other browser, and I'm just wasting my CPU cycles with unneeded html > scripts -- even with noscript & no-ads plugins for Seamonkey! > > Maybe hook-up with the FLTK mailing list to see if they're really going to push > 1.3? They're committed to it. I've posted some links to their forums from time to time. > From what I read a week ago, they're devoting all efforts on 1.3 and > deprecated 2.0 branch. 2.0 branch might get it's features ported to 1.3. In a nutshell: 2.0 is dead. The remaining developers agreed to cuncur on 1.3 long ago, and to try to release near Christmas (still in the ballpark). -- Cheers Jorge.-

Dec. 28, 2010

FLTK 1.3.0 RC 1 released!

by jcid＠dillo.org

On Mon, Dec 27, 2010 at 07:53:20PM -0500, Rob S. wrote: > [...] > So this is perhaps a little off topic, but what is the status > of dillo with regard to FLTK 1.3.0? ?Will it be ported to that, > or is the plan to continue with the "dead" FLTK 2? As laconically stated in our [Current Plans] link, the idea is to give high priority to the FLTK 1.3 port (for the reasons higuita summarized very well in a former post). -- Cheers Jorge.-

Dec. 28, 2010

A question about the nature of this list

by corvid＠lavabit.com

Rob wrote: > Ok, here is what I am looking at: > http://www3.sympatico.ca/rsquared/images/misc/dillo.png > As you can see, there is a bunch of text that has sort of "scraped off" the page at the top and the bottom of the viewing area as I scroll up and down. ?When I first start the browser, the two areas I have highlighted are clean, but text kind of builds up there until you see the smudgy mess in the picture. ?I have never seen it before - I asked my wife if she has had that trouble with her computer, and she says no. ?I also showed another friend who uses dillo, and she hadn't seen it before either. ?Since I did a standard build, I am starting to wonder if it is maybe faulty hardware on my machine. ?But I wanted to show you all to see if you had seen this before I start checking elsewhere. Almost certainly something wrong in fltk2 or dillo. The situations that I'm aware of that screw up rendering are: - configuring fltk with --enable-cairo - running on OSX Do either of these apply?

Dec. 28, 2010

A question about the nature of this list

by mr_semantics＠hotmail.com

> If you can provide a link to a picture for interested parties > to follow, that'd work well. (Our convention is only to use > attachments for smallish patches.) Ok, here is what I am looking at: http://www3.sympatico.ca/rsquared/images/misc/dillo.png As you can see, there is a bunch of text that has sort of "scraped off" the page at the top and the bottom of the viewing area as I scroll up and down. ?When I first start the browser, the two areas I have highlighted are clean, but text kind of builds up there until you see the smudgy mess in the picture. ?I have never seen it before - I asked my wife if she has had that trouble with her computer, and she says no. ?I also showed another friend who uses dillo, and she hadn't seen it before either. ?Since I did a standard build, I am starting to wonder if it is maybe faulty hardware on my machine. ?But I wanted to show you all to see if you had seen this before I start checking elsewhere. Rob

Dec. 28, 2010

A question about the nature of this list

by corvid＠lavabit.com

Rob wrote: > Is it permissible to ask questions about odd dillo behavior on this list? Yup. > I have a weird issue that I have not encountered before, and it is best > "described" with a picture, but before I post anything, I want to ensure > that it is ok to do so. If you can provide a link to a picture for interested parties to follow, that'd work well. (Our convention is only to use attachments for smallish patches.)

Dec. 28, 2010

A question about the nature of this list

by obeythepenguin＠gmail.com

On Mon, 27 Dec 2010 22:57:21 -0500, Rob S. <mr_semantics(a)hotmail.com> wrote: > Gentlemen,Is it permissible to ask questions about odd dillo behavior on > this list? I have a weird issue that I have not encountered before, and > it is best "described" with a picture, but before I post anything, I > want to ensure that it is ok to do so.Regards, > Rob Somers I think it's OK (but don't quote me on it). I'm certainly intrigued. ~Benjamin

Dec. 28, 2010

A question about the nature of this list

by mr_semantics＠hotmail.com

Gentlemen,? Is it permissible to ask questions about odd dillo behavior on this list? ?I have a weird issue that I have not encountered before, and it is best "described" with a picture, but before I post anything, I want to ensure that it is ok to do so.? Regards, Rob Somers

Dec. 28, 2010

Re: FLTK 1.3.0 RC 1 released!

by rogerx.oss＠gmail.com

Dunno about the *other* distros, but Gentoo has several versions of FLTK available including 2.0_pre branch. And, somebody has volunteered a FLTK-1.3_rc1 ebuild on bugs.gentoo.org. Dillo is extremely important on all my platforms as I use Intel P3 CPU's. Using any other browser, and I'm just wasting my CPU cycles with unneeded html scripts -- even with noscript & no-ads plugins for Seamonkey! Maybe hook-up with the FLTK mailing list to see if they're really going to push 1.3? From what I read a week ago, they're devoting all efforts on 1.3 and deprecated 2.0 branch. 2.0 branch might get it's features ported to 1.3. Cheers! -- Roger http://rogerx.freeshell.org/

Dec. 28, 2010

FLTK 1.3.0 RC 1 released!

by mr_semantics＠hotmail.com

> To: dillo-dev(a)dillo.org > Subject: Re: [Dillo-dev] FLTK 1.3.0 RC 1 released! > Date: Mon, 27 Dec 2010 16:41:04 -0500 > From: obeythepenguin(a)gmail.com > > On Mon, 27 Dec 2010 15:38:55 -0500, Jorge Arellano Cid <jcid(a)dillo.org> > wrote: > > > Mainly GNU/Linux flavours. > > > > Most of them have a policy of not packing unreleased libraries > > (quite understandable if you ask me). FLTK-2.0 was never released > > so, as a most unfortunate side effect, we were left out of the > > repositories. > > That makes sense, though then again I've seen a lot of "released" code in > distributions much worse than FLTK-2.0... > > One thing I like about Windows development is that, with comparatively > little effort, you can produce a single executable that runs on any > Windows system. Binary compatibility isn't possible to nearly that extent > on Linux/Unix -- the software, even the culture makes it limited and > extremely difficult at best. Part of the reason I stopped Unix > development, but I digress. I know you probably see things a bit > differently. > > ~Benjamin My apologies to Mr. Johnson - I am used to another list I am on where hitting reply sends it to the list. ?I should have checked before I hit send. So this is perhaps a little off topic, but what is the status of dillo with regard to FLTK 1.3.0? ?Will it be ported to that, or is the plan to continue with the "dead" FLTK 2?For me, it does not really matter a lot - I just grab the source and build it myself, but I was just curious about the direction you fellows are taking.

Dec. 28, 2010

FLTK 1.3.0 RC 1 released!

by higuita7＠yahoo.co.uk

hi On Mon, 27 Dec 2010 11:48:30 -0500, "Benjamin Johnson" <obeythepenguin(a)gmail.com> wrote: > Out of curiosity, who's not carrying it? It's been a while since I've > run Linux, but OpenBSD has dillo-2.2 in its package tree. Almost all distros/OS with binary packages... fltk 2.0 is not yet released and have a very slow development cycle (ie: almost dead), and that generates two problems: -less software uses the "new", "unstable" and incompatible(with previous versions) lib, creating less demand for distros to use it -as devs dont tell its finish and looks dead, no distro will "waste" time packaging it in beta state, they wait for the "stable" version when it show up sadly, dillo is not important enough yet to pressure distros to use it and many distros don like statically linked binaries For source distros/OS, its easier, grab what is in the repository and forget... if its broken its upstream fault.. if its dead, its user fault :) right now, the main linux distros (ubuntu, debian, fedora, opensuse) none have fltk2 binary package released. Of course, all can be build from source, but most (binary distros/OS) users dont want/know to build a package cya 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. 27, 2010

FLTK 1.3.0 RC 1 released!

by obeythepenguin＠gmail.com

On Mon, 27 Dec 2010 15:38:55 -0500, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Mainly GNU/Linux flavours. > > Most of them have a policy of not packing unreleased libraries > (quite understandable if you ask me). FLTK-2.0 was never released > so, as a most unfortunate side effect, we were left out of the > repositories. That makes sense, though then again I've seen a lot of "released" code in distributions much worse than FLTK-2.0... One thing I like about Windows development is that, with comparatively little effort, you can produce a single executable that runs on any Windows system. Binary compatibility isn't possible to nearly that extent on Linux/Unix -- the software, even the culture makes it limited and extremely difficult at best. Part of the reason I stopped Unix development, but I digress. I know you probably see things a bit differently. ~Benjamin

Dec. 27, 2010

FLTK 1.3.0 RC 1 released!

by jcid＠dillo.org

On Mon, Dec 27, 2010 at 11:48:30AM -0500, Benjamin Johnson wrote: > On Mon, 27 Dec 2010 11:26:05 -0500, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > >Hi there, > > > > Good news, it looks as though FLTK-1.3.0 is close to an > >official release. This is an important fact because once dillo is > >ported to it, distros repos could carry dillo again. > > > > http://fltk.org/articles.php?L1028 > > > > Out of curiosity, who's not carrying it? It's been a while since > I've run Linux, but OpenBSD has dillo-2.2 in its package tree. Mainly GNU/Linux flavours. Most of them have a policy of not packing unreleased libraries (quite understandable if you ask me). FLTK-2.0 was never released so, as a most unfortunate side effect, we were left out of the repositories. -- Cheers Jorge.-

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by obeythepenguin＠gmail.com

On Mon, 27 Dec 2010 15:02:19 -0500, corvid <corvid(a)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

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by corvid＠lavabit.com

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

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by onepoint＠starurchin.org

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

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by obeythepenguin＠gmail.com

On Mon, 27 Dec 2010 13:26:36 -0500, corvid <corvid(a)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

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by corvid＠lavabit.com

BTW, I was curious why it handles a subset of the prefs. Are the others not interesting on windows?

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by obeythepenguin＠gmail.com

On Mon, 27 Dec 2010 11:45:39 -0500, corvid <corvid(a)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

Dec. 27, 2010

FLTK 1.3.0 RC 1 released!

by obeythepenguin＠gmail.com

On Mon, 27 Dec 2010 11:26:05 -0500, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi there, > > Good news, it looks as though FLTK-1.3.0 is close to an > official release. This is an important fact because once dillo is > ported to it, distros repos could carry dillo again. > > http://fltk.org/articles.php?L1028 > Out of curiosity, who's not carrying it? It's been a while since I've run Linux, but OpenBSD has dillo-2.2 in its package tree. ~Benjamin

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by corvid＠lavabit.com

Benjamin wrote: > On Sun, Dec 26, 2010 at 11:17 PM, corvid <corvid(a)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.

Dec. 27, 2010

FLTK 1.3.0 RC 1 released!

by jcid＠dillo.org

Hi there, Good news, it looks as though FLTK-1.3.0 is close to an official release. This is an important fact because once dillo is ported to it, distros repos could carry dillo again. http://fltk.org/articles.php?L1028 -- Cheers Jorge.-

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by cs_bittin＠msn.com

Merry Christmas and nice present :) > From: obeythepenguin(a)gmail.com > Date: Mon, 27 Dec 2010 00:58:00 -0500 > Subject: Re: [Dillo-dev] Merry Christmas! I've got presents :-) > To: dillo-dev(a)dillo.org > > On Sun, Dec 26, 2010 at 11:16 PM, corvid <corvid(a)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(a)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(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by obeythepenguin＠gmail.com

On Sun, Dec 26, 2010 at 11:16 PM, corvid <corvid(a)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(a)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

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by corvid＠lavabit.com

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 :)

Dec. 27, 2010

Merry Christmas! I've got presents :-)

by obeythepenguin＠gmail.com

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

Dec. 27, 2010

Re: complex buttons and limit text width

by Johannes.Hofmann＠gmx.de

On Tue, Nov 30, 2010 at 09:15:26PM +0100, Johannes Hofmann wrote: > On Tue, Nov 30, 2010 at 07:07:40PM +0000, corvid wrote: > > Do you remember whether that was a Hard Problem, or just > > one that we didn't get around to looking into? > > I don't remember, but a 100% CPU hog sounds fixable. Haha, famous last words. I still didn't find cause. It's a redraw loop somehow. Cheers, Johannes

Dec. 20, 2010

[patch]: CSS parser cleanup and media-conditional @import.

by Johannes.Hofmann＠gmx.de

On Sat, Dec 18, 2010 at 05:26:05PM +0000, Jeremy Henty wrote: > On Sat, Dec 18, 2010 at 01:51:02PM +0100, Johannes Hofmann wrote: > > > > for some reason I thought I had already answered this... > > That's strange! The only record I have (in memory or file system) is > a reply from corvid. Maybe I'm losing track! :-) No no, it was me loosing track. I checked my sent mail and I hadn't sent the reply - I just thought I did :-)

Dec. 18, 2010

[patch]: CSS parser cleanup and media-conditional @import.

by onepoint＠starurchin.org

On Sat, Dec 18, 2010 at 01:51:02PM +0100, Johannes Hofmann wrote: > > for some reason I thought I had already answered this... That's strange! The only record I have (in memory or file system) is a reply from corvid. Maybe I'm losing track! :-) > Anyway, I already looked at it and tested it a little and it seems > fine to me. > Just go ahead and commit. Thanks, it's done. Regards, Jeremy Henty

Dec. 18, 2010

[patch]: CSS parser cleanup and media-conditional @import.

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Dec 18, 2010 at 01:59:09AM +0000, Jeremy Henty wrote: > > Reposting my CSS parser cleanup patches and adding the implementation > of CSS2 media-conditional @import rules. Please comment. for some reason I thought I had already answered this... Anyway, I already looked at it and tested it a little and it seems fine to me. Just go ahead and commit. Cheers, Johannes

Dec. 18, 2010

[patch]: CSS parser cleanup and media-conditional @import.

by onepoint＠starurchin.org

Reposting my CSS parser cleanup patches and adding the implementation of CSS2 media-conditional @import rules. Please comment. Regards, Jeremy Henty

Dec. 18, 2010

patch: border-color: transparent

by Johannes.Hofmann＠gmx.de

On Tue, Dec 14, 2010 at 04:23:53PM +0000, corvid wrote: > Jorge wrote: > > Is there an open-issue/reason-not-to-commit it? > > I just wanted others to have a look at it first since I don't know > cssparser/styleengine in any detail. Looks good to me. Cheers, Johannes

Dec. 14, 2010

patch: border-color: transparent

by corvid＠lavabit.com

Jorge wrote: > Is there an open-issue/reason-not-to-commit it? I just wanted others to have a look at it first since I don't know cssparser/styleengine in any detail.

Dec. 14, 2010

patch: border-color: transparent

by jcid＠dillo.org

On Tue, Dec 14, 2010 at 02:02:08AM +0000, corvid wrote: > With user agent set to firefox, google likes to give me a > border-color: transparent, and I was tired of the no-values msg. It looks OK, according to the SPEC: <quote CSS3> 4.2.3. "transparent" color keyword CSS1 introduced the "transparent" value for the background-color property. CSS2 allowed border-color to also accept the "transparent" value. The Open eBook(tm) Publication Structure 1.0.1 [OEB101] extended the "color" property to also accept the "transparent" keyword. CSS3 extends the color value to include the "transparent" keyword to allow its use with all properties that accept a <color> value. This simplifies the definition of those properties in CSS3. transparent Fully transparent. This keyword can be considered a shorthand for transparent black, rgba(0,0,0,0), which is its computed value. </quote> Is there an open-issue/reason-not-to-commit it? -- Cheers Jorge.-

Dec. 14, 2010

[patch]: CSS parser cleanup

by onepoint＠starurchin.org

On Tue, Dec 14, 2010 at 02:10:49AM +0000, corvid wrote: > Jeremy wrote: > > diff -r 6276951c09ca -r 863857740f7f src/cssparser.cc > > --- a/src/cssparser.cc Sun Dec 05 16:45:24 2010 +0000 > > +++ b/src/cssparser.cc Sun Dec 05 18:50:21 2010 +0000 > > @@ -1422,12 +1422,7 @@ > > else if (ttype == CSS_TK_STRING) > > urlStr = dStrdup (tval); > > > > - /* Skip all tokens until the expected end. */ > > - while (!(ttype == CSS_TK_END || > > - (ttype == CSS_TK_CHAR && (tval[0] == ';')))) > > - nextToken(); > > - > > - nextToken(); > > + ignoreStatement(); > > > > if (urlStr) { > > MSG("CssParser::parseImport(): @import %s\n", urlStr); > > I just wanted to mention that CSS2 says that there can be media types > after the URL there... Next on the TO DO list! But I don't think this patch will block implementing that - just call nextToken() before ignoreStatement() and do the right thing if it's a string. Regards, Jeremy Henty

Dec. 14, 2010

[patch]: CSS parser cleanup

by corvid＠lavabit.com

Jeremy wrote: > diff -r 6276951c09ca -r 863857740f7f src/cssparser.cc > --- a/src/cssparser.cc Sun Dec 05 16:45:24 2010 +0000 > +++ b/src/cssparser.cc Sun Dec 05 18:50:21 2010 +0000 > @@ -1422,12 +1422,7 @@ > else if (ttype == CSS_TK_STRING) > urlStr = dStrdup (tval); > > - /* Skip all tokens until the expected end. */ > - while (!(ttype == CSS_TK_END || > - (ttype == CSS_TK_CHAR && (tval[0] == ';')))) > - nextToken(); > - > - nextToken(); > + ignoreStatement(); > > if (urlStr) { > MSG("CssParser::parseImport(): @import %s\n", urlStr); I just wanted to mention that CSS2 says that there can be media types after the URL there...

Dec. 14, 2010

patch: border-color: transparent

by corvid＠lavabit.com

With user agent set to firefox, google likes to give me a border-color: transparent, and I was tired of the no-values msg.

Dec. 14, 2010

[henry@compdata.org: Dillo 2.2 NetBSD macppc StrawBerry iMac 333]

by onepoint＠starurchin.org

On Mon, Dec 13, 2010 at 12:34:55PM -0300, Jorge Arellano Cid wrote: > On Mon, Dec 13, 2010 at 07:21:44AM +0000, Jeremy Henty wrote: > > > > That's cool! Is there a list of platforms that Dillo is known to > > run on? I looked around the web site but couldn't find any such > > thing. > > The [Compatibility] link (6th in left column). Wow! That's an impressive list! Jeremy

Dec. 13, 2010

[henry@compdata.org: Dillo 2.2 NetBSD macppc StrawBerry iMac 333]

by jcid＠dillo.org

On Mon, Dec 13, 2010 at 07:21:44AM +0000, Jeremy Henty wrote: > On Fri, Dec 10, 2010 at 06:13:25PM -0300, Jorge Arellano Cid wrote: > > FYI, > > > > -- > > Cheers > > Jorge.- > > > Just compiled and installed Dillo on an Apple Strawberry iMac 333. > > Platform: NetBSD 5.1 macppc > > That's cool! Is there a list of platforms that Dillo is known to run > on? I looked around the web site but couldn't find any such thing. The [Compatibility] link (6th in left column). -- Cheers Jorge.-

Dec. 13, 2010

Yong Li wants to stay in touch on LinkedIn

by sdliyong＠gmail.com

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Yong Li Yong Li platform software developer at Hewlett-Packard China Confirm that you know Yong Li https://www.linkedin.com/e/m1sm8i-ghnbkyy3-6p/isd/2018522004/2K69vPKA/ -- (c) 2010, LinkedIn Corporation

Dec. 13, 2010

[patch]: CSS parser cleanup

by onepoint＠starurchin.org

Just some small cleanup and refactoring of the CSS parser code. Any reason not to push these? Regards, Jeremy Henty

Dec. 13, 2010

[henry@compdata.org: Dillo 2.2 NetBSD macppc StrawBerry iMac 333]

by onepoint＠starurchin.org

On Fri, Dec 10, 2010 at 06:13:25PM -0300, Jorge Arellano Cid wrote: > FYI, > > -- > Cheers > Jorge.- > Just compiled and installed Dillo on an Apple Strawberry iMac 333. > Platform: NetBSD 5.1 macppc That's cool! Is there a list of platforms that Dillo is known to run on? I looked around the web site but couldn't find any such thing. Regards, Jeremy Henty

Dec. 13, 2010

[henry@compdata.org: Dillo 2.2 NetBSD macppc StrawBerry iMac 333]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Dec. 10, 2010

[patch]: dpip.c: remove unused static

by onepoint＠starurchin.org

On Tue, Dec 07, 2010 at 01:24:27PM -0300, Jorge Arellano Cid wrote: > On Tue, Dec 07, 2010 at 03:30:20PM +0000, corvid wrote: > > Jeremy wrote: > > > Does anyone know what the static variable DpipTag in dpip.c was used > > > for? It's not used any more. Shall I push this? > > > > It appears to have been introduced in revision 1385, and I don't > > see it being used for anything even then. > > Most probably me, experimenting with the protocol making a > difference between a dpip tag and raw data. > > Currently raw data is escaped within dpip tags so it's safe to > remove. Done. Regards, Jeremy Henty

Dec. 7, 2010

[patch]: dpip.c: remove unused static

by jcid＠dillo.org

On Tue, Dec 07, 2010 at 03:30:20PM +0000, corvid wrote: > Jeremy wrote: > > Does anyone know what the static variable DpipTag in dpip.c was used > > for? It's not used any more. Shall I push this? > > It appears to have been introduced in revision 1385, and I don't > see it being used for anything even then. Most probably me, experimenting with the protocol making a difference between a dpip tag and raw data. Currently raw data is escaped within dpip tags so it's safe to remove. -- Cheers Jorge.-

Dec. 7, 2010

[patch]: dpip.c: remove unused static

by corvid＠lavabit.com

Jeremy wrote: > Does anyone know what the static variable DpipTag in dpip.c was used > for? It's not used any more. Shall I push this? It appears to have been introduced in revision 1385, and I don't see it being used for anything even then.

Dec. 7, 2010

[patch]: dpip.c: remove unused static

by onepoint＠starurchin.org

Does anyone know what the static variable DpipTag in dpip.c was used for? It's not used any more. Shall I push this? Regards, Jeremy Henty

Dec. 7, 2010

[patch]: fix the obsolete usage of AC_OUTPUT

by corvid＠lavabit.com

Jeremy wrote: > On Thu, Dec 02, 2010 at 11:28:51AM -0300, Jorge Arellano Cid wrote: > > On Thu, Dec 02, 2010 at 01:08:54PM +0000, Jeremy Henty wrote: > > > > > > Bump? Is this OK? ... > > > > It looks OK to me. Especially after reading the AC_OUTPUT section in > > http://www.gnu.org/software/hello/manual/autoconf/Obsolete-Macros.html#Obso… > > > > I'd say: commit, and let's see whether a hidden issue arises. > > OK, I'll hang on to it over the weekend and then push it if there are > no other comments. I had looked at the docs and it seemed all right to me as well, but of course I'm no autoconf expert either.

Dec. 3, 2010

[patch]: fix the obsolete usage of AC_OUTPUT

by onepoint＠starurchin.org

On Thu, Dec 02, 2010 at 11:28:51AM -0300, Jorge Arellano Cid wrote: > On Thu, Dec 02, 2010 at 01:08:54PM +0000, Jeremy Henty wrote: > > > > Bump? Is this OK? ... > > It looks OK to me. Especially after reading the AC_OUTPUT section in > http://www.gnu.org/software/hello/manual/autoconf/Obsolete-Macros.html#Obso… > > I'd say: commit, and let's see whether a hidden issue arises. OK, I'll hang on to it over the weekend and then push it if there are no other comments. Regards, Jeremy Henty

Dec. 3, 2010

[patch]: fix the obsolete usage of AC_OUTPUT

by jcid＠dillo.org

On Thu, Dec 02, 2010 at 01:08:54PM +0000, Jeremy Henty wrote: > > Bump? Is this OK? Personally I think it's a no-brainer but I didn't > to change the build system in any way without feedback. Please > comment. It looks OK to me. Especially after reading the AC_OUTPUT section in http://www.gnu.org/software/hello/manual/autoconf/Obsolete-Macros.html#Obso… I'd say: commit, and let's see whether a hidden issue arises. > On Sun, Nov 28, 2010 at 05:06:17PM +0000, Jeremy Henty wrote: > > > > While implementing the Lua DPI I saw that configure.in uses AC_OUTPUT > > in an obsolete way. This patch changes it to use the modern calling > > convention. (It also puts each of the generated files on a separate > > line, which makes it much easier to read patches that modify that > > list.) > > > > Regards, > > > > Jeremy Henty > > > # HG changeset patch > > # Parent d21e2c45d0f9a2e1a6bb718132f948d48f619a73 > > configure.in: fix the obsolete usage of AC_OUTPUT. > > > > diff -r d21e2c45d0f9 configure.in > > --- a/configure.in Sun Nov 28 08:07:52 2010 +0000 > > +++ b/configure.in Sun Nov 28 16:52:48 2010 +0000 > > @@ -511,5 +511,18 @@ > > AC_SUBST(LIBICONV_LIBS) > > AC_SUBST(datadir) > > > > -AC_OUTPUT(Makefile dlib/Makefile dpip/Makefile dpid/Makefile dpi/Makefile doc/Makefile dw/Makefile lout/Makefile src/Makefile src/IO/Makefile test/Makefile) > > +AC_CONFIG_FILES([ > > + Makefile > > + dlib/Makefile > > + dpip/Makefile > > + dpid/Makefile > > + dpi/Makefile > > + doc/Makefile > > + dw/Makefile > > + lout/Makefile > > + src/Makefile > > + src/IO/Makefile > > + test/Makefile > > +]) > > > > +AC_OUTPUT > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Cheers Jorge.-

Dec. 2, 2010

[patch]: fix the obsolete usage of AC_OUTPUT

by onepoint＠starurchin.org

Bump? Is this OK? Personally I think it's a no-brainer but I didn't to change the build system in any way without feedback. Please comment. Regards, Jeremy Henty On Sun, Nov 28, 2010 at 05:06:17PM +0000, Jeremy Henty wrote: > > While implementing the Lua DPI I saw that configure.in uses AC_OUTPUT > in an obsolete way. This patch changes it to use the modern calling > convention. (It also puts each of the generated files on a separate > line, which makes it much easier to read patches that modify that > list.) > > Regards, > > Jeremy Henty > # HG changeset patch > # Parent d21e2c45d0f9a2e1a6bb718132f948d48f619a73 > configure.in: fix the obsolete usage of AC_OUTPUT. > > diff -r d21e2c45d0f9 configure.in > --- a/configure.in Sun Nov 28 08:07:52 2010 +0000 > +++ b/configure.in Sun Nov 28 16:52:48 2010 +0000 > @@ -511,5 +511,18 @@ > AC_SUBST(LIBICONV_LIBS) > AC_SUBST(datadir) > > -AC_OUTPUT(Makefile dlib/Makefile dpip/Makefile dpid/Makefile dpi/Makefile doc/Makefile dw/Makefile lout/Makefile src/Makefile src/IO/Makefile test/Makefile) > +AC_CONFIG_FILES([ > + Makefile > + dlib/Makefile > + dpip/Makefile > + dpid/Makefile > + dpi/Makefile > + doc/Makefile > + dw/Makefile > + lout/Makefile > + src/Makefile > + src/IO/Makefile > + test/Makefile > +]) > > +AC_OUTPUT

Dec. 2, 2010