Beiträge von fran13

danke Ulli, das gibt mir jetzt einen Schub mit xul weiter zu machen. Bleibt jedoch - rückblickend - die Frage, weswegen das Startup-XUL-Tutorial darauf nicht "fingerzeigend" hinweist:

*) Arbeiten mit einem expanded (not jar compressed) "locale"-Verzeichnis (ein code-sample zum download)
*) Abschalten des Cache während der Entwicklung

Ich hab' viel gelesen, doch auf diese beiden Sachen bin ich nirgends gestoßen ... und das ist doch *elementar*, das muss man doch wissen !

Das Rumprobieren (ohne diese zusätzl. Info) ist nervenaufreibend, einige werden frustriert aufgeben, ich konnt' nur am Ball bleiben, weil ich die Sache jeweils auf den nächsten Tag verschoben habe. Und am nächsten Tag hat man schon gar keinen Bock, weil man keinen Plan hat, wo das Problem liegen könnte.

Ein kleines Source-Code-Beispiel mit expand. Verzeichnissen und der erweiterten prefs.js und die Sache wär' erledigt: keine stundenlange Sucherei nach dem wie, wo, was, warum.

Nun gut, ich selbst komm' jetzt weiter ... doch eine Frage noch zu "locale": manchmal finde ich "de", dann finde ich "de-de", dann "de-DE" und auch "de_DE". Was ist jetzt wann richtig und wo kann man das nachlesen. Vielleicht habt ihr da noch ein paar links für mich ... und ich sag schon mal Danke!

Vielen, vielen Dank ! Das war eine echt schwere Geburt ... allerdings begünstigt durch ein paar seltsame Effekte, die nach wie vor bestehen:

wenn ich in meiner "xapp.xul" eine Änderung vornehme (mit notepad++), dann kommt dies beim Ausführen mit xulrunner *nicht* an. Es scheint, als würde der Quelltext der xapp.xul "gecache-d" sein (so dass meine zwischenzeitlich geänderte Source nicht mehr geladen wird).

Was kann ich hier tun?! Folgende Prozedur führe ich nach jeder Änderung meiner xapp.xul durch (damit die geänderte Source verwendet wird):
1) ich benenne meine "xapp.xul" um (damit der xulrunner sie nicht findet)
2) der xulrunner hängt als Prozess im Speicher und ich beende ihn im Task-Manager.
3) ich benenne meine "xapp.xul" wieder in den richtigen Namen zurück

-> der nächste Start mit xulrunner lädt jetzt die mittlerweile geänderte Source

das ist furchtbar umständlich. Es kann doch nicht sein, dass ich der Erste bin, der über solche Hürden stolpert ?!

hab nochmal neu aufgesetzt (xapp), gleicher Fehler wie zuvor. Referenziere ich die DTD falsch ?

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<!DOCTYPE window SYSTEM "chrome://locale/de-de/xapp.dtd">
<window id="xapp" title="xapp" width="300" height="300" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <caption label="Mye World"/>
  <hbox>
    <button id="back" label="&xapp.back;" oncommand="back();" disabled="true"/>
  </hbox>
</window>

