- Dillo-dev - lists.mailman3.com

[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

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

patch: SELECT size > 1 !multiple

by jcid＠dillo.org

On Fri, Feb 13, 2009 at 07:42:34PM +0000, corvid wrote: > When I was working on the SELECT size code recently, > I enabled using the plain fltk::Browser if > size > 1 and multiple was not set. > > I didn't realize that the callbacks for a plain Browser > and a MultiBrowser behave differently. Committed. -- Cheers Jorge.-

Feb. 13, 2009

relative urls

by jcid＠dillo.org

On Fri, Feb 13, 2009 at 02:18:06PM +0100, Hofmann Johannes wrote: > On Fri, Feb 13, 2009 at 10:07:36AM -0300, Jorge Arellano Cid wrote: > > On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > > > correctly (check "5.1. Normal Examples"), dillo does not handle > > > relative urls with queries correctly. In case of queries it > > > truncates the filename. Anchors are handled correctly. > > > You can see the difference here: > > > > > > <a href="#foo">#foo</a> > > > <a href="?foo=bar">?foo=bar</a> > > > > Yes, dillo doesn't follow rfc1808.txt. > > > > Dillo follows rfc2396 which updates rfc1808. > > This particular case was changed by it. > > The nice thing about RFCs is that there is so many to choose from :) > > Just found this here: > http://www.communities.hp.com/securitysoftware/blogs/jeff/archive/2007/12/1… > After reading it I would suggest to follow RFC 3986 which > reintroduces the old (rfc1808) behaviour which is also consistent > with e.g. firefox. After a more detailed review of rfc3986 there turned out to be more cases with a different resolution than in rfc2396. A new patch was committed. It passes all the tests in rfc3986 plus some more, and also the below quoted page to resolve as Firefox: <HTML> <HEAD> <TITLE>Relative URL test</TITLE> <BASE href="http://a/b/c/d;p?q#f"> </HEAD> <BODY> BASE ="http://a/b/c/d;p?q#f"<br> <a href="#foo">#foo</a><br> <a href="?foo=bar">?foo=bar</a><br> <a href="?foo=bar#frag">?foo=bar#frag</a><br> <a href="">empty</a> </BODY> </HTML> It was very good you spotted this bug! Now this kind of links will work in dillo. e.g. those in http://hg.dillo.org/dillo ;-) @all: Please test. -- Cheers Jorge.-

Feb. 13, 2009

patch: SELECT size > 1 !multiple

by corvid＠lavabit.com

When I was working on the SELECT size code recently, I enabled using the plain fltk::Browser if size > 1 and multiple was not set. I didn't realize that the callbacks for a plain Browser and a MultiBrowser behave differently.

Feb. 13, 2009

relative urls

by jcid＠dillo.org

On Fri, Feb 13, 2009 at 02:18:06PM +0100, Hofmann Johannes wrote: > On Fri, Feb 13, 2009 at 10:07:36AM -0300, Jorge Arellano Cid wrote: > > On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > > > correctly (check "5.1. Normal Examples"), dillo does not handle > > > relative urls with queries correctly. In case of queries it > > > truncates the filename. Anchors are handled correctly. > > > You can see the difference here: > > > > > > <a href="#foo">#foo</a> > > > <a href="?foo=bar">?foo=bar</a> > > > > Yes, dillo doesn't follow rfc1808.txt. > > > > Dillo follows rfc2396 which updates rfc1808. > > This particular case was changed by it. > > The nice thing about RFCs is that there is so many to choose from :) > > Just found this here: > http://www.communities.hp.com/securitysoftware/blogs/jeff/archive/2007/12/1… > After reading it I would suggest to follow RFC 3986 which > reintroduces the old (rfc1808) behaviour which is also consistent > with e.g. firefox. Given that info, it looks like RFC 3986 is the one to follow. I'll work on it. -- Cheers Jorge.-

Feb. 13, 2009

relative urls

by Johannes.Hofmann＠gmx.de

On Fri, Feb 13, 2009 at 10:07:36AM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > > Hi, > > > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > > correctly (check "5.1. Normal Examples"), dillo does not handle > > relative urls with queries correctly. In case of queries it > > truncates the filename. Anchors are handled correctly. > > You can see the difference here: > > > > <a href="#foo">#foo</a> > > <a href="?foo=bar">?foo=bar</a> > > Yes, dillo doesn't follow rfc1808.txt. > > Dillo follows rfc2396 which updates rfc1808. > This particular case was changed by it. The nice thing about RFCs is that there is so many to choose from :) Just found this here: http://www.communities.hp.com/securitysoftware/blogs/jeff/archive/2007/12/1… After reading it I would suggest to follow RFC 3986 which reintroduces the old (rfc1808) behaviour which is also consistent with e.g. firefox. Cheers, Johannes > > It took me some time to review the issue. A long > time ago I made a test program for the URL resolver > that tests all the examples in rfc2396. The riddle > became clear once I reviewed its tests and the result > for this case was different. ;) > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 13, 2009

relative urls

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > Hi, > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > correctly (check "5.1. Normal Examples"), dillo does not handle > relative urls with queries correctly. In case of queries it > truncates the filename. Anchors are handled correctly. > You can see the difference here: > > <a href="#foo">#foo</a> > <a href="?foo=bar">?foo=bar</a> Yes, dillo doesn't follow rfc1808.txt. Dillo follows rfc2396 which updates rfc1808. This particular case was changed by it. It took me some time to review the issue. A long time ago I made a test program for the URL resolver that tests all the examples in rfc2396. The riddle became clear once I reviewed its tests and the result for this case was different. ;) -- Cheers Jorge.-

Feb. 13, 2009

Close-tab Button

by onepoint＠starurchin.org

On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote: > Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu: > > BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a > > developer from Brazil that just joined our team! > > Jo?o Hi Jo?o, welcome aboard! Dillo is a great project to work on. The code is good and the team spirit and mutual respect is good too. I'm sure you'll fit right in! Regards, Jeremy Henty

Feb. 13, 2009

[patch] Search Previous

by corvid＠lavabit.com

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.

Feb. 13, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

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 Jo?o > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 13, 2009

[patch] Search Previous

by corvid＠lavabit.com

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?

Feb. 13, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Qui, 2009-02-12 ?s 19:38 +0000, corvid escreveu: > I updated the UTF-8 sampler search bar screenshot > to show off the nifty new button :) > > Great, thanks! Onto another subject 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. Thanks, Jo?o

