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

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

google news link

by jcid＠dillo.org

On Wed, Feb 11, 2009 at 08:40:01PM +0900, furaisanjin wrote: > I notice that dillo doesn't allow <div> inside <a>. That's why link > doesn't work. This is one example from news.google.com. > > <a class=d href="/news?ned=us&topic=w"> > <div class=naventry> > <font size=-1> > <b> > World</b> > </font> > </div> > </a> Yes. It's dillo trying to follow and help others to play by standards. This page has more than a hundred bugs in the bug-meter. 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. BTW, this is the same reason why you can't make a link out of a TABLE. -- Cheers Jorge.-

Feb. 11, 2009

google news link

by furaisanjin＠gmail.com

I notice that dillo doesn't allow <div> inside <a>. That's why link doesn't work. This is one example from news.google.com. <a class=d href="/news?ned=us&topic=w"> <div class=naventry> <font size=-1> <b> World</b> </font> </div> </a> Regards, furaisanjin

Feb. 11, 2009