Ersetze ich "&xapp.back" durch ein simples label (z.B. "back ... also ohne DTD), dann funktioniert es.
Anderfalls kommt ein Fehler (siehe Dateianhang)

Ja, habs gelesen, rückwärts & vorwärts, senkrecht und diagonal. Wenn ich wenigstens mal wüßte, weswegen Änderungen an meiner <app.xul> nicht wirksam werden, als würde eine <app.xul> gecache-d.

Ich habe bestimmt 20 Stunden damit zugebracht, und bestimmt auch 20 Tutorials gelesen, aber wie und wo man eine DTD (für die sprachänhängigen Labels) ablegt - ob es NUR in einem jar-file geht oder ob man auch mit expandierten Verzeichnissen arbeiten kann ... das find ich bisher nicht ...

ich habe das label xulapp.back aus xulapp.xul

<!DOCTYPE window SYSTEM "chrome://xulapp/locale/xulapp.dtd">


<window id="xulapp" title="My App" width="300" height="300"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <caption label="Hello World"/>
  <hbox>
    <button id="&xulapp.back" label="back" oncommand="back();" disabled="true"/>
  </hbox>	
</window>

in xulapp.dtd definiert:

<!ENTITY xulapp.back    "Back">

es wird aber (beim starten "xulrunner application.ini) nicht gefunden.

Meine Verzeichnisstruktur ist

xulapp
- chrome
- - content
- - - xulapp.xul (file)
- - locale
- - - de-de
- - - - xulapp.dtd (file)

kann mir jemand sagen, was ich wo eintragen muss (-> im chrome.manifest vielleicht ?), damit das label gefunden wird. Ich befinde mich in einer mentalen endlosschleife und komm' nicht mehr weiter ...

Zitat

dass kaum eine ernsthafte Anwendung (z.B. Songbird um einfach mal einen Namen zu nennen), die nicht direkt von Mozilla ist (und darum direkten Zugriff hat), ohne Änderungen am XULRunner auskommt

Ja. Man sollte sich nicht zu früh freuen. Wenn du nähere Info's dazu hast - vielleicht links - dann könnte das vermutlich sehr hilfreich sein (damit ich ein paar Sackgassen auslasse).

(Auch) folgende Sache (https://wiki.mozilla.org/XUL:Installation_Story ) läßt mich nicht nur schmunzeln, sondern auch ein wenig befürchten, was da noch auf mich zukommen wird.

Noch kurz ein statement zu prism: läuft toll, aber nicht perfekt. Die Darstellung ist zu Firefox nicht vollständig identisch. das CSS3 Style -moz-box-shadow wird nicht umgesetzt. Ebenso habe ich einen Darstellungsfehler bei einer custom scrollbar ... also es ist wirklich noch eine Beta.

Zitat

http://de.selfhtml.org/javascript/objek%20...%20#resize_to

wieder was dazu gelernt. THX !

mittlerweile habe ich den Grund gefunden, weswegen prism bei mir nicht lief: ich habe in den meisten Installationen und virtual machines den Windows Scripting host deaktiviert (HKLM, Software, Micrososft, windows scripting host, settings, enabled=0). Auf 1 setzen und prism läuft wie geschmiert. Werd' mich noch näher damit auseinandersetzen.

Allerdings muss ich zugeben, dass mir mittlerweile auch die XULRunner Lösung gefällt (wurde von dir ja ganz zu Anfang dieses Threads vorgeschlagen und später auch von Dr.Evil erwähnt). Mir ist aufgefallen, dass Firefox, Thunderbird, Kompozer und einige weitere bekannte Apps auf dieser - sagen wir - "Laufzeitumgebung" beruhen. Die Syntax ist ungewohnt, aber erlernbar. Wenn so komplexe Apps wie die eben genannten mit XUL erstellt werden, dann sollte sich auch eine 1-Window-Browser-App erstellen lassen (Wozu C++, wenn alles viel einfacher geht ?! . Und wenn ich einmal mehr möchte ... nach oben ist (fast) alles möglich ... bis hin zur Integration einer eigenen XPCOM-Komponente.

Super

ich werde die Sache im Auge behalten und weiter untersuchen. Das ist durchaus eine Alternative zum embedding. Schön wäre es, wenn ich die Größe des "prism"-Fensters bestimmen und fixieren könnte. Vielleicht könntest du mir - als "Frontend-Entwickler" - da noch eine kurze Bemerkung nachschieben (ist vermutlich über Javascript möglich ?)

Danke
fran

bzgl. prism:

habs zum laufen gekriegt bei einem 2er Firefox.
bei ff 3.5.7 und 3.6 definitiv nicht

Keine Chance. Es kommt immer die gleiche Fehlermeldung (siehe Anhang). Habs auch mit dem Firefox Icon versucht.

wenn ich die Prisma app nehme (statt des plugin's) bekomme ich error2.png: ... beschreibt eine inkorrekte Konfiguration. Was gibt es da zu konfigurieren? der download ist ein zip Datei, die man lediglich entpacken kann. Mache ich irgendetwas falsch ?

ich habe beides probiert -> gleiche Fehlermeldung. Aber ich hab' ein paar Virtual Machines mit unterschiedlichen FF Versionen. Dort werd' ich's weiter versuchen.

Hab noch was interessantes gefunden: https://wiki.mozilla.org/Embedding/NewApi

Damit kann man offensichtlich embedden ohne sich in XPCOM einarbeiten zu müssen.

Ausserdem ... beim googeln bin ich auf mehrere Kommentare gestoßen, dass sich webkit nicht in eine MFC-App einbinden läßt. Wer weiß, vielleicht sind diese comments mittlerweile out-of-date (?). All jene Leute haben stattdessen FF/Gecko embedded, notgedrungen wie sie sagen

bugcatcher

Zitat

Theoretisch sollte auch Prism als Portable funktionieren. Ansonsten bringt Prism auch einen Installer mit.

ich probier das mit Prism noch einmal in einem älteren Firefox.

webkit zu embedden sieht recht einfach aus. Das größte Problem dabei wird sein, die umfangreiche Umgebung aus Entwicklungsumgebung (VC++), Patches, ServicePacks, cygwin + Quellcode soaufzusetzen, dass alles läuft. Das kann schmerzhaft werden, wenn Fehler auftreten. I will see ...

Dr. Evil
interessanter Ansatz mit den XULRunner. Das werd' ich mir auch noch genauer ansehen ...

Zitat

Wenn es eine dll sein soll, kenne ich noch diesen Link: http://www.iol.ie/~locka/mozilla/control.htm#download.Die Gecko-Version der vorkompilierten dlls dort ist aber ziemlich veraltet.

richtig. Damit habe ich bisher gearbeit. Ist prinzipiell ne tolle Sache. Ich kann z.B. mit dem IE (embedded) entwickeln und das Programm dann auf den FF patchen. Neueste Techniken (CSS3, HTML5) fliessen dabei aber nicht mehr ein, weil - wie du schon sagst - das ActiveX-Control seit über 3 Jahren nicht mehr gepflegt wird.

Zitat

Faktisch Installiert man damit einen Browser mit einer festen Webseite oder XUL-Anwendung.

Das hört sich aber ähnlich dem an, das ich (umzusetzen) suche. Allerdings stellt sich dabei dann wieder die Frage, wie man das an den Kunden deployed. Wenn man die erzeugte Anwendung kopieren kann, evtl. eine portable app daraus machen kann, dann wäre das womöglich ein interessanter Weg. Aber soweit bin ich noch nicht, es läuft noch nicht (Fehlermeldung:

Zitat

Couldn't convert icon to native format. Default icon will be used.

... und weiter geht der Vorgang nicht.

Mittels XPCOM kann ich eine neue Komponente entwickeln, die Interfaces der Gecko engine nutzt. Fragt sich, ob das überhaupt nötig ist, denn ich brauche WENIGER, als Firefox bietet. Es soll keine url eingegeben werden können (das verwaltet die cloud app intern), also die url-leiste muss weg. Statusbar muss weg (die cloud app wird ihre eigene Statusbar haben). Alle Menu-Möglichkeiten müssen weg (die cloud app hat ihre eigenen menues). Keine Tabs, nur ein einziges Brwoser-Window (in dem die Cloud app läuft). Vielleicht gibt es (einfache) Möglichkeiten, über den XULRunner (wie auch immer) den FF auf das nötigste zu REDUZIEREN! Das wäre wohl die eleganteste Lösung. Wie man das macht, weiß ich allerdings noch nicht. Vielleicht geht das in die Richtung, die du wie folgt beschrieben hast

Zitat

Einfach die nicht benötigten Teile nicht nutzen

Zitat

vielleicht ist Webkit( http://www.webkit.org) etwas für dich

ich muss zugeben, dass ich parallel zu dieser Anfrage auch bei http://www.das-chrome-forum.de die gleiche Frage gestellt habe. Allerdings gibt es dort keinen bugcatcher :wink: , ich habe noch keine Antwort erhalten. Webkit könnte vielleicht auch deshalb interessant(er) sein, weil die zugehörige Javascript engine besonders schnell sein soll.

hi bugcatcher,

deine Hinweise haben sehr geholfen !!! Ich weiß zwar noch nicht, wie man eine XULunner App deployed, aber ich habe mich in XPCOM eingelesen https://developer.mozilla.org/en/Creating_XPCOM_Components und dabei wird vieles klarer.

http://mozillalabs.com/prism/ habe ich ausprobiert, funktioniert leider nicht, liegt vielleicht an einer Unverträglichkeit zwischen der prism-Version/Plugin 1.0b3 und meinem Firefox 3.5.7 - da komm ich noch dahinter.

Danke für deine Geduld & Sachlichkeit !

Grüße
fran

Zitat

Firefox selbst läuft auf Basis des XULRunners. Das ist eine vollwertige Runtime-Umgebung. Firefox selbst ist im Grunde nur eine GUI. Der Browser stellt sich quasi selbst dar.

hm. Das ist nicht leicht zu verstehen (für mich). Wie sieht das Deployment einer XULRunner App aus ? Weist du, wie man das (Firefox GUI) mit einer C++ Container app - also mit einer konkreten exe und dlls - koppelt ?

Zitat

http://mozillalabs.com/prism/

sehr interessant. Werd' ich genauer nachlesen ...

Ja, dort hab' ich mich schon rumgetrieben. Die Inhalte sind aber veraltet und teilweise widersprüchlich:

... zum einen steht dort (in der Nähe)

Roll your own browser - An embedding HowTo

was mich hopefully stimmt, doch dann folgt ...

Warning: This document is out of date. You should instead build XULRunner and use it for all new embedding. You should not need to, and should not, use embedding/config.

Offenbar soll man bei "embedding von gecko" den XULrunner installieren. Das ist eine komplette Laufzeitumgebung, jede Menge Holz, sowas ähnliches wie die Java Runtime, sehr viele Dateien. Das läßt sich künftigen usern meiner apps nicht zumuten (soviel Dateien auf den Rechner zu spielen). Ich bräuchte eine (oder ein paar) Libraries (dlls) mit dokumentierten Schnittstellen, die ich in die C++Container App einbinden und nutzen kann. Komisch das das so schwierig und so schwierig zu finden ist. Trotzdem danke für deinen Rat.

fran

Hi

ich arbeite an einer cloud app die im Browser läuft. Für user, die nicht in einer cloud arbeiten wollen, brauche ich eine native C++ app unter windows mit firefox/gecko-engine als frontend, eingebettet in ein C++ Backend (das die Server-Funktion übernimmt).

Weiss jemand, wie man gecko in eine C++ App einbetten und nutzen kann ?

Arbeitet jemand an solch einer App und würde den Code mit mir teilen, möglicherweise könnten wir die weitere Arbeit daran teilen.

Gibt es eine Doku dazu, wie man gecko in eine Container App einbettet (unter Windows/C++)?

Gibt es eine Beispiel-App oder ein Tutorial dazu ?

Wäre es denkbar, Firefox über plugins/extentions so zu modifizieren/reduzieren, dass nur ein Browserfenster (für die Cloud App) ohne URL-Eingabe-Möglichkeit (wird von der Cloud App über interne links gesteuert ) dabei heraus kommt ?

Grüße
fran

Phantastisch. Da hat einer der Firefox-Entwickler ganze Arbeit geleistet. Es gibt zahllose Programme mit dem Internet Explore ActiveX. Über einen einfachen Patch (IEPatcher) läßt sich das IE-Control mit dem Firefox- bzw. Gecko-ActiveX ersetzen. D.h. über einen einfachen Patch arbeite ich mit der Firefox-Render-Engine ! Endlich W3C-konform !

Die Einzelheiten finden sich unter folgendem link: http://www.iol.ie/~locka/mozilla/control.htm#usingPatcher

Ja. Besten Dank! da gibts wirklich einiges ...

Klasse! Besten Dank für die zügige & nützliche Reaktion. Vielleicht meldet sich noch jemand, der das schon mal gemacht hat. Vielleicht gibt es ein Stück Quellcode dazu ? Wär' prima !