- Dillo-dev - lists.mailman3.com

Digest authentication

by furaisanjin＠gmail.com

Sorry about confusion. 2011/10/11 corvid <corvid at lavabit.com>: > furaisanjin wrote: >> 2011/10/11 corvid <corvid at lavabit.com>: >> > Is there a site that isn't working? >> >> http://x68000.q-e-d.net/~68user/net/sample/http-auth-digest/secret.html >> >> This is just a test page and user name is hoge and password is fuga. > > It seems to work for me. I give user and pass, and then it shows me > a page with "Digest" and some Japanese text that I don't know how > to read. Originally I detected digest authentication problem with my DVD recorder. I put some debug code to see the behavior but I put extra quote like algorithm="MD5". This caused the problem to access the page mentioned above. >> > a_Digest_compute_digest() calculates A1 for MD5 and MD5-sess, >> > but I disabled digest auth for MD5-sess in >> > Auth_parse_digest_challenge_cb() because >> > http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestalgorit… >> > said "MD5-sess is not correctly implemented yet", which prevented >> > me from giving it much testing. >> >> RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html) mentions how A1 is >> calculated in 3.2.2.2 and MD5-sess >> requires more parameters and A1 is calculated only once but A1 is also >> calculated for MD5 and none >> specified algorithm. > > This is what a_Digest_compute_digest() does. Yes, I was looking at wrong place. The problems of my DVD recorder are 1 it doesn't allow extra space characters between '='. 2 uri needs to have quote 3 the order of parameter seems to have strict rule (username, realm, nonce, uri, cnonce, nc, algorithm, response, qop) Both IE and firefox follow 1 and 2 but only IE follows 3. Regards, furaisanjin

Oct. 11, 2011

Digest authentication

by corvid＠lavabit.com

furaisanjin wrote: > 2011/10/11 corvid <corvid at lavabit.com>: > > Is there a site that isn't working? > > http://x68000.q-e-d.net/~68user/net/sample/http-auth-digest/secret.html > > This is just a test page and user name is hoge and password is fuga. It seems to work for me. I give user and pass, and then it shows me a page with "Digest" and some Japanese text that I don't know how to read. > > a_Digest_compute_digest() calculates A1 for MD5 and MD5-sess, > > but I disabled digest auth for MD5-sess in > > Auth_parse_digest_challenge_cb() because > > http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestalgorit… > > said "MD5-sess is not correctly implemented yet", which prevented > > me from giving it much testing. > > RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html) mentions how A1 is > calculated in 3.2.2.2 and MD5-sess > requires more parameters and A1 is calculated only once but A1 is also > calculated for MD5 and none > specified algorithm. This is what a_Digest_compute_digest() does.

Oct. 10, 2011

Digest authentication

by furaisanjin＠gmail.com

2011/10/11 corvid <corvid at lavabit.com>: > Is there a site that isn't working? http://x68000.q-e-d.net/~68user/net/sample/http-auth-digest/secret.html This is just a test page and user name is hoge and password is fuga. > a_Digest_compute_digest() calculates A1 for MD5 and MD5-sess, > but I disabled digest auth for MD5-sess in > Auth_parse_digest_challenge_cb() because > http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestalgorit… > said "MD5-sess is not correctly implemented yet", which prevented > me from giving it much testing. RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html) mentions how A1 is calculated in 3.2.2.2 and MD5-sess requires more parameters and A1 is calculated only once but A1 is also calculated for MD5 and none specified algorithm. Regards, furaisanjin

Oct. 10, 2011

Digest authentication

by corvid＠lavabit.com

furaisanjin wrote: > It seems that current digest authentication doesn't supportsA1 > calculation. Is there any plan when this is implemented? Is there a site that isn't working? a_Digest_compute_digest() calculates A1 for MD5 and MD5-sess, but I disabled digest auth for MD5-sess in Auth_parse_digest_challenge_cb() because http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestalgorit… said "MD5-sess is not correctly implemented yet", which prevented me from giving it much testing.

Oct. 10, 2011

Digest authentication

by furaisanjin＠gmail.com

Hi all. It seems that current digest authentication doesn't supportsA1 calculation. Is there any plan when this is implemented? Regards, furaisanjin

Oct. 10, 2011

Dillo review article

by rogerx.oss＠gmail.com