Feb. 12, 2009

Close-tab Button

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 06:17:04PM +0100, Hofmann Johannes wrote: > Hello, > > On Thu, Feb 12, 2009 at 06:43:44PM +0200, Rogut?s Sparnuotos wrote: > > Hello, > > > > Some redrawing bug got uncovered with the close-tab button. Open dillo, > > click on bookmarks, hit ctrl-t and ctrl-q - the "km" part of the > > "Bookmarks" tab title is shown in white on the "Clear the URL box". Now > > click ctrl-t and the close-tab button - the whole "Bookmarks" title is > > shown in white over the toolbar. > > In the first case, it is hardly noticeable, but it is when using the new > > button. > > I guess this is http://fltk.org/str.php?L2062 > I'm thinking about the workaround suggested by AlbrechtS. It's a bit > nasty to implement though... Yeah, I'm also not for implementing this. We've had already a tough time with the close-tab button. For the short term, I'd try to ask AlbrechtS for inclusion of his fix in the next FLTK2 release. On the long term, it'd be nice to re-implement tabs without the TabGroup widget inside Dillo (i.e. like the control Panel). This way we can use native fltk widgets and avoid problems. All of this is minor compared with the hidden goal: to avoid having multiple pages rendered at the same time. With dillo's speed we can just save different navigation stacks and render tabs on demand. This would reduce memory footprint to a single page no matter how many tabs are openned. -- Cheers Jorge.-

Feb. 12, 2009

Repush and scroll position

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > position. This is, if you load a page, start scrolling and the > > > stylesheet arrives after that, it will no longer go back to the > > > top. > > > > > > Please test. > > > > Works for me with Slashdot. Very nice! > > Yes, works great. > > One minor thing, which also happens when going back/forward: > > It seems that the page is first drawn with scroll position 0 and then > immediately scrolled down to the remembered scroll position. > Any ideas where the first redraw comes from? Maybe we can eliminate > that? I thought that with the implementation of cancelQueueDraw(), and the respective call from scrollTo() it would work, but I was wrong. The attached patch implements cancelQueueDraw() and adds some debugging messages that show interesting facts: Nav_open_url: new url='dpi:/bm/' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw Nav_open_url: new url='http://localhost/htdocs/redraw.html' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw 1.- There's no need for an explicit call to cancelQueueDraw() from Layout::scrollTo0(). It happens anyway. 2.- For bookmarks there's just one draw() call. 3.- For coming back to a scrolled page, there're four calls!!! 4.- I'm using a test page with no repush(): <html><body><img src="image1.png"><br> <ul><li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 </ul></body></html> This could take some time, so I'm handing it back to you now... -- Cheers Jorge.-

Feb. 12, 2009

Close-tab Button

by jorl17.8＠gmail.com

