staging.inyokaproject.org

Hallo Leute,

Mich würde interessieren, ob man an einem Qt-Programm Interesse hätte, das Programme und Kommandos aufrufen kann. Das Programm stellt eine Shutdown- und eine Log-Option zur Verfügung, falls man nach dem Beenden des Programms oder Kommandos herunterfahren möchte. Konsolenausgaben sowie Fehlerausgaben werden jeweils (sofern man das möchte) abgespeichert.

Wenn jemand also z.B ein Programm kompilieren möchte, das Stunden dauert, kann man den PC anschließend automatisch herunterfahren lassen. Außerdem ist es auch möglich Programme oder Kommandos zu einem bestimmten Zeitpunkt starten zu lassen.

https://launchpad.net/~hakaishi/+archive/qt-program-starter

Also, was meint Ihr zu meinem Programm? - Habt Ihr Verbesserungsvorschläge?

Gruß, Hakaishi

Es ist jetzt eine neue Version verfügbar (die nicht mehr einfriert).
Hier gibt's noch die Source von mir -^_^-

Hat hier denn niemand eine Meinung zu meinem Programm?
Ein wenig konstruktive Kritik wäre durchaus wünschenswert...

Gruß, Hakaishi

Na dann:

Allgemein:

• README und src/resources.qrc sind ausführbar.

• „Protokoll“ sowie dessen englisches Original sind verwirrende Beschriftungen (v.a. im Englischen bezeichnet „protocol“ eigentlich etwas anderes). „Log action“ (bzw. „Aktion aufzeichnen“) oder so wäre besser …

• QTranslator für Qt-eigene Texte fehlt. Deswegen steht auch bei deutscher Spracheinstellung trotzdem „Cancel“ im Knopf.

main.cpp:

• Divergenz zwischen Kommentaren und Quelltext (im Kommentar steht fünf Sekunden, im Quelltext aber 3000 Millisekunden)

• Überflüssiger Dialog. Wenn die Anwendung bereits läuft, dann aktiviert man das laufende Exemplar und holt dessen Fenster in den Vordergrund, anstatt einen Dialog anzuzeigen, der den Nutzer selbst dazu auffordert. Noch dazu verschwindet dieser Dialog schnell wieder, so dass der Nutzer flott reagieren muss, um ihn überhaupt mitzubekommen.

• Dialog-Text ist nicht lokalisiert.

window.h:

• Die Dateien „window“ zu nennen, um darin dann eine Klasse Gui zu implementieren, ist bestenfalls ungewöhnlich.

• Verwende aussagekräftige Namen. Die meisten Deiner Namen sind das nicht. Gui, future, check, saved usw. und insbesondere i(!!) sind beispielsweise unglücklich bis richtig mies ...

• Entscheide Dich für eine Namenskonvention. Entweder camelCase() oder with_underscore(), aber nicht beides gleichzeitig. Übernehme bei Qt-Programmen am besten die Qt-Konventionen.

• Dokumentation der Attribute und Methoden fehlt.

• Q_OBJECT musst Du nicht kommentieren, das versteht jeder, aber wirklich jeder Qt-Entwickler (was man von future und i nicht sagen kann).

window.cpp:

• /etc/X11/default-display-manager ist nicht portabel. Probiere einfach alle Display-Manager durch, anstatt Dich auf irgendwelche distributionsspezifischen Konfigurationsdateien zu verlassen.

• all aus QString all = in.readAll() ist wieder ein schlechter Name. Das Du alles liest, sieht man an der Methode, der Name der Variable sollte sagen, was Du zu lesen erwartest (e.g. displayManagerName oder so).

• saved() ist kein passender Name für eine Methode, die in Wahrheit Einstellung lädt!

• QSettings-Methoden haben ein Argument für den Standardwert. Das Überprüfung darauf, ob die Datei existiert, ist daher Blödsinn, zumal die Datei ja auch existieren, aber keine Einträge enthalten kann. Auch die Vorgabe eines festen Pfads ist keine gute Idee. Richtig gehts so:

