wxWebView - Chromium

401 views
Skip to first unread message

Steve Lamerton

unread,
Dec 23, 2011, 2:41:44 PM12/23/11
to wx-...@googlegroups.com
Hi all,

Just to let everyone know that I have a back-end for wxWebview using
the Chromium Embedded Framework (CEF) [1] running under Windows, it
should also run under OSX and Linux. At the moment it is pretty fully
featured compared to the other ports, almost everything bar history
support and custom scheme handlers are implemented. The nice thing
about this is that it allows a better browser under MSW where old
versions of Internet Explorer may be present, and the opportunity to
use the same renderer on all three platforms.

Given that the CEF API is pretty unstable at the moment I am not
planning to commit anything at the moment, but if anyone is interested
I can upload a patch and some build instructions.

Kindest regards,

Steve

[1] http://code.google.com/p/chromiumembedded/

Vadim Zeitlin

unread,
Dec 23, 2011, 8:59:09 PM12/23/11
to wx-...@googlegroups.com
On Fri, 23 Dec 2011 19:41:44 +0000 Steve Lamerton <steve.l...@gmail.com> wrote:

SL> Just to let everyone know that I have a back-end for wxWebview using
SL> the Chromium Embedded Framework (CEF) [1] running under Windows, it
SL> should also run under OSX and Linux.

This is excellent news, I'm very glad to hear it. Thanks for your work on
this!

SL> Given that the CEF API is pretty unstable at the moment I am not
SL> planning to commit anything at the moment, but if anyone is interested
SL> I can upload a patch and some build instructions.

It would be nice to have it somewhere. Maybe you could create a wiki page
with the instructions and a link to the patch?

BTW, is it possible to compile and use this back-end without modifying the
rest of wxWidgets?

Thanks again!
VZ

char...@charjans.com

unread,
Dec 26, 2011, 4:20:47 PM12/26/11
to wx-dev
Yeah I would be interested in that. I wanted to auto export/print some
reports from my app but the current wxWebview
caused some artifacts in the reports that rendered them useless.

I was actually considering doing this myself but time constraints
prevented me from looking into it...

On Dec 23, 7:59 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>  application_pgp-signature_part
> < 1KViewDownload

Steve Lamerton

unread,
Dec 28, 2011, 6:18:11 AM12/28/11
to wx-...@googlegroups.com
> SL> Given that the CEF API is pretty unstable at the moment I am not
> SL> planning to commit anything at the moment, but if anyone is interested
> SL> I can upload a patch and some build instructions.
>
>  It would be nice to have it somewhere. Maybe you could create a wiki page
> with the instructions and a link to the patch?

Ah, I didn't think of the wiki, that would make a lot of sense. I have
a couple of changes to apply to the trunk to make it integrate as
easily as possible, then I'll add a new page with the patch and
instructions.

>  BTW, is it possible to compile and use this back-end without modifying the
> rest of wxWidgets?

I am not quite sure what you mean here, the patch makes a few changes
to the rest of the webview code, mostly to add a new value to the
wxWebViewBackend enum, to allow you to actually create it. Otherwise
it is all self contained. The only other changes needed to use it are
to link to the CEF libraries.

Regards,

Steve

Steve Lamerton

unread,
Dec 28, 2011, 6:20:21 AM12/28/11
to wx-...@googlegroups.com
On Mon, Dec 26, 2011 at 9:20 PM, char...@charjans.com
<char...@charjans.com> wrote:
> Yeah I would be interested in that. I wanted to auto export/print some
> reports from my app but the current wxWebview
>  caused some artifacts in the reports that rendered them useless.

What sort of artifacts do you see? If you could give me some sort of
way of reproducing this, ideally as a patch uploaded on
http://trac.wxwidgets.org then I can take a look at this.

Regards,

Steve

Vadim Zeitlin

unread,
Dec 28, 2011, 7:29:35 AM12/28/11
to wx-...@googlegroups.com
On Wed, 28 Dec 2011 11:18:11 +0000 Steve Lamerton <steve.l...@gmail.com> wrote:

SL> >  BTW, is it possible to compile and use this back-end without modifying the
SL> > rest of wxWidgets?
SL>
SL> I am not quite sure what you mean here, the patch makes a few changes
SL> to the rest of the webview code, mostly to add a new value to the
SL> wxWebViewBackend enum, to allow you to actually create it.