Qui, 2009-02-12 ?s 18:17 +0100, Hofmann Johannes escreveu: > Hello, > > On Thu, Feb 12, 2009 at 06:43:44PM +0200, Rogut?s Sparnuotos wrote: > > Hello, > > > > Some redrawing bug got uncovered with the close-tab button. Open dillo, > > click on bookmarks, hit ctrl-t and ctrl-q - the "km" part of the > > "Bookmarks" tab title is shown in white on the "Clear the URL box". Now > > click ctrl-t and the close-tab button - the whole "Bookmarks" title is > > shown in white over the toolbar. > > In the first case, it is hardly noticeable, but it is when using the new > > button. > > I guess this is http://fltk.org/str.php?L2062 > I'm thinking about the workaround suggested by AlbrechtS. It's a bit > nasty to implement though... > > Cheers, > Johannes > I did notice these things when I started work on the button, and I had always noticed that corruption, but since noone complained I thought it was a problem with my Compiz/Nvidia drivers or the like (i've been having some issues with them already). The workaround is indeed nasty to implement. Are you thinking of recreating the TabGroup class? Sending a redraw event to the UI also seems to fix this issue, the problem is finding the right spot to do it. Good luck, any help, just say, Jo?o > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 12, 2009

Close-tab Button

by Johannes.Hofmann＠gmx.de

Hello, On Thu, Feb 12, 2009 at 06:43:44PM +0200, Rogut?s Sparnuotos wrote: > Hello, > > Some redrawing bug got uncovered with the close-tab button. Open dillo, > click on bookmarks, hit ctrl-t and ctrl-q - the "km" part of the > "Bookmarks" tab title is shown in white on the "Clear the URL box". Now > click ctrl-t and the close-tab button - the whole "Bookmarks" title is > shown in white over the toolbar. > In the first case, it is hardly noticeable, but it is when using the new > button. I guess this is http://fltk.org/str.php?L2062 I'm thinking about the workaround suggested by AlbrechtS. It's a bit nasty to implement though... Cheers, Johannes

Feb. 12, 2009

Close-tab Button

by rogutes＠googlemail.com

Hello, Some redrawing bug got uncovered with the close-tab button. Open dillo, click on bookmarks, hit ctrl-t and ctrl-q - the "km" part of the "Bookmarks" tab title is shown in white on the "Clear the URL box". Now click ctrl-t and the close-tab button - the whole "Bookmarks" title is shown in white over the toolbar. In the first case, it is hardly noticeable, but it is when using the new button. -- -- Rogut?s Sparnuotos

Feb. 12, 2009

Close-tab Button

by darkspirit5000＠gmail.com

Hi Jo?o welcome from a spain lurker :P Diego.

Feb. 12, 2009

Repush and scroll position

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 12:09:43PM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 12, 2009 at 11:52:27AM -0300, Jorge Arellano Cid wrote: > > On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > > > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > > > position. This is, if you load a page, start scrolling and the > > > > > stylesheet arrives after that, it will no longer go back to the > > > > > top. > > > > > > > > > > Please test. > > > > > > > > Works for me with Slashdot. Very nice! > > > > > > Yes, works great. > > > > > > One minor thing, which also happens when going back/forward: > > > > > > It seems that the page is first drawn with scroll position 0 and then > > > immediately scrolled down to the remembered scroll position. > > > Any ideas where the first redraw comes from? Maybe we can eliminate > > > that? > > > > Yes, I've noticed this and share the feel on it! > > > > Maybe there's a redraw request for pos. 0, and then the scroll jump. > > If the jump is made from a timeout function, then the first draw will > > always complete. > > > > I haven't checked the code though. > > After a skim, that's exactly the case. > > Even more there's a FltkViewBase::cancelQueueDraw() function > that looks very much like what we need. > > The only caveat is that it's not implemented yet! :-) I'm working on it... -- Cheers Jorge.-

Feb. 12, 2009

Repush and scroll position

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 11:52:27AM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > > position. This is, if you load a page, start scrolling and the > > > > stylesheet arrives after that, it will no longer go back to the > > > > top. > > > > > > > > Please test. > > > > > > Works for me with Slashdot. Very nice! > > > > Yes, works great. > > > > One minor thing, which also happens when going back/forward: > > > > It seems that the page is first drawn with scroll position 0 and then > > immediately scrolled down to the remembered scroll position. > > Any ideas where the first redraw comes from? Maybe we can eliminate > > that? > > Yes, I've noticed this and share the feel on it! > > Maybe there's a redraw request for pos. 0, and then the scroll jump. > If the jump is made from a timeout function, then the first draw will > always complete. > > I haven't checked the code though. After a skim, that's exactly the case. Even more there's a FltkViewBase::cancelQueueDraw() function that looks very much like what we need. The only caveat is that it's not implemented yet! :-) -- Cheers Jorge.-

Feb. 12, 2009

