[linux-l] Java-Geraffel auf Netbooks

Mi Jun 16 15:56:19 CEST 2010

Olaf Radicke <briefkasten at olaf-radicke.de> schrieb:
> Am Freitag 11 Juni 2010, 23:32:58 schrieb Volker Grabsch:

[Qt-Creator]

> > Wie auch immer, ich meinte das Syntax-Highlighting, die Auto-
> > Vervollständigung, das automatische Aufrufen der Doku zum
> > aktuellen Wort (egal ob Klasse, Variable, etc.), und allgemein
> > die gute Integration der verschiedenen Komponenten.
> 
> Okay. Ich hatte vor einigen Jahren mal ein Projekt mit Kdeverlo(o)p gemacht. 
> Seid dem bin ich "kuriert". Die Projekt-Dateien funktionieren unter Windows 
> nicht und z.T. noch nicht mal bei unterschiedlichen Distries. Damals gab es 
> Konflikte zwischen Suse und Fedora (bzw. RedHat). Man war das ein Scheiß, in 
> tausenden Zeilen Maschinen generierten Make-Files rum zu wühlen. 
>
> Seid dem lautet meine Devise: "Keep It Simple" (übrigens ein Slogan der 
> /alcoholics anonymous/).

Ich habe früher mit KDevelop gearbeitet und kenne die Probleme. Ich
weiß nicht, sich KDevelop inzwischen gebessert hat, aber Qt-Creator
hat all diese Probleme _nicht_.

Qt-Creator benutzt QMake, das kriegt als Input _eine_ *.pro-Datei und
liefert als Output _eine_ Datei, nämlich das Makefile. Das ist alles.
Keine Autotools oder sonstwas.

Wenn sich die Projektdatei (*.pro) ändert, aktualisiert sich das
Makefile automatisch, und im Gegensatz zu den Autotools funktioniert
das auch zuverlässig. Und Qt-Creator macht auch nichts anderes.

Ich habe an einem Projekt abwechselnd mal mit Vim und mal mit Qt-Creator
gearbeitet. Überhaupt kein Problem bei den *.pro, *.cpp, *.h und *.qrc-
Dateien. (Zu den *.ui-Dateien siehe unten)

Das einzige, was Qt-Creator zusätzlich macht: Es erstellt eine *.pro.user-
Datei für die letzten Projekteinstellungen (welche Fenster offen waren etc.).
Diese Datei liegt mit im Projektordner statt sauber getrennt in ~/.config/...,
was ein wenig nervt. Aber solange man diese Datei nicht ausversehen unter
Versionskontrolle stellt, kann man sie gut ignorieren. Bei mir kommt sie in
die ".hgignore".

tl;dr: Qt-Creator macht (fast) alles richtig, vorallem im Gegensatz zu
       KDevelop & Co..

[Qt-Designer]

> Ich mache nichts mehr war ich nicht mit Emacs, Vim und Co beherrschen könnte. 
> Tausende Zeilen XML-UI-Code sind grausam und schwer verständlich. XML ist für 
> Maschinen gedacht und nicht für Menschen.
> [...]
> Ich finde nicht einen (von Menschen geschriebene) Kommentar in den XML-
> Dateien. Quellcode ohne Kommentare möglichst noch mit nichtssagenden 
> Variablen, ist wertlos. XML macht die Sache noch schlimmer, als es schon ist. 
> In der Regel gibt es dann nur zwei Möglichkeiten:
> 
> A) Nichts anfassen.
> B) Neu schreiben.
> 
> Refactoring ist in solchen Fällen /zu teuer/.

Wir reden aneinander vorbei. Folgende Punkt bestreite ich gar nicht:

    1)  Die UI-Dateien von Qt sind kaum mit Vim oder Emacs beherrschbar.

    2)  Wer seine GUI mit Qt-Designer (*.ui) erstellt, sollte sie auch im
        Qt-Designer editieren.

    3)  Die Qt-Entwickler haben bei ihren XML-Konvertierern Qt3 -> Qt4
        für *.ui-Dateien möglicherweise versagt.

