- Dillo-dev - lists.mailman3.com

[patch] Region is no Shape

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 07:41:06PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch cleans up Region. It no longer derives from Shape. > Region has grown pretty specialize for handling redraws. Also it was > never used as Shape object anyway. Committed. -- Cheers Jorge.-

June 23, 2008

[patch] cleanup ZoneAllocator

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 07:38:42PM +0200, Johannes Hofmann wrote: > Hi, > > here comes me ZoneAllocator cleanup again. This time without the > questionable strlen() stuff. Committed. -- Cheers Jorge.-

June 23, 2008

form.cc: more refactoring

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 12:58:41AM +0100, Jeremy Henty wrote: > On Fri, Jun 20, 2008 at 02:37:22PM -0400, Jorge Arellano Cid wrote: > > On Thu, Jun 19, 2008 at 08:48:48PM +0100, Jeremy Henty wrote: > > > On Wed, Jun 18, 2008 at 08:35:57AM -0400, Jorge Arellano Cid wrote: > > > > > > > Committed, except 00 and 05. > > > > > > > > 00: The stash buffer may hold a script, in that case > > > > parse_stash is not as clear as parse_entities. > > > > > > Would a better name make the change acceptable? For instance, > > > Html_parse_stash_entries() ? > > > > Html_parse_stash_entities() ? > > > > Why is it better than the traditional a_Html_parse_entities()? > > Sorry, I wasn't very clear. I read you as saying that the new > function a_Html_parse_stash() was not very well named, and I meant to > suggest a_Html_parse_stash_entities() as an improvement. If you were > saying that the refactoring itself is confusing then I misread you. I find the generic a_Html_parse_entities() OK. -- Cheers Jorge.-

June 23, 2008

[patch] Region is no Shape

by Johannes.Hofmann＠gmx.de

Hi, attached patch cleans up Region. It no longer derives from Shape. Region has grown pretty specialize for handling redraws. Also it was never used as Shape object anyway. Cheers, Johannes

June 23, 2008

[patch] cleanup ZoneAllocator

by Johannes.Hofmann＠gmx.de

Hi, here comes me ZoneAllocator cleanup again. This time without the questionable strlen() stuff. Cheers, Johannes

June 23, 2008

patch: Re: [Dillo-dev] back to that SELECT segfault

by corvid＠lavabit.com

Jorge wrote: > On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > > In SELECT, if standard_widget_colors is set, color and backgroundColor > > are set to NULL. This tells FltkResource::setWidgetStyle() to leave > > the colors on the widget alone. > > > > If an inline element inside a SELECT calls > > style->color->getColor() or style->backgroundColor->getColor(), > > we get that crash. > > > > This currently means FONT and IMG. > > OBJECT and A would as well if that a_Color_vc code were uncommented. > > > > options: > > - four IN_SELECT tests. > > - letting Html_stack_cleanup_at_open() be called for inline elements > > in order to close the SELECT or something if IN_SELECT and the new tag > > isn't OPTION or OPTGROUP. > > - generating our own standard widget colors to put into color and > > backgroundColor. > > > > I don't like the first one because someone innocently adding a > > getColor somewhere in the future will never know about this danger. > > (a good example would be adding the a_Color_vc to open_frame()) > > Without a deep understanding of the code involved, I'd > prefer the third option (standard widget colors) as it looks > more general and simple as a solution. All right.

June 23, 2008

back to that SELECT segfault

by onepoint＠starurchin.org

On Mon, Jun 23, 2008 at 10:01:43AM +0000, corvid wrote: > Jeremy wrote: > > On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > > > > > In SELECT, if standard_widget_colors is set, color and > > > backgroundColor are set to NULL. ... > > > > This is done for most input types in form.cc, not just SELECT, see: > > * Html_tag_open_input() > > * Html_tag_open_isindex() > > * Html_tag_open_select() > > > > However it is not done in: > > * Html_tag_open_button() > > * Html_input_image() > > The first three show fltk widgets. Hmm, whereas the other two create a ComplexButtonResource that does not. > > Is the potential crash only an issue for SELECT inputs? If so, > > why? > > INPUT and ISINDEX don't have close tags, so other tags can't be > sneaked inside them. Thanks for that. This is the bit of form.cc that I understand least which is why I have all these questions. I want to refactor the various code paths that lead to AddInput() but every time I look I see more ways in which they do things differently. The paths that call Html_tag_open_button() and Html_input_image() are particularly tricky and refactoring them correctly depends on understanding the DilloHtml stack, widget styles and layouts etc. Regards, Jeremy Henty

June 23, 2008

back to that SELECT segfault

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > In SELECT, if standard_widget_colors is set, color and backgroundColor > are set to NULL. This tells FltkResource::setWidgetStyle() to leave > the colors on the widget alone. > > If an inline element inside a SELECT calls > style->color->getColor() or style->backgroundColor->getColor(), > we get that crash. > > This currently means FONT and IMG. > OBJECT and A would as well if that a_Color_vc code were uncommented. > > options: > - four IN_SELECT tests. > - letting Html_stack_cleanup_at_open() be called for inline elements > in order to close the SELECT or something if IN_SELECT and the new tag > isn't OPTION or OPTGROUP. > - generating our own standard widget colors to put into color and > backgroundColor. > > I don't like the first one because someone innocently adding a > getColor somewhere in the future will never know about this danger. > (a good example would be adding the a_Color_vc to open_frame()) Without a deep understanding of the code involved, I'd prefer the third option (standard widget colors) as it looks more general and simple as a solution. -- Cheers Jorge.-

June 23, 2008

back to that SELECT segfault

by corvid＠lavabit.com

Jeremy wrote: > On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > > > In SELECT, if standard_widget_colors is set, color and > > backgroundColor are set to NULL. This tells > > FltkResource::setWidgetStyle() to leave the colors on the widget > > alone. > > This is done for most input types in form.cc, not just SELECT, see: > * Html_tag_open_input() > * Html_tag_open_isindex() > * Html_tag_open_select() > > However it is not done in: > * Html_tag_open_button() > * Html_input_image() The first three show fltk widgets. > Is the potential crash only an issue for SELECT inputs? If so, why? INPUT and ISINDEX don't have close tags, so other tags can't be sneaked inside them. > > If an inline element inside a SELECT calls style->color->getColor() > > or style->backgroundColor->getColor(), we get that crash. > > There's dw::core::Widget::getBgColor() , which chains up the widget > hierarchy looking for a non-NULL background color. Perhaps we should > be calling that? However there is no equivalent (that I can see) for > foreground colors. Perhaps there should be? I guess the getColor()s could go in something that goes up the DilloHtmlState stack looking for non-NULL...

June 23, 2008

back to that SELECT segfault

by onepoint＠starurchin.org

On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > In SELECT, if standard_widget_colors is set, color and > backgroundColor are set to NULL. This tells > FltkResource::setWidgetStyle() to leave the colors on the widget > alone. This is done for most input types in form.cc, not just SELECT, see: * Html_tag_open_input() * Html_tag_open_isindex() * Html_tag_open_select() However it is not done in: * Html_tag_open_button() * Html_input_image() Is the potential crash only an issue for SELECT inputs? If so, why? > If an inline element inside a SELECT calls style->color->getColor() > or style->backgroundColor->getColor(), we get that crash. There's dw::core::Widget::getBgColor() , which chains up the widget hierarchy looking for a non-NULL background color. Perhaps we should be calling that? However there is no equivalent (that I can see) for foreground colors. Perhaps there should be? Regards, Jeremy Henty

June 23, 2008