I see, looking at the code it's clear that currently this is unavoidable.
But I think it could be nice to have a way to create backends not known at
compilation time. E.g. replace this enum with string constants and allow
registering functions for creating a backend with the given name. Then we
could release wxWidgets 3.0 without this backend in it but make it possible
to use it easily by just compiling it in addition to wxWidgets code but
without modifying it. Do you see what I mean?

Regards,
VZ

M Gagnon

unread,
Dec 28, 2011, 11:15:41 AM12/28/11
to wx-...@googlegroups.com
Hi,

> I see, looking at the code it's clear that currently this is unavoidable.
> But I think it could be nice to have a way to create backends not known at
> compilation time. E.g. replace this enum with string constants and allow
> registering functions for creating a backend with the given name. Then we
> could release wxWidgets 3.0 without this backend in it but make it
> possible
> to use it easily by just compiling it in addition to wxWidgets code but
> without modifying it. Do you see what I mean?
my humble view on this. With Vadium's idea, it would look like :

#ifdef __WXMSW__
m_webview = wxWebView::New(wxWEB_VIEW_BACKEND_CHROMIUM, ...);
#else
m_webview = wxWebView::New(wxWEB_VIEW_BACKEND_DEFAULT, ...);
#endif

but without Vadim's idea, it would look like (AFAICT) :

#ifdef __WXMSW__
m_webview = new wxWebViewChromium(...);
#else
m_webview = wxWebView::New(wxWEB_VIEW_BACKEND_DEFAULT, ...);
#endif

I'm not sure if the first is so better that it's worth it

-- Auria


Vadim Zeitlin

unread,
Dec 28, 2011, 12:58:50 PM12/28/11
to wx-...@googlegroups.com
On Wed, 28 Dec 2011 11:15:41 -0500 M Gagnon <auri...@gmail.com> wrote:

MG> my humble view on this. With Vadium's idea, it would look like :
MG>
MG> #ifdef __WXMSW__
MG> m_webview = wxWebView::New(wxWEB_VIEW_BACKEND_CHROMIUM, ...);
MG> #else
MG> m_webview = wxWebView::New(wxWEB_VIEW_BACKEND_DEFAULT, ...);
MG> #endif
MG>
MG> but without Vadim's idea, it would look like (AFAICT) :
MG>
MG> #ifdef __WXMSW__
MG> m_webview = new wxWebViewChromium(...);
MG> #else
MG> m_webview = wxWebView::New(wxWEB_VIEW_BACKEND_DEFAULT, ...);
MG> #endif
MG>
MG> I'm not sure if the first is so better that it's worth it

Consistency is important. E.g. consider that the actual kind of web view
to use is actually an option loaded from configuration file. Then you'd
have to write something like this:

wxWebView* CreateConfiguredBackend(const wxString& backend)
{
if ( backend == "chromium" )
return new wxWebViewChromium;
if ( backend == "default" )
return wxWebView::New(wxWEB_VIEW_BACKEND_DEFAULT);
...
}

which is not ideal.


Also, currently New() is quite trivial but you could imagine that it would
do more in the future, in which case it would become important to pass by
it even for custom backends.


But I agree that it's not that critical, of course...

Regards,
VZ

evstevemd

unread,
Jun 27, 2012, 12:38:15 PM6/27/12
to wx-...@googlegroups.com
   How is this progressing especially its integration plans with wxWidgets?

Steve Lamerton

unread,
Jun 27, 2012, 2:23:02 PM6/27/12
to wx-...@googlegroups.com
On Wed, Jun 27, 2012 at 5:38 PM, evstevemd <mwinj...@gmail.com> wrote:
>    How is this progressing especially its integration plans with wxWidgets?

Because the Chromium Embedded Framework is under quite a lot of change
at the moment I don't have any plans to integrate this into wxWidgets
right now. I am keeping my Gituhb fork up to date with new releases
though and it is decidedly usable on Windows, it does need a little
work to get it working on Linux and OSX (should be less than 100 lines
of code, I just haven't had the chance).

Steve

evstevemd

unread,
Jun 27, 2012, 3:51:00 PM6/27/12
to wx-dev


On Jun 27, 9:23 pm, Steve Lamerton <steve.lamer...@gmail.com> wrote:
thanks and great work!
>
> Steve
Reply all
Reply to author
Forward
0 new messages