wxperl-users

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

[Dan S. <da...@si...>]

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. :)
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
da...@si...                         have teddy bears and even
                                       teddy bears get drunk

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

[Mattia B. \<mattia\.barbon\@libero\.it\> <mat...@li...>]

  Hi,

> 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 an=
yway. :)
> 
> I'll admit to being tempted towards option #2, with some 

  Me too.

> 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.

  FWIW the wxWidgets people's plan is to implement[1] wxHtml-2 which
can have the current rendering engine or Mozilla or IE (using the
ActiveX) or WebKit or whatever as backend. So they like option 2 as
well. Not that this will help you ;-)

Regards
Mattia

[1] in the future [2]
[2] no, there are no timetables...

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