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

[axeljaeger]

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


#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();
}

[anda_skoa]

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.

[axeljaeger]

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.

[anda_skoa]

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,
_

[axeljaeger]

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.

[anda_skoa]

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,
_

[axeljaeger]

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.

[anda_skoa]

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. :confused:
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,
_

[axeljaeger]

Original geschrieben von anda_skoa
Da komm ich nicht mit. :confused:
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.

[anda_skoa]

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,
_

[axeljaeger]

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.

[anda_skoa]

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,
_

[axeljaeger]

gerne poste ich den Code zu popen:


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:


[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:


[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:


[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.

[anda_skoa]

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 :D



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 :D



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,
_

[tuxipuxi]

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 :D


*dooffrag* ist nicht schon KFileTreeView mit irgendwelchen filtern fuer so etwas gedacht?

[axeljaeger]

Genau den benutze ich im Moment. Es gibt sogar von KDE ein fertiges Textfeld, um Pfade einzugeben, mit Autocomplete und mit einem Knopf an der Seite, mit dem man einen Filechooser aufrufen kann. Den hab ich jetzt nicht benutzt, weil eben der Filechooser und nicht der TreeView genutzt wird. Ich wäre schon an dem Code interessiert, so einen DirChooser zu machen, ich versteh eh nicht, warum sowas bei Qt nicht dabei ist.

Styles in Qt müssen nicht zwangsläufig Plugins sein, die können auch in der Lib mit drinn sein. Wieso würde es sonst Sinn machen <qsgistyle.h> zu inkluden?

Das mit dem Paketmanager hat sicher seine Vorteile und Microsoft scheint ja mit MSI den Versuch unternommen zu haben, sowas zu implementieren. Ich hab aber leider die Erfahrung gemacht, dass das unter Linux auch nicht so funktioniert, wie es sollte. Beispiel: Mandrake Linux: Ich wollte einen aktuellen Mozilla installieren und dazu erstmal den alten löschen. Was der da noch alles mitlöschen wollte - praktisch das gesammte Gnome.

Zu 1MB Overhead: Ja, das ist schlimm: Man kann unter Windows einen Installer mit 4 kb Overhead bauen (CAB-Datei mit INF-Datei). Nullsoft(Winamp) hat einen Installer mit 34 kb Overhead geschrieben, gibt es bei Sourceforge, leider nur für Win.

Ob das starten von C++-Programmen sich mit der letzten Version gebessert hat, vermag ich nicht zu beurteilen, ich hab sicher nicht die aktuellste Version. Aber das es eben so lange dauert, ist für mich immer ein Grund, erstmal zu gucken, ob man die KDE-Libs wirklich braucht. Dann gibt es halt noch so andere Tricks, das man z.B. ohne libstdc++ auskommt.

Zum Tod von KApplication: Ich fände es auch besser, wenn man sein Qt-App nicht so sehr verhunzen müsste, um KDE-Funktionen zu verwenden. Aber wenn man schonmal am Entschlacken ist, sollte man sich überlegen, ob man nicht noch andere Sachen von Bord wirft. Ich werfe jetzt was neues in die Disukussion ein, und man wird mich dafür hassen: Ich hab letztens einen Screenshot gesehen, auf dem Qt-Programme ohne X11 mit DirectFB liefen. Gescheite Transparenz ist damit kein Thema mehr. Überzeugt euch selbst: http://www.directfb.org/screenshots/FirstQt.png

[anda_skoa]

Original geschrieben von tuxipuxi
*dooffrag* ist nicht schon KFileTreeView mit irgendwelchen filtern fuer so etwas gedacht?

Ja, klar.
Wenn das eine KDE Applikation wäre, gebe es diesen Thread nicht :)
Wir haben hier das "Problem" einer Qt-only Applikation, die hat keinen direkten Zugriff auf die Plattform API.

Ciao,
_

[axeljaeger]

Ich glaub, mein installerproblem hat sich in Luft aufgelöst: http://autopackage.org
Leider sind die noch nicht soweit, aber immerhin weiter als ich. Zu KDE 4.0 wird es wohl fertig sein. Ich werd trotzdem mal ein Tutorial schreiben, wie man eine Self-Extracting exe macht. Kommt dann zu den anderen auf http://axj.tuxipuxi.de/tutorials/

[anda_skoa]

Original geschrieben von axeljaeger
Ich wäre schon an dem Code interessiert, so einen DirChooser zu machen, ich versteh eh nicht, warum sowas bei Qt nicht dabei ist.


Wahrscheinlich weil es einfach ist, so etwas selber zu machen.



Styles in Qt müssen nicht zwangsläufig Plugins sein, die können auch in der Lib mit drinn sein. Wieso würde es sonst Sinn machen <qsgistyle.h> zu inkluden?


Natürlich kann man einen Style direkt in das Programm linken, wir machen das in der Firma, da der Kunde einen speziellen Style wünscht.
Aber ein normaler Build von Qt baut die Standard Styles als Plugins.



Das mit dem Paketmanager hat sicher seine Vorteile und Microsoft scheint ja mit MSI den Versuch unternommen zu haben, sowas zu implementieren.


Ja, das ist schon in diese Richtung. Das Fehlen eines Paketmanagements hat Windows bisher immer geschadet ("DLL-Hell")



Ich hab aber leider die Erfahrung gemacht, dass das unter Linux auch nicht so funktioniert, wie es sollte. Beispiel: Mandrake Linux: Ich wollte einen aktuellen Mozilla installieren und dazu erstmal den alten löschen. Was der da noch alles mitlöschen wollte - praktisch das gesammte Gnome.


Ein schlechtes Paket kann es immer geben.
RPM ist da auch nicht so gut wie zB DEB.
"Stable" bei Debian bedeutet auch stabile Paketabhängigkeiten, mit Erkennen von gültigen Alternativen, etc.

Ein hochqualitatives Paket ist mindestens so wichtig wie die Qualität des Inhalts.
Wenn man ein gutes Programm mies verpackt, leidet die Gesamtqualität.
Packaging ist ein Teil des Entwicklungszyklus.



Zu 1MB Overhead: Ja, das ist schlimm: Man kann unter Windows einen Installer mit 4 kb Overhead bauen (CAB-Datei mit INF-Datei). Nullsoft(Winamp) hat einen Installer mit 34 kb Overhead geschrieben, gibt es bei Sourceforge, leider nur für Win.


Einen Installer mit einem Buildframework zu vergleichen ist bischen weit hergeholt.
Die autoconf/automake Scripte sind so umfangreich, weil sie das Erzeugen auf einer riesigen Anzahl von Umgebungen ermöglichen.

Ich glaube es gibt in kdenonbeta einen Installer bzw der Loki Installer ist glaub ich auch frei verfügbar.



Aber das es eben so lange dauert, ist für mich immer ein Grund, erstmal zu gucken, ob man die KDE-Libs wirklich braucht.


Klar, kann ich verstehen.
Bei mir gbt sich die Problematik nicht, ich mache KDE Programme, aber wenn man nur eine GUI für etwas macht, ist das sicher ein Thema, dass man sich überlegen muss.



Zum Tod von KApplication: Ich fände es auch besser, wenn man sein Qt-App nicht so sehr verhunzen müsste, um KDE-Funktionen zu verwenden.


Das ist ja schon lange ein Anliegen, nur aufgrund der der KDE->Qt Abhängigkeit nicht so leicht.
Qt muss da auch "mithelfen", so wie sie es bei Qt1->Qt2 mit den Widgets gemacht haben (WidgetPlugins für Designer/UIC) und Qt2->Qt3 mit den StylePlugins.

Qt4/KDE4 wird das noch weiter verbessern, da bin ich mir sicher.


Aber wenn man schonmal am Entschlacken ist, sollte man sich überlegen, ob man nicht noch andere Sachen von Bord wirft. Ich werfe jetzt was neues in die Disukussion ein, und man wird mich dafür hassen: Ich hab letztens einen Screenshot gesehen, auf dem Qt-Programme ohne X11 mit DirectFB liefen. Gescheite Transparenz ist damit kein Thema mehr. Überzeugt euch selbst: http://www.directfb.org/screenshots/FirstQt.png
Qt läuft schon lange ohne X11, logischerweise, denn Qt/Win und Qt/Mac brauchen es ja auch nicht.
Qt/Embedded arbeitet auch am Framebuffer Devic (siehe Qtopia PDAs)

Transparenz geht aber auch mit X, alles eine Frage der Extensions.

Nicht ganz klar, was das mit Entschlacken zu tun hat.

Ciao,
_

[axeljaeger]

Zum LokiInstaller: Da warst du schneller als ich, hab grad noch einen Link oben reingemacht. Zu X11-Transparenzextension: Haben ein Gewehr. Alles, was ich bisher an transparenz gesehen habe, war gefaked. Ich glaub aber nicht, dass das bei WindowsXP anders ist. Mit entschlacken meine ich, das man mit weniger Libs, Abhängigkeiten und Overhead auskommt. DirectFB ist mit Sicherheit schneller, als jeder X-Server. Außerdem ist die Architektur moderner, kleiner. Man hat nicht diese Konfigurationsungetüme.

[anda_skoa]

Original geschrieben von axeljaeger
Zu X11-Transparenzextension: Haben ein Gewehr.


Bitte? :confused:



Alles, was ich bisher an transparenz gesehen habe, war gefaked. Ich glaub aber nicht, dass das bei WindowsXP anders ist.


Irgenwo müssen immer Bilder gemerged werden.
Ich nenne es gefaked wenn die Applikation es machen muss.
Windows und andere Framebuffer Libs machen es sicher in der Library, es ginge auch in der Grafikkarte. OpenGL macht das dort, wenn verfügbar.
Könnte also sein, dass zb Windows das auch die GraKa machen lässt, wenn der Treiber es kann.

Eine XServer extension könnte das auch entweder selber machen, oder in der GraKa, in beiden Fällen aus Sicht der Applikation echte Transparenz.



Mit entschlacken meine ich, das man mit weniger Libs, Abhängigkeiten und Overhead auskommt.


Man könnte sicher alles in einer Monsterlib zusammenfassen, aber ich hab da schon den modularen Ansatz lieber.
Abhängigkeiten sind sicher unabgenehm, aber besser als alles selber machen müssen.
Außerdem sind die Abhängigkeiten bei den meisten Programmen IMHO gar nicht so schlimm.



DirectFB ist mit Sicherheit schneller, als jeder X-Server.


Das glaub ich erst, wenn ich entsprechende Benchmarks sehen.
Die XServer von XiGraphic sind ziemlich schnell.
Der XFree ist eigentlich auch nicht langsam.
Hab mal gelesen das man auch mit einer besseren XLib Implementation viel rausholen könnte.


Außerdem ist die Architektur moderner, kleiner. Man hat nicht diese Konfigurationsungetüme.
Kann ich nicht beurteilen, ich kenne beide Architekturen nicht, X nur sehr oberflächlich.
Was genau meinst du mit "Konfigurationsungetüme"?

Ciao,
_
PS. Entertaste verwenden :)

[axeljaeger]

Haben ein Gewehr ist ein Sprichwort. Das wird angewendet wenn jmd. sagt: Nimm dieses, man es aber nicht zur Verfügung hat. Meines Wissens nach gibt es keine entsprechende Extension für X11.

Das mit dem Bildermergen sollte von der Grafikkarte gemacht werden, jede moderne Grafikkarte kann das in der Hardware sehr schnell. Wenn es die Anwedung machen muss, kann man halbtransparente Fenster über Animationen vergessen. Ich wette, unter Windows ist das auch nur gefaked. Interessant wird es mit QuarzExtreme auf Mac, da liegt jedes Fenster in einer OpenGL-Textur

Zum Entschlacken: Qtopia läuft von einer Diskette. Mein Linuxkernel bootet mit Framebuffer und kann schonmal prima Grafiken anzeigen. Da verstehe ich nicht, warum ich noch einen X-Server starten soll, zumal die API von X11 alles andere als kundenfreundlich ist. Da lasse ich mein Qt doch lieber direkt mit der Grafikkarte reden.

Benchmarks/Speed: Das schnellste, was man im Moment machen kann, ist sicher OpenGL. Aber es ist ja mit X11 nicht so ohne weiteres möglich, Bilder mit Alphakanal zu blitten. Das geht auch nicht mit Qt, erst die KDE-Libs machen das möglich.

Konfigurationsungetüm:

/usr/X11R6/XF86Config

Sowas muss doch nicht sein. Vor allem, wenn die Datei fehlt oder einen Fehler enthält, dann ist was los. Was das schon für ein Bohai war, dynamisch die Auflösung zu verändern. Geht ja wohl mit der neuesten Version während des Betriebes, aber hat lange gedauert. Das ist für mich ein anzeichen, das XFree recht unflexibel zu sein scheint.

[anda_skoa]

Original geschrieben von axeljaeger
Haben ein Gewehr ist ein Sprichwort. Das wird angewendet wenn jmd. sagt: Nimm dieses, man es aber nicht zur Verfügung hat. Meines Wissens nach gibt es keine entsprechende Extension für X11.

http://www.eax.com/render/
Beispiel http://www.eax.com/render/#d2 und darunter.



Das mit dem Bildermergen sollte von der Grafikkarte gemacht werden, jede moderne Grafikkarte kann das in der Hardware sehr schnell. Wenn es die Anwedung machen muss, kann man halbtransparente Fenster über Animationen vergessen.


Darum hab ich auch gesagt, auf Applikationsebene ist gefaked.
Wenn es das Rendering System macht, nicht mehr.
Am besten ist naürlich in der Grafikarte, wenn möglich.



Ich wette, unter Windows ist das auch nur gefaked. Interessant wird es mit QuarzExtreme auf Mac, da liegt jedes Fenster in einer OpenGL-Textur

Ich denke das Windows genug direkten Hardwarezugriff hat, um das in der Grafikkarte handlen zu lassen bzw notigenfalls zu emulieren.
Ich glaube nicht, dass es da eine Applikation selbst machen muss.



Zum Entschlacken: Qtopia läuft von einer Diskette. Mein Linuxkernel bootet mit Framebuffer und kann schonmal prima Grafiken anzeigen. Da verstehe ich nicht, warum ich noch einen X-Server starten soll, zumal die API von X11 alles andere als kundenfreundlich ist. Da lasse ich mein Qt doch lieber direkt mit der Grafikkarte reden.

Kein Problem, gibt es ja.
XServer benutzt man dann, wenn man X Applikationen benutzen will.

Nur versteh ich nicht, was das mit Entschlacken zu tun hat.
Ich versteh darunter, das man Sachen los wird, die man nicht braucht.



Benchmarks/Speed: Das schnellste, was man im Moment machen kann, ist sicher OpenGL.

OpenGL ist nur eine API.
Man könnte die sicher zum Benchmarken benutzen, also Gl auf Framebuffer und GL auf X.
Ich glaube nicht das GL auf X langsamer ist, solange ich keine entsprechenden Benchmarks gesehen habe.
Behauptungen werden da schnell aufgestellt.



Aber es ist ja mit X11 nicht so ohne weiteres möglich, Bilder mit Alphakanal zu blitten. Das geht auch nicht mit Qt, erst die KDE-Libs machen das möglich.


Das geht sicher auch Qt-only, hab schon QPixmaps mit Alphakanal zusammen geblittet.
Und ich glaube dass es mit XRender sogar der XServer machen kann.



Konfigurationsungetüm:

/usr/X11R6/XF86Config

Sowas muss doch nicht sein. Vor allem, wenn die Datei fehlt oder einen Fehler enthält, dann ist was los.

Was hat das mit X zu tun, wenn eine XServer Implementation eine komplexe Konfigurationsdatei hat?

eXceed hat sicher eine andere Config, benutzt als Windowsapp wahrscheinlich sogar die Registry.

XFree hat einfach komplexere Anforderungen, muss schliesslich auf vielen Plattformen laufen, mit vielen Grafikarten zurechtkommen, etc.

Dank der X11 Architektur hast du jederzeit die Möglichkeit einen anderen Xserver zu benutzen, wenn XFree nicht deinen Anfoderungen genügt.



Was das schon für ein Bohai war, dynamisch die Auflösung zu verändern. Geht ja wohl mit der neuesten Version während des Betriebes, aber hat lange gedauert.


Entwicklerzeit ist begrenzt. Vielleicht waren andere Sachen wichtiger.
Umschalten von Auflösungen ging schon immer, das Problem war nur das Mitteilen an die Applikationen.
X wurde bisher hauptsächlich auf Workstations eingesetzt, da ändert man keine Auflösung, warum auch.
Den einzigen Anwendungfall den ich kenne, ist das Umschalten auf eine kleinere Auflösung, wenn man ein Notebook an einen Beamer hängt.



Das ist für mich ein anzeichen, das XFree recht unflexibel zu sein scheint.

Du meinst die Art und Weise wie das XFree Team ihr Projekt leitet?
Darum gabs da auch entsprechendes Feedback auf den XFree Listen und Keith Packard hat mit anderen, denen das auch zu langsam ging, xwin.org gegründet.

Wie man an Keith's Extensions schön sieht, ist die Architektur sowohl von X als auch von XFree äußerst flexibel, wenn da Entwicklungsmodell des XFree Teams nicht besser wird (was aber wahrscheinlich ist), macht ein anderes Team einen Fork.

Ich will dir jetzt nichts unterstellen, aber es sieht so aus, als hättest du in deinen Betrachtungen irrtümlich X11 mit einer Umsetzung davon (XFree86) gleich gesetzt und dann mit X11 Alternativen verglichen.

Ciao,
_

[axeljaeger]

Gut, XFree ist nunmal die am meisten genutzte Implementierung von X11 auf Linux. Ich denke nur, man muss zwischen Qt und die Hardware nicht mehr Steine legen, als notwendig. Selbst Trolltech schreibt ja in der Qt-Doku vom X11 Horror bezogen auf das Fonthandling.

Die Extension von X11 für Transparenz kannte ich noch nicht, die Screenshots finde ich aber weniger beeindruckend, als Screenshots von DirectFB, wo man mal ein halbtransparentes Quake 3 sieht. Mit schnellem OpenGL meine ich folgendes: Ich möchte in einer Qt-App tausend Rechtecke malen. Wie wird das wohl schneller sein? Mit QPainter oder mit glRect() in einem QGLWidget? Zumal ich bei GL so Sachen wie transparenz geschenkt bekomme.

Das transparenz unter XP gefaked ist, schließe ich daraus, das ich die gleichen Symptome bei Menüs mit Schatten habe, wie unter KDE: Die Animation bleibt im Bereich des Schattens stehen.

Ob X11 eine gute Grafikapi ist, möchte ich nicht ausdiskutieren, für einen PC, auf dem nur ich arbeite, sind aber einige Funktionen nicht nötig.

[anda_skoa]

Original geschrieben von axeljaeger
Gut, XFree ist nunmal die am meisten genutzte Implementierung von X11 auf Linux. Ich denke nur, man muss zwischen Qt und die Hardware nicht mehr Steine legen, als notwendig. Selbst Trolltech schreibt ja in der Qt-Doku vom X11 Horror bezogen auf das Fonthandling.

TT hat da auch den Nachteil, zu möglichst vielen und daher auch sehr alten XServer Implementationen kompatibel sein zu müssen.
XFree ist da gar nicht so schlecht, im Bereiche Rendering sicher den meisten kommerziellen Servern vorraus.

Alternative System sind aber meisten eingeschränkter.
Es fehlt manchmal die Netzwerktransparenz, oder es geht nur unter Linux, oder es gibt keine Möglichkeit X Applikationen laufen zu lassen, oder sie die Treiberunterstützung ist noch geringer als bei XFree.

Aber wie gesagt, man hat da ja durchaus die Wahl.
Qt/Embedded ist am direktesten, das setzt direkt am Framebuffer auf.
AFAIK gibt es auch eine DirectFB Implementierung, also mit zusätzlicher Zwischenschicht.
Man kann auch ein System mit eigenem Toolkit verwenden, Fresco zum Beispiel.



Die Extension von X11 für Transparenz kannte ich noch nicht, die Screenshots finde ich aber weniger beeindruckend, als Screenshots von DirectFB, wo man mal ein halbtransparentes Quake 3 sieht.


Heißt nicht, dass das nicht geht, DirectFB scheint aber nur Screenshots zu taugen :D
Hab noch was gefunden:
http://www.stud.uni-karlsruhe.de/~unk6/transluxent/



Mit schnellem OpenGL meine ich folgendes: Ich möchte in einer Qt-App tausend Rechtecke malen. Wie wird das wohl schneller sein? Mit QPainter oder mit glRect() in einem QGLWidget? Zumal ich bei GL so Sachen wie transparenz geschenkt bekomme.


Ja, niemand widerspricht da, oder?
GL kann auf praktisch allen Rendersystemen implementiert werden.
Wie man sieht auch auf einem XServer.
Wie man sieht auch schnell.



Das transparenz unter XP gefaked ist, schließe ich daraus, das ich die gleichen Symptome bei Menüs mit Schatten habe, wie unter KDE: Die Animation bleibt im Bereich des Schattens stehen.

Wahrscheinlich eine Frage der Widgetimplementation. Könnte sicher auch über DirectX implementiert werden.



Ob X11 eine gute Grafikapi ist, möchte ich nicht ausdiskutieren, für einen PC, auf dem nur ich arbeite, sind aber einige Funktionen nicht nötig.
Ja, wahrscheinlich.
Im Moment fällt mir zwar keine offensichtliche Funktion ein, die überflüssig wäre, aber das hängt sicher vom Benutzer ab.
Mir gehts eher so, dass mir nichts fehlt :)
Bei anderen System fehlt mir praktisch immer die Netzwerktransparenz.
Windows kann das jetzt angeblich zumindest auf Desktop Basis, aber meistens braucht man ja nur eine Applikation.

