[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 #19 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-08-04 07:20:20 PDT ---
(In reply to comment #17)
> (In reply to comment #16)
> > (From update of attachment 34008 [details] [details])
> > This is *much* better!
> 
>  goood :)
> 
> > Why is HTMLName.cpp compiled by inclusion in the element factory wrapper? That
> > seems wrong.  We should at least add a FIXME there.
> > 
> > Why are we skipping DATAGRID?
> > 612         # skip DATAGRID for now
> >  613         next if ($conditional eq 'DATAGRID');
> 
>  because i don't have Gdom headers for anything that's DATAGRID based.

 ok - i gave this a shot - getting the CodeGeneratorGObject.pm to auto-generate
GdomHTMLDataGridElement.cpp,h etc. and they depend on the existence of
GdomDataGridDataSource.cpp,h.

 these files do not exist.

 and... they're not auto-generated, they must be created manually.

 i'm done with extra workload - adding extra functionality - until this series
of patches is in, or unless there's a damn good reason.

 so, that means that i'm not willing to create GdomDataGridDataSource at this
time (from looking at WebCore/bindings/JS/JSDataGridDataSource.cpp,h).

 therefore, to reduce workload, a small and simple hack is needed, to skip
anything that is #ifdef DATAGRID.

 this simple hack will still allow people to create JS-based DATAGRID bindings,
and a working web browser, but they will just not have gobject bindings to
datagrid.

 DATAGRID can be looked at _after_ the series of gobject patches are landed.

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