Close-tab Button

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote: > Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu: > > On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote: > > > Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu: > > > > On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > > > > > > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > > A simple update. > > > > > > > > > > > > > > I've fixed most issues I found. For instance, we were processing the > > > > > > > click on PUSH and not RELEASE, that was causing some problems and The > > > > > > > issue I talked about earlier (working while not visible). > > > > > > > > > > > > Good. > > > > > > > > > > > > > I've got a working tooltip, added to CustTabGroup. > > > > > > > > > > > > Good 2. I feared this could be harder. > > > > > > > > > > > > > The only problem is drawing into the button. Should I use an image (or > > > > > > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > > > > > > Adding a cross is easy, adding an image involves digging some more but > > > > > > > it is obviously doable. > > > > > > > > > > > > Try drawing a cross with a couple of lines. After all this is a > > > > > > well-baheved workaround, but no more. At some point in time it > > > > > > will be fixed in FLTK (I hope). > > > > > > > > > > > > > > > > Fixed a couple more issues relating to focus and events getting lost, > > > > > including the tooltip not showing up after fixing some of these. > > > > > > > > > > To draw the 'X', I thought of writting an 'X' there. This turned out OK: > > > > > I set the color to black and, then, determine the positions of the 'X' > > > > > based on fltk::measure. I thought the cross was too 'thin' so I decided > > > > > to use a bold font. Now here comes the problem. For some reason, > > > > > measure() uses the previously set font (although the selected is > > > > > printed)). Maybe I'm missing something, here's the code: > > > > > > > > > > fltk::setfont(fltk::getfont()->bold(), > > > > > fltk::getsize()); > > > > > int textW=0, textH=0; > > > > > fltk::measure("X", textW, textH, ALIGN_CENTER); > > > > > MSG("W: %d, H: %d.\n", textW, textH); > > > > > fltk::drawtext("X", btn_x+textW, textH); > > > > > > > > > > Any change to setfont() (bold, font itself) does not affect measure, > > > > > which affects the positioning of the cross... > > > > > > > > > > I tried to draw the lines, but they were simply too 'choppy' and it even > > > > > looks better with the 'skinny text' itself. > > > > > > > > This works OK for me: > > > > > > > > setcolor(GRAY10); > > > > r.h(r.h()-2); > > > > drawtext("X", r, ALIGN_CENTER); > > > > > > > > (added just after fillrect()) > > > > > > > > > > OK, I've got a working patch with (as far as I can tell) one bug: > > > > > > Once a tooltip has popped-up in the button, if we move the cursor to the > > > search button, the tooltip for that button will not appear, until we > > > move out of this button and back in. A solution I found caused another > > > bug which I considered more annoying (tooltip always visible while the > > > mouse doesn't leave the whole tabs area). But this occurs only when > > > moving immediatly to the search button, and not when moving to anything > > > else (location bar works immediatly). Also, it seems that this doesn't > > > always. > > > > > > Apart from that, it seems to be OK. > > > > > > I tried to keep indenting as close as possible, do say if I missed > > > something. > > > > > > This patch includes your code, my code and my changes to your code. > > > > > > Thanks, > > > > Committed! > > > > With this minor changes: > > > > - Moved update_positions() out of the class decl. > > - Used event_inside() instead of our custom test. > > - Separated some assignements: a=b; -> a = b; > > - Changed the button colors, and added a highlight effect. > > - Made debug messages silent. > > > > It took more effort than anticipated, but now we have our shiny > > close-tab button. > > > > Note: the tooltip issue is still unresolved. OTOH it's so minor, > > we can perfectly live with it. > > > > All: please test and find it great! :-) > > > > Thanks Jo?o! > > > > BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a > > developer from Brazil that just joined our team! > > > > Thanks, and I completely forgot to thank you for your help on the code! > > There's one small mistake there, I'm from Portugal :) Oh, sorry. I thought you were at unicamp. -- Cheers Jorge.-

Feb. 12, 2009

Repush and scroll position

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > position. This is, if you load a page, start scrolling and the > > > stylesheet arrives after that, it will no longer go back to the > > > top. > > > > > > Please test. > > > > Works for me with Slashdot. Very nice! > > Yes, works great. > > One minor thing, which also happens when going back/forward: > > It seems that the page is first drawn with scroll position 0 and then > immediately scrolled down to the remembered scroll position. > Any ideas where the first redraw comes from? Maybe we can eliminate > that? Yes, I've noticed this and share the feel on it! Maybe there's a redraw request for pos. 0, and then the scroll jump. If the jump is made from a timeout function, then the first draw will always complete. I haven't checked the code though. -- Cheers Jorge.-

Feb. 12, 2009

Close-tab Button

by Johannes.Hofmann＠gmx.de

