February 2009 - Dillo-dev - lists.mailman3.com

patch: optgroup for OptionMenu

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:13:03AM +0000, corvid wrote: > I've had this kicking around in my tree for months...finally got > around to implementing the max string width for OptionMenu and > doing a little polishing. > > Here it treats optgroup, option, and /optgroup as types of options > because when I tried keeping options inside optgroup structures, it > turned out to be messier. > The idea is that if this is accepted, I will later do some renaming. It looks good so far. Please set the itemGroup position relative to its parent widget and not to cursor. This is confusing. The same or similar trick used for the file menu may help. > (Not enabled for ListResource yet because the straightforward approach > did not result in something very usable...) OK. -- Cheers Jorge.-

Feb. 14, 2009

google login redirect

by furaisanjin＠gmail.com

2009/2/14 corvid <corvid(a)lavabit.com>: > furaisanjin wrote: >> > Does reloading work? >> >> Do you mean redirecting? > > I meant pressing reload. OK, I understand. Yes, it works. I just see the same page again. Regards, furaisanjin

Feb. 14, 2009

google login redirect

by corvid＠lavabit.com

furaisanjin wrote: > > Does reloading work? > > Do you mean redirecting? I meant pressing reload.

Feb. 14, 2009

google login redirect

by furaisanjin＠gmail.com

> Does reloading work? Do you mean redirecting? I modified html.cc like this. There is tailing single quotation mark but it seems that dillo ignores it. --- a/src/html.cc Sat Feb 14 10:14:38 2009 +0900 +++ b/src/html.cc Sat Feb 14 17:06:29 2009 +0900 @@ -2898,6 +2898,9 @@ /* Skip to anything after "URL=" */ while (*content && *(content++) != '=') ; + if (*content == '\'') + content++; + /* Send a custom HTML message. * TODO: This is a hairy hack, * It'd be much better to build a widget. */ now I can login by clicking "here". Regards, furaisanjin

Feb. 14, 2009

google login redirect

by corvid＠lavabit.com

furaisanjin wrote: > I have noticed that google login redirect is something like this. > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> > > So generated redirect template looks like > > <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> > <td bgcolor='#8899aa' width='100%'> > This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC > (sec 7.4.4) recommends explicitly to avoid it.</td></tr> > <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go > <a href=''http://www.google.com/ ... > > So dillo just navigates to the same page. This is the reason why we can't login. Does reloading work?

Feb. 14, 2009

google login redirect

by furaisanjin＠gmail.com

Hi all. I have noticed that google login redirect is something like this. <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> So generated redirect template looks like <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> <td bgcolor='#8899aa' width='100%'> This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC (sec 7.4.4) recommends explicitly to avoid it.</td></tr> <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go <a href=''http://www.google.com/ ... So dillo just navigates to the same page. This is the reason why we can't login. Regards, furaisanjin

Feb. 14, 2009

[patch] Search Previous

by corvid＠lavabit.com

Jo?o wrote: > Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > > Jo?o wrote: > > > Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > > > > Jo?o wrote: > > > > > I've been trying to understand what's going on in CharIterator::prev() > > > > > and have been running tests and I have a question regarding iterator.hh. > > > > > > > > > > In the following code: > > > > > > > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > > > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > > > > (isspace (c1) && isspace (c2)); } > > > > > > > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > > > > according to my tests, is wrecking the search-previous functionality. > > > > > > > > We do want to regard whitespace chars as equivalent, don't we? > > > > > > > > > > > > > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't > > > 'change' the whitespace, as far as I know. Or do we want to consider ' ' > > > a tab too (for example)? Maybe I missed the point. :S > > > > I think we want to treat something like tab and space as the same. > > > > > > Oh and one more thing. If our purpose is to treat all whitespace equaly > (tabs=Spaces...), why do we _only_ do that when not doing a > case-sensitive comparison? > > A way to verify that (isspace (c1) && isspace (c2)) is causing the fail > is to search for ' ' backwards with case-sens* on --- it finds it. I don't really know that code in any detail whatsoever. I think Johannes implemented it.

Feb. 14, 2009

patch: optgroup for OptionMenu

by corvid＠lavabit.com

I've had this kicking around in my tree for months...finally got around to implementing the max string width for OptionMenu and doing a little polishing. Here it treats optgroup, option, and /optgroup as types of options because when I tried keeping options inside optgroup structures, it turned out to be messier. The idea is that if this is accepted, I will later do some renaming. (Not enabled for ListResource yet because the straightforward approach did not result in something very usable...)

Feb. 14, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > Jo?o wrote: > > Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > > > Jo?o wrote: > > > > I've been trying to understand what's going on in CharIterator::prev() > > > > and have been running tests and I have a question regarding iterator.hh. > > > > > > > > In the following code: > > > > > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > > > (isspace (c1) && isspace (c2)); } > > > > > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > > > according to my tests, is wrecking the search-previous functionality. > > > > > > We do want to regard whitespace chars as equivalent, don't we? > > > > > > > > > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't > > 'change' the whitespace, as far as I know. Or do we want to consider ' ' > > a tab too (for example)? Maybe I missed the point. :S > > I think we want to treat something like tab and space as the same. > > Oh and one more thing. If our purpose is to treat all whitespace equaly (tabs=Spaces...), why do we _only_ do that when not doing a case-sensitive comparison? A way to verify that (isspace (c1) && isspace (c2)) is causing the fail is to search for ' ' backwards with case-sens* on --- it finds it. Thanks, Jo?o > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 14, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > Jo?o wrote: > > Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > > > Jo?o wrote: > > > > I've been trying to understand what's going on in CharIterator::prev() > > > > and have been running tests and I have a question regarding iterator.hh. > > > > > > > > In the following code: > > > > > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > > > (isspace (c1) && isspace (c2)); } > > > > > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > > > according to my tests, is wrecking the search-previous functionality. > > > > > > We do want to regard whitespace chars as equivalent, don't we? > > > > > > > > > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't > > 'change' the whitespace, as far as I know. Or do we want to consider ' ' > > a tab too (for example)? Maybe I missed the point. :S > > I think we want to treat something like tab and space as the same. > > OK, I'm not quite sure why we want that, but now I'll try to focus on why it fails with thast particular expression. Thanks for that. Jo?o > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 14, 2009