[linux-l] Java-Geraffel auf Netbooks

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

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.

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

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.

Bis auf sehr, sehr, sehr wenige Ausnahmen ist es generell niemals
sinnvoll, automatisch erzeugte Dateien mit in die Versionskontrolle
zu packen. Denn das hat keinen Nutzen (nicht einmal der Performance-
Gewinn ist nennenswert) und macht nur Ärger.

> 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 *.ui-Dateien sind zwar XML, aber sie sind relativ gut
lesbares XML, das zumindest nicht schwerer lesbar ist als
der zugehörige C++-Code.

> Ü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. Wer kein Gefühl für gute GUIs hat, wird
beim Coden genauso versagen wie beim Klicken. Denn auch beim
Coden würde er den Weg des geringsten Widerstandes gehen, und
dann kommt ebenfalls Mist heraus.

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.

Einzige Ausnahme: Auf NeXT/MacOS bietet der GUI-Designer sehr
viele Anker und Raster beim Erstellen von GUIs an. So sind die
Elemente zwar absolut positioniert, doch sie können sich automatisch
vergrößern, verkleinern und verschieben, wenn sich die Größe des
Fensters ändert. Das hat zwar Nachteile gegenüber Containern,
aber diesen Nachteilen stehen zumindest auch ein paar Vorteile
gegenüber.

In jedem anderen System hingegen (Delphi, Glade, Qt-Designer, etc.) 
ist absolute Positionierung tödlich für das GUI-Design.

Aber deswegen muss man nicht gleich den Qt-Designer wegwerfen.
Man muss den Leuten nur rechtzeitig auf die Finger hauen, wenn
sie ihr Zeug absolut positionieren wollen.


Gruß
Volker

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