Re: [wxperl-users] Extra wrappy bits for Wx::Mozilla and Wx::WebKit

[John R. <jr...@ce...>]

On Apr 28, 2006, at 9:26 AM, Dan Sugalski wrote:

> Okay, so I've been doing some fiddling with my app to test some of  
> the fancier HTML rendering capabilities of the non-WxHTMLWindow  
> HTML widgets (mozilla and webkit) and I hit what I'd consider a  
> pretty big annoyance -- these things aren't drop-in replacements  
> for WxHTMLWindow.
>
> That is, the basic HTML option in Wx is a window, while WxMozilla  
> and WxWebKit are both controls. Can't swap in one for another. (And  
> yeah, I know, the method names are different, but that's easy  
> enough to deal with)
>
> Anyway, since I wrote both the Wx::Mozilla and Wx::WebKit wrappers,  
> I can make things a little different. The question here is, what'd  
> be best? Would it be better to:
>
> 1) Have Wx::Mozilla and Wx::WebKit widgets be windows or panels,  
> and basically be compatible with WxHTMLWindow in usage? (Which'd  
> make the perl versions different than the underlying C++ widgets)
>
> 2) Add in a compatibility class in the distributions that provides  
> a window or panel version of the widgets in addition to the control  
> version they are by default
>
> 3) Leave it as is and fix it in my app shims since nobody much  
> cares anyway. :)
>
> I'll admit to being tempted towards option #2, with some WxHTML- 
> compatible methods thrown in as an extra (WebKit has SetPageSource  
> rather than SetPage to send HTML to the widget, for example) but  
> I'm not sure if that's really the best way to go about it.
>
> Suggestions'd be greatly appreciated, thanks. :)

Philosophy first: I don't think having the wxPerl wrappers act  
differently from the underlying wxWidgets is a good idea: It will  
serve mostly to drive people nuts.

Next, terminology: wxControls *are* wxWindows. What you mean to say  
is that wxHTMLWindow  is derived from wxPanel, and wxMozilla and  
wxWebKit aren't.   In fact, wxWebKit is derived from wxControl, but  
wxMozillaBrowser is derived from wxWindow directly and  
wxMozillaWindow is derived from wxFrame.

Kevin Ollivier, one of the developers of both wxMozilla and wxWebKit,  
is quite active on wx-...@li.... I suggest you ask  
there what is the best strategy for replacing a wxHTMLWindow with  
each of the other html widgets. Make clear at the outset what derived  
functions from wxPanel or wxScrolledWindow are lacking in wxMozilla  
and wxWebkit, and which can't be achieved by either plopping one into  
a wxScrolledWindow or deriving a class which simply inherits from  
both. Once that's worked out, you can decide whether it makes more  
sense to execute the strategy in C++ and add wxPerl bindings to it or  
to do it directly in wxPerl.

Regards,
John Ralls