On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote: > Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu: > > On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote: > > > Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu: > > > > On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > > > > > > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > > A simple update. > > > > > > > > > > > > > > I've fixed most issues I found. For instance, we were processing the > > > > > > > click on PUSH and not RELEASE, that was causing some problems and The > > > > > > > issue I talked about earlier (working while not visible). > > > > > > > > > > > > Good. > > > > > > > > > > > > > I've got a working tooltip, added to CustTabGroup. > > > > > > > > > > > > Good 2. I feared this could be harder. > > > > > > > > > > > > > The only problem is drawing into the button. Should I use an image (or > > > > > > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > > > > > > Adding a cross is easy, adding an image involves digging some more but > > > > > > > it is obviously doable. > > > > > > > > > > > > Try drawing a cross with a couple of lines. After all this is a > > > > > > well-baheved workaround, but no more. At some point in time it > > > > > > will be fixed in FLTK (I hope). > > > > > > > > > > > > > > > > Fixed a couple more issues relating to focus and events getting lost, > > > > > including the tooltip not showing up after fixing some of these. > > > > > > > > > > To draw the 'X', I thought of writting an 'X' there. This turned out OK: > > > > > I set the color to black and, then, determine the positions of the 'X' > > > > > based on fltk::measure. I thought the cross was too 'thin' so I decided > > > > > to use a bold font. Now here comes the problem. For some reason, > > > > > measure() uses the previously set font (although the selected is > > > > > printed)). Maybe I'm missing something, here's the code: > > > > > > > > > > fltk::setfont(fltk::getfont()->bold(), > > > > > fltk::getsize()); > > > > > int textW=0, textH=0; > > > > > fltk::measure("X", textW, textH, ALIGN_CENTER); > > > > > MSG("W: %d, H: %d.\n", textW, textH); > > > > > fltk::drawtext("X", btn_x+textW, textH); > > > > > > > > > > Any change to setfont() (bold, font itself) does not affect measure, > > > > > which affects the positioning of the cross... > > > > > > > > > > I tried to draw the lines, but they were simply too 'choppy' and it even > > > > > looks better with the 'skinny text' itself. > > > > > > > > This works OK for me: > > > > > > > > setcolor(GRAY10); > > > > r.h(r.h()-2); > > > > drawtext("X", r, ALIGN_CENTER); > > > > > > > > (added just after fillrect()) > > > > > > > > > > OK, I've got a working patch with (as far as I can tell) one bug: > > > > > > Once a tooltip has popped-up in the button, if we move the cursor to the > > > search button, the tooltip for that button will not appear, until we > > > move out of this button and back in. A solution I found caused another > > > bug which I considered more annoying (tooltip always visible while the > > > mouse doesn't leave the whole tabs area). But this occurs only when > > > moving immediatly to the search button, and not when moving to anything > > > else (location bar works immediatly). Also, it seems that this doesn't > > > always. > > > > > > Apart from that, it seems to be OK. > > > > > > I tried to keep indenting as close as possible, do say if I missed > > > something. > > > > > > This patch includes your code, my code and my changes to your code. > > > > > > Thanks, > > > > Committed! > > > > With this minor changes: > > > > - Moved update_positions() out of the class decl. > > - Used event_inside() instead of our custom test. > > - Separated some assignements: a=b; -> a = b; > > - Changed the button colors, and added a highlight effect. > > - Made debug messages silent. > > > > It took more effort than anticipated, but now we have our shiny > > close-tab button. > > > > Note: the tooltip issue is still unresolved. OTOH it's so minor, > > we can perfectly live with it. > > > > All: please test and find it great! :-) > > > > Thanks Jo?o! > > > > BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a > > developer from Brazil that just joined our team! > > > > Thanks, and I completely forgot to thank you for your help on the code! > > There's one small mistake there, I'm from Portugal :) > > Let's hope the tests work out ok! Hi Jo?o and welcome on board! Cheers, Johannes

Feb. 12, 2009

Repush and scroll position

by Johannes.Hofmann＠gmx.de

On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > Patch b134ea74331b is to make repush remmeber the scrolling > > position. This is, if you load a page, start scrolling and the > > stylesheet arrives after that, it will no longer go back to the > > top. > > > > Please test. > > Works for me with Slashdot. Very nice! Yes, works great. One minor thing, which also happens when going back/forward: It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that? Regards, Johannes

Feb. 12, 2009

Repush and scroll position

by onepoint＠starurchin.org

On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > Patch b134ea74331b is to make repush remmeber the scrolling > position. This is, if you load a page, start scrolling and the > stylesheet arrives after that, it will no longer go back to the > top. > > Please test. Works for me with Slashdot. Very nice! Regards, Jeremy Henty

Feb. 12, 2009

Close-tab Button