> If the tools menu holds a "My CSS" menu entry, holding a list >of custom style sheets (.css files in ~/.dillo/), and allowing to >apply it on-the-fly (similar to "Panel Size"), it would be quite >handy. The only real use I see with different styles are those whom work at night, or are just light sensitive (AKA old age) like me. (Aside from those that want pretty colors.) > We may include some pre-made ones, as the dark background Rogut >suggested (readability), larger font, etc. <shrugs> I'm still using the suggested dark style css posted to this thread. Haven't had any issues with it yet, else I would have switched back to default. One issue I recall now, there is a flash of total white background on page reload. If any page flashing, should use the default background color within the style css settings. >> [...] >> When browsing at night, I sometimes use the following snippet with >> Firefox. Works with dillo too. Colors could use some tweaking. >> >> * { >> font-family: 'M+ 1p' !important; >> background:#1E2426 !important; >> color:#C7C7C7 !important; >> border-color:#6B8299 !important; >> border-width:0.1em !important; >> } >> a { color:#C17B6C !important; } >> hr, h1, h2, h3, h4 { margin-bottom:0.2em !important; } >> th, td { padding:0.1em !important; } >> a { text-decoration:underline !important; border:none !important; } >> a:hover { text-decoration:none !important; } >> input, select, button, textarea { color:#548A1E !important; } > > Just appended this line: > > :visited {color: #008080 !important} > > to it. Yea, the links can be tricky when changing colors. -- Roger http://rogerx.freeshell.org/

Oct. 10, 2011

Dillo review article

by jcid＠dillo.org

On Fri, Oct 07, 2011 at 11:05:03AM +0300, Rogut??s Sparnuotos wrote: > Roger (2011-10-06 19:59): > > > On Thu, Oct 06, 2011 at 08:24:18PM +0000, corvid wrote: > > >Roger wrote: > > >> 2) Should there be at least a style.css template file within the tarball doc > > >> folder for users to play with? This is an interesting idea... Funny how the article was able to make us (in dillo-dev) put some atention in style.css again. I just discovered that the file is re-read each time. There's no need to load another dillo to test changes to it. Just reload the page you're viewing. If the tools menu holds a "My CSS" menu entry, holding a list of custom style sheets (.css files in ~/.dillo/), and allowing to apply it on-the-fly (similar to "Panel Size"), it would be quite handy. We may include some pre-made ones, as the dark background Rogut suggested (readability), larger font, etc. > [...] > When browsing at night, I sometimes use the following snippet with > Firefox. Works with dillo too. Colors could use some tweaking. > > * { > font-family: 'M+ 1p' !important; > background:#1E2426 !important; > color:#C7C7C7 !important; > border-color:#6B8299 !important; > border-width:0.1em !important; > } > a { color:#C17B6C !important; } > hr, h1, h2, h3, h4 { margin-bottom:0.2em !important; } > th, td { padding:0.1em !important; } > a { text-decoration:underline !important; border:none !important; } > a:hover { text-decoration:none !important; } > input, select, button, textarea { color:#548A1E !important; } Just appended this line: :visited {color: #008080 !important} to it. -- Cheers Jorge.-

Oct. 9, 2011

Dillo review article

by rogerx.oss＠gmail.com

> On Fri, Oct 07, 2011 at 11:05:03AM +0300, Rogut?s Sparnuotos wrote: >Roger (2011-10-06 19:59): >> > On Thu, Oct 06, 2011 at 08:24:18PM +0000, corvid wrote: >> >Roger wrote: >> >> 2) Should there be at least a style.css template file within the tarball doc >> >> folder for users to play with? >> > >> >What would be interesting to have in a sample style.css? >> >All I have in mine is...let's see... >> >":link, :visited {text-decoration: underline !important}" >> > >> >Colors, maybe... >> >> Just my thoughts on this, I don't customize the layouts much from the >> default as page formating gets screwed-up when viewing heavily formated >> websites. ie. CNN, FoxNews, ... >> >> In the past, I tried formating pages to use light fonts on a dark >> background, but as stated above, I would always encounter problems with >> other websites page colors. Since trying this 5+ years ago, just gave >> up and decided viewing the page as it was intended. Also conflicts if >> the user tries to print the page too. >> >> As such, we can see why styles.css obviously doesn't get much attention >> due to the above issues. And for resolving screen brightness when I >> have a headache, I just use a CLI browser called ELinks. > >When browsing at night, I sometimes use the following snippet with >Firefox. Works with dillo too. Colors could use some tweaking. > >* { > font-family: 'M+ 1p' !important; > background:#1E2426 !important; > color:#C7C7C7 !important; > border-color:#6B8299 !important; > border-width:0.1em !important; >} >a { color:#C17B6C !important; } >hr, h1, h2, h3, h4 { margin-bottom:0.2em !important; } >th, td { padding:0.1em !important; } >a { text-decoration:underline !important; border:none !important; } >a:hover { text-decoration:none !important; } >input, select, button, textarea { color:#548A1E !important; } > >-- >-- Rogut?s Sparnuotos Tested here and it looks pretty good to put a commented section like this within the style.css file. The snippet above could use some comments within each statement though, so a user can modify the background and font colors at first glance here though. (In other words, I've seen some really nice commented xml/css stylesheets from News sites which I could easily read. ;-) -- Roger http://rogerx.freeshell.org/

Oct. 7, 2011

Dillo review article

by rogutes＠googlemail.com

Roger (2011-10-06 19:59): > > On Thu, Oct 06, 2011 at 08:24:18PM +0000, corvid wrote: > >Roger wrote: > >> 2) Should there be at least a style.css template file within the tarball doc > >> folder for users to play with? > > > >What would be interesting to have in a sample style.css? > >All I have in mine is...let's see... > >":link, :visited {text-decoration: underline !important}" > > > >Colors, maybe... > > Just my thoughts on this, I don't customize the layouts much from the > default as page formating gets screwed-up when viewing heavily formated > websites. ie. CNN, FoxNews, ... > > In the past, I tried formating pages to use light fonts on a dark > background, but as stated above, I would always encounter problems with > other websites page colors. Since trying this 5+ years ago, just gave > up and decided viewing the page as it was intended. Also conflicts if > the user tries to print the page too. > > As such, we can see why styles.css obviously doesn't get much attention > due to the above issues. And for resolving screen brightness when I > have a headache, I just use a CLI browser called ELinks. When browsing at night, I sometimes use the following snippet with Firefox. Works with dillo too. Colors could use some tweaking. * { font-family: 'M+ 1p' !important; background:#1E2426 !important; color:#C7C7C7 !important; border-color:#6B8299 !important; border-width:0.1em !important; } a { color:#C17B6C !important; } hr, h1, h2, h3, h4 { margin-bottom:0.2em !important; } th, td { padding:0.1em !important; } a { text-decoration:underline !important; border:none !important; } a:hover { text-decoration:none !important; } input, select, button, textarea { color:#548A1E !important; } -- -- Rogut?s Sparnuotos

Oct. 7, 2011

Dillo review article

by rogerx.oss＠gmail.com

> On Thu, Oct 06, 2011 at 08:24:18PM +0000, corvid wrote: >Roger wrote: >> 2) Should there be at least a style.css template file within the tarball doc >> folder for users to play with? > >What would be interesting to have in a sample style.css? >All I have in mine is...let's see... >":link, :visited {text-decoration: underline !important}" > >Colors, maybe... Just my thoughts on this, I don't customize the layouts much from the default as page formating gets screwed-up when viewing heavily formated websites. ie. CNN, FoxNews, ... In the past, I tried formating pages to use light fonts on a dark background, but as stated above, I would always encounter problems with other websites page colors. Since trying this 5+ years ago, just gave up and decided viewing the page as it was intended. Also conflicts if the user tries to print the page too. As such, we can see why styles.css obviously doesn't get much attention due to the above issues. And for resolving screen brightness when I have a headache, I just use a CLI browser called ELinks. -- Roger http://rogerx.freeshell.org/

Oct. 7, 2011

Dillo review article

by rogerx.oss＠gmail.com