1
2
3
4
5

QSettings settings;
at_date->setChecked(settings.value("CheckBoxes/at_date", false).toBool());
proto->setChecked(settings.value("CheckBoxes/protocol", false).toBool());
shutd->setChecked(settings.value("CheckBoxes/shutdown", false).toBool());
textEdit->setText(settings.value("Text/text").toString());

Und in main.cpp dann organizationName und applicationName richtig setzen:

1
2

app.setOrganizationName("hakaishi");
app.setApplicationName("qt-program-starter");

• Wieso musst Du shutd unbedingt abkürzen? Der ausgeschriebene Name bringt Dich schon nicht um …

Deine Oberfläche ist auch nicht so glücklich entworfen. Zeige sie mal jemandem, der von der Funktionsweise des Programms keine Ahnung hat, und beobachte, wie lange er braucht, um das Programm zu durchblicken. Im Allgemeinen sollte eine Oberfläche für jemanden, der den Zweck des Programms kennt, aber nicht die genaue Funktionsweise, intuitiv verständlich sein. Deine Oberfläche ist das weniger.

Vor allem aber solltest Du Arbeit in Deinen C++-Stil investieren, und endlich mal sinnvolle Namen vergeben. Dieses Defizit ist mir schon das letzte Mal aufgefallen.

Ich find es schönder das ganze in GTK zu schreiben. Wie es aussieht wird es ja unter Gnome benutzt.

MFG

Man kann unter Gnome problemlos Qt-Programme nutzen. Qt integriert sich sehr gut in eine Gtk-Umgebung, besser als umgekehrt. Wahrscheinlich würdest Du den Unterschied zwischen einer Qt- und einer Gtk-Version nicht mal bemerken.