by jorl17.8＠gmail.com

Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu: > On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote: > > Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu: > > > On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote: > > > > Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > > > > > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > A simple update. > > > > > > > > > > > > I've fixed most issues I found. For instance, we were processing the > > > > > > click on PUSH and not RELEASE, that was causing some problems and The > > > > > > issue I talked about earlier (working while not visible). > > > > > > > > > > Good. > > > > > > > > > > > I've got a working tooltip, added to CustTabGroup. > > > > > > > > > > Good 2. I feared this could be harder. > > > > > > > > > > > The only problem is drawing into the button. Should I use an image (or > > > > > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > > > > > Adding a cross is easy, adding an image involves digging some more but > > > > > > it is obviously doable. > > > > > > > > > > Try drawing a cross with a couple of lines. After all this is a > > > > > well-baheved workaround, but no more. At some point in time it > > > > > will be fixed in FLTK (I hope). > > > > > > > > > > > > > Fixed a couple more issues relating to focus and events getting lost, > > > > including the tooltip not showing up after fixing some of these. > > > > > > > > To draw the 'X', I thought of writting an 'X' there. This turned out OK: > > > > I set the color to black and, then, determine the positions of the 'X' > > > > based on fltk::measure. I thought the cross was too 'thin' so I decided > > > > to use a bold font. Now here comes the problem. For some reason, > > > > measure() uses the previously set font (although the selected is > > > > printed)). Maybe I'm missing something, here's the code: > > > > > > > > fltk::setfont(fltk::getfont()->bold(), > > > > fltk::getsize()); > > > > int textW=0, textH=0; > > > > fltk::measure("X", textW, textH, ALIGN_CENTER); > > > > MSG("W: %d, H: %d.\n", textW, textH); > > > > fltk::drawtext("X", btn_x+textW, textH); > > > > > > > > Any change to setfont() (bold, font itself) does not affect measure, > > > > which affects the positioning of the cross... > > > > > > > > I tried to draw the lines, but they were simply too 'choppy' and it even > > > > looks better with the 'skinny text' itself. > > > > > > This works OK for me: > > > > > > setcolor(GRAY10); > > > r.h(r.h()-2); > > > drawtext("X", r, ALIGN_CENTER); > > > > > > (added just after fillrect()) > > > > > > > OK, I've got a working patch with (as far as I can tell) one bug: > > > > Once a tooltip has popped-up in the button, if we move the cursor to the > > search button, the tooltip for that button will not appear, until we > > move out of this button and back in. A solution I found caused another > > bug which I considered more annoying (tooltip always visible while the > > mouse doesn't leave the whole tabs area). But this occurs only when > > moving immediatly to the search button, and not when moving to anything > > else (location bar works immediatly). Also, it seems that this doesn't > > always. > > > > Apart from that, it seems to be OK. > > > > I tried to keep indenting as close as possible, do say if I missed > > something. > > > > This patch includes your code, my code and my changes to your code. > > > > Thanks, > > Committed! > > With this minor changes: > > - Moved update_positions() out of the class decl. > - Used event_inside() instead of our custom test. > - Separated some assignements: a=b; -> a = b; > - Changed the button colors, and added a highlight effect. > - Made debug messages silent. > > It took more effort than anticipated, but now we have our shiny > close-tab button. > > Note: the tooltip issue is still unresolved. OTOH it's so minor, > we can perfectly live with it. > > All: please test and find it great! :-) > > Thanks Jo?o! > > BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a > developer from Brazil that just joined our team! > Thanks, and I completely forgot to thank you for your help on the code! There's one small mistake there, I'm from Portugal :) Let's hope the tests work out ok! Jo?o

Feb. 12, 2009

Close-tab Button

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote: > Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu: > > On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote: > > > Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > > > > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > A simple update. > > > > > > > > > > I've fixed most issues I found. For instance, we were processing the > > > > > click on PUSH and not RELEASE, that was causing some problems and The > > > > > issue I talked about earlier (working while not visible). > > > > > > > > Good. > > > > > > > > > I've got a working tooltip, added to CustTabGroup. > > > > > > > > Good 2. I feared this could be harder. > > > > > > > > > The only problem is drawing into the button. Should I use an image (or > > > > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > > > > Adding a cross is easy, adding an image involves digging some more but > > > > > it is obviously doable. > > > > > > > > Try drawing a cross with a couple of lines. After all this is a > > > > well-baheved workaround, but no more. At some point in time it > > > > will be fixed in FLTK (I hope). > > > > > > > > > > Fixed a couple more issues relating to focus and events getting lost, > > > including the tooltip not showing up after fixing some of these. > > > > > > To draw the 'X', I thought of writting an 'X' there. This turned out OK: > > > I set the color to black and, then, determine the positions of the 'X' > > > based on fltk::measure. I thought the cross was too 'thin' so I decided > > > to use a bold font. Now here comes the problem. For some reason, > > > measure() uses the previously set font (although the selected is > > > printed)). Maybe I'm missing something, here's the code: > > > > > > fltk::setfont(fltk::getfont()->bold(), > > > fltk::getsize()); > > > int textW=0, textH=0; > > > fltk::measure("X", textW, textH, ALIGN_CENTER); > > > MSG("W: %d, H: %d.\n", textW, textH); > > > fltk::drawtext("X", btn_x+textW, textH); > > > > > > Any change to setfont() (bold, font itself) does not affect measure, > > > which affects the positioning of the cross... > > > > > > I tried to draw the lines, but they were simply too 'choppy' and it even > > > looks better with the 'skinny text' itself. > > > > This works OK for me: > > > > setcolor(GRAY10); > > r.h(r.h()-2); > > drawtext("X", r, ALIGN_CENTER); > > > > (added just after fillrect()) > > > > OK, I've got a working patch with (as far as I can tell) one bug: > > Once a tooltip has popped-up in the button, if we move the cursor to the > search button, the tooltip for that button will not appear, until we > move out of this button and back in. A solution I found caused another > bug which I considered more annoying (tooltip always visible while the > mouse doesn't leave the whole tabs area). But this occurs only when > moving immediatly to the search button, and not when moving to anything > else (location bar works immediatly). Also, it seems that this doesn't > always. > > Apart from that, it seems to be OK. > > I tried to keep indenting as close as possible, do say if I missed > something. > > This patch includes your code, my code and my changes to your code. > > Thanks, Committed! With this minor changes: - Moved update_positions() out of the class decl. - Used event_inside() instead of our custom test. - Separated some assignements: a=b; -> a = b; - Changed the button colors, and added a highlight effect. - Made debug messages silent. It took more effort than anticipated, but now we have our shiny close-tab button. Note: the tooltip issue is still unresolved. OTOH it's so minor, we can perfectly live with it. All: please test and find it great! :-) Thanks Jo?o! BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a developer from Brazil that just joined our team! -- Cheers Jorge.-

