- Dillo-dev - lists.mailman3.com

Few more dillo issues

by sandshrew＠gmail.com

Issues: 1) ssl dpi looping when entering: http://www.elitehackers.info/forums 2) logging into kde forum (forum.kde.org) and gmail (which I reported earlier) doesn't seem to work for same reasons. I guess there should be much more similar cases.

Nov. 8, 2008

Re: css prototype on freehg.org

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Nov 07, 2008 at 11:36:21AM -0300, Jorge Arellano Cid wrote: > Hi, > > We've been arranging some CSS things behind the scenes > with Johannes (he'll forward some past mails here soon). > > > On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > I just created a repository > > http://freehg.org/u/jh33/dillo-css-prototype/ > > > > freehg.org is a free mercurial hosting service. > > This gives access to the newest version of the css prototyping work. > > Also you can check whether you like mercurial. > > > > To get a copy of the repository call > > > > hg clone http://freehg.org/u/jh33/dillo-css-prototype/ > > > > and start hacking. You can commit locally using > > > > hg commit > > OK, I'll make some patches with Hg once I grasp how this > distributed model works. > > On the current code, basically it looks OK to me. i.e. we can > continue working from that basis (having in mind that it's still > in a flux state and that a validation is pending on whether the > model is able to handle the current functionality in html.cc). > > My main comment is that the code needs more comments! :) Agreed. I started to add comments (visible in the hg repo). > > Accurate comments are written when the code is developed (every > detail is in the brain then). I've tried in the past to develop > first and comment later, and found it only works OK for small > code projects. > > As with CSS we don't have a main expert (yet), the team will be > trying to understand and develop at the same time, and thus > comments are very necessary. Even something like "I don't know > how to implement this part" helps! > > I'd suggest to use the same format that's in css.cc. e.g. > > /** \todo dummy only */ > > with a view to integrate it smoothly with doxygen docs. in the > future. > > > Some specific examples: > > 1.- What do these functions do? > - style0() > - startElement() > - endElement() > > 2.- On memory handling, there are some places with: > > // html->styleEngine->style () = > // Style::create (HT2LT(html), &style_attrs); > // old_style->unref (); > > or > > // (html->styleEngine->style ())->unref (); > > Why are they commented and left in the code? Is proper > memory handling pending, is there a design decision to be > made before getting rid of them? They can be deleted. I will do that. The idea is that in html.cc no styles are created anymore. Instead only the style handed out by styleEngine is used. > > 3.- With regard, for instance, to font_factor and visited link > color. Do they belong to buildUserAgentStyle() or > buildUserStyle() or elsewhere? I think the userAgentStyle should contain the defaults, the userStyle can override those. We can create the userStyle from what's in dillorc or - once we have a CSS parser - we could parse a user defined custom stylesheet as it is possible in other browsers. > > 4.- strdup/free should be dStrdup/dFree > (Please let me use this extremely simple case to make my > first Hg patch :-) > Great. You could also create a repo on freehg.org were you can publish your work. We could then pull from each other. Or we send patches to the list and someone integrates them. > > I know this was just a prototype for the CSS implementation > idea, but considering that we don't have any better, and that we > agreed on it, now it has attained the status of "official CSS > merge effort". ;-) > > From now comments are paramount, and we may eventually get to > a dw-like quality docs in the future. Yes, let's take dw as an example. The documentation is really good there. > > > Bottom line: Great, let's get started! Excellent. Here's my todo list: * Adjust CssProperty::Value. As Sebastian has stated "CssValue (is) a union, which represents values exactly in the way they have been parsed" In addition to the values from style.hh it must be able to hold relative values (e.g. "bolder" for font weights). The translation to actual values is then done in StyleEngine::apply (). * Add support for pseudo classes and use it to change the color of visited links in Html_tag_open_a(). * Transform the rest of html.cc, table.cc, and form.cc to use styleEngine instead of creating styles itself. * Port the CSS parser code from dillo-0.8.0-css-3. Any help or comments are welcome! Make sure to have a look at dillo-0.8.0-css-3 as it contains a lot of useful code! Cheers, Johannes

Nov. 7, 2008

[jcid@dillo.org: Re: css prototype on freehg.org]

by Johannes.Hofmann＠gmx.de

