Ich habe noch etwas neues entdeckt (hoffe, ihr seid nicht genervt vom Dreifachpost... ;P). Und zwar gibt es Webkit auch für Gtk (was der ein oder andere sicher schon wusste). Nun habe ich allerdings entdeckt, dass jemand `jswebkit` entwickelt hat. Das ist offenbar ein Wrapper für Webkits JavaScript-Engine und allein das was in der `testwebkit.py` gemacht wird (Zugriff auf den DOM-Tree via `getElementsByTagName()`, Abschicken einer Suchanfrage in Google durch Ausfüllen von `form`) sieht IMHO höchst vielversprechend aus und erinnert auch schon sehr an die API von `mechanize`. Mal sehen, vielleicht probiere ich mich in den nächsten Tagen mal an einer Implementierung hinsichtlich Links besuchen, Dinge anklicken usw...
Achso, hier der Issue wo es auch das Archiv gibt (letzter Eintrag).
Qt: Kompletten Quelltext von Webkit bekommen
Vllt. ist den Leuten von mechanize ja an einer Komplettrevision im Hinblick auf mögliche JS-Features gelegen. Du könntest die ja mal kontaktieren, oder halt selbst die Sache in die Hand nehmen 
Allerdings ändern sich die Anforderungen an ein so aufgebortes mechanize grundlegend, ich sag nur Gtk/Qt + Webkit, GUI-Zugriffsmöglichkeit und JS-Engine, von evtl. Portierungsschwierigkeiten mit den erweiteren Abhängigkeiten ganz zu schweigen. Ein Browsertoolkit in einer Sprache vorzuhalten ist eben ein "bisschen" mehr als das, was mechanize derzeit kann.
Allerdings ändern sich die Anforderungen an ein so aufgebortes mechanize grundlegend, ich sag nur Gtk/Qt + Webkit, GUI-Zugriffsmöglichkeit und JS-Engine, von evtl. Portierungsschwierigkeiten mit den erweiteren Abhängigkeiten ganz zu schweigen. Ein Browsertoolkit in einer Sprache vorzuhalten ist eben ein "bisschen" mehr als das, was mechanize derzeit kann.
Ich werde das bisher erreichte (siehe `Codesnippets`) erstmal auf Qt portieren, da mir die Gtk-Version zu fehleranfällig ist und ich jetzt herausgefunden habe, wie ich dort die JS-Engine ansprechen (also Code direkt ausführen lassen) kann. Allerdings muss ich mir da erstmal einen Wrapper für schreiben (ist in der Mache, gibt ja auch einen entsprechenden Thread).
Das ganze werde ich nach und nach erweitern bis es in etwa mechanize-Niveau erreicht hat und die grundsätzliche Struktur somit steht. Bei meinem Arbeitstempo ist bis dahin vielleicht schon Qt 4.6 erschienen (*lölz*) und man kann das Programm dann auf die versprochene DOM-API von Qt umstellen (mal sehen wie der gute phil von PyQt da Schritt hält).
Am schönsten wäre es natürlich, wenn die Webkit-API bald dokumentiert würde. Aber selbst dann dauert es sicher eine ganze Weile bis jemand entsprechende Python-Bindings geschrieben hat (diese Aufgabe ist mir persönlich zu hoch).
Was natürlich der große Vorteil an einem Toolkit als Abhängigkeit ist. Man kann bestimmte Befehle ausprobieren und sich dann bspw. mittels `show()` den Stand der Dinge als Fenster anzeigen lassen (z.B. das dieses und jenes Feld nun ausgefüllt wurden und man auf der korrekten Folgeseite ist - oder eben auch nicht). Umgekehrt ließe sich *vielleicht* auch verfolgen, welche Schritte im Browserfenster gemacht wurden und man erhält entsprechenden Python-Code. Das wäre ja schon irgendwie ganz ... cool.
Das ganze werde ich nach und nach erweitern bis es in etwa mechanize-Niveau erreicht hat und die grundsätzliche Struktur somit steht. Bei meinem Arbeitstempo ist bis dahin vielleicht schon Qt 4.6 erschienen (*lölz*) und man kann das Programm dann auf die versprochene DOM-API von Qt umstellen (mal sehen wie der gute phil von PyQt da Schritt hält).
Am schönsten wäre es natürlich, wenn die Webkit-API bald dokumentiert würde. Aber selbst dann dauert es sicher eine ganze Weile bis jemand entsprechende Python-Bindings geschrieben hat (diese Aufgabe ist mir persönlich zu hoch).
Was natürlich der große Vorteil an einem Toolkit als Abhängigkeit ist. Man kann bestimmte Befehle ausprobieren und sich dann bspw. mittels `show()` den Stand der Dinge als Fenster anzeigen lassen (z.B. das dieses und jenes Feld nun ausgefüllt wurden und man auf der korrekten Folgeseite ist - oder eben auch nicht). Umgekehrt ließe sich *vielleicht* auch verfolgen, welche Schritte im Browserfenster gemacht wurden und man erhält entsprechenden Python-Code. Das wäre ja schon irgendwie ganz ... cool.
Eine Runde "Wünsch Dir was":
mechanize abwärtskompatibel, eleganter DOM-Zugriff, volle JS-Unterstützung, Konsolen-/Guimodus, Makrorecorder: in Gui-Fenster-Modus Makro browsend aufzeichen, Makrosprache - Python (was sonst), Konsolenmodus: Abspielen der Makros, komplette curl-Unterstützung, HTML-Editor, lxml-binding, Seitenindizierung, Spielekonsole, google nachbauen, Zeitreisen, Weltherrschaft
Hab ich was vergessen?
Spaß beiseite, ich habe absolut keine Ahnung, wie brauchbar das WebKit-Gtk-Binding ist oder dessen JS-Unterstützung. Mit QWebKit habe ich bisher recht gute Erfahrungen gemacht, auch wenn es etwas unpythonisch daher kommt. Und da sich die WebKit-Leute über eine Roadmap ausschweigen, würde ich eben zur Qt-Lösung tendieren.
Wie wärs, das ganze als Projekt aufzuziehen, vllt. findest Du hierfür Mitstreiter im Forum bzw. unter den mechanize-Leuten. So wäre auch eine halbwegs sichere Platzierung in das Biotop mechanize-webkit-pyqt-python möglich.
mechanize abwärtskompatibel, eleganter DOM-Zugriff, volle JS-Unterstützung, Konsolen-/Guimodus, Makrorecorder: in Gui-Fenster-Modus Makro browsend aufzeichen, Makrosprache - Python (was sonst), Konsolenmodus: Abspielen der Makros, komplette curl-Unterstützung, HTML-Editor, lxml-binding, Seitenindizierung, Spielekonsole, google nachbauen, Zeitreisen, Weltherrschaft
Hab ich was vergessen?
Spaß beiseite, ich habe absolut keine Ahnung, wie brauchbar das WebKit-Gtk-Binding ist oder dessen JS-Unterstützung. Mit QWebKit habe ich bisher recht gute Erfahrungen gemacht, auch wenn es etwas unpythonisch daher kommt. Und da sich die WebKit-Leute über eine Roadmap ausschweigen, würde ich eben zur Qt-Lösung tendieren.
Wie wärs, das ganze als Projekt aufzuziehen, vllt. findest Du hierfür Mitstreiter im Forum bzw. unter den mechanize-Leuten. So wäre auch eine halbwegs sichere Platzierung in das Biotop mechanize-webkit-pyqt-python möglich.
Bin heute auf OWB gestoßen. Dazu das englische Wikipedia im Artikel zu WebKit:
Das klang vielversprechend und tatsächlich finde ich die API einigermaßen verständlich, zumal auch ein bißchen Doku dabei ist.
Ich kompiliere es gerade noch und werde dann mal versuchen, ob ich durch diese Methode den richtigen Einstiegspunkt für mein Vorhaben finde.
Langfristig ist das hoffentlich auch eine gute Basis, um die Abläufe in WebKit selbst besser zu verstehen.
<Quelle>There is also a project synchronized with WebKit (sponsored by Pleyo) called Origyn Web Browser, which provides a meta-port to an abstract platform with the aim of making porting to embedded or lightweight systems quicker and easier.
Das klang vielversprechend und tatsächlich finde ich die API einigermaßen verständlich, zumal auch ein bißchen Doku dabei ist.
Ich kompiliere es gerade noch und werde dann mal versuchen, ob ich durch diese Methode den richtigen Einstiegspunkt für mein Vorhaben finde.
Langfristig ist das hoffentlich auch eine gute Basis, um die Abläufe in WebKit selbst besser zu verstehen.