Anzeige:
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 29

Thema: Stdout von Programm in QString lesen geht (fast) (ohne QProcess)

  1. #1
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719

    Stdout von Programm in QString lesen geht (fast) (ohne QProcess)

    Weil mir das zu dumm war, immer mit QProcess was zu basteln, nur im den Output von einem Befehl zu bekommen, hab ich mal eine Funktion gebaut, die das alles ohne QProcess macht. Es geht noch nicht 100%ig, es werden nach dem Pfad von KDE (Beispiel) immer noch andere Zeichen angezegt. Außerdem ist der Output auf 4 kb beschränkt
    Code:
    #include <qapplication.h>
    #include <qlineedit.h>
    #include <qstring.h>
    
    #include <stdio.h>
    #include <unistd.h>
    
    #include <sys/wait.h>
    #include <sys/types.h>
    
    #define MAXL 4096
    
    #define ERROR -1
    
    QString getProcOutput(QString path, QString arg0, QString arg1)
    {
     int fd[2];
     pid_t pid;
     FILE* pipe_reader;
     char buffer[MAXL];
    
     if(pipe(fd) == ERROR)
       return QString();
    
     if((pid=fork()) == ERROR)
       return QString();
    
     switch(pid)
     {
      case -1:
       return QString();
      break;
      case 0:
       close(fd[0]);
           if(fd[1] != STDOUT_FILENO)
           {
             if(dup2(fd[1], STDOUT_FILENO) != STDOUT_FILENO)
               return QString();
             close(fd[1]);
           }
         if(execl(path.latin1(), arg0.latin1(), arg1.latin1(), NULL) == ERROR)
       return QString();
      break;
      default:
       sleep(1);
       close(fd[1]);
    
         if((pipe_reader = fdopen(fd[0], "r")) == NULL)
           return QString();
    
         fread(&buffer, MAXL, 1, pipe_reader);
    
         fclose(pipe_reader);
    
        printf("path = %s", buffer);
    
        if(waitpid(pid,NULL,0) == ERROR)
          return QString();
      break;
     }
    
     return QString(buffer);
    }
    
    int main(int argc, char** argv)
    {
     QApplication app(argc, argv);
     QLineEdit edit(0);
     app.setMainWidget(&edit);
     edit.show();
     edit.setText(getProcOutput("/usr/bin/kde-config", "kde-config", "--prefix"));
     return app.exec();
    }

  2. #2
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Wo liegt er Vorteil von selber fork'en außer das es den Nachteil hat dass es weniger portabel wird und mehr Aufwand ist?

    Ciao,
    _

    PS: bei Objekten als Funktionsparameter immer const Class& statt call by value.
    PPS: Pfade mit QFile::encodeName in lokale Repräsentation umwandeln, es ist nicht sicher das Pfade latin1 kodiert sind.
    Qt/KDE Entwickler
    Debian Benutzer

  3. #3
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Ich sehe den Vorteil darin, das man sich "mal eben schnell" den Output von einem Programm holen kann, und zwar mit einer Funktion. Wollte ich den Installationspfad von KDE mit den Bordmitteln von Qt bestimmen, müsste ich einen QProcess starten und einen Slot, in dem Ich den Output sammle. Dann müsste ich noch eine Vorrichtung einbauen, die wartet, bis der Prozess fertig ist. Ich hoffe diesen Aufwand mit meiner Funktion erschlagen zu können.

  4. #4
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Abgesehen davon, dass ich es nicht für eine sehr gute Idee halte, in einer GUI Applikation blocking I/O zu benutzen, wäre der Weg über popen() wahrscheinlich einfacher als über fork() und exec().

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  5. #5
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Sag mir, wie das geht, und ich mach das. Ich hab mir das mit fork usw, auch nicht selber ausgedacht. Das kommt mit Copy&Paste von Pronix.de. Wenn du eine bessereLösung hast, immer her damit. Das mit IO-Blocking ist im Prinzip richtig, ich wollte die Funktion aber eher in der Initalisierungsphase des Programms verwenden. Auf jden Fall finde ich QProcess zu umständlich, wenn ich mal eben kde-config --prefix in einer Variablen speichern möchte.

  6. #6
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Wenn du eine bessereLösung hast, immer her damit.
    Wie gesagt, popen sieht aus als wäre es genau dafür gedacht.


    Das mit IO-Blocking ist im Prinzip richtig, ich wollte die Funktion aber eher in der Initalisierungsphase des Programms verwenden.
    Ist dann doch umso schlimmer wenn es blockiert, weil dann der Start verzügert wird, oder?


    Auf jden Fall finde ich QProcess zu umständlich, wenn ich mal eben kde-config --prefix in einer Variablen speichern möchte.
    Naja, so kompliziert ist das auch wieder nicht
    Starten, einen Slot auf processExited connecten und dort mit readLineStdout lesen.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  7. #7
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Original geschrieben von anda_skoa
    Wie gesagt, popen sieht aus als wäre es genau dafür gedacht.
    Ich werd's ausprobieren
    Original geschrieben von anda_skoa

    Ist dann doch umso schlimmer wenn es blockiert, weil dann der Start verzügert wird, oder?
    Das bißchen Zeitverzögerung halte ich für lächerlich im Vergleich zum Overhead, bis alle KDE-Libs geladen sind.
    Original geschrieben von anda_skoa

    Naja, so kompliziert ist das auch wieder nicht
    Starten, einen Slot auf processExited connecten und dort mit readLineStdout lesen.
    Stimmt, so kann man es machen. Ich hab immer readyReadStdOut verwendet, alles in einen Buffer gelesen, usw. mit processExited ist es schon einfacher, aber mit einer Funktion glaub ich, kann ich das noch kompakter machen.

  8. #8
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Das bißchen Zeitverzögerung halte ich für lächerlich im Vergleich zum Overhead, bis alle KDE-Libs geladen sind.
    Da komm ich nicht mit.
    Wieso sollte ein Qt Programm KDE Libs laden?


    Stimmt, so kann man es machen. Ich hab immer readyReadStdOut verwendet, alles in einen Buffer gelesen, usw. mit processExited ist es schon einfacher, aber mit einer Funktion glaub ich, kann ich das noch kompakter machen.
    Soviel kompakter als ein Slot mit einer Zeile Code ist das auch wieder nicht

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  9. #9
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Original geschrieben von anda_skoa
    Da komm ich nicht mit.
    Wieso sollte ein Qt Programm KDE Libs laden?
    Weil man sonst Schelte von KDE-Nutzern bekommt, weil Keramik angeblich nicht gescheit angezeigt wird. Ich denke mal, es dauert auch länger, bis ein winziges Qt-Programm geladen ist, im Gegensatz zur Ausführung von kde-config


    Original geschrieben von anda_skoa

    Soviel kompakter als ein Slot mit einer Zeile Code ist das auch wieder nicht
    Folgendes Problem: Ich habe eine XML-Datei, in der Pfade stehen. Diese Datei wird von einem Parser gelesen. Die Pfade können sowas wie ${prefix} enthalten. Da ist eine Funktion, die mir den Output gibt, einfacher, einen Prozess zu starten und auf ein Signal zu warten.

  10. #10
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    Weil man sonst Schelte von KDE-Nutzern bekommt, weil Keramik angeblich nicht gescheit angezeigt wird.
    Keramik ist doch ein WidgetStyle, oder?
    Wozu brauchst du dann kde-config?
    Der WidgetStyle wird von qtconfig festgelegt, bzw von KDE.


    Ich denke mal, es dauert auch länger, bis ein winziges Qt-Programm geladen ist, im Gegensatz zur Ausführung von kde-config
    Ist es dann nicht um so schlechter, wenn die Startuptime der Applikation von einem externen Programmaufruf verzögert wird, wenn der Aufruf mehr Zeit braucht als die App eigentlich alleine bräuchte?


    Folgendes Problem: Ich habe eine XML-Datei, in der Pfade stehen. Diese Datei wird von einem Parser gelesen. Die Pfade können sowas wie ${prefix} enthalten. Da ist eine Funktion, die mir den Output gibt, einfacher, einen Prozess zu starten und auf ein Signal zu warten.
    Dann stell dir mal vor, du hast mehrere solcher Einträge und für jeden musst du ein Programm ausführen.
    Wenn du das dann blocking machen würdest, bräuchtest du einen Childprozess und einen Fortschrittsbalken.

    Oder geduldige User

    kde-config wirst du wahrscheinlich eh nur einmal beim ersten Programmstart ausführen, könnte man also eventuell auch in eine Art Setup Programm auslagern.
    Danach kann man den Pfad dann aus einer Configdatei lesen.

    Für was brauchst du den Pfad eigentlich?
    Icons?

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  11. #11
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    So, popen geht, danke für den Tipp.

    Original geschrieben von anda_skoa
    Keramik ist doch ein WidgetStyle, oder?
    Wozu brauchst du dann kde-config?
    Der WidgetStyle wird von qtconfig festgelegt, bzw von KDE.
    Ja, Keramik ist ein Widgetstyle. Ich würde gerne Qt-Only programmieren, leider muss ich schon KApplication verwenden, wenn ich nur einen kleinen DirChooser aus KDE brauche. Wenn ich den normalen Qt-Filechooser nehmen würde, bekäme ich einen normalen Fileselector, und nicht den von mir gewünschten TreeView. Angeblich werden Teile von Keramik nicht gescheit angezeigt, wenn man QToolbar und QMenuBar anstatt den KDE-Pendants nimmt.

    Original geschrieben von anda_skoa
    Ist es dann nicht um so schlechter, wenn die Startuptime der Applikation von einem externen Programmaufruf verzögert wird, wenn der Aufruf mehr Zeit braucht als die App eigentlich alleine bräuchte?
    Ich meine, das bißchen fällt nicht ins Gewicht, verglichen mit dem Overhead einer Qt-Application. Elegant finde ich das auch nicht, das man ein Programms starten muss, um einen Pfad zu bekommen.


    Dann stell dir mal vor, du hast mehrere solcher Einträge und für jeden musst du ein Programm ausführen.
    Wenn du das dann blocking machen würdest, bräuchtest du einen Childprozess und einen Fortschrittsbalken.
    Das wollte ich schon cachen.

    Oder geduldige User
    Das es KDE-Nutzer sind, sind sie geduldig *Seitenhieb*

    kde-config wirst du wahrscheinlich eh nur einmal beim ersten Programmstart ausführen, könnte man also eventuell auch in eine Art Setup Programm auslagern.
    Danach kann man den Pfad dann aus einer Configdatei lesen.
    Für was brauchst du den Pfad eigentlich?
    Icons?
    Das es eine Klasse gibt, um Icons zu laden ist mir bekannt. Ich will einen self-extracting InstallWizard bauen. Damit mache ich mir in bestimmten Gruppen von Linuxnutzern keine Freunde, das ist mir klar, aber irgendwie gefällt mir das nicht, das selbst Autoconf-Packages zwischen Mandrake und SuSE nicht kompatibel zu sein scheinen. Ich würde halt gerne meinen Installer dazu bringen, das er gleich ins richtige Verzeichnis installiert. Auch so Sachen wie xmms-config --cflags möchte ich abfragen können. Das ein Benutzer zwischendrinn mal warten muss, halte ich für vertretbar, das ist ja bei RPM auch angesagt, nach dem alle Dateien kopiert wurden. Ich beabsichtige sogar, die Sourcen und die Binary in einem Paket anzubieten, und bei Bedarf die Binary während des Setups neu erstellen lassen zu können. Der zusätzliche Platz scheint mir vertretbar, wenn man daran denkt, das mein Installer im Moment 34kb Overhead im Gegensatz zu > 1MB bei Autoconf ist. Mir stellt sich selbstverständlich die Frage, warum KDE-Programme, die im Source angeboten werden, in der Regel unter Mandrake nicht richtig funktionieren, weil Mandrake KDE in /usr installiert. Theoretisch sollte es doch kein Problem sein, den entsprechenden Pfad im configure-skript mittels KDE-Config herauszufinden?

    Ich kann gerne mal einen Prototyp meines Installers hier posten, bisher kann er aber noch nicht viel installieren. Bisher geht auspacken, Wizard anzeigen, Config-XML einlesen.
    Geändert von axeljaeger (19-09-2003 um 17:45 Uhr)

  12. #12
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    So, popen geht, danke für den Tipp.
    Könntest du den Codeabschnitt posten? Würde mich interessieren


    Ja, Keramik ist ein Widgetstyle. Ich würde gerne Qt-Only programmieren, leider muss ich schon KApplication verwenden, wenn ich nur einen kleinen DirChooser aus KDE brauche.
    Das ist halt eine Kompromissfrage. Entweder zu Qt/Win und Qt/Mac kompatibel bleiben, oder KDE Funktionlität benutzen können
    Das ist leider der Nachteil bei Crossplatform Programming, man kann nicht die coolen Features einer Plattform verwenden.


    Wenn ich den normalen Qt-Filechooser nehmen würde, bekäme ich einen normalen Fileselector, und nicht den von mir gewünschten TreeView.
    Nunja, für einen Installer wird das ja wohl reichen, oder?


    Angeblich werden Teile von Keramik nicht gescheit angezeigt, wenn man QToolbar und QMenuBar anstatt den KDE-Pendants nimmt.
    Hört sich nach einem Bug im Style an. Ich würde entsprechende Userreports an dessen Maintainer weiterleiten.


    Elegant finde ich das auch nicht, das man ein Programms starten muss, um einen Pfad zu bekommen.
    IMHO schon elegant, weil es immer funktioniert.
    Man könnte auch selber suchen, aber das wäre weit ineffektiver.


    Das es KDE-Nutzer sind, sind sie geduldig *Seitenhieb*
    Versteh ich zwar jetzt nicht, aber wenn das schon KDE läuft, könnte eine KDE Applikation den Pfad viel leichter und schneller ermitteln.


    Ich will einen self-extracting InstallWizard bauen. Damit mache ich mir in bestimmten Gruppen von Linuxnutzern keine Freunde, das ist mir klar, aber irgendwie gefällt mir das nicht, das selbst Autoconf-Packages zwischen Mandrake und SuSE nicht kompatibel zu sein scheinen.
    Komisch, ist mir neu. Hab noch nie von Benutzern einer der beiden Distributionen Klagen gehört, nachdem Mandrake wieder einen echten C++ Kompiler dabei hatte.


    Ich würde halt gerne meinen Installer dazu bringen, das er gleich ins richtige Verzeichnis installiert.
    Definiere "richtig"

    Bei mir kommen nur gemanagte Pakete in KDEPREFIX, die anderen in Sekunäre Verzeichnisse aus KDEDIRS

    Idee: KDEDIRS und KDEDIR auswerten und nur wenn beide nicht gesetzt sind kde-config bemühen

    Das ein Benutzer zwischendrinn mal warten muss, halte ich für vertretbar, das ist ja bei RPM auch angesagt, nach dem alle Dateien kopiert wurden.
    Schon, aber da blockiert keine GUI.


    Der zusätzliche Platz scheint mir vertretbar, wenn man daran denkt, das mein Installer im Moment 34kb Overhead im Gegensatz zu > 1MB bei Autoconf ist.
    Ich weiß ja nicht, was du da alles reinpackst, aber autoconf/automake hat sicher kein MB overhead.


    Mir stellt sich selbstverständlich die Frage, warum KDE-Programme, die im Source angeboten werden, in der Regel unter Mandrake nicht richtig funktionieren, weil Mandrake KDE in /usr installiert.
    Daran kanns nicht liegen, das ist auch das KDE Prefix bei Debian.

    Gibt es da Probleme beim Kompilieren?


    Theoretisch sollte es doch kein Problem sein, den entsprechenden Pfad im configure-skript mittels KDE-Config herauszufinden?
    Soweit ich weiß probiert das Script verschiedene Pfade durch, wenn es Header und Libs sucht.
    Kann mich nicht erinnern, dass es da mal keine gefunden hätte.

    Vielleicht ist bei Mandrake irgendwie eine inkompatible automake Version schuld.
    Ich hatte da mal Probleme mit zu neuen admin Verzeichnissen und einer zu alten automake Version.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  13. #13
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    gerne poste ich den Code zu popen:
    Code:
    QString SetupWizard::getProcStdOut(const QString & command)
    {
     QString out;
     FILE* procout;
     char c;
     procout = popen((const char*)(QFile::encodeName(command)), "r");
    
     while((c = getc(procout)) != EOF)
     {
      out += c;
     }
     pclose(procout);
     return out;
    }
    Ich weis nicht, ob das mit der while-Schleife schon die optimale Lösung ist, aber mein Wissen über C-Dateihandling hält sich in Grenzen. Das mit der Crossplattformprogrammierung ist eine schwierige
    Frage, wie du schon gesagt hast. Mich ärgert nur ein bißchen, das ich KApplication nutzen muss, obwohl ich nur eine statische Funktion aus einer Bibliothek aufrufe, zumal sich die Main-Methode einer
    KApplication ja nicht unerheblich von der einer QApplication unterscheidet.
    Ein Filechooser, in dem man nur Verzeichnisse anwählen kann, möchte ich möglichst nicht benutzen, weil ich selber am Anfang schon Probleme in der Bedienung hatte. Es war für mich einfach ungewohnt in
    einem Dateiselector ein Verzeichnis auszuwählen, zumal der Treeview unter Windows Gang und Gäbe ist und ich die Lösung besser finde.
    Das Keramik nicht gescheit mit reinen Qt-Widgets angezeigt wird, liegt meines Wissens nach an der begrezten Stylebarkeit von QMenuBar und ähnliches Widgets. In der API-Reference zu KDE steht auch
    drin, dass KMenuBar QMenuBar nur um die Stylebarkeit erweitert. Die Sache mit dem Program, um einen Pfad zu bekommen, ist aus meiner Sicht nicht elegant, weil man einen Prozess starten muss. Für
    Shellskripte ist das ideal, für GUI-Programme finde ich eher nicht. Es funktioniert auch nur so lange, wie das Program, das den Pfad liefern soll, verfügbar ist. Unter Windows würde ich erwarten,
    dass ein entsprechender Registryschlüssel angelegt wird, den ich dann easy per API-Funktion auslesen kann. Da ist mir das GUI-Blocking egal, weil es sehr schnell geht. Das mit dem träge bezieht sich
    auf die Zeit, die benötigt wird, bis ein KDE-Programm in die Puschen kommt, wenn man es nicht über KDE-Init startet. Und selbst da dauert es länger, als vergleichbare Gtk-Programme (vgl. Gimp: dauert
    bei mir keine Sekunde, bis der Splash erscheint, Quanta etwa 3 Sekunden)(PII @266Mhz). Ich hab im Moment eine KDE-Application, da kann ich den Pfad also schnell ermitteln? Das wäre für die eine
    Anwendung sicher zugebrauchen, aber für etwa xmms-config muss ich weiterhin Prozesse verwenden.
    Wenn du mal Mandrakenutzer über Autoconfpackages klagen hören willst, guck mal auf KDE-Look.org. Wenn da etwas vorgestellt wird, dauert es icht lange, bis der erste Mandrakenutzer kommt und klagt, das
    bei ihm dieses und jenes nicht angezeigt wird. Beliebtes Beispiel: Liquid.
    Außerdem steht im Featureplan zu KDE 3.2, das kde-config genutzt werden soll, um den Installationsort von KDE herauszufinden. Verantwortlich ist Stephan Kulow, der ja die ganzen Autoconfgeschichten
    rund um KDE macht. IMHO ist es sogar so, das keine Binärkompatiblität zwischen Mandrake und SuSE gewährleistet ist, weil in der Mandrake-Qt-Bibliothek Symbole fehlen, nämlich zu QSGIStyle. Angeblich
    sind diese Styles als Plugin realisiert, ich konnte sie aber bisher nicht finden, auch im Kontrollzentrum tauchen sie nicht auf. Man kann sicher auf diese Styles verzichten, eine Augenweide sind sie
    nicht, aber da sollten sich die Distributionen mal abstimmen. Ich glaube, auch unter Debian werden die Styles ausgelagert.
    Mit dem richtigen Verzeichnis meine ich, das ein dummer Benutzer draufklicken kann, dreimal auf weiter klickt und er das, was er installieren will, zur Verfügung hat. Ich sehe selbstverständlich eine
    Option vor, in ein anderes Verzeichnis zu installieren, aber ich will einen sinnvollen und funktionierenden Vorschlag anbieten.
    Zu KDEDITS und KDEDIR: Wenn ich in meine Konsole $K [TAB] eingebe, kommt nur das hier:
    Code:
    [axel@tecton beweisanda_skoa]$ $K
    $KBCHARSET             $KEYBOARD              $KONSOLE_DCOP
    $KDE_MULTIHEAD         $KEYTABLE              $KONSOLE_DCOP_SESSION
    [axel@tecton beweisanda_skoa]$ $K
    Das bei RPM keine GUI blockiert stimmt - wo nichts vorhanden ist, kann auch nichts blockieren. Frontends zu RPM blockieren aber gerne, z.B. grpmi. Da wird erst eine Progressbar angezeigt, aber wenn
    die bei 100% ist, dauert es immer noch eine ganze Weile, bis die Installation dann fertig ist, meistens länger, als das kopieren. Zu configure@mandrake: Siehe oben. Aber wenn es noch auf der
    ToDo-Liste ist, verstehe ich nicht, wie das bei dir bereits funktionieren kann. Es gab auch öfters mal den Tipp, dem configure-skript --prefix=/usr/ zu übergeben. Eigentlich sollten ja die
    An einer krummen Version kann es eigentlich nicht liegen, die configure-skripte sollten auch ohne Automake/Autoconf laufen, oder?
    Zum Overhead von Autoconf: Ich hab mal ein neues Projekt mit KDevelop angelegt. Projekttyp: KDE-Normal. Ich hab gleich eine Sourcedistribution gemacht und den Plattenplatz gemessen:
    Code:
    [axel@tecton beweisanda_skoa]$ du beweisanda_skoa-0.1.tar.gz
    428K    beweisanda_skoa-0.1.tar.gz
    [axel@tecton beweisanda_skoa]$
    Mann kann ja in etwa hochrechnen, wie groß das entpackt sein wird. Oder ich kann es dir auch genau sagen:
    Code:
    [axel@tecton programmieren]$ du beweisanda_skoa-0.1
    1,2M    beweisanda_skoa-0.1/admin
    92K     beweisanda_skoa-0.1/beweisanda_skoa
    16K     beweisanda_skoa-0.1/po
    1,9M    beweisanda_skoa-0.1
    [axel@tecton programmieren]$
    Und da habe ich noch keine Zeile Quellcode geschrieben. Das tollste ist ja, das diese Skripte gröstenteils bei jedem KDE-Programm gleich sind. 10 Programme runtergeladen, 10 MB für den Eimer.

  14. #14
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Original geschrieben von axeljaeger
    gerne poste ich den Code zu popen:
    Thx!


    Ich weis nicht, ob das mit der while-Schleife schon die optimale Lösung ist, aber mein Wissen über C-Dateihandling hält sich in Grenzen.
    Wenn du die Länge abschätzen kannst, geht es mit fgets eventuell sogar in einem Aufruf.

    Aber probier mal QFile:: open(int, FILE*) um das ganze ins Qt Handling zu bringen.

    Mich ärgert nur ein bißchen, das ich KApplication nutzen muss, obwohl ich nur eine statische Funktion aus einer Bibliothek aufrufe, zumal sich die Main-Methode einer KApplication ja nicht unerheblich von der einer QApplication unterscheidet.
    Nunja, das ist ziemlich vereinfacht
    Das "nur aufrufen einer statischen Methode" ist ja nur die API, im Hintergrund muss die Infrastruktur für KIO usw. schon verfügbar sein.
    Ein FileDialog ist ja nicht nur ein Widget.

    Das mit KApplikation vs. QApplikation stimmt schon, sie war halt ein einfacher zentraler Punkt, wo man zentrale Funktionalität unterbringen konnte und jedes KDE Programm hat eh eine KApplication Instanz.
    Aber zu dem Thema wird sich noch was tun: http://www.kdedevelopers.org/node/view/191


    Ein Filechooser, in dem man nur Verzeichnisse anwählen kann, möchte ich möglichst nicht benutzen, weil ich selber am Anfang schon Probleme in der Bedienung hatte.
    Hmm, das kenn ich eigentlich von vielen Programmen, auch unter Windows.

    Es war für mich einfach ungewohnt in einem Dateiselector ein Verzeichnis auszuwählen, zumal der Treeview unter Windows Gang und Gäbe ist und ich die Lösung besser finde.
    Ja, ist sicher übersichtlicher.
    Einen ListView aus einem Directory Baum zu befüllen ist aber ziemlich trivial.
    Wenn du willst, schreib ich dir sowas


    Das Keramik nicht gescheit mit reinen Qt-Widgets angezeigt wird, liegt meines Wissens nach an der begrezten Stylebarkeit von QMenuBar und ähnliches Widgets.
    Dann ist es ja auch nicht dein Problem, oder?
    Eine Pure-Qt Applikation verhält sich nie ganz wie eine native KDE Applikation.
    Eigentlich ist es ganz OK wenn sie bischen anders aussieht, denn dann hat man einen visuellen Hinweis, dass es keine echte KDE Applikation ist und mit anderem Verhalten rechnen muss.


    Die Sache mit dem Program, um einen Pfad zu bekommen, ist aus meiner Sicht nicht elegant, weil man einen Prozess starten muss. Für Shellskripte ist das ideal, für GUI-Programme finde ich eher nicht.
    Die brauchen das aber auch eher selten, aber dafür ist es universell.
    Ein externes Programm aufrufen und den Output benutzen geht einfach in jeder Sprache.


    Es funktioniert auch nur so lange, wie das Program, das den Pfad liefern soll, verfügbar ist.
    Klar, aber wenn es nicht vorhanden ist, gibts auch kein KDE, also ist das KDE Pfad suchen dann ziemlich hinfällig


    Unter Windows würde ich erwarten, dass ein entsprechender Registryschlüssel angelegt wird, den ich dann easy per API-Funktion auslesen kann.
    Ist unter KDE nicht anders -> KStandardDirs


    Das mit dem träge bezieht sich auf die Zeit, die benötigt wird, bis ein KDE-Programm in die Puschen kommt, wenn man es nicht über KDE-Init startet. Und selbst da dauert es länger, als vergleichbare Gtk-Programme (vgl. Gimp: dauert
    bei mir keine Sekunde, bis der Splash erscheint, Quanta etwa 3 Sekunden)(PII @266Mhz).
    Ja, die leidige Geschichte mir dem schlechten GNU runtime linker
    Ich dachte die letzte binutils Reihe hat das verbessert.
    Hängt auch davon ab, wieviele libs man linkt.


    Ich hab im Moment eine KDE-Application, da kann ich den Pfad also schnell ermitteln?
    KStandardDirs kann dir alle Pfade geben. Wo die Executables sind, wo Libs sind, wo Plugins sind, etc.


    IMHO ist es sogar so, das keine Binärkompatiblität zwischen Mandrake und SuSE gewährleistet ist, weil in der Mandrake-Qt-Bibliothek Symbole fehlen, nämlich zu QSGIStyle. Angeblich sind diese Styles als Plugin realisiert, ich konnte sie aber bisher nicht finden, auch im Kontrollzentrum tauchen sie nicht auf.
    Styles sind immer Plugins.
    Schau mal in deinem Qt Lib Verzeichnis ins Unterverzeichnis plugins/styles.


    Ich glaube, auch unter Debian werden die Styles ausgelagert.
    Bei Stable sind sie im normalen libqt-mt Paket mit drinnen.


    Mit dem richtigen Verzeichnis meine ich, das ein dummer Benutzer draufklicken kann, dreimal auf weiter klickt und er das, was er installieren will, zur Verfügung hat. Ich sehe selbstverständlich eine Option vor, in ein anderes Verzeichnis zu installieren, aber ich will einen sinnvollen und funktionierenden Vorschlag anbieten.
    Alles klar.
    Wäre es nicht aber trotzdem sinnvoller, ins Hauptverzeichnis nur Sachen unter Kontrolle des Package Managers zu installieren?
    Das Package Management ist schliesslich einer der Pluspunkte von Linux.
    Wird noch eine Zeit lang dauern, bis man unter Windows ähnlichen Komfort hat.


    Zu KDEDITS und KDEDIR: Wenn ich in meine Konsole $K [TAB] eingebe, kommt nur das hier
    Ja, sie müssen nicht gesetzt sein.
    Wenn sie aber gesetzt sind, sollten sie schon vorranging behandelt werden, denn sie spiegeln dann ja auch die Systemsettings wieder.


    Das bei RPM keine GUI blockiert stimmt - wo nichts vorhanden ist, kann auch nichts blockieren.
    Schon klar ich meinte eh GUI Frontends.


    Frontends zu RPM blockieren aber gerne, z.B. grpmi. Da wird erst eine Progressbar angezeigt, aber wenn die bei 100% ist, dauert es immer noch eine ganze Weile, bis die Installation dann fertig ist, meistens länger, als das kopieren.
    Sollte nicht blockieren, schliesslich läuft rpm als externer Prozess.
    Schlechte Applikation würde ich sagen.

    An einer krummen Version kann es eigentlich nicht liegen, die configure-skripte sollten auch ohne Automake/Autoconf laufen, oder?
    autoconf vielleicht. Automake wird ja von configure benutzt, um aus den Makefile.am Dateien die Makefiles zu generieren.
    Das geht schhliesslich erst, wenn configure die Systemeigenschaften festgestellt hat.


    Zum Overhead von Autoconf
    Ok, entpackt hat es mehr als 1 MB.
    Schlimm


    Und da habe ich noch keine Zeile Quellcode geschrieben. Das tollste ist ja, das diese Skripte gröstenteils bei jedem KDE-Programm gleich sind. 10 Programme runtergeladen, 10 MB für den Eimer.
    Müsste man nicht.
    Das admin Verzeichnis ist immer das selbe.
    Im KDE CVS is es zB nur in kde-common.
    Wenn man CVS kompiliert linkt man es in die jeweiligen Pakete rein.
    Ist halt eine Bequemlichkeitssache für den Benutzer, wenn er es dabei hat.

    Fertig kompilierte Programm haben manchmal sogar Libs von denen sie Abhängen in ihren Downloadpaketen enthalten.
    Kommt noch aus der Ära wo System keine Paketmanagment hatten.
    Ist daher unter Windows immer noch üblich, weil das dort erst langsam im Entstehen ist.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  15. #15
    Registrierter Benutzer Avatar von tuxipuxi
    Registriert seit
    30.08.2002
    Beiträge
    667
    Original geschrieben von anda_skoa


    Ja, ist sicher übersichtlicher.
    Einen ListView aus einem Directory Baum zu befüllen ist aber ziemlich trivial.
    Wenn du willst, schreib ich dir sowas
    *dooffrag* ist nicht schon KFileTreeView mit irgendwelchen filtern fuer so etwas gedacht?

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •