I tend to agree with this assessment... if it is almost free to include it
(not more than 4KB additional size would be my definition of almost free),
then why not? Well, one reason might be because of the multitude of
security holes in IE... and that alone would make me prefer it being
separate...
The C code compiles to a dll of about 20k - so this would be the minimum
benchmark. Win32::GUI shouldn't take any longer to load, to initialise or
take any extra CPU cycles in general use. The real benefit would be for
people who use the current solution since you wouldn't need several big
modules (win32::ole being one of them).
Having it as a separately loadable module, but implementing fixes in
Win32::GUI to support it fully, would be the optimum solution if it isn't
almost free. I'd be content to allow the distributions to be bundled as
long as Win32::GUI::Browser didn't get loaded if it wasn't used... and if
things like PAR & PerlApp would still package Win32::GUI without including
Win32::GUI::Browser if it isn't needed for the application.
Understood.
I don't suppose anyone has figured out how to embed Mozilla? Now there'd
be a solution I could go for!
:)
It might be worth pointing out that the main use of embedding a browser, is
not to view pages on the web, but to render HTML pages that are generated on
the fly by the host application. For example, you might generate a report
and use some of the more advanced features to HTML to improve the layout or
embed images etc.
Most GUI tool sets have a browser of somesort in the core - but since we
have an alternative it may be worth putting on the back burner for a while?
In the meantime I've created a feature request on the sourceforge site:
http://sourceforge.net/tracker/index.php?func=detail&aid=1086958&group_id=16572&atid=366572
Cheers,
jez.
