Re: Gtk2::MozEmbed + DOM

[Torsten Schoenfeld <kaffeetisch gmx de>]

On Sat, 2005-04-02 at 22:36 +0000, Scott Lanning wrote:

> > This is where the magical ExtUtils::Depends comes in.  It lets modules
> > depend on other XS modules.
>
> Thanks, it works!

Sweet!

>    I removed the Gtk2 dependency from Makefile.PL, but not Glib yet.
> I was also thinking of changing mozilla-gtkmozembed to
> mozilla-xpcom (lacking anything better, at least that would not
> require GtkMozEmbed). Not sure what write_version_macros does,
> though; and anyway, for the time being only Gtk2::MozEmbed would
> use this module, and it already requires mozilla-gtkmozembed.

Yeah, I think from those pc files Mozilla installs, mozilla-xpcom seems
to make the most sense.  write_version_macros creates a header that
defines version macros like GTK_MOZ_EMBED_CHECK_VERSION (x, y, z) that
can be used in pre-processor directives to, for example, only include an
xsub if Mozilla is younger than 1.7.1.  But see below.

>    I meant to have separate .xs files, but I couldn't figure
> out how to make it work so I left them in one file.

The Makefile.PL uses every XS file it can find (<xs/*.xs>), so you can
just create a new one.  The module name (MODULE = xxx) needs to be
different from that in all the other XS files, and it needs to be the
same in the whole file; the package name (PACKAGE = xxx) can of course
change.

Some more comments on Mozilla-DOM-0.01:

About the exportable symbols in DOM.pm: I'd suggest to make them
exportable from the main package and perhaps prefix the alias.  Thus you
could do

  use Mozilla::DOM (:event_phases);

A more Gtk2-Perl'ish approach would be to create custom type converters
for these enum types as well.  They would map strings like
"capturing-phase" to the corresponding number (and vice versa).  See
Glib/GType.xs ("enum and flags handling") for the gory details.  You
could also just use Glib::Type->register_enum and let Glib do all the
work for you, but that would make you dependent on Glib again.

In Makefile.PL:

  ExtUtils::PkgConfig->write_version_macros (
    "build/${label}2perl-version.h",
    "mozilla-gtkmozembed" => "GTK_MOZ_EMBED",
  );

This creates the header build/${label}2perl-version.h with four version
macros.  It uses the pkg-config name mozilla-gtkmozembed to retrieve the
version information and prefixes the macros with GTK_MOZ_EMBED.  So this
is what gets generated:

#define GTK_MOZ_EMBED_MAJOR_VERSION (1)
#define GTK_MOZ_EMBED_MINOR_VERSION (7)
#define GTK_MOZ_EMBED_MICRO_VERSION (6)
#define GTK_MOZ_EMBED_CHECK_VERSION(major,minor,micro) ...

Also in Makefile.PL:

  my $mozdom = ExtUtils::Depends->new($package);
  # XXX: -I. is hacky but I couldn't figure out why mozilladom2perl.h
  # isn't being found (in blib/arch/Mozilla/DOM/Install/).
  $mozdom->set_inc($pkgcfg{cflags}, '-I.', '-I./build', "-I$incdir", "-I$incdir/dom");

If you specified Glib in the ExtUtils::Depends->new() call, -I. would
automatically be added for you, but since you don't want that, it's ok
to add it manually.

In mozilladom.typemap:

  # (T_GPERL_GENERIC_WRAPPER from Glib/typemap; I wasn't sure if having the
  # same name would conflict or something)

The same applies here.  If you chose to depend on Glib (specified it in
the ExtUtils::Depends->new() call), you'd get all of Glib's typemaps,
too.

Other than that, I think the module's very cool.  You *could* get rid of
the Glib dependency, but you'll lose quite some functionality,
especially with respect to doc generation.  But if you're willing to
write the POD manually, then I think it's possible.

>    I changed Gtk2::MozEmbed to check if Mozilla::DOM is installed.
> If so, c++ is used. The build depends on whether c++ is used to tell
> if the marshaller parts should be included in the build. I was thinking
> an ENABLE_DOM option to Makefile.PL could also be added, but I didn't
> do that. Patch attached. Mozilla::DOM was just uploaded to CPAN.

The patch looks fine; I'll apply it after some testing.  Thanks a lot.

-- 
Bye,
-Torsten