Version: (using KDE 3.5.9) OS: Linux Installed from: Unspecified see http://lists.kde.org/?l=kde-devel&r=1&b=200810&w=2 for details, including a simple and comprehensively explained example that illustrates the problem. the issue is straightforward: it's not enough to return Node* or Element* from any of the function calls, you must return the actual object itself at its proper object c++ class level. so, when you have a c++ object of type HTMLTableElement and you do a getElementById, you must not return an object of type "Node*" you must return an object of type HTMLTableElement* the methodology to do this is explained in the post.
code which implements HashMap in webkit - glib bindings - is here: http://github.com/lkcl/webkit/tree/16401.master/WebCore/bindings/gdom
Hi.. Since we don't have anything to do with the Python bindings, and since I don't know the people behind them, I am somewhat limited in what I can tell you/do to help you. First of all, none of that information on other bindings you helpfully provided is of any particular interest, since they all involve the internal API which we simply cannot export as we can't guarantee binary compatibility for it, and hence the python bindings will not be able to use such techniques. Basically, what the bindings have to do is cast the C++ bindings object to the appropriate type before invoking the method. So if a Node is an Element with XHTML namespace and "img" tagName it can be safely converted to an HTMLImageElement and then its methods can be dispatched. Obviously, string comparisons would be slow and messy, so what I can do is add a typeTag method which will provide a array of enums listing all types that it matches, from most specific to most general (e.g. Tag_HTMLPreElement, Tag_HTMLElement, Tag_Element, Tag_Node, 0). I will do so if the bindings people say that this makes sense and that they will use it.
(In reply to comment #0) > Version: (using KDE 3.5.9) > OS: Linux > Installed from: Unspecified > HTMLImageElement and then its methods can be dispatched. Obviously, string > comparisons would be slow and messy, so what I can do is add a typeTag method > which will provide a array of enums listing all types that it matches, from > most specific to most general (e.g. Tag_HTMLPreElement, Tag_HTMLElement, > Tag_Element, Tag_Node, 0). webkit's JSbindings, ObjectiveC bindings, and now, also, the glib bindings, deploy the technique of "up-casting" based on exactly this: an enum technique. if you take a look at GDOMBindings.cpp and also GDOMHtmlElementWrapperFactory.cpp you will see that quite literally EVERY single object and i do mean every single one is "typecasted" up. the use of convenience functions "isHTMLElementNode()" or "isSVGElementNode()" are also extensively used, to determine which further function should be deployed to further perform yet more and more specific typecasting. but yes, i've seen some code snippets from uses of KHTML::DOM and yes, they're forced to use string comparisons. so, whilst it _may not_ be your immediate concern to deploy the technique of up-casting, the addition of enums and boolean result functions which help determine the objects type _real_ fast would make their lives a great deal easier.
http://www.nabble.com/Re%3A-port-of-pyjamas-to-pykde---khtml---issues-and-observations-with-pykde-tt19971326.html yes an enum is _really_ needed. a vague attempt has been made, in the ruby bindings (see above) and it's woefully incomplete, and non-optimal at best.
... but he's along the right lines [the ruby bindings maintainer[
http://www.mail-archive.com/pyqt@riverbankcomputing.com/msg15197.html for follow-up purposes, for anyone wishing to pursue this. i'll cross-link this bug with a post to the pyqt ml as well.
hi folks, jim bublitz explains clearly what the problem is, in the posts to riverbankcomputing pyqt list. he mentions that someone called simon is now maintaining twine, and it's twine where the problem lies. has anyone made any progress on this issue? l.