----- Forwarded message from Jorge Arellano Cid <jcid(a)dillo.org> ----- Date: Thu, 6 Nov 2008 14:05:33 -0300 From: Jorge Arellano Cid <jcid(a)dillo.org> To: Johannes Hofmann <Johannes.Hofmann(a)gmx.de> Subject: Re: css prototype on freehg.org On Thu, Nov 06, 2008 at 05:31:34PM +0100, Johannes Hofmann wrote: > > > > I'm currently reviewing the CSS work you uploaded! > > > > On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > I just created a repository > > > http://freehg.org/u/jh33/dillo-css-prototype/ > > > > > > freehg.org is a free mercurial hosting service. > > > This gives access to the newest version of the css prototyping work. > > > Also you can check whether you like mercurial. > > > > Hmm, that's another topic that needs a resolution: > > to git or to hg? > > Featurewise there is hardly a difference. I prefer mercurial because > of it's nice and simple ui. > Just recently there was the same discussion for DragonFlyBSD: > http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/msg00144.html Yes, I also like simple UIs. > > [...] > > Do you have a recommended quick-start guide? > > http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart > > and a bit longer: > > http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial > > and a lot longer: > > http://hgbook.red-bean.com/hgbook.html Thanks. > > > > > I didn't send this to the list, because I want to be sure that you > > > are ok with this step. > > > > Which one, the mercurial or the CSS code? > > Both. Publishing CSS prototype in a separate repository. For now the Hg repository is OK. I'm yet to grasp the distributed workflow model. It seems our old CVS needs an update. > > > > As far as CSS, after the first review it looks OK, and > > seems the way to go. I'm going more in depth now to try to > > understand how it works and fits in the plan. > > Great. Please keep in mind that the current work tries to find a > proper interface between CSS stuff and the code in html.cc. > It needs to be verified that the concept covers all the edge cases. > One is probabely the table code that stores a separate > table_cell_style on the stack. > Is this to hold cell properties that were set in the <table> or <tr> > tags? I'll check. Most probably that's the case though. e.g. bgcolor. OK, once I've grasped the concept, I'll tell you what I find. > > > Also the CSS prototype contains some code from dillo-0.8.0-css-3 > > > that doesn't have license headers. Can you contact Sebastian to ask > > > if it is ok to use stuff from his prototype? > > > > I have an email from him (long time ago) where he advocates > > on making the CSS prototype code more visible from the website, > > to attract developers. He also said he was working on floating objects! > > > > I'll try to contact him and see what's up with him... > > > > As from his email, and conversations we had long ago, > > I believe it's quite safe to use the code. > > Great. It seems to contain a pretty complete CSS parser. > > Cheers, > Johannes > > PS: We should probabely take this discussion to the list. It's a bit > quiet there. What do You think? Sure, feel free to forward the thread (or relevant parts). -- Cheers Jorge.- ----- End forwarded message -----

Nov. 7, 2008

Re: css prototype on freehg.org

by jcid＠dillo.org

Hi, We've been arranging some CSS things behind the scenes with Johannes (he'll forward some past mails here soon). On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > I just created a repository > http://freehg.org/u/jh33/dillo-css-prototype/ > > freehg.org is a free mercurial hosting service. > This gives access to the newest version of the css prototyping work. > Also you can check whether you like mercurial. > > To get a copy of the repository call > > hg clone http://freehg.org/u/jh33/dillo-css-prototype/ > > and start hacking. You can commit locally using > > hg commit OK, I'll make some patches with Hg once I grasp how this distributed model works. On the current code, basically it looks OK to me. i.e. we can continue working from that basis (having in mind that it's still in a flux state and that a validation is pending on whether the model is able to handle the current functionality in html.cc). My main comment is that the code needs more comments! :) Accurate comments are written when the code is developed (every detail is in the brain then). I've tried in the past to develop first and comment later, and found it only works OK for small code projects. As with CSS we don't have a main expert (yet), the team will be trying to understand and develop at the same time, and thus comments are very necessary. Even something like "I don't know how to implement this part" helps! I'd suggest to use the same format that's in css.cc. e.g. /** \todo dummy only */ with a view to integrate it smoothly with doxygen docs. in the future. Some specific examples: 1.- What do these functions do? - style0() - startElement() - endElement() 2.- On memory handling, there are some places with: // html->styleEngine->style () = // Style::create (HT2LT(html), &style_attrs); // old_style->unref (); or // (html->styleEngine->style ())->unref (); Why are they commented and left in the code? Is proper memory handling pending, is there a design decision to be made before getting rid of them? 3.- With regard, for instance, to font_factor and visited link color. Do they belong to buildUserAgentStyle() or buildUserStyle() or elsewhere? 4.- strdup/free should be dStrdup/dFree (Please let me use this extremely simple case to make my first Hg patch :-) I know this was just a prototype for the CSS implementation idea, but considering that we don't have any better, and that we agreed on it, now it has attained the status of "official CSS merge effort". ;-) From now comments are paramount, and we may eventually get to a dw-like quality docs in the future. Bottom line: Great, let's get started! -- Cheers Jorge.-