> On Thu, Oct 06, 2011 at 08:20:35PM +0000, corvid wrote: >Roger wrote: >> > On Thu, Oct 06, 2011 at 08:11:52AM -0300, Jorge Arellano Cid wrote: >> >Hi there, >> > >> > This may be worth adding to our "Dillo in the Press" section: >> > >> > http://www.linuxinsider.com/story/For-Fast-Light-Web-Browsing-Dillos-No-Dal… >> >> Just read the first sentence and boy is he wrong! > >I've never seen one of these articles without a number of...issues, >which I suppose is unavoidable when you've just started playing with >it a little bit. > >- He talks about --enable-cookies instead of cookiesrc. >- It sounds like his distribution has fullwindow_start set, which strikes > me as the wrong thing by default. >- He's using an old version if it uses Ctrl-Q and Alt-Q and doesn't have > panel size in the menu. >- It's surprising to mention style.css instead of dillorc. I was just joking, but stating how I love that I can actually use a minimal browser with such a useful site such as Amazon.com's search feature. However, on my second post to this thread, I did notice too the style.css mention was likely mistaken for the dillorc file. (I do this all the time myself when learning new features/functions. :-/ ) As to what to put in a default style.css file? I'm having problems with just "converting XML to HTML" and "other formats to MOBI (E-Book XML markup)" As such, I admit I know just enough to interpret and use css style sheets. If the style.css file is for styling fonts (aka theme), I'm terrible at styling and feel that one terminal font is just fine and dandy as long as I can read it. The site requires a user:pass account, so can't immediately post a comment suggesting the author really meant dillorc. -- Roger http://rogerx.freeshell.org/

Oct. 6, 2011

[patch]: download window resizes its contents to its width

by onepoint＠starurchin.org

Purely cosmetic, but I dislike it when the contents ignore their container, even in only one out of two dimensions. Comments? Regards, Jeremy Henty

Oct. 6, 2011

Dillo review article

by corvid＠lavabit.com

Roger wrote: > 2) Should there be at least a style.css template file within the tarball doc > folder for users to play with? What would be interesting to have in a sample style.css? All I have in mine is...let's see... ":link, :visited {text-decoration: underline !important}" Colors, maybe...

Oct. 6, 2011

Dillo review article

by corvid＠lavabit.com

Roger wrote: > > On Thu, Oct 06, 2011 at 08:11:52AM -0300, Jorge Arellano Cid wrote: > >Hi there, > > > > This may be worth adding to our "Dillo in the Press" section: > > > > http://www.linuxinsider.com/story/For-Fast-Light-Web-Browsing-Dillos-No-Dal… > > Just read the first sentence and boy is he wrong! I've never seen one of these articles without a number of...issues, which I suppose is unavoidable when you've just started playing with it a little bit. - He talks about --enable-cookies instead of cookiesrc. - It sounds like his distribution has fullwindow_start set, which strikes me as the wrong thing by default. - He's using an old version if it uses Ctrl-Q and Alt-Q and doesn't have panel size in the menu. - It's surprising to mention style.css instead of dillorc.

Oct. 6, 2011

Dillo review article

by rogerx.oss＠gmail.com

> On Thu, Oct 06, 2011 at 08:11:52AM -0300, Jorge Arellano Cid wrote: >Hi there, > > This may be worth adding to our "Dillo in the Press" section: > > http://www.linuxinsider.com/story/For-Fast-Light-Web-Browsing-Dillos-No-Dal… > > :-) Just read the full article and noticed this on about the second to last paragraph: "But if you insist, open the plain text file called "style.css" in the .dillo folder. This file uses standard cascading style sheet definitions." I'm not seeing this file within my install or within my $HOME/.dillo folder. Further searching the dillo-3.0.1 tarball shows no template style.css files. Grepping the tarball shows me there's mention within the dillo manual page only along with a few relevant code statements within the tarball, but I can't see enough to verify this file is created on $HOME/.dillo folder creation. 1) How did he get a style.css file created automagically when I don't get one automagically created? (Is he more special then me?) Grepping the code only shows a few statements for this file, which leads me to believe his distribution rolled-up a style.css file? 2) Should there be at least a style.css template file within the tarball doc folder for users to play with? -- Roger http://rogerx.freeshell.org/

Oct. 6, 2011

Dillo review article

by rogerx.oss＠gmail.com

> On Thu, Oct 06, 2011 at 08:11:52AM -0300, Jorge Arellano Cid wrote: >Hi there, > > This may be worth adding to our "Dillo in the Press" section: > > http://www.linuxinsider.com/story/For-Fast-Light-Web-Browsing-Dillos-No-Dal… Just read the first sentence and boy is he wrong! "First things first: Unless you visit only very simple websites, Dillo will probably not be your one and only Web browser" Dillo seems to work just fine and dandy with the Amazon.com website and it's search function. And it is my best buddy when searching for products on Amazon.com as it's super fast... for some odd reason. ;-) Just wish Google News wouldn't list all those (not-needed) languages at the top of it's page. -- Roger http://rogerx.freeshell.org/

Oct. 6, 2011

Dillo review article

by jcid＠dillo.org

Hi there, This may be worth adding to our "Dillo in the Press" section: http://www.linuxinsider.com/story/For-Fast-Light-Web-Browsing-Dillos-No-Dal… :-) -- Cheers Jorge.-

Oct. 6, 2011

white-space patch

by Johannes.Hofmann＠gmx.de

