May 2008 - Dillo-dev - lists.mailman3.com

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by jcid＠dillo.org

On Tue, May 27, 2008 at 01:26:26AM +0100, Jeremy Henty wrote: > > Except that I didn't include the patch. Here it is. Committed. -- Cheers Jorge.-

May 27, 2008

[patch]: html.cc: DilloHtmlInput class: WAS: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

This turns DilloHtmlInput into a class and adds a constructor and destructor to manage its data members. Note that DilloHtmlForm::inputs is now a vector of pointers instead of structs. This is consistent with the earlier change to DilloHtml::forms . I think the next task is to move code that accesses DilloHtmlInput internals into DilloHtmlInput methods. In particular, if we can make the type member private we can consider replacing it in favour of a class hierarchy. Comments are welcome, Jeremy Henty

May 27, 2008

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

Except that I didn't include the patch. Here it is. Jeremy Henty

May 27, 2008

an experiment in widget coloring

by corvid＠lavabit.com

I saw a page that reminded me that the matter of when to have light text vs. dark text on widgets was not decided. earlier discussion: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-February/003760.html trimmed-down bit of the page I saw: <form> <table bgcolor="#F8C473"> <tr><td> <input type="submit" value="I can hardly see the text"> </table> </form>

May 27, 2008

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

This refactors DilloHtmlForm code into a new "inline DilloHtmlInput *getCurrentInput()" method. It's just like the earlier patch that created DilloHtml::getCurrentForm() . Comments are welcome, although I hope it is uncontroversial. Regards, Jeremy Henty

May 27, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by corvid＠lavabit.com

> corvid wrote: > > > I just remembered that inputs don't have to be in forms according to > > the spec, > > Ouch, yes. I guess this is because JavaScript can read inputs > whether or not they are inside a form? Yes, although I ran into it when I was looking up information about inputs. The pages liked to show examples of them, but dillo would give me bug meter messages instead.

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > > But I mean it finishes seeing the first head, enables view source, > > user views the source, and then the charset in the second head causes > > a repush. Is the parser avoiding that? > > Yes, once you are IN_BODY, HEAD can't be re-opened, > and META doesn't work outside HEAD. But if I give it a page containing <html> <head> <title>first head</title> </head> <body> body </body> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> </head> </html> I get .. META Content-Type changes charset to: iso-8859-1 .. META Content-Type gave charset as: iso-8859-1 a_Nav_expect_done: repush! > I'd prefer to try the dpi before optimizing. I don't know dpis, so to me that's the difficult way...

May 26, 2008

[patch]: DilloHtmlForm class: WAS: Re: [Dillo-dev] [patch]: html.cc cleanup: DilloHtml::currentForm()

by jcid＠dillo.org

On Mon, May 26, 2008 at 09:07:46PM +0100, Jeremy Henty wrote: > > A revised version of the previous patch that applies cleanly against > the latest CVS. No other changes. Committed. -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

corvid wrote: > I just remembered that inputs don't have to be in forms according to > the spec, Ouch, yes. I guess this is because JavaScript can read inputs whether or not they are inside a form? > ... so maybe it won't be as easy to move so much to form.cc (unless > form.cc is given an html-ui-widgety general sort of name...) I think the real obstacle is circular data structures and dependencies. DilloHtml objects have pointers to DilloHtmlForm objects, which have pointers to ::form::Form objects which in turn depend on DilloHtml objects. So the code can't be split up as it stands. My tentative solution is to factor things through APIs that treat pointers as black boxes. For example, "delete form_ptr;", which requires the DilloHtmlForm class definition, could be wrapped inside a function "Html_form_delete (DilloHtmlForm *form_ptr);", which only requires the declaration "class DilloHtmlForm;". I'm sure it can be done but it may be too messy to be worth doing. At the moment I am doing cleanups that I think are clearly worth doing anyway and hoping that they will also help us to split up html.cc in a useful way. Regards, Jeremy Henty

May 26, 2008

[patch]: DilloHtmlForm class: WAS: Re: [Dillo-dev] [patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

A revised version of the previous patch that applies cleanly against the latest CVS. No other changes. Jeremy Henty

May 26, 2008