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

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