Hi Greg,<br><br><div class="gmail_quote">On Mon, Dec 19, 2011 at 11:03 PM, Greg Hellings <span dir="ltr"><<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Mon, Dec 19, 2011 at 11:06 AM, Jonathan Morgan <<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>> wrote:<br>
> Hi Greg,<br>
><br>
</div><div class="im">> On Mon, Dec 19, 2011 at 10:11 PM, Greg Hellings <<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>><br>
> wrote:<br>
>><br>
</div><div class="im">>> If Gecko/Xul ceases being good enough for you or stops updating, that<br>
>> might be a direction worth considering in the future. It's been<br>
>> underway for quite some time, but I have no idea how mature it has<br>
>> ever become. It was originally started by one of the main wxHTML<br>
>> developers who saw that wxHTML was woefully inadequate.<br>
><br>
><br>
> When looking for a replacement, wxWebKit was the first thing I tried.  It<br>
> had a vast number of things with it that I thought unacceptable (the one<br>
> that comes strongest to mind was that hovering over a link would not change<br>
> the cursor from a pointer to a hand), and I couldn't understand the code<br>
> enough to try to fix it (whereas I have made many fixes and enchancements to<br>
> wxWebConnect).<br>
<br>
</div>Did you try a simple CSS solution like <style type="text/css"> *<br>
{cursor: default}</style> in the header of your rendered HTML? If<br>
wxWebKit doesn't understand that, then it's clearly got no business<br>
claiming to be an embedding of WebKit. I've used that with great<br>
success across all browsers for the past 10 years. Any HTML engine<br>
which fails to even support that basic of a CSS2 operation you're well<br>
right to just ignore!<br></blockquote><div><br>I did not, but I doubt it would have worked.  I looked in the code, and at that time the parts of the code handling cursor changes just returned "not implemented" (which is supported by WebKit's interfaces, and I would guess there are just about always parts of WebKit that are not implemented by one or more renderers).<br>

<br>For the record, the latest version did support cursor changing.<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
><br>
> Three months ago when running into more XULRunner problems that were<br>
> annoying me (some of which I was only able to mitigate rather than fix).  I<br>
> tried wxWebKit again, and again concluded that it was not a solution (apart<br>
> from anything else, it would hang and segfault too often in odd ways,<br>
> including on Acid2 and Acid3.  It also ended up very much slower than any<br>
> other WebKit browser I have used).  I am not in principle opposed to using<br>
> it, but in practice I have never found it reliable enough or performant<br>
> enough to fit the bill, and I gather that WebKit itself changes fast enough<br>
> that this is unlikely to change.<br>
<br>
</div>It must be something with the wx port of it. BibleTime has had no<br>
issues using QtWebKit and I haven't heard of related problems with<br>
GTKWebKit in Xiphos either. It's a shame that wx is stuck without a<br>
good solution. With Gecko/Xul APIs discontinued by Mozilla and WebKit<br>
so plagued by troubles in wx it's quite a shame.  Fortunately Gecko<br>
1.9.2 probably has enough support for what you're looking for as to be<br>
successful for quite a while so long as it doesn't have glaring bugs.</blockquote><div><br>I think wxWidgets has fortunately or unfortunately become a much more fringe platform than it was, and definitely feels more so than either Qt or Gtk.  The real problem with wxWebKit is (as far as I can tell) that there are 10,000+ lines of code to implement all the rendering to physical window, cursor management and other bits WebKit needs on a particular platform, and wxWebKit as an essentially one-man project has not completed and optimised those lines of code.  Understandable, but not the best for other projects (and, as I said, the feeling I get is that the rate of change in WebKit is too fast for wxWebKit to keep up anyway).<br>

<br>On the other hand, wxWebConnect XULRunner embedding you are essentially getting the actual window embedded without trying to render it using wxWidgets primitives, which does have occasional frustrating issues with how that window interacts with the rest of your app, but guarantees that everything about the rendering, etc. has been implemented and tested on a big large project like Firefox and will not just behave differently because the wx backend is implemented differently.<br>

<br>Jon<br></div></div>