Ich frag mich immer, was die Designer von sowas denken.
Haufenweise Eyecandy, das bei normalem Arbeiten nur stört, und keine Netzwerkschnitstelle vorsehen :rolleyes:
Die einzige X Alternative, die das gecheckt hat, ist AFAIK Fresco (IMHO derzeit die vielversprechendste Umsetzung eines modernen Rendersystems)

Ciao,
_

[axeljaeger]

Das OpenGL X11 sieht sehr interessant aus, ob damit auch so Effekte möglich sind, wie das vergrößern und verkleinern wie bei OSX?

An (für mich) überflüssigen Funktionen fällt mir da schon die Netzwerktransparenz ein. Aber ich bin sowieso ein Spezialfall. Ich stehe schon ziemlich auf Eyecandy, am liebsten pulsierende Buttons. Ich hab auch mal ein Textfeld mit einem pulsierenden Cursor gesehen, das war stylish!

[anda_skoa]

Original geschrieben von axeljaeger
Das OpenGL X11 sieht sehr interessant aus, ob damit auch so Effekte möglich sind, wie das vergrößern und verkleinern wie bei OSX?

No idea



An (für mich) überflüssigen Funktionen fällt mir da schon die Netzwerktransparenz ein.

:D
Dann würd ich sagen, da sie nicht stört und andere Leute es brauchen, lassen wir es drinnen. :)