Feb. 12, 2009

relative urls

by Johannes.Hofmann＠gmx.de

Hi, if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt correctly (check "5.1. Normal Examples"), dillo does not handle relative urls with queries correctly. In case of queries it truncates the filename. Anchors are handled correctly. You can see the difference here: <a href="#foo">#foo</a> <a href="?foo=bar">?foo=bar</a> Please check attached patch. Cheers, Johannes

Feb. 12, 2009

Close-tab Button

by jorl17.8＠gmail.com

Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu: > On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote: > > Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > > > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > > > A simple update. > > > > > > > > I've fixed most issues I found. For instance, we were processing the > > > > click on PUSH and not RELEASE, that was causing some problems and The > > > > issue I talked about earlier (working while not visible). > > > > > > Good. > > > > > > > I've got a working tooltip, added to CustTabGroup. > > > > > > Good 2. I feared this could be harder. > > > > > > > The only problem is drawing into the button. Should I use an image (or > > > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > > > Adding a cross is easy, adding an image involves digging some more but > > > > it is obviously doable. > > > > > > Try drawing a cross with a couple of lines. After all this is a > > > well-baheved workaround, but no more. At some point in time it > > > will be fixed in FLTK (I hope). > > > > > > > Fixed a couple more issues relating to focus and events getting lost, > > including the tooltip not showing up after fixing some of these. > > > > To draw the 'X', I thought of writting an 'X' there. This turned out OK: > > I set the color to black and, then, determine the positions of the 'X' > > based on fltk::measure. I thought the cross was too 'thin' so I decided > > to use a bold font. Now here comes the problem. For some reason, > > measure() uses the previously set font (although the selected is > > printed)). Maybe I'm missing something, here's the code: > > > > fltk::setfont(fltk::getfont()->bold(), > > fltk::getsize()); > > int textW=0, textH=0; > > fltk::measure("X", textW, textH, ALIGN_CENTER); > > MSG("W: %d, H: %d.\n", textW, textH); > > fltk::drawtext("X", btn_x+textW, textH); > > > > Any change to setfont() (bold, font itself) does not affect measure, > > which affects the positioning of the cross... > > > > I tried to draw the lines, but they were simply too 'choppy' and it even > > looks better with the 'skinny text' itself. > > This works OK for me: > > setcolor(GRAY10); > r.h(r.h()-2); > drawtext("X", r, ALIGN_CENTER); > > (added just after fillrect()) > OK, I've got a working patch with (as far as I can tell) one bug: Once a tooltip has popped-up in the button, if we move the cursor to the search button, the tooltip for that button will not appear, until we move out of this button and back in. A solution I found caused another bug which I considered more annoying (tooltip always visible while the mouse doesn't leave the whole tabs area). But this occurs only when moving immediatly to the search button, and not when moving to anything else (location bar works immediatly). Also, it seems that this doesn't always. Apart from that, it seems to be OK. I tried to keep indenting as close as possible, do say if I missed something. This patch includes your code, my code and my changes to your code. Thanks, Jo?o

Feb. 12, 2009

Close-tab Button

by jcid＠dillo.org

