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

[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