[linux-l] Java-Geraffel auf Netbooks

Olaf Radicke briefkasten at olaf-radicke.de
Mi Jun 16 00:55:14 CEST 2010


Am Freitag 11 Juni 2010, 23:32:58 schrieb Volker Grabsch:
> Olaf Radicke <briefkasten at olaf-radicke.de> schrieb:
> > On Fri, Jun 11, 2010 at 07:54:28PM +0200, Volker Grabsch wrote:
> > > "Es macht einfach Spaß." Das trifft es. Gut gelungen ist übrigens auch
> > > die IDE, die Qt mitliefert (Qt Creator).
> > 
> > Qt-Creator generiert XML-Code der vom MOC (Meter Object Compiler) zu
> > C++ umgewandelt wird, was dann der g++ weiter verarbeitet.
> 
> Kann es sein, dass du Qt-Designer (zum Zusammenklicken von GUIs)
> und Qt-Creator verwechselst?

Aye!

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

> > Der Nachteil liegt auf der Hand: Wenn ein Programmierer im Projekt
> > etwas Ändert, lässt sich das mit Git schwer nachvollziehen was
> > gemacht wurde. Du müsstest dir die alte Version wieder auschecken,
> > übersetzen und noch mal anschauen.
> 
> Falls du den Qt-Desginer meinst: Wenn ich in der GUI was ändere,
> ändert sich auch nur dieser Bereich im XML. Das daraus entstehende
> Diff ist gut lesbar.

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

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

> Selbstverständlich liegen bei mir nur die Quelldateien im Repository,
> also XML-GUI-Beschreibungen (*.ui), Programmcode (*.cpp, *.h) und
> die Projektdatei (Projekt.pro).
> 
> Nichts weiter. Wer das Project auscheckt (bzw. klont), der macht
> zuerst ein "qmake", dann "make", und alles ist gut.

Es geht darum wie viel Zeit man bracht Code zu verstehen und Fehler zu 
beseitigen oder Funktionen hinzu zu führen. Vielleicht auf unterschiedlichen 
Plattformen mit unterschiedlichen Tools. 

Das ist wie bei der Feuerwehr. Erst wenn es Brennt, stellt man fest, das die 
Fluchtwege verstellt sind, die Rauchmelder von der Rauchern in der Toilette 
manipuliert wurden, das Schild der Brandmeldezentrahle abgefallen und die 
Feuerwehrzufahrt zugeparkt ist. 

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

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

=================== C++-Code begin ===================

        // #### Autors ####
        this->autorsTextBox = new QTextEdit();
        this->autorsTextBox->setReadOnly(true);
        QFile _authors_file(":/authors.txt");
        if (!_authors_file.open(QIODevice::ReadOnly | QIODevice::Text))
        {
            _komplet = tr("Error: loding \":/authors.txt\" is failed!");
            this->autorsTextBox->setText(_komplet);
        }else
        {
            QTextStream _authors_stream(&_authors_file);
            _komplet = "";
            while (!_authors_stream.atEnd()) {
                _komplet += _authors_stream.readLine();
            }
            this->autorsTextBox->setText(_komplet);
        }
        this->tabWidget->addTab(this->autorsTextBox, tr("Autors"));


=================== C++-Code end ===================


=================== XNL-Code begin ===================

            <widget class="QWidget">
                <property name="name">
                    <cstring>tab</cstring>
                </property>
                <attribute name="title">
                    <string>&Authors</string>
                </attribute>
                <grid>
                    <property name="name">
                        <cstring>unnamed</cstring>
                    </property>
                    <widget class="QTextEdit" row="0" column="0">
                        <property name="name">
                            <cstring>mAuthorText</cstring>
                        </property>
                        <property name="textFormat">
                            <enum>RichText</enum>
                        </property>
                        <property name="text">
                            <string><strong>Jeremy 
Erickson</strong><BR 
/><em>jerickson314 at users.sourceforge.net</em><br 
/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Original author. If you 
e-mail me, be sure to include the name of this program in the message to 
bypass my spam filter.<br /></string>
                        </property>
                        <property name="readOnly">
                            <bool>true</bool>
                        </property>
                    </widget>
                </grid>
            </widget>


=================== C++-Code end ===================

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. 

> > Über usebility kann man ja streiten, aber bei der alten GUI von
> > BibleMemoritzer hatte ich das Gefühl, das bestimmte Dinge sehr
> > /holzig/ in der Bedienung waren, weil er Derjenige der die GUI
> > mit Qt-Creator zusammengeklik hat, den Weg gegangen ist, der
> > sich am einfachsten zusammen klicken lässt.
> 
> Auch hier: Du meinst wohl Qt-Designer.
> 
> 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. Gerade 
die GUI-Bindings sind Laufzeitfehler. Wenn sich mal jemand verklickt fällt das 
unter Umständen erst sehr fiel später auf. 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. 

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.

> Der einzige wirkliche Vorteil des Codens per Hand ist doch der,
> dass die Leute erst gar nicht in Versuchung geraten, die Elemente
> absolut zu positionieren. Denn _das_ ist tatsächlich ne Krankheit.
> Mit Containern wie HBox, VBox, Grids, etc. sollte man schon
> umgehen können.

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. Gut 
möglich, das ich ein totes Widget herumschleppe, weil es in der Klick-Umgebung 
nicht zusehen ist. 

Die Diskussion ist vergleichbar mit der LaTeX vs OOWriter.

Olaf


-- 
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/3.0/de/



Mehr Informationen über die Mailingliste linux-l