full DOM bindings to wxWebkit

i've created full - and direct - python bindings to webkit DOM, which
are functionally equivalent to, and a full peer of, the webkit
javascript bindings. access to these functions, in python, can be
achieved by adding three functions - GetDomDocument, GetDomWindow and
GetXMLHttpRequest - in about 50 lines of c code, inside the python wx
module... which i will add once i have a working "vanilla" build of
wxpython.

first things: i've seen the discussion "wxPython build cannot find
include files" and have noted that .i files are missing (which i also
have encountered: am building on debian - advice of which debian
package should be installed, that contains these missing files, much
appreciated).

second thing: there appears to be some includfe paths missing from the
waf file (see below)

third thing: the waf file actually appears to have entirely moved!
when first running the build, an HTTP "redirection" html message was
endeavoured to be executed. examination of this file showed a
location, which i obtained with wget, and then replaced the HTML with
that file. progress could be made until the missing include paths
error was encountered.

advice appreciated.

l.

[ 181/2353] cxx: WebCore/DerivedSources/CSSGrammar.cpp -> build/
default/WebCore/DerivedSources/CSSGrammar_1.o
In file included from ../WebCore/bindings/js/DOMWrapperWorld.h:25,
                 from ../WebCore/bindings/js/JSDOMBinding.h:27,
                 from ../WebCore/bindings/js/ScriptValue.h:34,
                 from ../WebCore/bindings/js/SerializedScriptValue.h:
30,
                 from ../WebCore/dom/MessagePortChannel.h:36,
                 from ../WebCore/dom/MessagePort.h:32,
                 from ../WebCore/page/DOMWindow.h:31,
                 from ../WebCore/bindings/cpp/WebDOMEventTarget.cpp:
25:
../WebCore/dom/Document.h:29:34: error: CachedResourceHandle.h: No
such file or directory

first things: i've seen the discussion "wxPython build cannot find
include files" and have noted that .i files are missing (which i also
have encountered: am building on debian - advice of which debian
package should be installed, that contains these missing files, much
appreciated).

They should be in the wx2.8-headers pacakge.

second thing:

I'll let Kevin answer the remaining questions.

···

On 5/22/11 11:36 AM, lkcl wrote:

--
Robin Dunn
Software Craftsman

> first things: i've seen the discussion "wxPython build cannot find
> include files" and have noted that .i files are missing (which i also
> have encountered: am building on debian - advice of which debian
> package should be installed, that contains these missing files, much
> appreciated).

They should be in the wx2.8-headers pacakge.

ahh, they're not. ok, so i've raised a bugreport with the debian
maintainers, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627728
to get that resolved.

thanks for alerting me to the correct package name, robin.

I'll let Kevin answer the remaining questions.

understood. appreciated.

l.

···

On May 23, 5:45 pm, Robin Dunn <ro...@alldunn.com> wrote:

On 5/22/11 11:36 AM, lkcl wrote:

... btw, i have the python bindings working for the gtk2 port, and
also for the (new and experimental) DirectFB port which denis did,
last year. so they're "known to work", and are a bit quicker than
using introspection on the GObject bindings. and functionally
equivalent to the JS ones (which the GObject ones are not). so it
would be nice to extend wxPython as well: pywebkitgtk is a leetle
awkward because it's taken a direction that's incompatible with
javascript interoperability/equivalence. pywebkitqt4's python
bindings are truly f****** awful, forcing users to execute (i.e. have
translated and interpreted) javascript code snippets - sounds great in
theory until you want to cover absolutely every function in the entire
HTML5 specification...

Hi Luke,

i've created full - and direct - python bindings to webkit DOM, which
are functionally equivalent to, and a full peer of, the webkit
javascript bindings. access to these functions, in python, can be
achieved by adding three functions - GetDomDocument, GetDomWindow and
GetXMLHttpRequest - in about 50 lines of c code, inside the python wx
module... which i will add once i have a working "vanilla" build of
wxpython.

first things: i've seen the discussion "wxPython build cannot find
include files" and have noted that .i files are missing (which i also
have encountered: am building on debian - advice of which debian
package should be installed, that contains these missing files, much
appreciated).

second thing: there appears to be some includfe paths missing from the
waf file (see below)

third thing: the waf file actually appears to have entirely moved!
when first running the build, an HTTP "redirection" html message was
endeavoured to be executed. examination of this file showed a
location, which i obtained with wget, and then replaced the HTML with
that file. progress could be made until the missing include paths
error was encountered.

Yes, it has moved - there was recently a patch applied which moved waf from the wx subdir to its own waf subdir, to make it easier for other ports to test out the waf build system. However, I have not seen the error message you posted below in my testing, so I don't know if there's some debian-specific issue (I test on ubuntu) or if it's a side-effect of some of your changes not being merged properly after the waf move, or something else.

I can't really offer more specific help without seeing your patch and what you've done.

Thanks,

Kevin

···

On May 22, 2011, at 11:36 AM, lkcl wrote:

advice appreciated.

l.

[ 181/2353] cxx: WebCore/DerivedSources/CSSGrammar.cpp -> build/
default/WebCore/DerivedSources/CSSGrammar_1.o
In file included from ../WebCore/bindings/js/DOMWrapperWorld.h:25,
                from ../WebCore/bindings/js/JSDOMBinding.h:27,
                from ../WebCore/bindings/js/ScriptValue.h:34,
                from ../WebCore/bindings/js/SerializedScriptValue.h:
30,
                from ../WebCore/dom/MessagePortChannel.h:36,
                from ../WebCore/dom/MessagePort.h:32,
                from ../WebCore/page/DOMWindow.h:31,
                from ../WebCore/bindings/cpp/WebDOMEventTarget.cpp:
25:
../WebCore/dom/Document.h:29:34: error: CachedResourceHandle.h: No
such file or directory

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

ok, well i'm embarrassed to say that it was actually a vanilla
version of webkit... but.. um... from over six months ago :slight_smile: so, i
don't know what the waf file is doing but - let me guess, does it
specify the include paths? i think basically there's been some
changes, the include paths are 1 less subdirectory deep than is needed

anyway i've compiled the latest git (450mb of objects downloaded -
scary!) and it's all hunky-dory, so i have a working point to go from
(with no --wxpython bindings)

···

On May 24, 9:01 pm, Kevin Ollivier <kevin-li...@theolliviers.com> wrote:

Hi Luke,

On May 22, 2011, at 11:36 AM, lkcl wrote:

> i've created full - and direct - python bindings to webkit DOM, which
> are functionally equivalent to, and a full peer of, the webkit
> javascript bindings. access to these functions, in python, can be
> achieved by adding three functions - GetDomDocument, GetDomWindow and
> GetXMLHttpRequest - in about 50 lines of c code, inside the python wx
> module... which i will add once i have a working "vanilla" build of
> wxpython.

> first things: i've seen the discussion "wxPython build cannot find
> include files" and have noted that .i files are missing (which i also
> have encountered: am building on debian - advice of which debian
> package should be installed, that contains these missing files, much
> appreciated).

> second thing: there appears to be some includfe paths missing from the
> waf file (see below)

> third thing: the waf file actually appears to have entirely moved!
> when first running the build, an HTTP "redirection" html message was
> endeavoured to be executed. examination of this file showed a
> location, which i obtained with wget, and then replaced the HTML with
> that file. progress could be made until the missing include paths
> error was encountered.

Yes, it has moved - there was recently a patch applied which moved waf from the wx subdir to its own waf subdir, to make it easier for other ports to test out the waf build system. However, I have not seen the error message you posted below in my testing, so I don't know if there's some debian-specific issue (I test on ubuntu) or if it's a side-effect of some of your changes not being merged properly after the waf move, or something else.

I can't really offer more specific help without seeing your patch and what you've done.

Hi Luke,

Hi Luke,

i've created full - and direct - python bindings to webkit DOM, which
are functionally equivalent to, and a full peer of, the webkit
javascript bindings. access to these functions, in python, can be
achieved by adding three functions - GetDomDocument, GetDomWindow and
GetXMLHttpRequest - in about 50 lines of c code, inside the python wx
module... which i will add once i have a working "vanilla" build of
wxpython.