Nov. 7, 2008

Dillo too fast?

by jcid＠dillo.org

Hi, On Fri, Nov 07, 2008 at 09:06:57AM +0100, Thomas Orgis wrote: > Did anyone else encounter this from google? > Not sure if this is something specific in dillo's network behaviour... > > > We're sorry... > > > ... but your query looks similar to automated requests from a > > computer virus or spyware application. To protect our users, > > we can't process your request right now. I've been using Dillo with google for years, and hit that message yesterday for the first time. It made sense to me because the rejected query was just an email address, which looks like a spammer's check. > > It's at least the second time I got this now, after issuing a > search, seeing that there was a typo, resissuing. > It is not that rare that this happens, but it is rare that > google slaps me in the face for it > ... and I _think_ it has been dillo before, too. But not sure. > > Anyhow, does someone know what is behind that "virus check"? > > > If you're continually receiving this error, you may be able to resolve the problem by deleting your Google cookie and > > revisiting Google. For browser-specific instructions, please consult your browser's online support center. > > Hm... I don't have any cookie from 'em. Perhaps that is the key? I don't think so, here it had worked perfectly w/o cookies for a long time. -- Cheers Jorge.-

Nov. 7, 2008

Dillo too fast?

by onepoint＠starurchin.org

On Fri, Nov 07, 2008 at 09:06:57AM +0100, Thomas Orgis wrote: > Did anyone else encounter this from google? Yes. A few months ago Google locked me out of all blogspot.com sites with the same message. It lasted about a day and then stopped. I had not done anything to change my browsing software or habits for ages. I have always assumed they tweaked their spyware detection, screwed it up and started generating lots of false positives, then reverted the change. It certainly didn't have anything to do with my browsers. Regards, Jeremy Henty

Nov. 7, 2008

Dillo too fast?

by thomas-forum＠orgis.org

Did anyone else encounter this from google? Not sure if this is something specific in dillo's network behaviour... > We're sorry... > ... but your query looks similar to automated requests from a computer virus or spyware application. To protect our users, > we can't process your request right now. It's at least the second time I got this now, after issuing a search, seeing that there was a typo, resissuing. It is not that rare that this happens, but it is rare that google slaps me in the face for it ... and I _think_ it has been dillo before, too. But not sure. Anyhow, does someone know what is behind that "virus check"? > If you're continually receiving this error, you may be able to resolve the problem by deleting your Google cookie and > revisiting Google. For browser-specific instructions, please consult your browser's online support center. Hm... I don't have any cookie from 'em. Perhaps that is the key? Alrighty then, Thomas.

Nov. 7, 2008

Another mention of Dillo-2

by onepoint＠starurchin.org

"Dillo 2.0 is fast, but limited" http://www.linux.com/feature/151983 Summary: "It's *fast*, even faster than Dillo-1, but too limited to be of use to much people.". It singles out lack of JavaScript, pointing out that most business sites need it (although I'd imagine most business sites would need full SSL support too). Jeremy Henty

Nov. 6, 2008

Repost: D_SUN_LEN cleanup (and a typo fix)

by jcid＠dillo.org

On Wed, Nov 05, 2008 at 02:26:48PM +0000, Jeremy Henty wrote: > > This is a repost of three tidy-up patches that have been left hanging > without resolution. Please comment. > > 1. Remove unused D_SUN_LEN declarations from DPIs. (The DPIs connect > to their sockets with accept() which doesn't use D_SUN_LEN.) > > 2. Use D_SUN_LEN whenever calling connect() on a struct sockaddr_un. > (Some of the calls already did this, this patch makes all of them > do so.) > > 3. Update a GPL reference in a comment from version 2 to version 3. Committed! -- Cheers Jorge.-

Nov. 5, 2008

Repost: D_SUN_LEN cleanup (and a typo fix)

by onepoint＠starurchin.org

This is a repost of three tidy-up patches that have been left hanging without resolution. Please comment. 1. Remove unused D_SUN_LEN declarations from DPIs. (The DPIs connect to their sockets with accept() which doesn't use D_SUN_LEN.) 2. Use D_SUN_LEN whenever calling connect() on a struct sockaddr_un. (Some of the calls already did this, this patch makes all of them do so.) 3. Update a GPL reference in a comment from version 2 to version 3. Regards, Jeremy Henty

Nov. 5, 2008