- Dillo-dev - lists.mailman3.com

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > 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"? Sorry, I think I don't fully understand the question. * {font-size: 30px !important} would set a fixed font size of 30px. The <span> itself doesn't alter it. What am I missing? > > I was also thinking that we would need to get the color and > size from StyleEngine for plain and root png/gif backgrounds... Not sure about plain. Which color should StyleEngine choose? Or do you mean we should simulate a dummy DocTree for plain (e.g. <html><body><pre> ... </pre></body></html>)? Alternatively we could move plain handling into a dpi together with the source view ... Cheers, Johannes

Feb. 15, 2009

[patch] Search Previous

by Johannes.Hofmann＠gmx.de

On Sat, Feb 14, 2009 at 03:16:56AM +0000, corvid wrote: > 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. Yes, I had added the (isspace (c1) && isspace (c2)) part to treat all whitespace equally. I didn't touch the caseSens==true case, because I wasn't sure whether we want to retain the possibility to search for e.g. \t or \n in plain text or not. Cheers, Johannes

Feb. 15, 2009

My valgrind logs, for all to see.

by jcid＠dillo.org

On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote: > On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > > > Would having a single page with anchors for each link be enough, > > > or do you want separate pages for each one? > > > > A single page seems easier. > > Actually, I've gone for a summary page with links to a separate page > for each error. I've put some information from the stack traces into > the link texts. I think it works rather well, eg. you can clearly see > that most of the errors are coming from CSS handling (and some of > those leaks are not as small as I thought). Please comment. > > http://starurchin.org/dillo/valgrind.html It looks much more insightful. But, I miss the URL to reproduce the BUG. That's what I meant in the previous email; please excuse me if it wasn't clear. That's the starting point for debugging. Even if only a few have their URLs that's a good start. We can point new developers to this page too, as usually this bugs are not too complex to fix. -- Cheers Jorge.-

Feb. 15, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote: > On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > > Would having a single page with anchors for each link be enough, > > or do you want separate pages for each one? > > A single page seems easier. Actually, I've gone for a summary page with links to a separate page for each error. I've put some information from the stack traces into the link texts. I think it works rather well, eg. you can clearly see that most of the errors are coming from CSS handling (and some of those leaks are not as small as I thought). Please comment. http://starurchin.org/dillo/valgrind.html If you find spurious entries then tell me and I'll add the suppressions to my Dillo/Valgrind script and they won't appear in subsequent log files. I'll do all the ones that come from FLTK, so you needn't point those out. Regards, Jeremy Henty

Feb. 15, 2009

My valgrind logs, for all to see.

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > On Sat, Feb 14, 2009 at 05:04:27PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote: > > > > > > 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. > > > > One URL that reproduces each leak would be very helpful. > > Would having a single page with anchors for each link be enough, or do > you want separate pages for each one? A single page seems easier. > > Repeated leaks can be omitted. > > It should already be doing that. I extract the suppression (the part > in { ... }) and eliminate duplicates based on that. It's not perfect > because different code paths may trigger the same error. I'm hoping > it proves to be good enough. I can't see an easy way to do better. > Suggestions are welcome. Usually when fixing one of these bugs, a few others dissappear. But you're right is hard to tell before the fix. You can erase the ones belonging to FLTK. -- Cheers Jorge.-

Feb. 14, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sat, Feb 14, 2009 at 05:04:27PM -0300, Jorge Arellano Cid wrote: > On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote: > > > > 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. > > One URL that reproduces each leak would be very helpful. Would having a single page with anchors for each link be enough, or do you want separate pages for each one? > Repeated leaks can be omitted. It should already be doing that. I extract the suppression (the part in { ... }) and eliminate duplicates based on that. It's not perfect because different code paths may trigger the same error. I'm hoping it proves to be good enough. I can't see an easy way to do better. Suggestions are welcome. Regards, Jeremy Henty

Feb. 14, 2009

My valgrind logs, for all to see.

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote: > > 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. One URL that reproduces each leak would be very helpful. Repeated leaks can be omitted. -- Cheers Jorge.-

Feb. 14, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 05:22:54PM +0200, Rogut??s Sparnuotos wrote: > 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." Thanks a lot for the useful information! It seems like w3c decided to tolerate META refresh when the delay is zero. i.e. "instant client-side redirect". That explains its usage. OK, I'll work on a patch for this and the related bug that furaisanjin wrote (W3C's example uses a quoted URL). -- Cheers Jorge.-

Feb. 14, 2009

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