[Webkit-unassigned] [Bug 27425] adding auto-generator support for GDOMHTMLElementWrapperFactory[.cpp/.h]

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=27425





--- Comment #22 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-08-04 13:27:51 PDT ---
(In reply to comment #21)
> (From update of attachment 34060 [details])
> I wasn't clear, sorry.  I agree that JS should be default.  I just wanted all
> the places where you assumed !JS was Gdom to turn into explicit GDom checks.

 done.  yep.

> passing no --bindingType can/should default to JS.  Otherwise you'd have to
> change lots more files here. :)

 ack.  whew.

> 327         if ($binding eq 'Gdom') {
>  328             # skip DATAGRID for now
>  329             next if ($conditional eq 'DATAGRID');
>  330         }
> 
> Those can all go away if you just remove DATAGRID from the list of tags at the
> start, no? 

 yes - good idea, but my perl skills don't extend to doing that.

 cut-and-paste if it's already in the same perl file (or in any other one i've
encountered, which aren't many) i can manage.  i even managed to look up how to
do includes recently...

 ... but that's about it, really.  the only reason CodeGeneratorGObject.pm
works is because the other CodeGenerator*.pm files were complex enough to
contain everything that i needed.


> Removing it once instead of skipping it in every for loop seems
> like a cleaner solution, or?  Also, don't you all have ENABLE_DATAGRID off
> anyway? 

 no - it appears to be on by default.  and, anyone enabling it will end up with
a compile-time error, because the CodeGeneratorGObject.pm isn't equipped to
auto-generate GdomHTMLDataGrid{Row,Col,Element}.{cpp,h}, and neither is the
infrastructure there to support it.

> Won't make_names just print #defines around all the DATAGRID stuff
> which will be compiled out?

 yes - but then suppose someone _does_ want JS-based DATAGRID support, and
doesn't care about GObject or doesn't care about DATAGRID not being in GObject
bindings?


> $F really should have a better name, per our style guidelines:
> http://webkit.org/coding/coding-style.html.  Since you're just moving existing
> code, I guess it's OK as is though.

 ack.  whew.

> So the GNUMakefile.am changes are fine, but not required if you restore the JS
> default.

 going.  prefer not to hack GNUmakefile.am right now, i have a number of other
mods to it that i'm keeping track of.

> This in general looks great.  I think we still can fix the DATAGRID with a
> cleaner hack.

 not with my level of perl skills, though.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.