- Dillo-dev - lists.mailman3.com

patch: clean up a_Html_add_image
by onepoint＠starurchin.org Feb. 8, 2009

Feb. 8, 2009

There is IMHO a nasty code smell around a_Html_add_new_image(): it takes a boolean parameter that determines whether or not it actually adds the image. It's only called from two other places, once with the parameter set to false and once with it set to true. This patch cleans things up by renaming a_Html_add_new_image() to a_Html_image_new(), removing the boolean parameter and making the caller add the image (or not) as appropriate. Perhaps it is a judgement call as to whether this is an improvement, but I feel that it is. Please comment. Regards, Jeremy Henty

4 7

patch: <s> line appearance
by corvid＠lavabit.com Feb. 8, 2009

Feb. 8, 2009

I was thinking that large text with a thin line through it looks odd. Turns out that there was also a problem with <sup> causing the <s> line to be too high. This looks about right to me with the few fonts I have around. I'm attaching an example html file as well. PS Might be good to go through that area of the code one day to see what opportunities there are to make it clearer...

3 4

name/id bug
by corvid＠lavabit.com Feb. 8, 2009

Feb. 8, 2009

<a name="a"></a> <p id="p"></p> <p> <a name="same" id="same"></a> gives HTML warning: line 2, 'id' and 'name' attribute of <a> tag differ HTML warning: line 4, Anchor names must be unique within the document Dillo would seem to be unhappy now that the id attr is checked before open_a checks the name attr -- but then it looks like the move was made in October (a88b4a31cb7a) and I have a dillo around from roughly Dec. 22 that does not have a problem with this. In any case, I don't know whether there are styleEngine issues with just sticking the id check back after the open.

3 11

Rendering XHTML 1.1
by Hole.destructor＠gmx.de Feb. 8, 2009

Feb. 8, 2009

Hello Dillo developers, since you are planing to release Dillo-2.1 in about a month, I am wondering whether there are plans to support XHTML 1.1, HTML 5 and XHTML 2 web pages in the near future? Thanks, Alexander.

2 1

Close-tab Button
by jorl17.8＠gmail.com Feb. 8, 2009

Feb. 8, 2009

S?b, 2009-02-07 ?s 23:38 -0300, Jorge Arellano Cid escreveu: > On Sat, Feb 07, 2009 at 09:57:52PM +0000, Jo?o Ricardo Louren?o wrote: > > S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu: > > > On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote: > > > > > 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. > > > > > > > > I'm reviewing it now. > > > > > > Well, the good part is that it works and can be polished a bit. > > > The problem is side effects (e.g. redraw storms while moving the mouse > > > over the panel buttons, and who knows what else?). > > > > > > I tried a different approach and it almost worked OK, but after > > > resizing the window, the redraw storms are on the whole window. > > > > > > Frustrating... > > > > > > It looks like drawing the button in the pager could work. I'll > > > try to write some code this way. > > > > > > > Thanks. Redraw storms are visible when running it under valgrind. Also, > > parts of the code there were/are unnecessary. For instance, we could > > send the redraw() message only when adding a new tab and not > > continuously, but the redraw storms continue either way... > > > > Adding it to the pager seems the way to go there, but will you add it as > > a button, or a custom drawn widget? > > > > If you need any help, do say, I'll try to do my best, > > Attached goes a patch that behaves nicely. > Please polish it to a final state. It is commented. > > The button drawing code lacks the "X", the callback is not hooked, > and there's no tooltip, but it doesn't trigger redraw storms, > and feels right. > > Good luck! OK, I've already implemented update_positions() to prevent tabs from going over the button (grabbed it from FLTK and altered it). I don't think there is the need for a callback function, since it only calls a simple line. I've noticed that we have no checking if the button is visible or not, so it is working even though there are no tabs, I'll add a check for that in event() rather than in other places. Thanks, Jo?o

1 0

[patch]: fix leak in a_Cookies_get_query()
by onepoint＠starurchin.org Feb. 6, 2009

Feb. 6, 2009

This patch stops a_Cookies_get_query() leaking. However, I'm a little puzzled by the logic here. Why does a_Cookies_get_query() return a "Cookies2" header even if the cookies DPI returns nothing? Can't it just return NULL or an empty string? Wouldn't that be cleaner? Regards, Jeremy Henty

3 3

Re: view stylesheets from page menu
by Johannes.Hofmann＠gmx.de Feb. 6, 2009

Feb. 6, 2009

On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 03, 2009 at 08:00:12PM +0100, Hofmann Johannes wrote: > > Hi corvid, > > > > On Tue, Feb 03, 2009 at 05:13:27PM +0000, corvid wrote: > > > > > > (a rough quick patch just to get feedback) > > > I saw that Jorge added cssUrls, which provided an opportunity... > > > > Very nice! Just one small thing. The stylesheets entry does not get > > disabled on non-CSS pages here. Extending the check like this: > > > > + if (cssUrls && cssUrls->size () > 0) { > > > > helps. > > To me: It looks more like a developers feature than one for user level. Well, not more than "View page source". I think it's important and in the spirit of dillo to make the web as transparent for the user as possible. > > > > BTW: Viewing stylesheets in a normal browser window is really fast > > compared to the fltk text viewer we use for "View page source"! > > Yes, since a long time I've wanted to find some time to turn > "View page source" into a dpi. > > Maybe after the close-tab button I can give it a hand. > Yes, that would be great. Cheers, Johannes > -- > Cheers > Jorge.-

3 2

RE: Free HG performance
by CHalbersma.12＠westminster-mo.edu Feb. 6, 2009

Feb. 6, 2009

Souceforge always seemed pretty good at hosting open souce projects. Of course I could be wrong there. Christopher "Chewy" R. Halbersma

2 1

FreeHG performance
by onepoint＠starurchin.org Feb. 5, 2009

Feb. 5, 2009

Am I the only one getting very poor performance from FreeHG ? Quite often I get a 404 Not Found and right now it's hanging. Everyone confirms that Mercurial itself is really fast and I've seen other reports criticising FreeHG's performance. Perhaps we should think about moving host? It's not always easy to find time to devote to Dillo so it's rather aggravating when that time is wasted just waiting for a connection to the server. I'm committed enough to grit my teeth and wait but I can see it putting off would-be contributors. Just a thought, Jeremy Henty

5 14

Bad character coding for www.blisty.cz
by newman.x＠gmail.com Feb. 3, 2009

Feb. 3, 2009

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? :) Thanks, -- Regards, Michal Nowak

4 10