Aber ich bin sowieso ein Spezialfall. Ich stehe schon ziemlich auf Eyecandy, am liebsten pulsierende Buttons. Ich hab auch mal ein Textfeld mit einem pulsierenden Cursor gesehen, das war stylish!
Nicht, dass es nicht fein ist, wenn was cool aussieht, aber beim Arbeiten will ich eigentlich nicht abegelenkt werden.

Zum Herzeigen ist sowas wie ein transparentes Menü fein, beim Arbeiten will ich sehen was dort steht.

Ich hab eine transparente Konsole in der mein Log läuft, aber wenn ich mit einer Konsole arbeiten will, brauch ich guten Kontrast, schwarz auf weiß, grün auf schwarz, weiß auf schwarz, etc.

Ciao,
_

[anda_skoa]

Original geschrieben von axeljaeger
Ich wäre schon an dem Code interessiert, so einen DirChooser zu machen, ich versteh eh nicht, warum sowas bei Qt nicht dabei ist.


http://doc.trolltech.com/3.1/dirview-example.html

Ciao,
_

[axeljaeger]

thx für den Treeview

Jetzt kann man natürlich über Eyecandy oder nicht streiten, aber ich muss erhlich zugeben ich war sehr beeindruckt, als ich osc zum ersten mal gesehen hab, mit den ganzen Animationen