Allerdings ist die Situation nicht so schlimm, wie du sie darstellst, denn:

    4)  Die Unlesbarkeit der *.ui-Dateien begründet sich im schlechten
        Design seitens Qt. Es ist kein generelles Problem von XML. (s.u.)

    5)  Trotz allem sind _Diffs_ über die *.ui-Dateien gut lesbar und
        nachvollziehbar. Ich benutze sie wie beim Quelltext dafür, um
        kurz vor dem Commit nochmal die Änderungen zu reviewen. Geht super.

    6)  Der von UIC generierte Code aus den *.ui-Dateien ist sehr gut
        formatiert und relativ gut lesbar. Ein Weg von *.ui -> *.cpp
        ist mit akzeptablem Aufwand verbunden und erfordert _kein_
        komplettes Neuschreiben.

    7)  XML-Dateien sind _eigentlich_ sehr gut zur automatischen
        Transformation (z.B. Qt3 -> Qt4) geeignet, dank XSLT bzw.
        XQuery. Auf jeden Fall besser als *.cpp-Dateien, bei denen
        man um Handarbeit nicht herum kommt.

> Vergleich mal den XML-Code
> http://github.com/OlafRadicke/BibleMemorizer/blob/biblememorizer_sf_net/src/ui/AboutUI.ui
> 
> mit dem C++-Code
> http://github.com/OlafRadicke/BibleMemorizer/blob/master/src/AlterGUI/AboutWindow.cpp
> 
> Wenn du wirklich der Auffassung bist, der Erstere lese sich genauso, oder 
> besser wie der Zweite, brauchen wir nicht weiter diskutieren...

Siehe Punkt 5). Ich sprach von Diffs, nicht von den gesamten Dateien.

> > > Ich habe bei BibleMemorizer den XML-Code entfernt und die GUI
> > > wieder mit Editor in C++ gecodet. Die Tools haben es nicht geschafft
> > > den XML-Code von Qt3 auf Qt4 zu portieren.
> > 
> > Eine Migration Qt3 -> Qt4 habe ich bisher noch nie gehabt.
> > Dennoch wage ich zu bezweifeln, dass das Portieren der
> > *.cpp-Dateien leichter sein soll als das Portieren der
> > *.ui-Dateien.
> 
> Die *.cpp-Dateien waren mehr oder weniger nur Fleißaufgaben. Es gab einige 
> wenige Stellen wo es konzeptionelle Änderungen gab. Das wurde genutzt um 
> gleich den Code zu entschlacken. Der MOC und g++ sagt einem ziemlich genau, 
> was ihm nicht passt.
> 
> Bei den XML-Code gibt es portierungs Tools. Wenn die sagen: "geht nicht" dann 
> hast du tausende Zeilen Müll. Da kannst du alles neu zusammenklicken. Oder 
> willst du mir allen ernstes erzählen, du machst das dann alles mit Vim und 
> sed? Nie im Leben! 

Siehe Punkt 7). Das war als grundsätzliche Bemerkung gedacht.
"Vollautomatisch" ist weniger Aufwand als "Handarbeit". (wenn's
denn funktioniert, siehe Punkt 3))

> > Die *.ui-Dateien sind zwar XML, aber sie sind relativ gut
> > lesbares XML, das zumindest nicht schwerer lesbar ist als
> > der zugehörige C++-Code.
> 
> Genau das bezweifle ich. Schon allein die schiere Größe der XML-Dateien ist 
> ein Problem.

Sorry, ich hatte das UI-Format falsch in Erinnerung. Das dortige
XML ist nur als _Diff_ gut lesbar, siehe Punkt 5).

Das ist jedoch kein grundsätzliches Problem, siehe Punkt 4), denn
die Qt-Entwickler hätten das UI-Format ja auch folgendermaßen
gestalten können (identisches Beispiel wie deines):

    <QWidget name="tab" title="&Authors" layout="grid">
        <QTextEdit row="0" column="0" name="mAuthorText" readOnly="true"
                   textFormat="RichText" textSource=":/authors.txt"/>
    </QWidget>

Und _das_ wäre wiederum recht gut lesbar.

> Wenn ich den Text hart eincodiert hätte und auf die Fehlerprüfung verzichtet 
> hätte und den Kommentar weggelassen hätte, dann hätte ich den C++-Code auf 
> drei Zeilen /einkochen/ können.

Ohne Zeilenumbruch wäre mein Vorschlag auch 3 Zeilen. Will sagen,
es kommt auf das Sprach-Design an, und weniger auf das Metaformat
(hier: XML, könnte aber genauso gut auch JSON sein).

> > Davon abgesehen verstehe ich auch hier die Kritik nicht. Eine
> > komplexe GUI mit vielen Containern ist immer noch schneller
> > geklickt als gecoded. 
> 
> Pflegbarer Code ist auf Dauer /billiger/ als immer neu zusammenklicken.

Du vergleichst Äpfel mit Birnen.

Das Pflegen des Codes muss mit dem Bearbeiten der GUI im Qt-Designer
verglichen werden.

