- Dillo-dev - lists.mailman3.com

Close-tab Button

by jorl17.8＠gmail.com

Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > Greetings to all. > > > > As a simple introduction may I say I thank you all for your work on > > Dillo. > > > > Currently, I am trying to implement the Close-Tab button. I've been > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > dillo-dev. > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > and the idea was to have a button at the end of the tabs list. > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > this widget at the end of the tabs list and, then, I add() it to the > > CustTabGroup's parent() (UI). > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > such a way that it doesn't resize the button itself, but only moves it. > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > handle() method of the CustTabGroup. > > > > Just a second ago I solved one of the problems, which was the fact that > > tab_height() returned 0 in the constructor and resize() didn't work. I > > worked around that by constructing the button only in event() if > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > the correct height for the button. > > > > It may not seem reliable to do so many things in handle(). Any > > suggestions? > > We need to get something working, review it, and then we may > ask in fltk.general whether it could have side effects. > > > It is functional, only you can say if it fully suits Dillo's needs > > though. > > Please post the patch here so we can look at it. > > > Unfortunately, there are some problems: > > > > The first one is the most-relevant one. When the list of tabs grows it > > can go over the button. I have been trying to fix this, but I can't seem > > to do it. > > A possible way could (maybe) be to 'trick' the pager into thinking it > > has less space left to draw the tabs, and that could possibly be > > achieved using update_positions(), although I am having some problems > > with that. > > Or maybe just tweaking the value. After all it's a workaround. > > > The second problem is a minor one, but annoying. I believe when CSS > > rendering is triggered, the render area flickers and that is normal. > > However, the way I implemented this (probably because of it being in > > handle()) makes the Button also flash. > > A side affect of being a child of UI. > So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically. Jo?o

Feb. 2, 2009

Address Bar Text Clears

by corvid＠lavabit.com

Calvin wrote: > open up a website, make sure to pick one that loads slowly and to type > it in the address bar. as it's loading open up a new tab, now click > back. the URL in the address bar field is empty. Hmm...I can't seem to get this to break. Is this the 2.0 release or the current tree? Suitably recent FLTK2 snapshot? Are you running on OSX by any chance?

Feb. 2, 2009

[patch]: fix signature of Html_add_new_linkimage()

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 08:45:06PM +0000, Jeremy Henty wrote: > > A small cleanup patch. > > * The return value of Html_add_new_linkimage() is never used, so it > should return void. Committed this part. > > * There's no need to pass the url to Html_add_new_linkimage() as a > (DilloUrl **), so just copy the (DilloUrl *) pointer. It's used to emphasize the url parameter changes owner. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 2, 2009

Address Bar Text Clears

by crazycal00＠gmail.com

Hi, Found kind of a bug but dunno if it really counts as one so i figured i'd run it past the mailing list first. open up a website, make sure to pick one that loads slowly and to type it in the address bar. as it's loading open up a new tab, now click back. the URL in the address bar field is empty. just thought i'd share. Calvin

Feb. 1, 2009

FIELDSET element

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 06:05:09PM -0300, Jorge Arellano Cid wrote: > Hi, > > Now that we have align in CSS, it may be easy to add support > for the FIELDSET element: > > http://www.w3.org/TR/html401/interact/forms.html#h-17.10 This is not an urgent matter. I just noticed BUG#720 while updating the bug tracker. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

FIELDSET element

by jcid＠dillo.org

Hi, Now that we have align in CSS, it may be easy to add support for the FIELDSET element: http://www.w3.org/TR/html401/interact/forms.html#h-17.10 -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

[patch]: fix signature of Html_add_new_linkimage()

by onepoint＠starurchin.org

A small cleanup patch. * The return value of Html_add_new_linkimage() is never used, so it should return void. * There's no need to pass the url to Html_add_new_linkimage() as a (DilloUrl **), so just copy the (DilloUrl *) pointer. Regards, Jeremy Henty

Feb. 1, 2009

Bad character coding for www.blisty.cz

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > Michal wrote: > > > > > Hi, > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > following sence (it's in Czech) > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > was changed. > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > 2) dillo www.blisty.cz > > > > > 3) --> PASS > > > > > 4) quit dillo > > > > > 5) dillo www.blisty.cz > > > > > 6) --> FAIL > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > Breaks for me, too. > > > > > > > > Plus having to wait through 116K of download before anything > > > > appears is no fun. > > > > > > It works for me! :-) > > > > > > Seriously, I still have a pending item to review here, and it's > > > when charset appears after the stylesheet in HEAD. This page also > > > has timing issues: http://www.daemonnews.org > > > > > > It looks like queueing the stylesheets and asking for them > > > after charset or at head close may fix it. > > > > Does anyone else experience pages not rendering until > > download is complete? I see this with the dillo.org > > pages, for instance, since the meta charset is iso-8859-1. > > Yes, I'm also seeing it. Not sure when this started. According to hg bisect it starts with d29cdb5b842e, but I don't see any obvious issues there. Jorge, can you have a look please? Cheers, Johannes

Feb. 1, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > I was just looking at some of the prefs that I > don't think are doing anything right now, e.g., > link_color, force_my_colors... > I could stuff them into buildUserStyle(), but > I don't know which should prevail in case of > conflicts. > > I can't remember whether I've already mentioned that > I've been wondering whether it might be reasonable to > rip a bunch of color stuff out of dillorc and expect > a dillo user to be able to deal with a well-commented > sample style.css instead. Good point. I always favor simplicity so I think we should have just one way to modify the style. Having two (style.css and preferences) just adds confusion. We need to document this properly as you said. Johannes

Feb. 1, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

I was just looking at some of the prefs that I don't think are doing anything right now, e.g., link_color, force_my_colors... I could stuff them into buildUserStyle(), but I don't know which should prevail in case of conflicts. I can't remember whether I've already mentioned that I've been wondering whether it might be reasonable to rip a bunch of color stuff out of dillorc and expect a dillo user to be able to deal with a well-commented sample style.css instead.

Feb. 1, 2009