- Dillo-dev - lists.mailman3.com

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > I get the feeling we are close to releasing dillo-2.1. Do others > agree? What's left to be done? It looks like the main part is done. The close-tab icon is still missing (Jo?o Ricardo is working on it). I'm yet to push more dicache/image cleanups and to update the respective docs. There're more valgrind issues to look into. It would also be interesting to look at the addblock code; corvid made a prototype based on RE. I have the feeling (i.e. not backed with actual data) that maybe an option to not load resources from sites other than where the page is hosted, would get rid of most of the problems cheaply. Another posibility is to filter by host (dStrncasecmp() against URL_HOST), and maybe also offer RE filtering for more fine tunning (comments encouraged). CSS, we need Johannes green light on this. More stabilizing & testing. After that, custom packages need to be built for Debian, Ubuntu, RedHat... We may be more or less one month away... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > I get the feeling we are close to releasing dillo-2.1. Do others > agree? What's left to be done? I agree. Of course there is a lot todo regarding CSS conformance, but we won't pass any ACID test soon anyway. I'd like to get the font-size issue on wikipedia.org fixed however - help on that is very welcome :-). Regards, Johannes

Jan. 31, 2009

What's left to do for dillo-2.1?

by onepoint＠starurchin.org

I get the feeling we are close to releasing dillo-2.1. Do others agree? What's left to be done? Regards, Jeremy Henty

Jan. 31, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > * {font-family: sans !important} > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > So this should work. > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > Does it work for you? > > > > > > > > > > Yes, I tried: > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > * {color: red !important} > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > All red for me. > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > much except forms code in my tree right now. > > > > Still all red. > > > > > > > > How strange that we would see different behaviour here... > > > > I guess I'll have to dive into the code myself... > > > > > > Please check again with attached patch. > > > > It's working! > > Thanks! Excellent customer service :) > > It's not the proper solution though. > Here's the plan to apply rules according to > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > * For each CssRule compute the specificity according to > http://www.w3.org/TR/CSS21/cascade.html#specificity > > * Store the rules in RuleList sorted by this specificity. > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > potentially matching rules and apply them in the order given by > their specificity. > > If anyone feels like implementing it - go ahead :) Just implemented that. Please test. Cheers, Johannes

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

Hi Andreas, On Fri, Jan 30, 2009 at 05:24:56PM +0100, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 30 Jan 2009 12:22:46 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > 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, > > > > Yes, I've also had trouble with it, and when normal it's slower > > than our Wearlab's CVS. > > > > A couple of days ago (while developoing/reviewing patches) I > > digged a bit on it and it seems that bitbucket is much faster. We > > can try bitbucket while we find a long term solution (e.g. FSF's > > savannah is offering Mercurial and Git repos, but the applying > > process may take some time). > > > > At some point in time we should move out from the Wearlab, as > > it may be closed soon. Currently we need webserver/CGI/python > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > we may use another bugtracker too. > > > The server which actually hosts the dillo debian and openmoko > packages should be an alternative. > At least performance and bandwidth should be no problem. Maybe moving > hg there is a starting point. Does this server belong to the Wearlab? If not, what's its expected lifespan? Or are you suggesting it as an interim solution for mercurial hosting? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009

FreeHG performance

by akemnade＠tzi.de

Hi Jorge, On Fri, 30 Jan 2009 12:22:46 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > 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, > > Yes, I've also had trouble with it, and when normal it's slower > than our Wearlab's CVS. > > A couple of days ago (while developoing/reviewing patches) I > digged a bit on it and it seems that bitbucket is much faster. We > can try bitbucket while we find a long term solution (e.g. FSF's > savannah is offering Mercurial and Git repos, but the applying > process may take some time). > > At some point in time we should move out from the Wearlab, as > it may be closed soon. Currently we need webserver/CGI/python > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > we may use another bugtracker too. > The server which actually hosts the dillo debian and openmoko packages should be an alternative. At least performance and bandwidth should be no problem. Maybe moving hg there is a starting point. Greetings Andreas Kemnade

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 12:22:46PM -0300, Jorge Arellano Cid wrote: > [...] > At some point in time we should move out from the Wearlab, as > it may be closed soon. Currently we need webserver/CGI/python > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > we may use another bugtracker too. Oh, I forgot email! (that's paramount :) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > 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, Yes, I've also had trouble with it, and when normal it's slower than our Wearlab's CVS. A couple of days ago (while developoing/reviewing patches) I digged a bit on it and it seems that bitbucket is much faster. We can try bitbucket while we find a long term solution (e.g. FSF's savannah is offering Mercurial and Git repos, but the applying process may take some time). At some point in time we should move out from the Wearlab, as it may be closed soon. Currently we need webserver/CGI/python shell accounts and a DCVS (Hg or Git). CGI is quite useful, but we may use another bugtracker too. Suggestions? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009

Still leaking CSS values

by onepoint＠starurchin.org

On Fri, Jan 30, 2009 at 01:25:19PM +0100, Hofmann Johannes wrote: > Should be fixed in tip now. It is! (After three tries to "hg pull" from freehg.org, see my grumbling elsewhere.) Regards, Jeremy Henty

Jan. 30, 2009

FreeHG performance

by onepoint＠starurchin.org

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

Jan. 30, 2009