Und ja, der Qt-Designer nervt manchmal, genau wie die Qt-API manchmal
nervt. Für die Qt-GUIs, die ich bisher gebaut habe, bin ich mit Qt-
Designer ganz gut gefahren. Aber wenn ich eine GUI völlig flexibel
zusammenstecken muss, dann schreibe ich das natürlich in C++, weil's
nicht anders geht.

> Gerade 
> die GUI-Bindings sind Laufzeitfehler. Wenn sich mal jemand verklickt fällt das 
> unter Umständen erst sehr fiel später auf.

Nein.

Der UIC erzeugt eine *.h-Datei, die du direkt einbindest. Das ist
C++-Code, der normal durch MOC und GCC wandert. Es hat _genau_ die
selben Compilierungs- und Laufzeit-Eigenschaften wir der von Hand
geschriebene Code.

Du verwechselst hier vielleicht Qt mit GTK? Bei GTK werden die
Glade-UIs nämlich in der Tat erst zur Laufzeit geladen, und über
Strings referenziert. Das hat in der Tat hohes Problem-Potential.
Doch selbst in GTK kann man sich den C-Code auf aus der Glade-
Datei generieren lassen, wenn man will.

> Was die Fehlersuche erschwert. Mit 
> schwer lesbaren Code und Diffs wird die Sacher nicht leichter. So oft ändert 
> man an der GUI auch nichts, da es den Benutzer nur verwirrt. 

Da habe ich völlig andere Erfahrungen gemacht. Gerade in den Anfangs-
versionen baut man sehr viel an der GUI. Den Benutzer konnte ich dabei
nicht verwirren, weil von eben diesen ja die Änderungs-Aufträge kamen.

Außerdem wächst die GUI in dieser Phase recht schnell, weil die ersten
Versionen stets unvollständig sind. Und weil man wie im Quelltext nicht
immer nur dazupacken kann, muss man zwischendurch auch immer wieder
aufräumen, umordnen, etc.

Auch in späteren Releases stellt sich bei größeren Features immer
wieder die Frage, wie man sie am geschicktesten in die GUI integriert.
Man muss viel ausprobieren und anderen zeigen, bis man eine gute Lösung
hat, gerade _weil_ man auch nicht zu viel im Vergleich zu vorher umwerfen
möchte.

> Sich mal ein fraktionslosen Prototypen zusammen zu klicken, um sich über die 
> grundsätzliche Gestaltung einig zu werden, ist Okay. Es ist aber bei Qt-GUIs 
> nicht so wie bei Web-Applikationen, wo Graphiker Monate lang am Aussehen 
> feilen und die Programm-Logik nur 10% des Codes ausmachen.

Ich bezweifle, dass das Web-Applikationen anders ist als bei GUIs,
aber sei's drum:

Die GUI-Gestaltung macht schon einen wichtigen Teil aus, wenn auch
nicht den größten. Es ist schwer zu sagen, ob das Bearbeiten am
Quelltext oder das Bearbeiten im Qt-Designer schnellere Fortschritte
bringt. Beide Arbeitsweisen können zu hervorragenden wie auch zu
desaströsen Ergebnissen führen.

> Wenn ich im Editor an einer Zeile Code was ändere gibt es selten große 
> Überraschungen. Bei den GUI-Tools sehe ich nicht was ich wirklich tue.

Im Qt-Designer sehe ich ziemlich genau, was ich tue. Ich sehe zum
Beispiel, welche Attribute ich explizit setze und welche auf ihren
Standardwerten verbleiben. Auch im späteren Diff sehe ich genau, was
ich letztlich geändert habe und was nicht.

> Gut möglich, das ich ein totes Widget herumschleppe, weil es in der Klick-Umgebung 
> nicht zusehen ist. 

Der Qt-Designer bietet einen Widget-Baum, und alle GUI-Elemente
darin haben Namen - die man natürlich auch sinnvoll setzen sollte,
genau wie die Variablen im Quellcode vernünftige Namen brauchen.

Ich sehe ziemlich genau, was ich mit einhandele und was nicht.
Versteckte Widgets habe ich zumindest in Qt noch nicht erlebt.

> Die Diskussion ist vergleichbar mit der LaTeX vs OOWriter.

Die Analogie gefällt mir.

Dennoch spüre ich beim GUI-Design etwas andere Ansprüche und Zwänge
als beim Schreiben.

Ich sehe Qt-Designer und Qt-Konstruktion-Code viel dichter
beieinander als bspw. LaTeX und LyX/OOWriter.

Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR