On Sun, 27 Mar 2005, Torsten Schoenfeld wrote:
Well, the POD in the XS files is not really standard, but rather an own dialect that is parsed by Glib::GenPod. See `perldoc Glib::GenPod` for more.
Figured that out, so all the POD is done. I got the dom_* signal docs mostly from the DOM specs. The only thing I don't know for sure is what the return value of those signals means. I assume it's similar to `open_uri', where returning true means the signal has already been handled and returning false means to let the default handling continue.
I think it's not going to be easy to test this stuff in an automated fashion.
I just added code to connect all the dom signals in pumzilla. Experimenting with it, it seemed to produce reasonable results. I attached what is probably the final patch for this, unless it needs further refining. Note: I don't in any way _expect_ you to commit the patch. It might be that you find it to be too much complication for the little it gains. (In any case, I've gained experience in XS, XS + C++, and gtk-perl; so I'm thankful for your patience in helping me to understand how this stuff works.) Now that I see what's possible, I'm anxious to add a lot of things. nsIDOMKeyEvent and nsIDOMMouseEvent are both of type nsIDOMUIEvent, which is in turn an nsIDOMEvent. There are methods for finding out more about the event and its targets, for initiating events, adding listeners. And, as you mentioned, nsIWebBrowser has a GetContentDOMWindow method, which returns an nsIDOMWindow, from which you can get an nsIDOMDocument, which has methods like GetElementsByTagName and CreateElement (familiar from javascript). Then combining those two (events and DOM), presumably somebody could implement things like "click on this button" and "select this item". That's what I envisage, at least. Do you think it's beyond the scope of Gtk2::MozEmbed?
Attachment:
gtkmozemb.diff
Description: cvs diff, for Gtk2-MozEmbed 0.04