- Dillo-dev - lists.mailman3.com

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