- Dillo-dev - lists.mailman3.com

patch: optgroup for OptionMenu

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:41:40PM +0000, corvid wrote: > Jorge wrote: > > 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. > > I'm not sure what you mean by this. Currently, the item group positions itself relative to the selected item and the cursor. This is: the selected item is drawn under the mouse pointer, and the rest of the widget adjusted around. This is confusing (especially when one is drawn over the other). This is a FLTK feature that can be disabled. The idea is to have the parent menu drawn just under the selection widget, like here: [Option 1 v] .-------------. | Group1 >| | Group2 >| | Group3 >|.----------. '-------------'| Opt1 G3 | |=Opt2=G3==| <- Selected option | Opt3 G3 | '----------' Note 1: in this case a click with the mouse pointer over the "[Option 1 v]" widget is necessary to display the menus, but they draw relative to the parent ("[Option 1 v]") instead of making the selected option appear under the mouse pointer. Note 2: Firefox does an "incorrect" rendering according to this page: http://www.tantek.com/HTML4/OPTGROUP.html -- Cheers Jorge.-

Feb. 14, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

For your information. http://starurchin.org/dillo/valgrind.html It lists the valgrind errors from my most recent Dillo sessions. It's just one big static HTML page at the moment. Feel free to suggest how it could be more useful. You can see we're still getting lots of small leaks from the CSS parser, though the big ones have been fixed by recent commits. Regards, Jeremy Henty

Feb. 14, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Johannes wrote: > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > I was just looking at some of the prefs that I > > don't think are doing anything right now, e.g., > > link_color, force_my_colors... > > I could stuff them into buildUserStyle(), but > > I don't know which should prevail in case of > > conflicts. > > > > I can't remember whether I've already mentioned that > > I've been wondering whether it might be reasonable to > > rip a bunch of color stuff out of dillorc and expect > > a dillo user to be able to deal with a well-commented > > sample style.css instead. > > Good point. I always favor simplicity so I think we should have just > one way to modify the style. Having two (style.css and preferences) > just adds confusion. We need to document this properly as you > said. If I have a style.css containing: * {font-size: 30px} and a page containing: regular regular <span>large</span> Can it be interpreted as "make everything big"? I was also thinking that we would need to get the color and size from StyleEngine for plain and root png/gif backgrounds...

Feb. 14, 2009

patch: optgroup for OptionMenu

by corvid＠lavabit.com

Jorge wrote: > 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. I'm not sure what you mean by this. > This is confusing. The same or similar trick > used for the file menu may help.

Feb. 14, 2009

google login redirect

by rogutes＠googlemail.com

Jorge Arellano Cid (2009-02-14 11:35): > On Sat, Feb 14, 2009 at 03:44:49PM +0900, furaisanjin wrote: > > Hi all. > > > > I have noticed that google login redirect is something like this. > > > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> > > BTW, does anybody know why some sites are using a refresh with > delay zero? > > I also saw this technique used in gitweb, but don't know what > problem it is suppossed to solve. I think that * it is used as a supplement to server-side redirect (the Location: header) * instead of server-side redirect (whatever the reasons [1]) In both cases, the user is not supposed to see the redirect happening, as it is happening for technical (and not necessarily clever) reasons. I might be totally wrong, but these are the impressions I got while investigating how to redirect the user to another page after a successful POST (so the data is not submitted again in case of a client-side page refresh). [1] Following the link, there is this sentence: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G110.html "However, authors do not always have control over server-side technologies; in that case, they can use a client-side redirect." [2] -- -- Rogut?s Sparnuotos

Feb. 14, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:44:49PM +0900, furaisanjin wrote: > Hi all. > > I have noticed that google login redirect is something like this. > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> BTW, does anybody know why some sites are using a refresh with delay zero? I also saw this technique used in gitweb, but don't know what problem it is suppossed to solve. -- Cheers Jorge.-

Feb. 14, 2009

[patch] Search Previous

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 12:38:36AM +0000, Jo?o Ricardo Louren?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? It looks like a bug. > 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. -- Cheers Jorge.-

Feb. 14, 2009

[patch] Search Previous

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 12:29:32AM +0000, Jo?o Ricardo Louren?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. > > > > > > OK, I'm not quite sure why we want that, When parsing in HTML mode, all whitespace are equal. > but now I'll try to focus on > why it fails with thast particular expression. Thanks for that. -- Cheers Jorge.-

Feb. 14, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:44:49PM +0900, furaisanjin wrote: > 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. The problem is that "content" in META can be anything. There's no format for it. It seems an heuristic may be of use here... What do you do to get that redirection? I've tried some google pages but can't get the ' -- Cheers Jorge.-

Feb. 14, 2009

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