[Fwd: [wxPython-users] Re: wxWebkit]

[Ken Seehart]

Kevin Ollivier wrote:
> Hi Ken,
>
> On Nov 29, 2007, at 8:42 PM, Ken Seehart wrote:
>
>> Is there a new version of webkit for wxPython available?  I'd love to 
>> try it out.  Based on that, especially if some progress has been 
>> made, I expect to have an affirmative decision on funding some 
>> bounties on Tuesday.  Do you have any suggestions on how these 
>> bounties are structured (to avoid duplication of effort, etc.)?  I'm 
>> thinking in terms of a time-decay arrangement of some kind.
>
> We've completed the migration to Apple's trunk, and now have a Mac 
> buildbot set up, which is good news because now we've gotten all the 
> fixes made to WebKit over the past few months and also when Apple 
> changes break the wxWebKit build they actually go through and fix it 
> for us. :-) The current status of the ports are as follows:
>
> 1) Mac - all green, building and passes all tests
>
> 2) Linux/GTK - builds and passes tests, but an issue with 
> JavaScriptCore/API exports requires a hack to build the sample. I 
> expect this to be resolved fairly soon, at which point we'll get that 
> on the buildbot too. Needs Cairo implementation of API to get 
> properties GetTextExtent doesn't retrieve (e.g. ascent, line spacing).
>
> 3) Windows - So far I've been unable to get it to build using either 
> MSVC 2003 or 2005 with stock wxPython libs, but getting this going is 
> my current priority. Kevin Watters has a running build but he's 
> building his own Python/wxPython and doing everything with MSVC 2005. 
>
Okay.  I forgot to mention I'm developing on Windows.  Kevin W, any 
chance you can upload a windows binary and send me a link so I can play 
with it?
> International text handling and improper loading of resources when no 
> protocol was specified (e.g. "www.google.com" as opposed to 
> "http://www.google.com") are fixed, the other Win-specific bugs I 
> haven't been able to test yet due to my problems with the Windows build.
Yeah, I'm having trouble with the Windows build too.  And I don't really 
have time right now to figure them out.
>
> As for the bounties question, I think I'd have to see the actual 
> bounties to give a better idea of how to break them up, etc.
>
Okay.  I'll send a list of proposed bounties after I wee where we are now.
> Thanks,
>
> Kevin
>
>>
>> Ken Seehart
>>
>>
>>>
>>> On Oct 17, 2007, at 5:40 PM, Ken Seehart wrote:
>>>
>>>> Looks like the wxWebkit project needs a shot of adrenaline  :-)   
>>>> It's a very promising project, worthy of being completed.
>>>>
>>>> There is currently no viable alternative for embedding an html 
>>>> browser in wxPython, although there are several partial solutions.  
>>>> We would very much like to see one.  wxWebkit is currently the 
>>>> closest in that it aims to provide the basic necessities: 
>>>> portability (windows, linux, mac) and sufficient html standards 
>>>> compliance to be considered a true browser.
>>>>
>>>> We can provide some financial assistance.  I'm not sure how much 
>>>> yet, but it's negotiable.  I will know more about my budget a week 
>>>> from now.  It would be helpful to get an estimate of the amount of 
>>>> time needed.
>>>
>>> Thanks, the project could use some extra help! :-)
>>>
>>>> I want to put feelers out there for other organizations that can 
>>>> match funds.
>>>>
>>>> I would like to attach the funding to specific bounties.  The major 
>>>> issues that we need resolved are as follows:
>>>>
>>>> 1. Support for forms (check boxes, combo boxes, edit boxes with 
>>>> accurate cursor location, etc.)
>>>
>>> The cursor location issue is nearly fixed (on Windows), thanks to a 
>>> lot of help by Kevin Watters and Chris Mellon. For the rest, IMHO we 
>>> need to improve wxRendererNative to add these renderers.
>>>
>>>> 2. Crash (probably related to image caching bug)
>>>
>>> Note that I'm in the process of testing with Apple's latest SVN (my 
>>> last update was in May!) - I'll let you know if the updated code 
>>> fixes this issue, or if we still need to work something out.
>>>
>>>> 3. Selection causes undesirable scroll to top (making it impossible 
>>>> for the user to select from portions of the document that require 
>>>> scrolling to get to).
>>>
>>> I fixed this one last weekend. :-) I'm still trying to figure out 
>>> the autoscroll handling though.
>>>
>>>> 4. Handle start selection and end selection messages (I need the 
>>>> ability to write code that defers dynamic changes to the content 
>>>> while the user is attempting to make a selection)
>>>
>>> WebKit fires a shouldChangeSelectedDOMRange message, which should be 
>>> what you're looking for. It'd just be a matter of sending off a wx 
>>> event for this when it gets fired.
>>>
>>>> Also would be nice:
>>>> 5. Ability to rebuild wxPython with wxWebkit (I'm having trouble 
>>>> getting the build to happen), or make it a separate library.
>>>
>>> I'm not sure what you mean by rebuilding wxPython with wxWebKit. 
>>> wxWebKit is designed to build against stock wxPython with the most 
>>> recent builds (just use the wxPython-devel package to get the 
>>> necessary headers and libs), so you shouldn't need to build wxPython 
>>> at all to build wxWebKit. Of course, as I mentioned before, wxWebKit 
>>> can't build against MSVC6, so there unfortunately won't be any 
>>> Python 2.3 builds, but for Python 2.4+ everything works fine.
>>>
>>>> 6. Smaller redistributable size.
>>>>
>>>> Please let me know if you are interested in developing wxWebkit, or 
>>>> if you are interested in matching funds for development.
>>>
>>> What wxWebKit could really use is some funding to get some 
>>> developers, particularly those familiar with the native APIs and 
>>> wxWidgets itself, to spend some time bug testing the code and 
>>> filling in the gaps. There is a lot of stuff done, but those 4 
>>> issues above are not the only things that need done to get things 
>>> stable, and we are touching some areas where the native platform 
>>> implementations differ significantly. For example, I can say that 
>>> the wxWidgets classes for text rendering are very simplified 
>>> compared to the APIs exposed by native platforms, and that even the 
>>> APIs don't necessarily behave the same across platforms.
>>>
>>> Actually, to be honest, a lot of the major remaining issues are 
>>> caused by holes in wxWidgets - things that we can do with the native 
>>> APIs, but that wxWidgets has no functionality for, or at least I 
>>> can't see how to implement using wxWidgets. (i.e. non-kerned text 
>>> drawing on Windows, the aforementioned wxRenderer APIs we need, IME 
>>> position management in wxWindow, a class for storing image data as 
>>> it is downloaded, etc.) This has had me stepping into a lot of code 
>>> areas I haven't ever touched before, and using native APIs which I'm 
>>> not necessarily familiar with. And since I want to work with 
>>> wxPython, and thus released wxPython builds, I have to measure 
>>> whether or not I should fix something in wx and wait for an official 
>>> release, or try to develop an external solution first.
>>>
>>>> Also let me know if you are in any way interested in the wxWebkit 
>>>> project.  I'd like to know what the level of community interest is.
>>>
>>> I'm not going to name names since I've often been contacted directly 
>>> and I don't know if I would be announcing things I shouldn't, but I 
>>> know of at least 4-5 developers that have shown significant interest 
>>> in the project, and most of those people went to the time and effort 
>>> to actually track down info on the project. ;-)
>>>
>>>> I not sure whether this message would have been better to post at 
>>>> wx-users at lists.wxwidgets.org.  People don't like cross-posting.
>>>
>>> I think it's relevant, so I'm introducing wx-users into this, and 
>>> they can flame me if they feel it's inappropriate. ;-)
>>>
>>>> Any suggestions of how to reach that group without cross-posting?  
>>>> There is also wxwebkit-devel but there is almost no activity there.
>>>
>>> Most wxWebKit discussion these days happens on #wxWidgets and 
>>> #WebKit IRC channels, since we can work in pretty much real-time 
>>> that way. It doesn't have the record that the mailing list does, but 
>>> we can work much faster, which right now is very important.
>>>
>>> Thanks,
>>>
>>> Kevin