On Wed, Oct 05, 2011 at 05:54:22PM +0200, Johannes Hofmann wrote: > On Wed, Oct 05, 2011 at 12:48:56PM -0300, Jorge Arellano Cid wrote: > > On Wed, Oct 05, 2011 at 01:32:29PM +0200, Johannes Hofmann wrote: > > > On Tue, Oct 04, 2011 at 04:13:57PM -0300, Jorge Arellano Cid wrote: > > > > On Tue, Oct 04, 2011 at 01:57:05PM -0300, Jorge Arellano Cid wrote: > > > > > > > > > [...] > > > > > Attached goes a small and very interesting testcase. > > > > > (I had a hard time reducing google's page :-P). > > > > > > > > > > Compare with Firefox/Iceweasel rendering. > > > > > > > > There's a "min-width" CSS element that dillo doesn't support: > > > > > > > > #center_col{min-width:562px} > > > > > > > > Taking it out of the equation makes Firefox render the page > > > > quite similar to dillo; so maybe it is not a rewrap bug, but a > > > > lack of implementation of CSS' min-width. > > > > > > A colleague just found a simple test case, and the fix for it also > > > seems to fix the google case - but it needs some more testing. > > > > > > Testcase: > > > > > > <b>Hello World</b><div>Hello world</div> > > > > > > Notice how the first line breaks without need when narrowing the > > > window. > > > > Good testcase! > > > > Here, the first sentence is broken regardless the window size, > > and FWIW, this patch solves it: > > > > @@ -1825,6 +1825,7 @@ void Textblock::addParbreak (int space, > > > > word = addWord (0, 0, 0, style); > > word->content.type = core::Content::BREAK; > > + word->content.breakType = core::Content::BREAK_OK; > > word->content.breakSpace = space; > > wordWrap (words->size () - 1); > > } > > @@ -1846,6 +1847,7 @@ void Textblock::addLinebreak (core::styl > > word = addWord (0, 0, 0, style); > > > > word->content.type = core::Content::BREAK; > > + word->content.breakType = core::Content::BREAK_OK; > > word->content.breakSpace = 0; > > wordWrap (words->size () - 1); > > } > > > > > > (this patch doesn't solve the google testcase, so I thought > > it was better to let you know of it). > > Thanks! I already have a fix and I think the whole thing can > be committed tonight or tomorrow. Ok, another round of testing. Please check how attached patch works for you. Cheers, Johannes PS: Kudos to Florian who by accident found the nice test case!

Oct. 5, 2011

white-space patch

by johannes.hofmann＠gmx.de

On Wed, Oct 05, 2011 at 12:48:56PM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 05, 2011 at 01:32:29PM +0200, Johannes Hofmann wrote: > > On Tue, Oct 04, 2011 at 04:13:57PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Oct 04, 2011 at 01:57:05PM -0300, Jorge Arellano Cid wrote: > > > > > > > [...] > > > > Attached goes a small and very interesting testcase. > > > > (I had a hard time reducing google's page :-P). > > > > > > > > Compare with Firefox/Iceweasel rendering. > > > > > > There's a "min-width" CSS element that dillo doesn't support: > > > > > > #center_col{min-width:562px} > > > > > > Taking it out of the equation makes Firefox render the page > > > quite similar to dillo; so maybe it is not a rewrap bug, but a > > > lack of implementation of CSS' min-width. > > > > A colleague just found a simple test case, and the fix for it also > > seems to fix the google case - but it needs some more testing. > > > > Testcase: > > > > <b>Hello World</b><div>Hello world</div> > > > > Notice how the first line breaks without need when narrowing the > > window. > > Good testcase! > > Here, the first sentence is broken regardless the window size, > and FWIW, this patch solves it: > > @@ -1825,6 +1825,7 @@ void Textblock::addParbreak (int space, > > word = addWord (0, 0, 0, style); > word->content.type = core::Content::BREAK; > + word->content.breakType = core::Content::BREAK_OK; > word->content.breakSpace = space; > wordWrap (words->size () - 1); > } > @@ -1846,6 +1847,7 @@ void Textblock::addLinebreak (core::styl > word = addWord (0, 0, 0, style); > > word->content.type = core::Content::BREAK; > + word->content.breakType = core::Content::BREAK_OK; > word->content.breakSpace = 0; > wordWrap (words->size () - 1); > } > > > (this patch doesn't solve the google testcase, so I thought > it was better to let you know of it). Thanks! I already have a fix and I think the whole thing can be committed tonight or tomorrow. Cheers, Johannes

Oct. 5, 2011

white-space patch

by jcid＠dillo.org

On Wed, Oct 05, 2011 at 01:32:29PM +0200, Johannes Hofmann wrote: > On Tue, Oct 04, 2011 at 04:13:57PM -0300, Jorge Arellano Cid wrote: > > On Tue, Oct 04, 2011 at 01:57:05PM -0300, Jorge Arellano Cid wrote: > > > > > [...] > > > Attached goes a small and very interesting testcase. > > > (I had a hard time reducing google's page :-P). > > > > > > Compare with Firefox/Iceweasel rendering. > > > > There's a "min-width" CSS element that dillo doesn't support: > > > > #center_col{min-width:562px} > > > > Taking it out of the equation makes Firefox render the page > > quite similar to dillo; so maybe it is not a rewrap bug, but a > > lack of implementation of CSS' min-width. > > A colleague just found a simple test case, and the fix for it also > seems to fix the google case - but it needs some more testing. > > Testcase: > > <b>Hello World</b><div>Hello world</div> > > Notice how the first line breaks without need when narrowing the > window. Good testcase! Here, the first sentence is broken regardless the window size, and FWIW, this patch solves it: @@ -1825,6 +1825,7 @@ void Textblock::addParbreak (int space, word = addWord (0, 0, 0, style); word->content.type = core::Content::BREAK; + word->content.breakType = core::Content::BREAK_OK; word->content.breakSpace = space; wordWrap (words->size () - 1); } @@ -1846,6 +1847,7 @@ void Textblock::addLinebreak (core::styl word = addWord (0, 0, 0, style); word->content.type = core::Content::BREAK; + word->content.breakType = core::Content::BREAK_OK; word->content.breakSpace = 0; wordWrap (words->size () - 1); } (this patch doesn't solve the google testcase, so I thought it was better to let you know of it). -- Cheers Jorge.-

Oct. 5, 2011

white-space patch

by johannes.hofmann＠gmx.de

On Tue, Oct 04, 2011 at 04:13:57PM -0300, Jorge Arellano Cid wrote: > On Tue, Oct 04, 2011 at 01:57:05PM -0300, Jorge Arellano Cid wrote: > > > [...] > > Attached goes a small and very interesting testcase. > > (I had a hard time reducing google's page :-P). > > > > Compare with Firefox/Iceweasel rendering. > > There's a "min-width" CSS element that dillo doesn't support: > > #center_col{min-width:562px} > > Taking it out of the equation makes Firefox render the page > quite similar to dillo; so maybe it is not a rewrap bug, but a > lack of implementation of CSS' min-width. A colleague just found a simple test case, and the fix for it also seems to fix the google case - but it needs some more testing. Testcase: <b>Hello World</b><div>Hello world</div> Notice how the first line breaks without need when narrowing the window. Cheers, Johannes

Oct. 5, 2011

white-space patch

by jcid＠dillo.org

On Tue, Oct 04, 2011 at 04:13:57PM -0300, Jorge Arellano Cid wrote: > On Tue, Oct 04, 2011 at 01:57:05PM -0300, Jorge Arellano Cid wrote: > > > [...] > > Attached goes a small and very interesting testcase. > > (I had a hard time reducing google's page :-P). > > > > Compare with Firefox/Iceweasel rendering. > > There's a "min-width" CSS element that dillo doesn't support: > > #center_col{min-width:562px} > > Taking it out of the equation makes Firefox render the page > quite similar to dillo; so maybe it is not a rewrap bug, but a > lack of implementation of CSS' min-width. More precisely: 1.- Without min-width, Firefox shrinks the contents down to a thin column following the window width (similar to dillo) but 2.- Firefox keeps the width of the two innermost DIVs touching the right margin of the parent DIV (unlike dillo). The second point looks like a bug in dillo, and it happens with and without the patch. -- Cheers Jorge.-

Oct. 5, 2011

white-space patch

by jcid＠dillo.org

On Tue, Oct 04, 2011 at 01:57:05PM -0300, Jorge Arellano Cid wrote: > [...] > Attached goes a small and very interesting testcase. > (I had a hard time reducing google's page :-P). > > Compare with Firefox/Iceweasel rendering. There's a "min-width" CSS element that dillo doesn't support: #center_col{min-width:562px} Taking it out of the equation makes Firefox render the page quite similar to dillo; so maybe it is not a rewrap bug, but a lack of implementation of CSS' min-width. -- Cheers Jorge.-

Oct. 4, 2011

white-space patch

by jcid＠dillo.org

On Sat, Oct 01, 2011 at 01:11:05PM -0300, Jorge Arellano Cid wrote: > On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote: > > On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > > > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > > > > [...] > > > > Please explain the non-deterministical behaviour at google. > > > > > > If I search for e.g. dillo on google, the first line (the link) of a > > > result entry is sometimes broken into two lines, sometimes not. > > > > Thanks for the explanation. > > > > After some time reviewing it and guessing, I succeeded to isolate > > a small testcase which I'm reviewing now. > > Sorry, it was not a reliable testcase... :-P Attached goes a small and very interesting testcase. (I had a hard time reducing google's page :-P). Compare with Firefox/Iceweasel rendering. -- Cheers Jorge.-

Oct. 4, 2011

white-space patch

by jcid＠dillo.org

On Sun, Oct 02, 2011 at 11:09:25AM +0200, Johannes Hofmann wrote: > On Sat, Oct 01, 2011 at 03:17:09PM -0300, Jorge Arellano Cid wrote: > > On Sat, Oct 01, 2011 at 04:45:52PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote: > > > > > On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > > > > > > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > > > > > > > > > > [...] > > > > > > > Please explain the non-deterministical behaviour at google. > > > > > > > > > > > > If I search for e.g. dillo on google, the first line (the link) of a > > > > > > result entry is sometimes broken into two lines, sometimes not. > > > > > > > > > > Thanks for the explanation. > > > > > > > > > > After some time reviewing it and guessing, I succeeded to isolate > > > > > a small testcase which I'm reviewing now. > > > > > > > > Sorry, it was not a reliable testcase... :-P > > > > > > I haven't looked into this, but do you suppose it could have to do with the > > > part in html.cc that goes > > > > > > if (isspace(buf[buf_index])) { > > > /* whitespace: group all available whitespace */ > > > while (++buf_index < bufsize && isspace(buf[buf_index])) ; > > > Html_process_space(html, buf + token_start, buf_index - token_start); > > > token_start = buf_index; > > > } ... > > > > > > that is, sends off whatever it's accumulated at the end of a packet? > > > > Not sure, but I don't think so. > > > > Without the whitespace patch, dillo also doesn't seem to get > > right the available horizontal space for the link [1]. > > > > To me it looks related to the way ParMin propagates upwards in > > a textblock, but I'm just starting to look into it. > > Yes, I also think it's related to that. > Textblock::getExtremesImpl() starts from wrapRef and uses the > precomputed line->maxWordMin, line->maxParMax, line->parMin, and > line->parMax. From there it does compute the stuff on it's own. > > So if the computation of line->maxWordMin, line->maxParMax, > line->parMin, and line->parMax in wordWrap() doesn't agree with what > Textblock::getExtremesImpl() does afterwards, the result becomes > unreliable. FWIW, this old comment in the code (not present today) may be a good hint of what happens now: textblock.cc, Textblock::wordWrap() /* NOTE: Most code relies on that all values of nowrap are equal for all * words within one line. */ -- Cheers Jorge.-

Oct. 2, 2011

white-space patch

by Johannes.Hofmann＠gmx.de

On Sat, Oct 01, 2011 at 03:17:09PM -0300, Jorge Arellano Cid wrote: > On Sat, Oct 01, 2011 at 04:45:52PM +0000, corvid wrote: > > Jorge wrote: > > > On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote: > > > > On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > > > > > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > > > > > > > > [...] > > > > > > Please explain the non-deterministical behaviour at google. > > > > > > > > > > If I search for e.g. dillo on google, the first line (the link) of a > > > > > result entry is sometimes broken into two lines, sometimes not. > > > > > > > > Thanks for the explanation. > > > > > > > > After some time reviewing it and guessing, I succeeded to isolate > > > > a small testcase which I'm reviewing now. > > > > > > Sorry, it was not a reliable testcase... :-P > > > > I haven't looked into this, but do you suppose it could have to do with the > > part in html.cc that goes > > > > if (isspace(buf[buf_index])) { > > /* whitespace: group all available whitespace */ > > while (++buf_index < bufsize && isspace(buf[buf_index])) ; > > Html_process_space(html, buf + token_start, buf_index - token_start); > > token_start = buf_index; > > } ... > > > > that is, sends off whatever it's accumulated at the end of a packet? > > Not sure, but I don't think so. > > Without the whitespace patch, dillo also doesn't seem to get > right the available horizontal space for the link [1]. > > To me it looks related to the way ParMin propagates upwards in > a textblock, but I'm just starting to look into it. Yes, I also think it's related to that. Textblock::getExtremesImpl() starts from wrapRef and uses the precomputed line->maxWordMin, line->maxParMax, line->parMin, and line->parMax. From there it does compute the stuff on it's own. So if the computation of line->maxWordMin, line->maxParMax, line->parMin, and line->parMax in wordWrap() doesn't agree with what Textblock::getExtremesImpl() does afterwards, the result becomes unreliable. Cheers, Johannes

Oct. 2, 2011

white-space patch

by jcid＠dillo.org

On Sat, Oct 01, 2011 at 04:45:52PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote: > > > On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > > > > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > > > > > > [...] > > > > > Please explain the non-deterministical behaviour at google. > > > > > > > > If I search for e.g. dillo on google, the first line (the link) of a > > > > result entry is sometimes broken into two lines, sometimes not. > > > > > > Thanks for the explanation. > > > > > > After some time reviewing it and guessing, I succeeded to isolate > > > a small testcase which I'm reviewing now. > > > > Sorry, it was not a reliable testcase... :-P > > I haven't looked into this, but do you suppose it could have to do with the > part in html.cc that goes > > if (isspace(buf[buf_index])) { > /* whitespace: group all available whitespace */ > while (++buf_index < bufsize && isspace(buf[buf_index])) ; > Html_process_space(html, buf + token_start, buf_index - token_start); > token_start = buf_index; > } ... > > that is, sends off whatever it's accumulated at the end of a packet? Not sure, but I don't think so. Without the whitespace patch, dillo also doesn't seem to get right the available horizontal space for the link [1]. To me it looks related to the way ParMin propagates upwards in a textblock, but I'm just starting to look into it. BTW, adding these lines to style.css helps to visualize it: table {border: 1px solid red !important} td {border: 1px solid green !important} div {border: 1px solid black !important} [1] http://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo -- Cheers Jorge.-

Oct. 1, 2011

white-space patch

by corvid＠lavabit.com

Jorge wrote: > On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote: > > On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > > > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > > > > [...] > > > > Please explain the non-deterministical behaviour at google. > > > > > > If I search for e.g. dillo on google, the first line (the link) of a > > > result entry is sometimes broken into two lines, sometimes not. > > > > Thanks for the explanation. > > > > After some time reviewing it and guessing, I succeeded to isolate > > a small testcase which I'm reviewing now. > > Sorry, it was not a reliable testcase... :-P I haven't looked into this, but do you suppose it could have to do with the part in html.cc that goes if (isspace(buf[buf_index])) { /* whitespace: group all available whitespace */ while (++buf_index < bufsize && isspace(buf[buf_index])) ; Html_process_space(html, buf + token_start, buf_index - token_start); token_start = buf_index; } ... that is, sends off whatever it's accumulated at the end of a packet?

Oct. 1, 2011

white-space patch

by jcid＠dillo.org

On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote: > On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > > [...] > > > Please explain the non-deterministical behaviour at google. > > > > If I search for e.g. dillo on google, the first line (the link) of a > > result entry is sometimes broken into two lines, sometimes not. > > Thanks for the explanation. > > After some time reviewing it and guessing, I succeeded to isolate > a small testcase which I'm reviewing now. Sorry, it was not a reliable testcase... :-P -- Cheers Jorge.-

Oct. 1, 2011

white-space patch

by jcid＠dillo.org

On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote: > On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Sep 27, 2011 at 09:30:24PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > attached is a preliminary patch for white-space: nowrap handling. > > > It' supposed to fix the following issues: > > > > > > * Weird page width in combination with white-space:nowrap sequences > > > (e.g. on http://en.wikipedia.org/wiki/Web_browser. > > > * Line breaks at tags (e.g. <b>D</b>illo should not break after > > > the "D". (similar issue on > > > http://fltk.org/newsgroups.php?gfltk.development+T) > > > > > > without breaking: > > > > > > * zero width space handling. > > > * ideographic character handling. > > > > > > It's not ready for commit yet, as google results don't render > > > deterministically the same way. > > > Nevertheless please give it a try and report how it works for you. > > > > Good! > > > > I'm reviewing the patch and it seems to work well so far. > > > > Please explain the non-deterministical behaviour at google. > > If I search for e.g. dillo on google, the first line (the link) of a > result entry is sometimes broken into two lines, sometimes not. Thanks for the explanation. After some time reviewing it and guessing, I succeeded to isolate a small testcase which I'm reviewing now. -- Cheers Jorge.-

Oct. 1, 2011

white-space patch

by Johannes.Hofmann＠gmx.de

On Thu, Sep 29, 2011 at 03:02:24PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Sep 27, 2011 at 09:30:24PM +0200, Johannes Hofmann wrote: > > > attached is a preliminary patch for white-space: nowrap handling. > > > It' supposed to fix the following issues: > > > > > > * Weird page width in combination with white-space:nowrap sequences > > > (e.g. on http://en.wikipedia.org/wiki/Web_browser. > > > * Line breaks at tags (e.g. <b>D</b>illo should not break after > > > the "D". (similar issue on > > > http://fltk.org/newsgroups.php?gfltk.development+T) > > > > > > without breaking: > > > > > > * zero width space handling. > > > * ideographic character handling. > > > > > > It's not ready for commit yet, as google results don't render > > > deterministically the same way. > > > Nevertheless please give it a try and report how it works for you. > > > > Good! > > > > I'm reviewing the patch and it seems to work well so far. > > I just noticed that page source isn't wrapping. Ah good point. Seems I broke white-space:pre-wrap. I will try to fix that.

Sept. 30, 2011

white-space patch

by johannes.hofmann＠gmx.de

On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Tue, Sep 27, 2011 at 09:30:24PM +0200, Johannes Hofmann wrote: > > Hi, > > > > attached is a preliminary patch for white-space: nowrap handling. > > It' supposed to fix the following issues: > > > > * Weird page width in combination with white-space:nowrap sequences > > (e.g. on http://en.wikipedia.org/wiki/Web_browser. > > * Line breaks at tags (e.g. <b>D</b>illo should not break after > > the "D". (similar issue on > > http://fltk.org/newsgroups.php?gfltk.development+T) > > > > without breaking: > > > > * zero width space handling. > > * ideographic character handling. > > > > It's not ready for commit yet, as google results don't render > > deterministically the same way. > > Nevertheless please give it a try and report how it works for you. > > Good! > > I'm reviewing the patch and it seems to work well so far. > > Please explain the non-deterministical behaviour at google. If I search for e.g. dillo on google, the first line (the link) of a result entry is sometimes broken into two lines, sometimes not. Cheers, Johannes

Sept. 30, 2011

remember digest authentication?

by 4winter＠informatik.uni-hamburg.de

Hey everyone :) Quoting corvid (2011-09-29 18:53:15) > >I dug up Justus's old http auth patch a little while back, got everything >ironed out, and it's working well for me now, so I just committed it. >Please test! Nice to hear that :) Cheers, Justus

Sept. 29, 2011

remember digest authentication?

by corvid＠lavabit.com

I dug up Justus's old http auth patch a little while back, got everything ironed out, and it's working well for me now, so I just committed it. Please test!

Sept. 29, 2011

white-space patch

by corvid＠lavabit.com

Jorge wrote: > On Tue, Sep 27, 2011 at 09:30:24PM +0200, Johannes Hofmann wrote: > > attached is a preliminary patch for white-space: nowrap handling. > > It' supposed to fix the following issues: > > > > * Weird page width in combination with white-space:nowrap sequences > > (e.g. on http://en.wikipedia.org/wiki/Web_browser. > > * Line breaks at tags (e.g. <b>D</b>illo should not break after > > the "D". (similar issue on > > http://fltk.org/newsgroups.php?gfltk.development+T) > > > > without breaking: > > > > * zero width space handling. > > * ideographic character handling. > > > > It's not ready for commit yet, as google results don't render > > deterministically the same way. > > Nevertheless please give it a try and report how it works for you. > > Good! > > I'm reviewing the patch and it seems to work well so far. I just noticed that page source isn't wrapping.

Sept. 29, 2011

white-space patch

by jcid＠dillo.org

Hi Johannes, On Tue, Sep 27, 2011 at 09:30:24PM +0200, Johannes Hofmann wrote: > Hi, > > attached is a preliminary patch for white-space: nowrap handling. > It' supposed to fix the following issues: > > * Weird page width in combination with white-space:nowrap sequences > (e.g. on http://en.wikipedia.org/wiki/Web_browser. > * Line breaks at tags (e.g. <b>D</b>illo should not break after > the "D". (similar issue on > http://fltk.org/newsgroups.php?gfltk.development+T) > > without breaking: > > * zero width space handling. > * ideographic character handling. > > It's not ready for commit yet, as google results don't render > deterministically the same way. > Nevertheless please give it a try and report how it works for you. Good! I'm reviewing the patch and it seems to work well so far. Please explain the non-deterministical behaviour at google. -- Cheers Jorge.-

Sept. 28, 2011

white-space patch

by Johannes.Hofmann＠gmx.de

Hi, attached is a preliminary patch for white-space: nowrap handling. It' supposed to fix the following issues: * Weird page width in combination with white-space:nowrap sequences (e.g. on http://en.wikipedia.org/wiki/Web_browser. * Line breaks at tags (e.g. <b>D</b>illo should not break after the "D". (similar issue on http://fltk.org/newsgroups.php?gfltk.development+T) without breaking: * zero width space handling. * ideographic character handling. It's not ready for commit yet, as google results don't render deterministically the same way. Nevertheless please give it a try and report how it works for you. Cheers, Johannes

Sept. 27, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by corvid＠lavabit.com

Roger wrote: > > On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: > >Anybody else notice the mouse wheel is slow within Dillo? > > > >Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower > >compared to Seamonkey. > > > >Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. Fighting with xinput and my rarely-used touchpad (someday I'll put in the time to find out why it's so flaky), I enabled the scrollwheel emulation, and I can at least see that, whereas we use 28*font_factor, firefox was using 3*line_height on the page that I used. (And I did verify that the FL_MOUSEWHEEL events from Fl_x.cxx's fl_handle() were all reaching the scrollbars, FWIW.)

Sept. 26, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

> On Sun, Sep 25, 2011 at 09:55:41PM -0800, Roger wrote: >> On Sun, Sep 25, 2011 at 09:51:37PM -0800, Roger wrote: >>> On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: >>>Anybody else notice the mouse wheel is slow within Dillo? >>> >>>Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower >>>compared to Seamonkey. >>> >>>Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. >> >>I've found a better solution then modifying the code concerning mouse scroll >>speed. >> >>IMWheel >>http://imwheel.sourceforge.net/ >> >> >>file: /home/roger/.imwheelrc >> >>"^Dillo" >>None, Up, Button4, 25 >>None, Down, Button5, 25 >> >>"^GNU Screen" >>None, Up, Button4, 15 >>None, Down, Button5, 15 >> >>"^SeaMonkey" >>None, Up, Button4, 9 >>None, Down, Button5, 9 Only problem with this, this only increases the number of lines scrolled at once. As such, it's causes jaggy or staggered scrolling, inhibiting the user to be able to distinguish where he/she is at on a page. In which case, it's better to just left-click on the empty part of the scroll bar to scroll by page. A better solution, just code xset with increasing/decreasing mouse scroll rate. -- Roger http://rogerx.freeshell.org/

Sept. 26, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

> On Sun, Sep 25, 2011 at 09:51:37PM -0800, Roger wrote: >> On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: >>Anybody else notice the mouse wheel is slow within Dillo? >> >>Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower >>compared to Seamonkey. >> >>Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. > >I've found a better solution then modifying the code concerning mouse scroll >speed. > >IMWheel >http://imwheel.sourceforge.net/ > > >file: /home/roger/.imwheelrc > >"^Dillo" >None, Up, Button4, 25 >None, Down, Button5, 25 > >"^GNU Screen" >None, Up, Button4, 15 >None, Down, Button5, 15 > >"^SeaMonkey" >None, Up, Button4, 9 >None, Down, Button5, 9 > > >You can find your wheel/scroll buttons by using "imwheel -c" > >Prevent detach/daemon mode by using "imwheel -d" and use "imwheel -D" for >debugging. Or use both options. > > >I can now see the issues with different scrolls speeds between applications and >the reason why one scroll speed within xorg.conf won't solve much. As such, >it's an application specific issue but IMWheel solves this quite well! Although getting off-topic here, if you find the above helpful, you might also find the below helpful for increasing mouse speed: xset m 6/3 0 # normal speed is "5/3 0" -- Roger http://rogerx.freeshell.org/

Sept. 26, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

> On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: >Anybody else notice the mouse wheel is slow within Dillo? > >Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower >compared to Seamonkey. > >Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. I've found a better solution then modifying the code concerning mouse scroll speed. IMWheel http://imwheel.sourceforge.net/ file: /home/roger/.imwheelrc "^Dillo" None, Up, Button4, 25 None, Down, Button5, 25 "^GNU Screen" None, Up, Button4, 15 None, Down, Button5, 15 "^SeaMonkey" None, Up, Button4, 9 None, Down, Button5, 9 You can find your wheel/scroll buttons by using "imwheel -c" Prevent detach/daemon mode by using "imwheel -d" and use "imwheel -D" for debugging. Or use both options. I can now see the issues with different scrolls speeds between applications and the reason why one scroll speed within xorg.conf won't solve much. As such, it's an application specific issue but IMWheel solves this quite well! -- Roger http://rogerx.freeshell.org/

Sept. 26, 2011

Another occurrence of "2.2" found: doc/dillo.1

by corvid＠lavabit.com

Axel wrote: > just noticed that the manpage doc/dillo.1 still has "version 2.2" in > its headers. *removes version number*

Sept. 24, 2011

3.0.1 released [Re: release candidate for dillo-3.0.1 ready for testing]

by onepoint＠starurchin.org

corvid wrote: > It's official now :) > > http://www.dillo.org/download/dillo-3.0.1.tar.bz2 > http://www.dillo.org/download/dillo-3.0.1.tar.bz2.asc BLFS wiki page updated: http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 Regards, Jeremy Henty

Sept. 24, 2011

Another occurrence of "2.2" found: doc/dillo.1

by abe＠deuxchevaux.org

Hi, just noticed that the manpage doc/dillo.1 still has "version 2.2" in its headers. 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.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 24, 2011

release candidate for dillo-3.0.1 ready for testing

by obeythepenguin＠gmail.com

By the way, just to clarify on FL_NORMAL_SIZE: On Windows (and modern X toolkits like GTK+ and Qt), user interface fonts are a system setting, like colors. It's not perfect by a long shot, since fonts are still hard-coded in many applications and a number of other places, but it at least provides some level of consistency. More importantly, if the fonts are too small in your applications, you can adjust it once system-wide, rather than having to tweak each individual application's settings. This is not new stuff; Windows, for example, has been doing it since at least 1995. I really miss FLTK2, which actually used the system font settings rather than hard-coding the default fonts -- which, coincidentally, don't really match anything except old Motif apps and look-alikes, and who the hell still uses Motif? But now I digress. ~Benjamin

Sept. 24, 2011

release candidate for dillo-3.0.1 ready for testing

by obeythepenguin＠gmail.com

On 9/23/11, corvid <corvid at lavabit.com> wrote: > I think I'm with Axel on not liking to waste pixels on the tabs, Take another look at this screenshot: http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=Z02-dillo3… If there's any wasted space in that window, it's in the File menu and location bar, not in the tabs. A couple extra pixels in the tab bar height is *not* wasted space if it improves the tabs' appearance and readability; you wouldn't say books waste valuable inches with their margins, would you? > and, as for FL_NORMAL_SIZE, I'll likely commit the patch that > changes it based on font_factor, so if you have your font_factor > small, you may get your wish. (As for me, I'm happy with 14px.) If you're typing a document in a word processor and you zoom in, does the entire interface zoom with it? Of course not. The font face and size used in the user interface should be independent of the fonts used for page rendering. Of course, I suppose Unix is still a lawless wasteland, but professionally-developed modern desktop systems like Windows and OS X have guidelines for this sort of thing (and the higher-end toolkits like Qt even suggest following those guidelines, even if you don't develop for those specific platforms). Fortunately, by now I'm no stranger to patching either Dillo or FLTK... ~Benjamin

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by corvid＠lavabit.com

Benjamin wrote: > maybe set FL_NORMAL_SIZE a bit smaller, since the 14px default is > frankly ridiculous.) I think I'm with Axel on not liking to waste pixels on the tabs, and, as for FL_NORMAL_SIZE, I'll likely commit the patch that changes it based on font_factor, so if you have your font_factor small, you may get your wish. (As for me, I'm happy with 14px.)

Sept. 23, 2011

3.0.1 released [Re: release candidate for dillo-3.0.1 ready for testing]

by corvid＠lavabit.com

Johannes wrote: > due to some important privacy fixes we decided to make a > bugfix release. > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > is available for download now and want's to be tested. > Please give it a try and report back. If everything goes smoothly, > this will become dillo-3.0.1.tar.bz2 on Friday. It's official now :) http://www.dillo.org/download/dillo-3.0.1.tar.bz2 http://www.dillo.org/download/dillo-3.0.1.tar.bz2.asc

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by obeythepenguin＠gmail.com

On Fri, 23 Sep 2011 15:47:37 -0400, Axel Beckert <abe at deuxchevaux.org> wrote: > Ehm, I thought the screenshot was without the added four pixels as you > wrote something like making them the same height like the File menu > and on that screenshot the tabs still have less height than the File > menu. > > Kind regards, Axel No, that screenshot's with the added four pixels (which is still less than the height of the File menu on panel_size=medium). By the way, I use Dillo regularly on a laptop with an 800x600 screen. Setting small icons and panel_size=small more than makes up for a couple extra pixels on the tab bar. ~Benjamin

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by abe＠deuxchevaux.org

On Fri, Sep 23, 2011 at 03:35:50PM -0400, Benjamin Johnson wrote: >> Four pixels are already quite a lot on todays "HD" screens which just >> have a screen height of 768 pixels. And quite some low-end netbooks >> just have 600 or 480 pixels screen height. There, fource pixels do >> matter. >> >> But OTOH: Why not make it configurable if we disagree? >> >>> It's hardly a dramatic change, yet it dramatically improves the tab >>> appearance and readability: >>> http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=Z02-dillo3… >> >> Looks perfect and readable for me. > > You say it's wasting space, yet you agree it helps the readability. Ehm, I thought the screenshot was without the added four pixels as you wrote something like making them the same height like the File menu and on that screenshot the tabs still have less height than the File menu. 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.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 23, 2011