On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote: > Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > > A simple update. > > > > > > I've fixed most issues I found. For instance, we were processing the > > > click on PUSH and not RELEASE, that was causing some problems and The > > > issue I talked about earlier (working while not visible). > > > > Good. > > > > > I've got a working tooltip, added to CustTabGroup. > > > > Good 2. I feared this could be harder. > > > > > The only problem is drawing into the button. Should I use an image (or > > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > > Adding a cross is easy, adding an image involves digging some more but > > > it is obviously doable. > > > > Try drawing a cross with a couple of lines. After all this is a > > well-baheved workaround, but no more. At some point in time it > > will be fixed in FLTK (I hope). > > > > Fixed a couple more issues relating to focus and events getting lost, > including the tooltip not showing up after fixing some of these. > > To draw the 'X', I thought of writting an 'X' there. This turned out OK: > I set the color to black and, then, determine the positions of the 'X' > based on fltk::measure. I thought the cross was too 'thin' so I decided > to use a bold font. Now here comes the problem. For some reason, > measure() uses the previously set font (although the selected is > printed)). Maybe I'm missing something, here's the code: > > fltk::setfont(fltk::getfont()->bold(), > fltk::getsize()); > int textW=0, textH=0; > fltk::measure("X", textW, textH, ALIGN_CENTER); > MSG("W: %d, H: %d.\n", textW, textH); > fltk::drawtext("X", btn_x+textW, textH); > > Any change to setfont() (bold, font itself) does not affect measure, > which affects the positioning of the cross... > > I tried to draw the lines, but they were simply too 'choppy' and it even > looks better with the 'skinny text' itself. This works OK for me: setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER); (added just after fillrect()) -- Cheers Jorge.-

Feb. 12, 2009

style parsing on iframe

by furaisanjin＠gmail.com

Hi all. I'm wondering if it's necessary to parse style on iframe. I see a large bullet sometimes and this is one example page. http://www.oshiimamoru.com/news/news_r0807.htm The page contains this kind of iframe tag. <iframe src="http://rcm-jp.amazon.co.jp/e/cm?t=deizcom-22&o=9&p=8&l=as1&asins=4344980891…" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"> Regards, furaisanjin

Feb. 11, 2009

Close-tab Button

by jorl17.8＠gmail.com

Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu: > On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > > A simple update. > > > > I've fixed most issues I found. For instance, we were processing the > > click on PUSH and not RELEASE, that was causing some problems and The > > issue I talked about earlier (working while not visible). > > Good. > > > I've got a working tooltip, added to CustTabGroup. > > Good 2. I feared this could be harder. > > > The only problem is drawing into the button. Should I use an image (or > > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > > Adding a cross is easy, adding an image involves digging some more but > > it is obviously doable. > > Try drawing a cross with a couple of lines. After all this is a > well-baheved workaround, but no more. At some point in time it > will be fixed in FLTK (I hope). > Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these. To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code: fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH); Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross... I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself. Thanks, Jo?o

Feb. 11, 2009

Repush and scroll position

by jcid＠dillo.org

Hi, Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top. Please test. -- Cheers Jorge.-

Feb. 11, 2009

google news link

by onepoint＠starurchin.org

On Wed, Feb 11, 2009 at 09:37:59AM -0300, Jorge Arellano Cid wrote: > A is an "inline container", DIV is a "block element". Only "block > containers" are allowed to have "block elements" inside. Hence it > is a bug. In this case Dillo closes the inline container and > keeps on parsing. Could the Dillo parser emit the warning but not close the container? The result would be more useful to the user, and web devs who care about correctness would still see the warning. (Disclaimer: I have no idea whether my suggestion is feasible, it's just a thought.) Regards, Jeremy Henty

Feb. 11, 2009

New mercurial repository

by onepoint＠starurchin.org

On Wed, Feb 11, 2009 at 10:58:24AM -0300, Jorge Arellano Cid wrote: > Good news: Andreas K. has just set a fast Hg repository for > dillo. Try it at: http://hg.dillo.org/dillo This is a vast improvement. Many thanks to Andreas! Jeremy Henty

Feb. 11, 2009

New mercurial repository

by corvid＠lavabit.com

Jorge wrote: > Good news: Andreas K. has just set a fast Hg repository for > dillo. Try it at: http://hg.dillo.org/dillo Blazing fast after being accustomed to freehg. Thanks Andreas! BTW, the web interface wants to load http://hg.dillo.org/?static=style.css which gets a 500 internal server error.

Feb. 11, 2009

google news link

by corvid＠lavabit.com

Johannes wrote: > That makes me think whether it is a good idea to let the cursor be > changed from CSS. For example: > > <a href="dangerous" style="cursor:default">harmless</a> > > might trick someone to click a link it doesn't want to. > Or am I paranoid here? If it's paranoia, it's a healthy paranoia :) (I already had to force underlining of links in style.css. I can't understand why non-malicious sites turn that off to make it hard to tell what's what.)

Feb. 11, 2009

ChangeLog

by jcid＠dillo.org

Hi, Johannes, corvid: it'd be good if you can update the ChangeLog file with your work. This ChangeLog is meant to be human-readable so please summarize as usual and highlight the important points. We have the full details in HG after all. -- Cheers Jorge.-

Feb. 11, 2009

New mercurial repository

by jcid＠dillo.org

Hi, Good news: Andreas K. has just set a fast Hg repository for dillo. Try it at: http://hg.dillo.org/dillo I'll switch the web page to point to it after sending this email. Enjoy! :-) -- Cheers Jorge.-

Feb. 11, 2009