first things: i've seen the discussion "wxPython build cannot find
include files" and have noted that .i files are missing (which i also
have encountered: am building on debian - advice of which debian
package should be installed, that contains these missing files, much
appreciated).

second thing: there appears to be some includfe paths missing from the
waf file (see below)

third thing: the waf file actually appears to have entirely moved!
when first running the build, an HTTP "redirection" html message was
endeavoured to be executed. examination of this file showed a
location, which i obtained with wget, and then replaced the HTML with
that file. progress could be made until the missing include paths
error was encountered.

Yes, it has moved - there was recently a patch applied which moved waf from the wx subdir to its own waf subdir, to make it easier for other ports to test out the waf build system. However, I have not seen the error message you posted below in my testing, so I don't know if there's some debian-specific issue (I test on ubuntu) or if it's a side-effect of some of your changes not being merged properly after the waf move, or something else.

I can't really offer more specific help without seeing your patch and what you've done.

ok, well i'm embarrassed to say that it was actually a vanilla
version of webkit... but.. um... from over six months ago :slight_smile: so, i
don't know what the waf file is doing but - let me guess, does it
specify the include paths? i think basically there's been some
changes, the include paths are 1 less subdirectory deep than is needed

Yes, another project-wide change was to move the WebCore, JavaScriptCore, etc. directories into a Source directory.

anyway i've compiled the latest git (450mb of objects downloaded -
scary!) and it's all hunky-dory, so i have a working point to go from
(with no --wxpython bindings)

What exactly are you working on, BTW? It sounds like you're using SWIG for your wrappers, but you don't want the actual wxWebKit wrappers generated by --wxpython? Are you replacing them with something, or do you just want DOM wrappers and nothing else? (But if so, how do you load the page?)

The wxPython bindings already have DOM wrappers, so I don't understand why the idea isn't just to add the GetDOMDocument and GetDOMWindow methods implemented on wxWebFrame and wxWebView.

Thanks,

Kevin

···

On May 24, 2011, at 1:38 PM, lkcl wrote:

On May 24, 9:01 pm, Kevin Ollivier <kevin-li...@theolliviers.com> > wrote:

On May 22, 2011, at 11:36 AM, lkcl wrote:

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