Naja. Ich bin ein Openbox Benutzer. Qt Anwendungen passen nicht so gut dort rein. Alleine schon vom Design. Hatte mein Projekt (http://forum.ubuntuusers.de/topic/bambus-2-1/) selber in Qt und GTK. Die Qt Anwendung wurde so gut wie nicht genutzt.

MFG

Endlich mal ein wenig Kritik!
Scheint, als müsste ich doch einiges noch mal überarbeiten. Vielen Dank Lunar.
Ich werde mich die Tage nochmal dran setzen. (Ich muss einige Klausuren schreiben...)

Gruß, Hakaishi

@Ying: Dein erster Beitrag sprach von Gnome. OpenBox ist etwas anderes, und wird als Nischenprodukt von Qt nicht wirklich berücksichtigt. Unter Gnome aber ist Qt sehr gut darin, sich möglichst in der Umgebung anzupassen.

Yop. Da hasste Recht.

hakaishi: Ich wünch dir noch ein gutes gelingen.

MFG

@Lunar:

• QTranslator für Qt-eigene Texte fehlt. Deswegen steht auch bei deutscher Spracheinstellung trotzdem „Cancel“ im Knopf.

Wie mache ich das? - Bis jetzt habe ich nichts gefunden -.-

• Überflüssiger Dialog. Wenn die Anwendung bereits läuft, dann aktiviert man das laufende Exemplar und holt dessen Fenster in den Vordergrund, anstatt einen Dialog anzuzeigen, der den Nutzer selbst dazu auffordert.

Wie kann ich dann auf die alte bzw. bereits gestartete Anwendung zugreifen, um sie in den Vordergrund zu holen?

• QSettings-Methoden haben ein Argument für den Standardwert. Auch die Vorgabe eines festen Pfads ist keine gute Idee. Richtig gehts so:

1 2 3 4 5

QSettings settings; at_date->setChecked(settings.value("CheckBoxes/at_date", false).toBool()); proto->setChecked(settings.value("CheckBoxes/protocol", false).toBool()); shutd->setChecked(settings.value("CheckBoxes/shutdown", false).toBool()); textEdit->setText(settings.value("Text/text").toString());

Und in main.cpp dann organizationName und applicationName richtig setzen:

1 2	app.setOrganizationName("hakaishi"); app.setApplicationName("qt-program-starter");

Wenn die Datei noch nicht existiert, werde ich wohl eine erzeugen müssen in der Vorgaben gesetzt werden, um diese dann abrufen zu können (Dein Code schreibt in keine Datei). Wenn ich die Datei ohne Abfrage ob die Datei existiert über QSettings erstelle, würde es die alte Datei überschreiben.
Wieso sollte ich keinen festen Pfad vorgeben? - Dann kann ich dem Anwender ja gar nicht sagen wo die Datei liegt (es sei denn sie liegt, egal auf welchem Betriebssystem immer in .kde, was ich aber nicht glaube).

Den QTranslator für Qt eigene Sachen:

1
2

QTranslator qtTranslator;
qtTranslator.load("qt" + QLocale::system().name(), ":/");

QSettings schreibt automatisch eine Datei, da brauchste dich garned drum zu kümmern.

@hakaishi: RTFM!

• Internationalization with Qt

• Writing Source Code for Translation

• QSettings

Du musst keine Datei erzeugen, um „Vorgaben“ zu machen. Dafür ist das zweite Argument defaultValue der QSettings::value()-Methode da. Damit kannst Du den Standardwert vorgeben, welchen die Methode zurück gibt, wenn die zu lesende Einstellung nicht existiert.

Einen festen Pfad gibt man nicht vor, damit Qt je nach System den passenden Pfad finden kann (siehe http://doc.qt.nokia.com/4.6/qsettings.html#fallback-mechanism), und damit man einfach mit dem Standard-Konstruktor QSettings-Exemplare erzeugen und trotzdem immer auf die selbe Konfiguration zugreifen kann. Und wieso sollte der Anwender wissen, wo die Datei liegt? Die Oberfläche ist doch dazu da, die Einstellungen zu setzen …

Um eine bereits laufende Anwendung zu kontrollieren, musst Du in dieser Anwendung Objekte über D-Bus exportieren. Wenn Du feststellst, dass die Anwendung bereits läuft, greifst Du über D-Bus auf ein solches Objekt zu, dass entsprechende Methoden zur Kontrolle der Anwendung anbietet.

@BodomBeachTerror: Dein QTranslator-Ansatz funktioniert nur, wenn man die Qt-Sprachdateien als Resource in die eigene Anwendung einbettet (was man nicht tun sollte). Außerdem beginnen die Sprachdateien mit "qt_".

Was ich nicht ganz nachvollziehen kann ist, warum ich keine Konfig-Datei so anlegen sollte, sodass der Anwender darauf zugreifen kann, wie es bei z.B. Mplayer und anderen Programmen möglich ist. Außerdem möchte ich es dem Anwender ermöglichen selbst eine Voreinstellung zu wählen. Für mich wäre es nervig jedes Mal wenn ich einen Haken setze, ihn beim nächsten Programmstart wieder zu deaktivieren bzw. entfernen.
Wie man übersetzt ist mir schon klar, aber wieso läuft das nur für die QDialogButtonBox nicht? - Was muss ich tun, damit das auch übersetzt wird?

Gruß, Hakaishi

hakaishi schrieb:

Was ich nicht ganz nachvollziehen kann ist, warum ich keine Konfig-Datei so anlegen sollte, sodass der Anwender darauf zugreifen kann, wie es bei z.B. Mplayer und anderen Programmen möglich ist.

Der Anwender kann doch darauf zugreifen, die Datei liegt nur an anderer Stelle (unterhalb von ~/.config). Dort legen die meisten Qt-Programme ihre Einstellungen ab.

Was muss ich tun, damit das auch übersetzt wird?

Siehe „Enabling Translation“. Soll ich Dir das auch noch vorlesen?