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

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

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

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