ok, rrright. so, having done "apt-get source wx2.8-headers", unpacked
the source tarball and worked out that the wxpython-NNN/src/*.i files
need to be copied to /usr/include/wx/wx-2.8/wxPython/i_files, i could
then do a build with --wxpython (yaay!)

and... ah. rright. a couple of things. the first is that, as you can
see, some header files can't be found (this is with latest git as
ooof... yesterday). ok, riight, i'm reading the errors a little more
closely: they're warnings, but the errors are actually stuff .py files
that were in the src/ directory (wx distribution)

ok, so now i've put _core_ex.py and friends in the same subdirectory (/
usr/include/....) those errors go.

let's have a look at what's generated... oo very cool, you've begun
some DOM bindings - WebDOMObject, WebDOMNode, WebDOMAttr and friends.
very cool! and, i see WebDOMElement even has "onmouse" callback
setting.

... hey, maybe you don't need the full DOM python bindings i wrote :slight_smile:
that would be very cool if you had full interoperability / equivalence
with javascript.

ok - so tell me, what's the progress and status? are you planning to
cover the entire range of DOM objects and functions, and if so, on
what sort of timescale?

also - and this is very VERY important: do you have a goal of
providing ABSOLUTE and COMPLETE, WITHOUT FAIL ABSOLUTE 100%
equivalence to javascript's DOM bindings (all 450 objects/elements,
all 3,000 functions and all 20,000 properties) including Timers,
XMLHttpRequest and complete compliance to the de-facto javascript DOM
"standard"?

or, do you have a goal of providing either a small subset of the DOM
functionality, or a goal of providing absolute adherence to the W3C
HTML5 standards, regardless of whether the javascript bindings in
webkit do not actually conform correctly to the W3C HTML5 standard?

if it's the former, i can help you with the bindings. if it's the
latter, i cannot help you, as the pyjamas project requires that the
python applications that users write have absolute 100% equivalent
*javascript*-driven DOM bindings, and absolute and complete and total
DOM bindings, *not* bindings as described in the W3C HTML5 standard.

it's a long, long story, but basically, the pyjamas project allows
developers to write applications in pure python, that are then either
translated to javascript (and executed in a web browser) *or* run
"natively" - as a desktop application - as pure python. this is
called "pyjamas desktop" - pyjd for short - and it requires browser
engines with FULL and ABSOLUTE COMPLETE bindings to the DOM.

i really, _really_ mean everything. one single function, property or
feature missing or wrong and it's a dog's dinner [complete waste of
time]. you can't have an application which works in web browsers yet
whoops doesn't support onmouseover on one particular platform! :slight_smile:

so.

let me know, one way or the other. take your time thinking about it:
where do you want the wxWebkit DOM bindings to go? what would you
ultimately like them to do? (oh, and if you'd like them to be fully
interoperable with the de-facto javascript standards, then you'd
automatically get a quite large test suite "for free" - the pyjamas
applications development environment - and an instant and grateful
medium-sized user base thrown in as well)

l.

re/css --include /home/lkcl/src/python-tv/WebKit/Source/WebCore/page --
include /home/lkcl/src/python-tv/WebKit/Source/WebCore/notifications --
include /home/lkcl/src/python-tv/WebKit/Source/WebCore/xml --include /
home/lkcl/src/python-tv/WebKit/Source/WebCore/svg --write-dependencies
--outputDir . --defines "ENABLE_DATABASE ENABLE_XSLT
ENABLE_JAVASCRIPT_DEBUGGER ENABLE_SVG ENABLE_SVG_USE ENABLE_FILTERS
ENABLE_SVG_FONTS ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE
ENABLE_SVG_FOREIGN_OBJECT ENABLE_JIT ENABLE_DOM_STORAGE BUILDING_WX
LANGUAGE_CPP" --generator CPP /home/lkcl/src/python-tv/WebKit/Source/
WebCore/dom/PopStateEvent.idl
Ensuring wxWebKit dependencies are up-to-date.
Checking for wx-config : yes
Checking for library python2.6 : yes
Checking for program python2.6-config : /usr/bin/python2.6-config
Checking for custom code : yes
Checking for libxslt : yes
Checking for xml2-config : yes
Checking for curl-config : yes
Checking for cairo : yes
Checking for pango : yes
Checking for gtk+-2.0 : yes
Checking for sqlite3 : yes
Checking for icu-config : yes
Checking for program swig : /usr/bin/swig
Checking for swig version >= 1.3.29 : ok 1.3.40
'configure' finished successfully (14.552s)
Waf: Entering directory `/home/lkcl/src/python-tv/WebKit/build'
could not find 'config.h'
could not find 'wx/wxPython/wxPython.h'
could not find 'wx/wxPython/pyclasses.h'
could not find 'WebBrowserShell.h'
could not find 'WebDOMSelection.h'
could not find 'WebEdit.h'
could not find 'WebFrame.h'
could not find 'WebSettings.h'
could not find 'WebView.h'
could not find 'WebDOMAttr.h'
could not find 'WebDOMCSSStyleDeclaration.h'
could not find 'WebDOMDocument.h'
could not find 'WebDOMDocumentFragment.h'
could not find 'WebDOMDOMSelection.h'
could not find 'WebDOMElement.h'
could not find 'WebDOMEventListener.h'
could not find 'WebDOMNamedNodeMap.h'
could not find 'WebDOMNode.h'
could not find 'WebDOMNodeList.h'
could not find 'WebDOMObject.h'
could not find 'WebDOMRange.h'
could not find 'WebDOMWebKitAnimationList.h'
[2542/2552] swig: Source/WebKit/wx/bindings/python/webview.i -> build/
default/Source/WebKit/wx/bindings/python/webview.swigwrap_1.cxx build/
default/Source/WebKit/wx/bindings/python/webview.py
/usr/include/wx-2.8/wx/wxPython/i_files/_event.i:21: Error: Couldn't
find '_event_ex.py'.
/usr/include/wx-2.8/wx/wxPython/i_files/_app.i:282: Error: Couldn't
find '_app_ex.py'.
/usr/include/wx-2.8/wx/wxPython/i_files/core.i:93: Error: Couldn't
find '_core_ex.py'.
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMDOMSelection.h:41: Warning(362): operator= ignored
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMDOMSelection.h:41: Warning(362): operator= ignored
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNodeList.h:40: Warning(362): operator= ignored
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMRange.h:42: Warning(362): operator= ignored
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:41: Warning(401): Nothing known about base class
'WebDOMEventTarget'. Ignored.
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:44: Warning(511): Can't use keyword arguments with
overloaded functions (WebDOMNode::WebDOMNode(WebCore::Node *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:111: Warning(511): Can't use keyword arguments with
overloaded functions (toWebCore(WebDOMNode const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:112: Warning(511): Can't use keyword arguments with
overloaded functions (toWebKit(WebCore::Node *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMAttr.h:38: Warning(511): Can't use keyword arguments with
overloaded functions (WebDOMAttr::WebDOMAttr(WebCore::Attr *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMAttr.h:51: Warning(511): Can't use keyword arguments with
overloaded functions (toWebCore(WebDOMAttr const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMAttr.h:52: Warning(511): Can't use keyword arguments with
overloaded functions (toWebKit(WebCore::Attr *)).

/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:44: Warning(511): Can't use keyword arguments with
overloaded functions (WebDOMNode::WebDOMNode(WebCore::Node *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:111: Warning(511): Can't use keyword arguments with
overloaded functions (toWebCore(WebDOMNode const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNode.h:112: Warning(511): Can't use keyword arguments with
overloaded functions (toWebKit(WebCore::Node *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMAttr.h:38: Warning(511): Can't use keyword arguments with
overloaded functions (WebDOMAttr::WebDOMAttr(WebCore::Attr *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMAttr.h:51: Warning(511): Can't use keyword arguments with
overloaded functions (toWebCore(WebDOMAttr const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMAttr.h:52: Warning(511): Can't use keyword arguments with
overloaded functions (toWebKit(WebCore::Attr *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMDOMSelection.h:39: Warning(511): Can't use keyword arguments
with overloaded functions
(WebDOMDOMSelection::WebDOMDOMSelection(WebCore::DOMSelection *)).

/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNodeList.h:54: Warning(511): Can't use keyword arguments with
overloaded functions (toWebCore(WebDOMNodeList const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMNodeList.h:55: Warning(511): Can't use keyword arguments with
overloaded functions (toWebKit(WebCore::NodeList *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMRange.h:40: Warning(511): Can't use keyword arguments with
overloaded functions (WebDOMRange::WebDOMRange(WebCore::Range *)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMRange.h:41: Warning(511): Can't use keyword arguments with
overloaded functions (WebDOMRange::WebDOMRange(WebDOMRange const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMRange.h:96: Warning(511): Can't use keyword arguments with
overloaded functions (toWebCore(WebDOMRange const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebCore/DerivedSources/
WebDOMRange.h:97: Warning(511): Can't use keyword arguments with
overloaded functions (toWebKit(WebCore::Range *)).
/home/lkcl/src/python-tv/WebKit/Source/WebKit/wx/WebDOMSelection.h:56:
Warning(511): Can't use keyword arguments with overloaded functions
(wxWebKitSelection::wxWebKitSelection(WebCore::FrameSelection *)).
/home/lkcl/src/python-tv/WebKit/Source/WebKit/wx/WebDOMSelection.h:58:
Warning(511): Can't use keyword arguments with overloaded functions
(wxWebKitSelection::wxWebKitSelection(wxWebKitSelection const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebKit/wx/WebFrame.h:60:
Warning(511): Can't use keyword arguments with overloaded functions
(wxWebViewDOMElementInfo::wxWebViewDOMElementInfo(wxWebViewDOMElementInfo
const &)).
/home/lkcl/src/python-tv/WebKit/Source/WebKit/wx/WebSettings.h:66:
Warning(511): Can't use keyword arguments with overloaded functions
(wxWebSettings::wxWebSettings(WebCore::Settings *)).

ok the instructions (and location of git repo, and branch) are at
Python Webkit DOM Bindings. once git cloned, look in
the wkcodegen subdirectory (badly-named, i know). the code in there
is a hybrid! what i did was:

* took xulrunner's xpidl IDL file parser (which uses python-ply) and
enhanced it to be capable of reading Webkit IDL files instead of
Mozilla Foundation XULRunner IDL files

* took python-gobject's "codegen" and transformed it to understand
the objects outputted from the above-modified xpidl parser

* further modified the codegen code to, instead of outputting gobject
code bindings, output a "pure python" module instead!

total time taken to get full and complete python DOM bindings: 10
(ten) days. start to finish. over a hundred and forty IDL files
parsed, code supporting all functions and properties. most of the
time was spent getting the data types right, which, once those were
there it's not the number of IDL files supported that matter. it
helped that i'd done the gobject bindings (in perl *shudder*) 3 years
ago, so i simply borrowed and adapted code that i knew worked.

caveat: i still haven't done SVG Canvas :slight_smile:

so, anyway: this is a... different approach. i take it you're doing
the SWIG files by hand? if so, can i recommend that you give serious
consideration to writing an auto-generator, that will take the Webkit
IDL files and output auto-generated SWIG files? it's the datatypes
that "get you".

l.

···

On May 24, 9:01 pm, Kevin Ollivier <kevin-li...@theolliviers.com> wrote:

I can't really offer more specific help without seeing your patch and what you've done.

Hi Luke,

>> Hi Luke,

>>> i've created full - and direct - python bindings to webkit DOM, which
>>> are functionally equivalent to, and a full peer of, the webkit
>>> javascript bindings. access to these functions, in python, can be
>>> achieved by adding three functions - GetDomDocument, GetDomWindow and
>>> GetXMLHttpRequest - in about 50 lines of c code, inside the python wx
>>> module... which i will add once i have a working "vanilla" build of
>>> wxpython.

>>> first things: i've seen the discussion "wxPython build cannot find
>>> include files" and have noted that .i files are missing (which i also
>>> have encountered: am building on debian - advice of which debian
>>> package should be installed, that contains these missing files, much
>>> appreciated).

>>> second thing: there appears to be some includfe paths missing from the
>>> waf file (see below)

>>> third thing: the waf file actually appears to have entirely moved!
>>> when first running the build, an HTTP "redirection" html message was
>>> endeavoured to be executed. examination of this file showed a
>>> location, which i obtained with wget, and then replaced the HTML with
>>> that file. progress could be made until the missing include paths
>>> error was encountered.

>> Yes, it has moved - there was recently a patch applied which moved waf from the wx subdir to its own waf subdir, to make it easier for other ports to test out the waf build system. However, I have not seen the error message you posted below in my testing, so I don't know if there's some debian-specific issue (I test on ubuntu) or if it's a side-effect of some of your changes not being merged properly after the waf move, or something else.

>> I can't really offer more specific help without seeing your patch and what you've done.

> ok, well i'm embarrassed to say that it was actually a vanilla
> version of webkit... but.. um... from over six months ago :slight_smile: so, i
> don't know what the waf file is doing but - let me guess, does it
> specify the include paths? i think basically there's been some
> changes, the include paths are 1 less subdirectory deep than is needed

Yes, another project-wide change was to move the WebCore, JavaScriptCore, etc. directories into a Source directory.

> anyway i've compiled the latest git (450mb of objects downloaded -
> scary!) and it's all hunky-dory, so i have a working point to go from
> (with no --wxpython bindings)

What exactly are you working on, BTW?

the pyjamas desktop project. a reply has just crossed over.

It sounds like you're using SWIG for your wrappers,

ah see the message that's just crossed over - i'll come back tomorrow
with a reply (end-of-day here). i describe the architecture of what i
did - it's a combination of xpidl and gobject codegen - both heavily
modified.

but you don't want the actual wxWebKit wrappers generated by --wxpython?

well that depends on whether they're 100% functionally equivalent to
javascript.

Are you replacing them with something, or do you just want DOM wrappers and nothing else? (But if so, how do you load the page?)

ok what i have is DOM wrappers (and nothing else) already. what i've
done for WebkitGTK as well as Webkit-DirectFB is add those 3 functions
GetDOMDocument, GetDOMWIndow and GetDOMXMLHttpRequest *into* the
WebFrame / WebView, and thus, once the page is loaded, can gain access
to its DOM in *full* python equivalence to javascript.

i'm trying to establish the extent to which wxWebKit already has this
capability. if it has FULL compliance to the de-facto javascript
standard, i don't need to add the stuff i've done! :slight_smile: i can just use
what you've got.

The wxPython bindings already have DOM wrappers, so I don't understand why the idea isn't just to add the GetDOMDocument and GetDOMWindow methods implemented on wxWebFrame and wxWebView.

in order to use those (for the pyjamas project) the DOM functions
*have* to be absolutely complete. not one single piece of
functionality missing.

so - are the existing wxPython DOM bindings absolutely - and i _mean_
absolutely - functionally equivalent to the current webkit javascript
bindings? if i take quite literally any javascript off of *any* web
site, anywhere in the world, and do a conversion of that code into
python and then, assuming that, hypothetically, webkit supported <
script "language=python" > as well as < script language="javascript" >
- would that converted application work absolutely 100%, including
absolute 100% conformance to errors and exceptions that occur in the
exact same javascript source code?

···

On May 24, 10:06 pm, Kevin Ollivier <kevin-li...@theolliviers.com> wrote:

On May 24, 2011, at 1:38 PM, lkcl wrote:
> On May 24, 9:01 pm, Kevin Ollivier <kevin-li...@theolliviers.com> > > wrote:
>> On May 22, 2011, at 11:36 AM, lkcl wrote:

why is this neccesary? If you are using WebKit to render the UI anyway, why not have the javascript do the actual DOM work in both the desktop and user-browser version?

Not that I don't think it would be cool -- and very useful -- to be able to use Python to manipulate the DOM, but it seems if you're doing the Python->Javascript translation anyway, you could just use that.

Just wondering what the design drivers are here...

-Chris

···

On 5/24/11 2:08 PM, lkcl wrote:

pyjamas project allows
developers to write applications in pure python, that are then either
translated to javascript (and executed in a web browser) *or* run
"natively" - as a desktop application - as pure python.

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Hi Luke,

Hi Luke,

Hi Luke,

i've created full - and direct - python bindings to webkit DOM, which
are functionally equivalent to, and a full peer of, the webkit
javascript bindings. access to these functions, in python, can be
achieved by adding three functions - GetDomDocument, GetDomWindow and
GetXMLHttpRequest - in about 50 lines of c code, inside the python wx
module... which i will add once i have a working "vanilla" build of
wxpython.

first things: i've seen the discussion "wxPython build cannot find
include files" and have noted that .i files are missing (which i also
have encountered: am building on debian - advice of which debian
package should be installed, that contains these missing files, much
appreciated).

second thing: there appears to be some includfe paths missing from the
waf file (see below)

third thing: the waf file actually appears to have entirely moved!
when first running the build, an HTTP "redirection" html message was
endeavoured to be executed. examination of this file showed a
location, which i obtained with wget, and then replaced the HTML with
that file. progress could be made until the missing include paths
error was encountered.

Yes, it has moved - there was recently a patch applied which moved waf from the wx subdir to its own waf subdir, to make it easier for other ports to test out the waf build system. However, I have not seen the error message you posted below in my testing, so I don't know if there's some debian-specific issue (I test on ubuntu) or if it's a side-effect of some of your changes not being merged properly after the waf move, or something else.

I can't really offer more specific help without seeing your patch and what you've done.

ok, well i'm embarrassed to say that it was actually a vanilla
version of webkit... but.. um... from over six months ago :slight_smile: so, i
don't know what the waf file is doing but - let me guess, does it
specify the include paths? i think basically there's been some
changes, the include paths are 1 less subdirectory deep than is needed

Yes, another project-wide change was to move the WebCore, JavaScriptCore, etc. directories into a Source directory.

anyway i've compiled the latest git (450mb of objects downloaded -
scary!) and it's all hunky-dory, so i have a working point to go from
(with no --wxpython bindings)

What exactly are you working on, BTW?

the pyjamas desktop project. a reply has just crossed over.

It sounds like you're using SWIG for your wrappers,

ah see the message that's just crossed over - i'll come back tomorrow
with a reply (end-of-day here). i describe the architecture of what i
did - it's a combination of xpidl and gobject codegen - both heavily
modified.

but you don't want the actual wxWebKit wrappers generated by --wxpython?

well that depends on whether they're 100% functionally equivalent to
javascript.

Are you replacing them with something, or do you just want DOM wrappers and nothing else? (But if so, how do you load the page?)

ok what i have is DOM wrappers (and nothing else) already. what i've
done for WebkitGTK as well as Webkit-DirectFB is add those 3 functions
GetDOMDocument, GetDOMWIndow and GetDOMXMLHttpRequest *into* the
WebFrame / WebView, and thus, once the page is loaded, can gain access
to its DOM in *full* python equivalence to javascript.

i'm trying to establish the extent to which wxWebKit already has this
capability. if it has FULL compliance to the de-facto javascript
standard, i don't need to add the stuff i've done! :slight_smile: i can just use
what you've got.

The wxPython bindings already have DOM wrappers, so I don't understand why the idea isn't just to add the GetDOMDocument and GetDOMWindow methods implemented on wxWebFrame and wxWebView.

in order to use those (for the pyjamas project) the DOM functions
*have* to be absolutely complete. not one single piece of
functionality missing.

so - are the existing wxPython DOM bindings absolutely - and i _mean_
absolutely - functionally equivalent to the current webkit javascript
bindings? if i take quite literally any javascript off of *any* web
site, anywhere in the world, and do a conversion of that code into
python and then, assuming that, hypothetically, webkit supported <
script "language=python" > as well as < script language="javascript" >
- would that converted application work absolutely 100%, including
absolute 100% conformance to errors and exceptions that occur in the
exact same javascript source code?

That is certainly the goal, and what I can say for sure is that CPP bindings are generated for all the same DOM APIs that WebKit generates JS bindings for, so if there are any issues, it would be specific to particular methods that maybe need some tweaks. (e.g. bugs or perhaps overlooked bits in the bindings generator) I'm actually using the bindings for a WYSIWYG-style HTML editor application, so the more the bindings expose, the better the HTML editor can be. :slight_smile:

The main thing that I can think of off-hand that would need more work is more code to have methods that return, say, WebDOMElement, get translated to the proper WebDOMElement subclass when the Python object is returned. That could probably be automated as well, but I haven't yet looked at it.

Is there a test suite that we could run after the addition of GetDOMWindow, GetDOMDocument, etc. to wxWebView and wxWebFrame in order to see how many problems it exposes? :wink:

Thanks,

Kevin

···

On May 24, 2011, at 2:27 PM, lkcl wrote:

On May 24, 10:06 pm, Kevin Ollivier <kevin-li...@theolliviers.com> > wrote:

On May 24, 2011, at 1:38 PM, lkcl wrote:

On May 24, 9:01 pm, Kevin Ollivier <kevin-li...@theolliviers.com> >>> wrote:

On May 22, 2011, at 11:36 AM, lkcl wrote:

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

apologies, chris, this is a bit long! there's a heck of a lot
involved. also it's kinda off-topic but does explain why full DOM
bindings to wxWebKit would be a good idea: to _not_ do so means that
wxWebKit would be left behind when compared to the alternatives
[mentioned below].

> pyjamas project allows
> developers to write applications in pure python, that are then either
> translated to javascript (and executed in a web browser) *or* run
> "natively" - as a desktop application - as pure python.

why is this neccesary? If you are using WebKit to render the UI anyway,
why not have the javascript do the actual DOM work in both the desktop
and user-browser version?

good question! and that's the approach that's taken by the GWT
"hosting" mode, which is actually based on webkit, and also by Adobe
in "Adobe AIR". which is _again_ based on webkit.

the primary reason is simple: speed. the second technical reason is
more of an acute problem that, after 18 months of work on the pyjs
python-to-javascript compiler, the task of translating python into
javascript has turned out to be one where you can either translate
_most_ of the features of the python language into javascript (head-
butting against things like "hello" + 5 not throwing an exception but
returning a string "hello5" instead) or you can suffer anywhere
between a 100% and a 400% performance penalty, for having to do things
like "if object has an __getattr__ function, then check this, then
check that, oh and don't forget to see if it's a simple javascript
datatype first, and _then_ you can set the property on it to make it
look like it was a python object".

these kinds of limitations are not something that i want to pass on
to python developers.

also i think there's very much a.. well not "pride" issue, but an
"eat your own dog-food" attitude. if you're going to present a python-
based GUI toolkit to the world, it's a definite "what the ****" moment
if it's solely and entirely dependent on another programming language
which has some absolutely truly dreadful mistakes in it (as well as
some extremely good parts, but that's not the point: you could just
end this sentence before the word "which" and it would be enough).

Not that I don't think it would be cool -- and very useful -- to be able
to use Python to manipulate the DOM, but it seems if you're doing the
Python->Javascript translation anyway, you could just use that.

yeah... you could, but that then defeats the underlying goal of
making python a true peer of javascript. i'm sick of javascript being
the only programming language that's _allowed_ access to the
incredible features offered by web browser technology.

it turns out that IE's Trident Engine [see
http://en.wikipedia.org/wiki/Trident_(layout_engine)\] has had the
ability to cleanly add full DOM bindings since... err... since its
first version. somewhere in the early 2000s people got very very
excited by the possibilities presented by having python bindings to
DCOM (aka COM) and started playing, creating web browsers using python
in the same way that people are creating free software web browsers in
python, now, with pywebkitgtk, pywebkitqt4 and python-wxWebKit.
however, it was a very small community, limited to python on w32, and
required some voodoo magic incantations and an understanding of i've
since rediscovered the tricks involved, and have encapsulated them
into the pyjd "MSHTML" port.

then, there is the python-hulahop project, which is actually by the
OLPC team! they wanted to create a fully-functioning (and SUGAR-
compliant) python web browser, with access to "Back" button, Web
browser "History", load progress notification and absolutely
everything. in 2006 the only way to do that was to use the full XPCOM
python DOM bindings written by ActiveState, and to "plug" them into a
python-to-gtk "shim" (called hulahop). so, inside hulahop is where
"GTK window" meets "full python DOM bindings" as presented by the
Mozilla Foundation "XulRunner XPCOM" dynamic interface.

so we _already_ have the Firefox (aka XULRunner) engine, we _already_
have the Internet Explorer (aka Trident) engine: what we _don't_ have
is the WebKit engine (ok, not properly, as ubiquitous and easy-to-
install packages, anyway).

Just wondering what the design drivers are here...

there is... hum, one hell of a lot that's joined together, here, as
you can see from the brief overview, above.

l.

···

On May 24, 10:39 pm, Christopher Barker <Chris.Bar...@noaa.gov> wrote:

On 5/24/11 2:08 PM, lkcl wrote:

Here's another approach if you want to have full access to the DOM in every browser via an arbitrary language. It might not be what you want though.

Basically you create a plugin. The plugin can provide custom javascript objects written in C++ through ActiveX/NPAPI. There's already a project out there which does this with like 2 button clicks, it's called firebreath.

I've started a proof-of-concept implementation on top of that which allows you to write javascript objects in any language. The start of it is here: https://github.com/Nitrogenycs/firebreath-x . Currently it allows you to write javascript objects in C# and "normal" python. I chose C# because you get access to .NET this way. .NET also includes IronPython as well as many other languages, so room for future investigations there. The interface is two-way, e.g. you can create wxPython windows from javascript or you can call javascript from python (e.g. manipulating the dom).

The basics work pretty well, one part which I didn't finish is the cross-language polymorphism in the javascript -> C# direction since it requires dynamic creation of types in C# which is a bit involved (however, I already know where to borrow the appropriate code from :)).

The advantages of the plugin approach is it works in every browser already now and you don't need to write complicated bindings. Disadvantages is that it's a plugin, so it has to be present on a page somewhere to be loaded (though I presume you could add some add-in to a browser which just appends the plugin-inclusion code to each page).

-Matthias

> so - are the existing wxPython DOM bindings absolutely - and i _mean_
> absolutely - functionally equivalent to the current webkit javascript
> bindings? if i take quite literally any javascript off of *any* web
> site, anywhere in the world, and do a conversion of that code into
> python and then, assuming that, hypothetically, webkit supported <
> script "language=python" > as well as < script language="javascript" >
> - would that converted application work absolutely 100%, including
> absolute 100% conformance to errors and exceptions that occur in the
> exact same javascript source code?

That is certainly the goal,

ouaaahh, fantastic. ok - just to check: that means even things like
the HTML5 "Video" tag's width and height properties, which are listed
in the W3C HTML5 specification as being "integer", are actually done
as "strings" in Webkit's JS bindings, and as COM "VARIANT" in the
Trident (MSHTML / IE) Engine, and as "string" in XULRunner (Firefox).
the reason is this: absolutely everybody doing web browser engine
development got sick to the back teeth of idiotic web developers
trying to set the "video" tag width or height to "500px" instead of
"500". so, they "allowed" string types, strip off the "px" and
completely ignore any dumb-ass attempts to set video width or height
to "100%" or, worse, "20em".

so, you _may_ need to fight the webkit developers (who actually
terminated my webkit developer account over these kinds of issues, yet
hypocritically then accepted *other* people's patches doing exactly
the same thing that i said needed to be done) over these kinds of
things, if you *truly* want "full javascript-driven de-facto standards
compliance" over-and-above the "W3C HTML5 specification".

and what I can say for sure is that CPP bindings are generated for all the same DOM APIs that WebKit generates JS bindings for, so if there are any issues, it would be specific to particular methods that maybe need some tweaks. (e.g. bugs or perhaps overlooked bits in the bindings generator) I'm actually using the bindings for a WYSIWYG-style HTML editor application, so the more the bindings expose, the better the HTML editor can be. :slight_smile:

that's a very good driving force. interesting. it _may_ be
possible, if it's designed along MVC lines, to actually run the source
code through pyjs and have it be run *inside* a web browser, as
javascript. but you'd have to subdivide all the functions such as
"file access" behind an AJAX service (think "writely" aka google docs)
in order to pull that off. which would have the side-benefit of
improving responsiveness *without* having to add in threading into the
python-wxWidgets application, btw, as you're no doubt aware.

i'm kinda fed up with the only decent online WYSIWYG editor being
proprietary (google docs) so yeah, good for you!

The main thing that I can think of off-hand that would need more work is more code to have methods that return, say, WebDOMElement, get translated to the proper WebDOMElement subclass when the Python object is returned. That could probably be automated as well, but I haven't yet looked at it.

yehhhs.... that'll be fun, i can tell you [i've solved this twice,
and am aware of how it works in all the other web technologies as
well]. technically, this is where it gets complicated, and it's where
the python DOM bindings in pywebkitqt4 completely fall over. i'll
cover it in a separate message to avoid running several issues in one.

Is there a test suite that we could run after the addition of GetDOMWindow, GetDOMDocument, etc. to wxWebView and wxWebFrame in order to see how many problems it exposes? :wink:

:slight_smile:

answer 1:

well, the pyjamas examples are so massively comprehensive - 70 of
them - that by the time you've got through HelloWorld, Mail,
JSONRPCExample, DynamicTable and KitchenSink, you can pretty much be
100% confident that youve got absolutely everything. it takes about
10 mins to fire all those up and click on all the tabs. *oh* - i
forgot: there's also a gwtcanvas example, for when you've got SVG 2D
Canvas up-and-running as well, which covers every single feature of
SVG 2D Canvas so that they can be visually checked.

answer 2:

there is a LibTest, but it's a python regression suite. i started a
UITest example, but it is quite basic at the moment. it actually
stores the expected HTML, grabs it using XMLHttpRequest from a server,
then uses GetDOMDocument().body.innerHTML to grab the document text
after each test has been run, and compares the two (ok it's not quite
that simple, won't go into reasons why).

so there's the _beginnings_ of a simple automated regression test
suite available, but the bar is so damn high on these DOM bindings
that actually by the time you can even display the "Hello World"
example you've had to complete about 90% to 95% of the required python
DOM bindings _anyway_!

what i'll do is i'll work out how to install system-wide these
wxWidget python bindings, then i'll create the beginnings of a pyjd
wxwidgets port, and let you know how far it got, ok?

l.

···

On May 24, 11:32 pm, Kevin Ollivier <kevin-li...@theolliviers.com> wrote:

Here's another approach if you want to have full access to the DOM in
every browser via an arbitrary language. It might not be what you want
though.

Basically you create a plugin. The plugin can provide custom javascript
objects written in C++ through ActiveX/NPAPI. There's already a project
out there which does this with like 2 button clicks, it's called
firebreath.

yes - it's a very cool way to do it. this is what the Mozilla
Foundation sponsored ActiveState to do, back in eek, 2000 / 2001, to
the extent where you could do full "script language='python'" it was
that feature-complete. the entire python runtime was added to the
plugin, and an additional plugin created which then "linked" the
python runtime (now in the browser) to the actual DOM (via xpcom).

it was a serious amount of work, and it's bit-rotted. also,
compiling the whole lot up for w32 was, is, and always will be, a
complete f****g nightmare (there is *no* automated build
infrastructure for w32 such as that available for gentoo or debian.
eeverything has to be done "by hand"). the only people with enough
money and time to tackle it recently - i _say_ recently - was Novell,
and even that was for version 1.8.0 of XulRunner.

the other project which does something like this is Titanium (which
uses silverlight). titanium provides .NET bindings, taking advantage
of the fact that the Trident (MSHTML) Engine has a DCOM (aka COM)
interface; it's dead-easy to re-present that via .NET (it's actually
just... automatic), and from there Silverlight hands over access to
Titanium.

in this way, the appcelerator guys even have support for python and
ruby (ok, IronPython and IronRuby).

I've started a proof-of-concept implementation on top of that which allows
you to write javascript objects in any language. The start of it is here: GitHub - Nitrogenycs/firebreath-x: Swig C# and Python bindings for FireBreath. Currently it allows you to
write javascript objects in C# and "normal" python. I chose C# because you
get access to .NET this way. .NET also includes IronPython as well as many
other languages, so room for future investigations there. The interface is
two-way, e.g. you can create wxPython windows from javascript or you can
call javascript from python (e.g. manipulating the dom).

yes - this is how the pywebkitqt4 guys from nokia did it.
unfortunately, if you actually try and use this technique to cover
"full" DOM bindings, it suddenly occurs to you that... wait a
minute... you're creating javascript text code-snippets from python,
whenever you want to access *anything* in the DOM, then... putting
them through a javascript interpreter and execution unit... and
then... translating the javascript basic types *back* into something
that python can handle... including opaque wrappers around javascript
objects??

The basics work pretty well, one part which I didn't finish is the
cross-language polymorphism in the javascript -> C# direction since it
requires dynamic creation of types in C# which is a bit involved (however,
I already know where to borrow the appropriate code from :)).

yes there are several (for python, anyway) - the pyv8 project (which
used libboost), the pywebkitqt4 project (which didn't use libboost),
and so on. problem is: even if you succeed, it's... well, take a look
at the pyjamas pyjd/pywebkitqt4.py source code, you'll soon see why it
was abandoned.

now that *isn't* to say that what you're doing isn't needed - it is.
why? because *once* you have full python DOM bindings, if you *can't*
interact with javascript (by having cross-language polymorphism and
having access to javascript "exec" etc.) then you actually run into
some limitations, most notably that you can't properly control or
interact with NPAPI plugins (such as adobe flash). sure, you can
create a bit of DOM that fires up a .swf plugin inside the Web View,
but you can't pass it any parameters nor can you get back any results
from it. whoops :slight_smile:

so, you're implementing an important bit of the puzzle, ok? :slight_smile:

l.

···

On May 25, 10:42 am, Matthias <nitrogen...@googlemail.com> wrote:

I've started a proof-of-concept implementation on top of that which allows you to write javascript objects in any language. The start of it is here: GitHub - Nitrogenycs/firebreath-x: Swig C# and Python bindings for FireBreath. Currently it allows you to write javascript objects in C# and "normal" python. I chose C# because you get access to .NET this way. .NET also includes IronPython as well as many other languages, so room for future investigations there. The interface is two-way, e.g. you can create wxPython windows from javascript or you can call javascript from python (e.g. manipulating the dom).

yes - this is how the pywebkitqt4 guys from nokia did it.
unfortunately, if you actually try and use this technique to cover
"full" DOM bindings, it suddenly occurs to you that... wait a
minute... you're creating javascript text code-snippets from python,
whenever you want to access *anything* in the DOM, then... putting
them through a javascript interpreter and execution unit... and
then... translating the javascript basic types *back* into something
that python can handle... including opaque wrappers around javascript
objects??

No, the firebreath-x approach doesn't work this way. In python you can do something like "print myJSObj.x". There's a __getattr__ which calls https://developer.mozilla.org/en/NPN_GetProperty (for NPAPI plugins). So no javascript engine or source snippets involved at all. So you can do document.title = 'blabla' in python and it will change the browser's title via a straight call to a C function. Or you can do window.open() which will call NPN_Invoke. So the objects are not opaque, they are live. E.g. you can inspect them just as if you were in a javascript debugger console..

Or you can use dom events like

def onClick(evt):
     evt.target.style.backgroundColor = 'red'

# use attachEvent if plugin runs in IE
document.getElementById('myDiv').addEventListener('click', onClick)

This code executes a bunch of and getproperty/setproperty/invoke C calls which work directly on the involved objects.

You can also go the opposite way

class MyObject(JSObject):
     def __init__(self, message):
         self.message = message

     def __getitem__(self, i):
         return self.message[i]

document.someObject = MyObject('Hello from python')

// ... somewhere in the html ...
<script type="text/javascript">
     // these two lines call directly into python
     alert( document.someObject.message );
     alert( document.someObject[2] );
</script>

The basics work pretty well, one part which I didn't finish is the cross-language polymorphism in the javascript -> C# direction since it requires dynamic creation of types in C# which is a bit involved (however, I already know where to borrow the appropriate code from :)).

yes there are several (for python, anyway) - the pyv8 project (which
used libboost), the pywebkitqt4 project (which didn't use libboost),
and so on. problem is: even if you succeed, it's... well, take a look
at the pyjamas pyjd/pywebkitqt4.py source code, you'll soon see why it
was abandoned.

I've looked at pyjamas before and honestly the basic idea in general doesn't strike me as very good. Why would I want to write javascript code in python? Javascript is an underestimated language imo. Look at http://www.extjs.com for a top notch javascript ui library. It can do a lot of things that wxPython can, in some respects even more (and in some less).

So while python is probably more powerful and gives you more magic, javascript is not all that bad as many people think imo.

Imo usually people want to code the browser (change dom, use canvas etc) in python. To accomplish this task they use the intermediate step of javascript. Which creates a ton of problems obviously. Direct bindings or using plugin objects side-steps all of these issues.

now that *isn't* to say that what you're doing isn't needed - it is.
why? because *once* you have full python DOM bindings, if you *can't*
interact with javascript (by having cross-language polymorphism and
having access to javascript "exec" etc.) then you actually run into
some limitations, most notably that you can't properly control or
interact with NPAPI plugins (such as adobe flash). sure, you can
create a bit of DOM that fires up a .swf plugin inside the Web View,
but you can't pass it any parameters nor can you get back any results
from it. whoops :slight_smile:

You can interact. Whatever the flash dom object exposes, you can access it directly at runtime. You can put stuff into it and you can make flash call your python functions. You can go further. Imagine you create a C#-js object like

     public class MyClass
     {
         public static string color = "red";
     }
     document.csobj = new MyClass();

In actionscript you do:

     ExternalInterface.addCallback("setPlayerColor", setPlayerColor); // exposes function to javascript

In python you do:

     document.getElementById('myflash').setPlayerColor( document.csobj )

So the python code gets the flash dom element, then asks the C#-js object for the color and finally calls actionscript to set the color. You could add more languages into the mix. All or most of this code should work already now with firebreath-x. You can also expose wxPython to any browser with a single line of code :slight_smile:

so, you're implementing an important bit of the puzzle, ok? :slight_smile:

I'm not sure what the puzzle exactly is. With the plugin approach outlined above I can talk to the browser and its dom from any language (python, c#, c++, ...) and I can also interact with javascript and I can interact between all the languages. Not sure what's missing.

-Matthias

···

Am 25.05.2011, 12:16 Uhr, schrieb lkcl <luke.leighton@gmail.com>:

The main thing that I can think of off-hand that would need more work is more code to have methods that return, say, WebDOMElement, get translated to the proper WebDOMElement subclass when the Python object is returned. That could probably be automated as well, but I haven't yet looked at it.

ok, so, as promised, subject changed. first thing: are you _sure_
you want to do this, kevin? it depends on what your goal is. do you
want to get wxWebkit its python DOM bindings _quickly_, or do you want
to use this as an opportunity to learn extensively about webkit and
significantly improve your programming skills? personally, if i'm
given a short-cut route, i don't arse about i take it :slight_smile: that's why
the GNU pythonwebkit bindings are such a mish-mash of what _should_ be
completely incompatible free software projects! so, if the former,
then i can help you to get GNU pythonwebkit into wxWebKit; if the
latter, then i can help advise you on how to do the other types of
HTMLElement and SVGElement objects, but as you'll see it's not for the
faint-hearted :slight_smile:

ok. rright. where to begin. first take a deep breath... :slight_smile:

begin with a description of the problem. the problem is this: objects
that are returned by e.g. the getElementsByTagName or getElementsById
function, or by enumerating e.g. an HTML Table's row/columns, can be
absolutely *any* type of object... but the specification says that the
objects returned are... yep, you guessed it: an HTMLElement.

and that HTMLElement is a *base class*.

in other words, the infrastructure that you're creating *must*
support Object-Orientated capabilities - i forget the exact compsci
term for this: opaque datatypes, some sort of bullshit like that.
example: if you call getElementsById, which you'll see its return type
is HTMLElement, you have to return the HTML "div" element (or whatever
it was) as a python object representing and wrapping that webkit
"HTMLDivElement" object *not* a python object which identifies itself
as an HTMLElement.

now with that in mind, i can describe some of the ways in which this
has been attempted with spectacular "fail" (but only accidentally).

the original code for Webkit is actually KDE's KHTMLPart. this code
has had, for some considerable time, python bindings. KHTMLPart (used
to create Konqueror) was actually fully W3C DOM TR2 compliant. the
python bindings *worked*... but *only* if the entire KHTMLPart source
code was built with c++ "RTTI" checking enabled... (yes you can
probably guess what happened but let me continue)

so, *if* you have the c++ RTTI checking enabled, the python bindings
to KHTMLPart utilised this information to identify the type of c++
WebKit (ok, KHTML) object being returned by each function e.g.
getElementsById, and to return the corresponding and correct type
Python object, but not only that, to return the correct and
corresponding python *object*.

to illustrate: the problem that occurs if you *do not* have c++ RTTI
checking enabled, is that you do something like this:

doc = wv.GetDOMDocument()
div = doc.createElement("div")
doc.body.appendChild(div)
div2 = doc.getElementsByTagName("div")[0]

assert div2 == div # this ***FAILS***

why does it fail??? what the bloody hell's going on?? well, you
probably guessed, but it's worth describing: the object returned from
the getElementsByTagName call is either the correct type of c++ object
but is a *new* type of python object, or is the correct type of c++
object but type-cast down to a c++ HTMLElement, and the python
"wrapper" object is... well, i think i illustrated it clearly enough.

in the Trident Engine, they got sick of this problem and added a non-
W3C-standards-compliant object property called "uniqueID". the reason
for this is that DCOM can work across multiple programming languages,
and even across the Internet. you *can't* do "==" across the
Internet! plus, in COM / DCOM, it's perfectly valid to return a DCOM
object which represents and wraps some remote object which is of "base
class" type, and then to perform some non-automated checking and then
"up-cast" the object to its *real* type. in python-comtypes, this non-
automated checking is so regular and monotonous that it's actually
possible to create a "lazy bindings" python class which performs all
this laborious checking on your behalf, with the end result being
that, although it's a dog's dinner underneath, the python objects that
you end up using are properly, properly representative of the Trident
DOM objects. with the exception of this "==" issue, where you're
forced to do "obj1.uniqueID == obj2.uniqueID" instead. whoops :slight_smile:

anyway, that's the scope of the problem, and you have to solve it by
having and maintaining a Hash Table of *all* python-to-webkitc++
objects. the bindings developers typically use the function
"toWebKit" and "to{BindingsName}" to convert between the two. they
create auto-code-generators which create these "towxPython" functions,
using c++ overloading and make the c++ compiler do all the hard work.
so, the pseudo-code goes like this:

1) before returning the result (e.g. to getElementsByTagName) and
*before* creating a PyObject, perform a lookup (indexed by the c++
object) to see if has ever been created before.

2) if yes, perform a PyObject "incref" but *DO NOT* perform a WebKit c
++ "incref" operation, and return it as the result.

3) if no, *then* you create a new PyObject, hand the Webkit c++
object to it, perform a WebKit c++ "incref" operation *and* a PyObject
"incref" operation, and return it as the result.

the important thing here is that you are relying on the underlying
webkit c++ pointer to be the lookup in the Hash Table, and thus you
are guaranteed to always get - and return - the correct python
object. if you do this, then the above example code will NOT throw an
"assert". the other solution is of course to copy what the Trident
(Internet Explorer) Team did, but that does get you into a bit of
lairy hairy coding, puts a burden onto users, and it's not what any of
the other webkit bindings developers have done.

so.... :slight_smile: with that background in mind (god, it's only
background...) it's possible to move on to doing the different types
of HTMLElement (HTMLTableElement, HTMLDivElement, HTMLButtonElement
etc.)

it's probably best if i describe how this is done in all the other
webkit bindings. what they do is they use a text file, and run it
through a perl program called ... ah yes here it is: Source/WebCore/
dom/make_names.pl. it's a dog's dinner (it's perl), but is extremely
flexible. it's coded basically to be able to create the wrappers you
were talking about, *but*, it's hard-coded to create stuff
*specifically* for the JS bindings (which, btw, have exactly the same
issues to deal with as i've described in excruciating detail, above...
irony).

you can see in make_names.pl that there is even a switch for enabling
Google V8 javascript bindings compatible code instead of webkit
javascript bindings compatible code. the code can also be asked to
auto-generate code for SVG HTML5 objects as well as plain HTML ones.

all of the code created basically is a *massive* switch statement,
which you pass in a webkit c++ object (type-cast to the webkit base
class HTMLElement or for the SVG version obviously typecast to the
webkit base class SVGHTMLElement) and it will go "switch (object-

nodeType)" if nodetype == WEBKIT_HTML_TABLE_TYPE { return

WEBKIT_JS_DOM_HTML_OBJECT(object); } else if .... blah blah

and that switch statement has, in the HTML auto-generated code,
something like 50 entries, and in the SVG case it's something like
120.

i have to say - it should be obvious - *do not* even *remotely*
consider doing this task by hand. adapt make_names.pl or, if you
prefer, adapt make_py_names.pl (which i wrote for the GNU pythonwebkit
- long story, not relevant here).

soooo, you have this whopping-great switch statement, and it creates
basically *one* function: "toJS(WebKitDOMHTMLElement* obj)" ok that'll
have to be "towxPython(WebKitDOMHTMLElement* obj)" and so, as you can
see, when you call that "towxPython" function on the c++ object, in
Stage 3) of the pseudo-code above, c++ *automatically*
DoesTheRightThing (tm) because that e.g. Webkit c++ function
getElementById returned a WebKitDOMHTMLElement, you don't have any
choice in the matter.

right now, the implementation of "towxPython(WebKitDOMHTMLElement*
obj)" is basically "wrap obj, shove it into a SWIG auto-generated
PyObject which tells the world that it's of type
PythonDOMHTMLElement", right? well, that's the code that needs to be
replaced with the above auto-generated code (created by make_names.pl
or equivalent).

_and_ you need to add in the Hash Table lookup, if you haven't
already done so. it's absolutely, absolutely essential that you do
so.

so this is just one of the technical issues that needs to be solved.
there are several others, such as event callbacks *including* Webkit
Timer object callbacks. no you *must* not expect wxWidgets timer
callbacks to work correctly: the webkit timers are designed to
interact correctly with the rest of the code, and they "pause" the
webkit engine in order to avoid race-conditions, whilst the code
inside the timer is being executed. if you do not have the webkit
engine correctly "paused", then all and any webkit timers (from
javascript or any other bindings) and all other operations being
executed will *also* be manipulating the DOM, so you will get race
conditions and, worse, data contention resulting in segfaults; at
best, users will have events that fire off code *simultaneously* as
the code being executed by a wxWidgets timer thread, and that could
lead to a runaway situation. the webkit engine is paused, and the
javascript code single-threaded, for _really_ good reasons.

i'm not "getting ahead" - i'm... just letting you know what you're
letting yourself in for. all these features - full and complete DOM
bindings to *all* Webkit HTML5 features _can_ be done - coded up,
entirely - in about 6-8 weeks (from scratch) but you have the
advantage that some code has already been written, which you may be
able to adapt, and shorten that timescale to about 10-14 days.

... orr, you could skip it entirely, help me add in the GNU
pythonwebkit bindings, which would probably take you about... 30
minutes, if that, to write about... 100 lines of code, if that (and 50
of those would be cut/paste from the pythonwebkit-gtk or pythonwebkit-
dfb ports), and then help me to improve and develop the GNU
pythonwebkit bindings.

two key things are needed in the GNU pythonwebkit bindings:

a) SVG Canvas objects. i did the HTML* objects, but the SVG Canvas
objects would have added an extra 120+ python objects and required
about another week of coding: i couldn't face it :slight_smile:

b) CSS properties as python properties. backgroundColor etc. right
now, these have to be done via the "setProperty" function e.g.
div1.style.setProperty("backgroundColor", "#fffeee") rather than
div1.style.backgroundColor = "#fffeee". *again* these are done in
WebKit via a "make_names.pl" trick (that make_names.pl program is very
obtuse but very flexible) where instead it's handed a list of CSS
properties and a template that outputs JS-equivalent to
property(__get__ fn, __set__ fn) etc.

b) you'll _also_ have to tackle if you decide to continue
implementing python-wxWidgets using the present coding approach (with
SWIG)... :slight_smile:

if i haven't convinced you to consider the GNU pythonwebkit approach
by now, i'm quite happy to give you some more reasons, but i think i'd
best leave it here and see how you react to the above, first!

l.

···

On May 24, 11:32 pm, Kevin Ollivier <kevin-li...@theolliviers.com> wrote:

>> I've started a proof-of-concept implementation on top of that which
>> allows you to write javascript objects in any language. The start of it
>> is here: GitHub - Nitrogenycs/firebreath-x: Swig C# and Python bindings for FireBreath. Currently it
>> allows you to write javascript objects in C# and "normal" python. I
>> chose C# because you get access to .NET this way. .NET also includes
>> IronPython as well as many other languages, so room for future
>> investigations there. The interface is two-way, e.g. you can create
>> wxPython windows from javascript or you can call javascript from python
>> (e.g. manipulating the dom).

> yes - this is how the pywebkitqt4 guys from nokia did it.
> unfortunately, if you actually try and use this technique to cover
> "full" DOM bindings, it suddenly occurs to you that... wait a
> minute... you're creating javascript text code-snippets from python,
> whenever you want to access *anything* in the DOM, then... putting
> them through a javascript interpreter and execution unit... and
> then... translating the javascript basic types *back* into something
> that python can handle... including opaque wrappers around javascript
> objects??

No, the firebreath-x approach doesn't work this way. In python you can do
something like "print myJSObj.x". There's a __getattr__ which calls https://developer.mozilla.org/en/NPN_GetProperty(for NPAPI plugins). So
no javascript engine or source snippets involved at all. So you can do
document.title = 'blabla' in python and it will change the browser's title
via a straight call to a C function. Or you can do window.open() which
will call NPN_Invoke. So the objects are not opaque, they are live. E.g.
you can inspect them just as if you were in a javascript debugger console..

Or you can use dom events like

def onClick(evt):
evt.target.style.backgroundColor = 'red'

ok. now you've got my attention. if you can also confirm for me that
XMLHTTPRequest can also be done, then i'm REALLY interested, and will
do a pyjd engine which makes use of the plugin that you've created.

I've looked at pyjamas before and honestly the basic idea in general
doesn't strike me as very good. Why would I want to write javascript code
in python?

yes - why would _anyone_ want to do that? that would be insane, to
write javascript code in python.

but that's a literal translation of what you've written. let me be
clear: the purpose of the pyjamas project is ****NOT**** to have to
write any javascript, and yet to gain access to the incredible
features available in Web Browser Technology.

let me be clearer: the purpose is to gain access to the incredible
features available in Web Browser Technology ****WITHOUT**** having to
impose onto users the requirement to install a plugin, a package, a
this, a that. just "access this web site", and as a user you don't
even need to know it was written in python, and at the same time, the
developer can "just write code in python", they do not even need to
know that the python is compiled to javascript.

Javascript is an underestimated language imo.

yes - it is. it's incredibly powerful, as evidenced by the fact that
not only can it provide emulation of the entire python language, but
also it's possible to emulate an entire x86 PC... *in javascript* (see
the jslinux project) *and* it's possible to do real-time music, and
much much more... but this is in part due to the fact that its usage
and speed is being extended, *NOT* that the features of the javascript
language - the f***** awful ones - are being fixed. that's just...
not possible.

so, i will be presumptious here and agree that "the uses to which
javascript as executed in web browser environments, through the
javascript bindings to underlying web technology as specified in the
HTML5 standard", are underestimated.

Look at http://www.extjs.com for a top notch javascript ui library. It can do a
lot of things that wxPython can, in some respects even more (and in some
less).

wonderful.... but:

1) it's not python, is it? therefore it is *automatically* discarded
by many, many (sane) developers

2) and, if you've ever seen on comp.lang.javascript what people
_really_ think of extjs, you wouldn't be using extjs as an example.
extjs started out with good intentions, but is gaining a reputation as
being completely insane to consider using. the latest versions are a
whopping 3 MEGABYTE overhead... per page-load! (ok, the latest
versions of pyjs ain't much better, but that's beside the point)

> now that *isn't* to say that what you're doing isn't needed - it is.
> why? because *once* you have full python DOM bindings, if you *can't*
> interact with javascript (by having cross-language polymorphism and
> [...]

You can interact. Whatever the flash dom object exposes, you can access it
directly at runtime. You can put stuff into it and you can make flash call
your python functions. You can go further.

that's why i'm veeery interested in what you've achieved. it sounds
like you've created something incredibly powerful. does it also
extend Trident (MSHTML / Internet Explorer) too? i.e. have you got a
plugin for Internet Explorer as well?

> so, you're implementing an important bit of the puzzle, ok? :slight_smile:

I'm not sure what the puzzle exactly is. With the plugin approach outlined
above I can talk to the browser and its dom from any language (python, c#,
c++, ...) and I can also interact with javascript and I can interact
between all the languages. Not sure what's missing.

nothing - i didn't realise you'd actually got quite as far as you
have. it's pretty stunning. why the bloody hell isn't it more widely
publicised??

l.

···

On May 25, 12:35 pm, Matthias <nitrogen...@googlemail.com> wrote:

Am 25.05.2011, 12:16 Uhr, schrieb lkcl <luke.leigh...@gmail.com>:

ok, i got this _completely_ wrong :slight_smile: you've gone way beyond the
limited "execute javascript snippets" approach.

l.

···

On May 25, 11:16 am, lkcl <luke.leigh...@gmail.com> wrote:

> I've started a proof-of-concept implementation on top of that which allows
> you to write javascript objects in any language. The start of it is here: GitHub - Nitrogenycs/firebreath-x: Swig C# and Python bindings for FireBreath. Currently it allows you to
> write javascript objects in C# and "normal" python. I chose C# because you
> get access to .NET this way. .NET also includes IronPython as well as many
> other languages, so room for future investigations there. The interface is
> two-way, e.g. you can create wxPython windows from javascript or you can
> call javascript from python (e.g. manipulating the dom).

yes - this is how the pywebkitqt4 guys from nokia did it.