Sebastian Lisken wrote:
Hallo. Nachdem Ralf mir die Antwort von Jan weitergeleitet hat, habe ich mich vorübergehend auf eurer Liste angemeldet.
Willkommen!
Das Projekt, um das es geht, ist die nächste Version des PrivacyDongle des FoeBuD (http://www.foebud.org/privacydongle). Der Dongle soll auf Windows, Mac OS X und Linux laufen. Aha.
Das habe ich auch erreicht. Zu meinem Hintergrund: Ich entwickele schon lange Software und habe nach Anfängen in der Schule mit C unter Unix viele Erfahrungen gesammelt, aber nie GUIs programmiert. Seit mehreren Jahren arbeite ich meistens in Java und mit Web-Programmierung, also wieder ohne "von Grund auf" entwickelte GUIs.
Das fragliche Programm ist nur das Startprogramm, gestartet wird ein Firefox mit einem bestimmten Profil, das u.a. Tor enthält. Das Startprogramm soll in der Lage sein, den Firefox und das Tor-Binary zu aktualisieren.
OK
Dafür sind die Dialogboxen da.
Hmmmm
Ich brauche nur zwei ganz grundlegende, das Äquivalent zu alert und confirm in JavaScript - also eine mit Text und OK-Knopf und eine mit zusätzlich einem Cancel-Knopf und der Rückmeldung, welcher Knopf gedrückt wurde.
Vergiss mal grad Dialogboxen, du brauchst allgemein Userinput.
Und das Ganze richtet sich an "unbedarfte" User und soll deshalb Dialoge benutzen, d.h. die xterm-Lösung wäre sehr unschön (obwohl ich auch schon selbst daran gedacht hatte).
Nunja, was spricht wirklich dagegen? Wenn ein User schon Linux hat, warum soll das als Fallback nicht gehen? Erst versuchen das mit GUI zu machen, wenn das nicht geht ein XTerm mit dialog-App starten? Hast du dir mal unter Knoppix die "Helper" aus dem "Startmenu" angesehen (um Wifi einzurichten, Terminalserver, etc.)? Einige sind mit GUI, sorgen aber warsch. dafuer, dass alle Dependencies da sind, einige oeffnen ein Xterm mit Eingaben. Sind die "unbenutzbar" aus User-sicht?
Deshalb trifft die folgende Bemerkung ...
Nein, im Ernst: Entweder das Projekt macht Bunt&Grafik, dann nimm das Toolkit welches das Projekt benutzt, oder lass es. Punkt.
... nicht ganz auf meine Situation zu, würde ich sagen. Ich habe per se kein Toolkit.
Doch, hast du: Ohne Toolkit und X und foo und whatever wird dein Firefox nicht laufen. Es kann sein das auf deinem PrivacyDongle wo der Firefox rumliegt (Ihr bringt ihn mit? Oder kommt er vom Nutzer?) auch die benoetigten Libs rumliegen, oder das versucht wird die vom System zu nutzen. Aber ein X werdet ihr wohl nicht mitbringen? Du hast also schon Abhaengigkeiten. Die sind entweder da, oder du kannst dem User gleich einen Fehler zeigen (der den unbedarften User aus der Bahn werfen wird), das da was fehlt. Unter Unixioden ein Binary-Only zu verteilen ohne ein README.1ST ist ... moeglich, aber egal wie nix fuer unbedarfte. Punkt. Das ist ein Kulturelles Problem. Seit Win und Mac ist es usus so ein Setup.exe oder Programm.dmg zu haben, einmal klicken, nicht nachdenken. Gibt es so ohne "grosse Schmerzen" nicht fuer Unixoide. Moegliche Loesungen grenzen das immer weiter fuer ein Unixoides ein, bis hin fuer eine Distribution, in Binaerpacketen sogar zu einer Version ("Runs with RHEL 4.5"). Das es vielleicht auch wo anders geht ist moeglich, aber nicht garantiert (aka. ueberfordert den unbedarften User), will man sogar nicht ("This is not RHEL, installation aborted"), koennte ja Support bedeuten.
Aber da das ja nicht hip ist: http://www.math.msu.su/~vvb/2course/Borisenko/CppProjects/GWindow/xintro.htm...
Würde das mir zu einigermaßen "hübschen" Boxen verhelfen?
Bei weitem, nein. X kann nur zeichnen, es kennt keine GUI-Elemente. Wir sind da so in der Liga "Zeichne Linie, setze Hintergrund, packe (ungepacktes) Bitmap auf Monitor". Fuer "mehr" sind die Toolkits da, und die koennen "fehlen" (oder einfach nicht dein gewuenschtes da sein). Um keine Abhaengigkeit auf ein Toolkit aufzubauen kann man aber X direkt ansprechen um ein "bischen" was auf den Schirm zu kriegen. Wie schoen das ist kommt halt drauf an wie viel Code man darein investiert. Man schreibt quasi sein eigenes Minimaltoolkit das nur das minimalsten Sachen kann: Fenster oeffnen, Text anzeigen, Knoepfe anzeigen, Knoepfe auswerten. Das ganze gleich in ein Programm gegossen was du von der CLI steuern kannst.
Ich stelle mir vor, daß das Programm auf einem Linux läuft, auf dem auch ein graphischer Web-Browser eingesetzt wird. Aber ich weiß natürlich nicht, was für eine Fensteroberfläche auf dem System installiert ist.
Darum gegen pures X arbeiten, nur _schoen_ ist was anderes. Oder irgendwie mit dem Webbrowser (und seinen Libs) arbeiten, den du ja eh brauchst.
Irgendwas auf den Bildschirm kleistern sollte in 200 Zeilen abgefruehstuckt sein.
Oder du must mal genauer beschreiben, was dieses Projekt machen soll.
Es geht wirklich nur um diese beiden Typen von Dialogen. Zu realisieren als C++-Funktionen void alert(char*) und int confirm(char*).
Als C++? Ah, nein, <Jedi-Power> Du *willst* kein C++ verweden </Jedi-Power> Zumindest nicht fuer binary only.
Ja, er wollte eine Dialogbox. Was erwartest er denn? Windows und OSX schummeln, da ist das ja auch schon alles gestartet.
Laßt uns bitte nicht in eine OS-Diskussion und eine Verteidigungshaltung in Bezug auf die Komplexität der Situation gehen. Ich bin mit Windows und Linux grundsätzlich recht gut vertraut. Es geht nur um die Schwierigkeiten eines Programmierers, diese Dialogboxen herzustellen, ohne Wertung.
Es ist ein Unterschied in der Kultur der Plattformen. Windows und MacX stellen eine Plattform dar, mit vielen APIs oft fuer alle moeglichen und unmoeglichen Anwendungsfaelle. Diese Plattform wird _nicht_ an einem "Runden Tisch" gemacht, und ist meist kaum bis garnicht standartisiert, denoch kann ich sagen: "braucht WinXP" und ich kann lustig WinRPC calls machen, DirectX benutzen, den IE zum HTML rendern einbinden/zum aus dem Web herunter laden benutzen, XML parsen, ODBC Datenbankabfragen machen, OLE Objekte einbinden, die Registry zum speichern meiner Einstellungen benutzen, whatever. Der Umfang wird diktiert, die Optionen sind begrenzt. (Denoch oft schon zu vielfaeltig) Eine Unix Plattform, nun durch POSIX definiert (und standartisiert), gibt es so nicht (mehr). Alle sind POSIX Kompatibel. Und POSIX enthaelt viel (selbst wie sich deine Shell verhaelt, dein make, welche optionen dein Compiler mindestens kennen muss), aber es ist ein Bruchteil dessen, was ein Windows/MacX ausmacht. HTML/XML? Wasn das? HTTP/FTP? Mach dir nen Socket auf! Config? Ja, sowas legen wir unter /etc ab. Wie? Sieh zu. Datenbanken? gehoert BerkleyDB irgendwie zu POSIX? k.a. Es ist das was Unix ausmacht, man kann diese Komponenten waehlen, austauschen wenn sie nicht gehen, oder weglassen wenn man sie nicht braucht, das mag ich, grade auch fuer Serverumgebungen. Denoch vermisse ich manchmal die "Einfachheit" das es "da ist", was dann da ist und es wohl keiner deinstalliert hat wenn man einiges davon brauchen koennte, keiner mekert das man es braucht. Man kann Platformen wie Windows/MacX sogar schnell POSIX beibringen (Ja, es gibt von MS den POSIX-Layer fuer den NT-Kernel, Interix schimpft sich das AFAIK, natuerlich an den wichtigen Stellen schoen inkompatibel gehalten damit eine Portierung eines groesseren Unix-Programms gleich ein rewrite in WIN32 in betracht zieht...) Aber eine "reichhaltige Plattform" aus einem POSIX-Kompatiblem OS zu machen, ist schwer, teilweise auch weil man in der jetzigen Position selten eine Technik "durchdruecken" kann (Ob sie schlecht/gut/lahm/genial/whatever ist, ist egal, Hauptsache sie ist die kanonische Loesung).
Ich habe mir für Windows mingw32 installiert und ein bißchen Code aus dem Netz genommen und war sehr zufrieden, daß ich damit recht "normal" aussehende Boxen mit sehr wenig Aufwand bekam. Mir ist durchaus klar, daß unter Windows soviel einfacher ist.
Klar, ein Aufruf zu MsgBox, bumm Fertig, und das wird immer da sein. (oder jemand hat GDI aus Windows entfernt, nicht unmoeglich (Xbox), aber unwarscheinlich)
Aber ich kann den Overhead von mehreren gestarteten KDE-Prozessen oder beispielsweise einer zu startenden kompletten Java-VM nicht für dieses kleine Startprogramm vertreten.
Tja, willkommen im Club. Ich moechte aus einem Programm gaaaanz selten eine HTTP Anfrage machen. Dafuer dem User curl mit 2 Mb und allen Zusatzlibs (kerberos, ldap) aufs Auge druecken? Oder selber coden und HTTP "nicht richtig" implementieren?
Aus Sicht eines Programmierers ist es wesentlich günstiger, daß das OS auch das Bauen von Dialogen und Fenstern mitdefiniert, das seht ihr hoffentlich auch.
Kommt drauf an ;) Wenn ich es brauche, ja, klar, schaff ran den Kram. Wenn nicht, was soll ich damit? Bloat!!1!elf! Selbst wenn es nur eine Loesung geben wuerde, so gaebe es (hoffentlich dannn immer noch) die Moeglichkeit das sie nicht da ist. "Das Leben ist kein Wunschkonzert" Sicher nicht der "unbedarfte User"-Fall, aber z.B.: 2 von den 5 hier anwesenden Linux-Kisten haben keinen Monitor. Eine hat nicht mal ne GraKa, die andere nutzt ihren Grafikspeicher als swap. So what?
Ich kenne aber auch die Geschichte von Unix und Linux - als ich unter Unix anfing, gab es noch kein X - und verstehe, warum die GUI unter Linux nicht zum eigentlichen OS gehört. Wie gesagt, lassen wir bitte die Wertung raus und konzentrieren uns auf Problemlösungen.
Ich moechte dir das zugrunde liegende Problem aufzeigen, den IMHO ist dein Problem/Wunsch so 100% nicht zu loesen. Ich versuche da keine OS-Diskussion zu starten, denoch komme ich nicht um eine Verteidigungshaltung "herum": - Das Leute dieses Konzept doof finden, weil nichts konsistent ist, alles voellig ueberholt ist, gut, hab ich (fast) kein Problem mit. (Anm.: nicht deine Haltung, nur ein haeufiges gebrachtes Argument) (Einschub: Das deshalb viele grade kleine Projekte/Produkte und Softwerker Linux ablehnen ist schade, und aus der Position des (erheblich) kleineren Markanteils nicht gut, wie angemerkt ich kann manches Argument verstehen, denoch, es ist "am Anfang" erstmal ein mentaler Schritt, vieles stellt sich dann als non-Issue raus.) - Das es sich deshalb trozdem bitte wie ein Windows zu benehmen hat, das geht mir auf den Zwirn. Und ja, dringend dem User eine Dialogbox um die Ohren hauen, weil er ja soooo unbedarft ist, aber bitte ohne zusaetzliche Kosten, ist eben "non-Unix". (Starte dein Linux mal mit "init=/bin/sh", dann weist du was zusaetzliche Kosten sind, aber auch was dir an Funktionen fehlt.) Ich versuchte dir klar zu machen, das du mit dem Kopf durch die Wand willst. Ja, ich weiss selber das unbedarfte User oft "panisch" reagieren wenn der Computer was "von ihnen will" was sie so noch nicht gesehen haben ("So ein komisches Fenster mit BUCHSTABEN!!!!!" "Buchstaben? Aha..."), frag mich nicht genau woran es liegt (Zu technische Texte?), ein Patentrezept hab ich auch nicht. Waer es schoen die Situation zu verbessern? Sicher. Wie? ... Dialogbox ist nett, aber fprintf und scanf tuhn auch. Dass das manchmal die implementierung einer zusaetzlich moeglichen Dialogbox verhindert ("wir haben doch schon was"), tja. Wie gesagt, anzuerkennen das es (vielleicht) keine Dialogbox gibt ist Teil des Weges zur Problemloesung ;)
Kein statisch gelinktes Binary. Vieleicht ein eigenes, das sich mit dem X-Server verbindet fuer ein bischen Fenster anzeigen, aber kein statisch gelinktes.
Das ist für mich immer noch der zentrale Teil dieser Diskussion. Deshalb bitte ich hier um Gründe.
Kompatibilitaet. Das ist ein schwieriges Thema und beide Seiten glauben, sie haben den "Stein der Weisen". Linke ich eine Bibliothek statisch, dann habe ich: - sie immer dabei - in der Version in der ich sie brauche (ABI & API, kompatibilitaet mit mir) Was ich verhindere (verhindern will): - Programm startet wegen fehlender Libs nicht. - Ich bekomme die Lib nicht (in der Version) fuer mein System - Programm macht was komisches nachdem die Lib vom System upgedated wurde. Was ich dazu bekomme: - Fuer Sicherheitsupdates bin ich zustaendig. - Kompatibilitaetsprobleme mit dem Zielsystem. => Ooops. Also loest statisches linken nicht wirklich das Problem. Ich bin deshalb dafuer dem User zu sagen, was er tun soll. Aber ich mute ihm damit wohl zuviel zu.
Andre Landwehr schreibt "klassischer Fall von nicht verstanden" und hat natürlich recht, denn das ist für mich Neuland. Aber ich habe gesehen, daß Qt4 von vielen Cross-OS-Projekten als Grundlage genommen wird und bei einer kurzen Recherche gelesen, daß man damit auch statische Binaries herstellen kann.
Ja, kann. Mal an einem Beispiel: Eagle ist ein binary only Platinen-Layout Program, das es fuer Windows, Mac und Linux gibt. Dank QT kein Ding. Fast. Es benutzt AFAIK in der 4er Version QT 3. Statisch gelinkt: $ ldd /opt/eagle-lin-ger-4.16/bin/eagle linux-gate.so.1 => (0xffffe000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7fc3000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e8c000) libdl.so.2 => /lib/libdl.so.2 (0xb7e88000) libm.so.6 => /lib/libm.so.6 (0xb7e62000) libc.so.6 => /lib/libc.so.6 (0xb7d32000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7d2e000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7d27000) /lib/ld-linux.so.2 (0xb800e000) Dies hat den Vorteil das ausser den Minimalanforung (X11) nichts da sein muss. Es kann auch nicht passieren das ich das "falsche" QT habe. Da zumindest der C++ schmontz statisch gelinkt ist, machen die C++-ABI Aenderungen kein Problem. Und es laeuft nicht mit Compositing, und ich kann auch nichts dran aendern (wie die gefixte und funktionierende QT3 Bibliothek meines Systems dahinlegen, ach wuerde auch nicht gehen, ist ja C++). Tolle Wurst.
Auf dieser Grundlage erscheint mir dieser Lösungsansatz zur Zeit als der interessanteste.
Denoch bedarf es dabei "viel Uebung". Was linkt man rein, was nicht, wie erreicht man das am besten mit welchen Linkoptionen. Man will z.B. libXwhatever nicht statisch einlinken, damit man hier das richtige Interface zum X-Server hat. Man will die libc nicht statisch einlinken und auf einem moeglichst alten (aber nicht zu altem ;) System kompilieren etc.
Unter Unix kannst du nur von der libc&POSIX ausgehen. Alles andere ist Optional, ergo muss man dem Benutzer komunizieren, was da sein muss, oder eben die Packetverwaltung benutzen. Darum will man die ja haben/benutzen.
Wie gesagt, es geht hier um ein kleines "Anhängsel" (ein vorgeschaltetes) für einen Start von Firefox,
Und wenn es in C++ geschrieben ist wird es statisch ein riesen Teil. Ausserdem musst du aufpassen das ALLE C++-Teile enthalten sind, es darf nichts mehr die System libstdc++ ziehen.
dafür kann ich dem Nutzer auf keinen Fall abverlangen, daß er Dependencies überprüft und seine Paketverwaltung anwirft.
Tja, du wirst nicht drumrum kommen...
Eine Frage zum Verständnis: wie schafft es eigentlich Firefox, daß es als .tar.bz2 heruntergeladen, ausgepackt und gestartet werden kann? Ich weiß, daß die Distributoren ihre eigenen Versionen anbieten, die man über die Paketverwaltung installiert, aber die auf der Firefox-Seite angebotenen Versionen funktionieren wahrscheinlich auch auf sehr vielen Linux-Installationen?
Es ist auch teils statisch gelinkt, das macht es schoen gross (10Mb firefox-bin alleine fuer 2.0.0.18). Weiterhin starten die nicht das Binary, sondern ein Skript, das vorher den LD_LIBRARY_PATH auf das Verzeichniss setzt, wo man es hininstalliert hat (fuer die mitgelieferten eigenen Bibliotheken), und dann braucht es eben auch noch Systembibliotheken: /var/tmp/firefox $ LD_LIBRARY_PATH=. ldd firefox-bin linux-gate.so.1 => (0xffffe000) ^^^^^^^^^----- System libmozjs.so => ./libmozjs.so (0xb7f2f000) libxpcom.so => ./libxpcom.so (0xb7f2c000) libxpcom_core.so => ./libxpcom_core.so (0xb7e81000) libplds4.so => ./libplds4.so (0xb7e7e000) libplc4.so => ./libplc4.so (0xb7e7a000) libnspr4.so => ./libnspr4.so (0xb7e4c000) ^^^^^^^^^^---- bringt es mit libpthread.so.0 => /lib/libpthread.so.0 (0xb7dff000) libdl.so.2 => /lib/libdl.so.2 (0xb7dfb000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7a97000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7a13000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb79f3000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb79db000) libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0xb79d2000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0xb79c4000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb797a000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7939000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7933000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7844000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb770d000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7708000) libm.so.6 => /lib/libm.so.6 (0xb76e2000) ^^^^^^^^^^----- vom System libsmime3.so => ./libsmime3.so (0xb76c1000) libssl3.so => ./libssl3.so (0xb769a000) libnss3.so => ./libnss3.so (0xb7631000) ^^^^^^^^^^---- bringt es mit libsoftokn3.so => ./libsoftokn3.so (0xb75e5000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb75da000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb75a4000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb74db000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb7472000) libXft.so.2 => /usr/lib/libXft.so.2 (0xb7452000) ^^^^^^^^^^----- vom System libxpcom_compat.so => ./libxpcom_compat.so (0xb743b000) ^^^^^^^^^^---- bringt es mit libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0xb737b000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 (0xb736c000) libc.so.6 => /lib/libc.so.6 (0xb723c000) /lib/ld-linux.so.2 (0xb7fcb000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7230000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb722c000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7229000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7223000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb717b000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7167000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7163000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb7159000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7151000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7143000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb70f8000) libz.so.1 => /lib/libz.so.1 (0xb70e0000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb70dc000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb70d5000) librt.so.1 => /lib/librt.so.1 (0xb70cc000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb709f000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb7094000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb7075000) libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7004000) libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb6ffd000) libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb6feb000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6fbe000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6f74000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb6df2000) ^^^^^^^^^^----- vom System ... denn zum glueck hab ich noch die alte C++ lib /var/tmp/firefox $ objdump -j .comment -s firefox-bin | head firefox-bin: file format elf32-i386 Contents of section .comment: 00000 00474343 3a202847 4e552920 332e322e .GCC: (GNU) 3.2. 00010 33203230 30333035 30322028 52656420 3 20030502 (Red 00020 48617420 4c696e75 7820332e 322e332d Hat Linux 3.2.3- 00030 35342900 00474343 3a202847 4e552920 54)..GCC: (GNU) 00040 332e322e 33203230 30333035 30322028 3.2.3 20030502 ( 00050 52656420 48617420 4c696e75 7820332e Red Hat Linux 3. Jetzt kann man nur hoffen, das keine von den gezogenen Systemlibs C++ ist, sonst knallts. Wie gesagt, die kunst ist, das "richtige" statisch zu linken, dann andere Bibliotheken dazu zu legen die man durch umbiegen des LD_LIBRARY_PATH bevorzugt und "sinnvolles" eben einfach als vorhanden voraussetzt. Und hier kommen wir dann in der Realitaet an. Wenn ein unbedarfter User keine X-Libs hat, dann ist irgendwas maechtig schief gegangen. Einem erfahrenem User helfen dann eher (die System-) Fehlermeldungen, ja, am besten als Text. Eine Popupbox mit einen "GTK-Libs nicht gefunden" hilft _mir_ nicht, besonders wenn der richtige Fehler, um den unbedarten User nicht zu erschrecken ("Ich mag Linux nicht, da sind beim starten immer so viele Fehlermeldungen auf dem Bildschirm" ...), nach /dev/null umgeleitet wird. Der unbedarfte User wird sich aber nicht mit den Feinheiten der libstdc++ rumschlagen wollen -> schon eher ein Problem. Und wie man das Problem loest, das gtk nicht da ist auf einem KDE-only System, tja, das weiss ich auch nicht. Das readme schickt einen auf die Runterlad-Seite, dort gibt es auch kein "requirements" oder sowas, sondern nur irgendwo in der Wissensdatenbank (Die nebenbei einen als erstes erklaert wie man Firefox besser ueber die Packetverwaltung installiert ^^). Jupp, sieht so aus, das Gtk da sein muss: Firefox wird ohne die folgenden Bibliotheken oder Pakete nicht ausführbar sein: * GTK+ 2.10 oder höher * GLib 2.12 oder höher * Pango 1.14 oder höher * X.Org 1.0 oder höher Da kann man nur davon ausgehen das selbst ein KDE-System einen Distributions-Firefox hat und deshalb die libs doch rumliegen. Man kann es einfach nicht auf jedem System zum laufen bringen, so das man vielleicht als minimum sowas wie "Fedora 5 o.ae." angeben muss. Und als konkrete Loesung: Legt deine eigene version von xdialog mit auf den Stick. Das Programm nutzt auch gtk, das muss also eh da sein. So gibts es auch schoene Boxen. Wenn sich xdialog nicht starten laesst, versuch, irgendwie einen puren Informationstext ueber den Fehler dem User naeher zu bringen (Es gab problem foo: ... Versuchen sie dies, das, jenes), irgendwas wird ja auf dem System sein (konqueror, links/lynx im xterm, groff mit xviewer, xterm mit printf, was einem noch so einfaellt). Wenn das alles faehlschlaegt, hat der unbedarfte User Pech (wie kommt er zu so einem System), andere werden sich dann mal den Output in der Shell ansehen.
Ich bin auch nur an solchen Installationen interessiert, weil ich eben so einen heruntergeladenen Firefox verwende.
Auf neueren Systemen wirst du damit "spass" haben (fehlende v5 C++-lib)
Danke schonmal
Sebastian
Gruss Jan -- Neulich bei Siemens: "Hast du die Maschinen geschmiert?" - "Und wenn, würde ich es nicht zugeben."