Qt-Designer

[Lykurg]

Hi,

Langsam aber sicher steige ich von der Handarbeit zu den nützlichen Helfern um! Nun stehe ich an folgendem Problem:
Im Qt-Designer mache ich ein "ui" für meine App. in dem ui.h kann ich die Slots beeinflussen. wie aber stelle ich es jetzt an, dass eine Slot in meiner Ursprungsdatei angesprochen wird?

Code: Alles auswählen

Main::Main()
    : ui_main( 0, "verben", WDestructiveClose )
{
}

void Main::test()
{
  [...]
}

Im Designer mit ui_main.ui soll ein Signal in der Menübar mit Main::test() verbunden werden.

Danke,
Lykurg

[jaegermeister]

Hi
Ich weiß nur das der QTDesigner bei jeder Änderung an der Grafik den Kompletten Code überschreibt.
Also leitet man am besten von den erstellten Oberfläche eine Klasse ab in der man seine Implementierungen macht.
Triff jetzt nicht dein Problem aber vielleicht hilft es ja.

Mfg jaegermeister

[Goos]

Hi,

Langsam aber sicher steige ich von der Handarbeit zu den nützlichen Helfern um! Nun stehe ich an folgendem Problem:
Im Qt-Designer mache ich ...

Danke,
Lykurg

Das kann ich nun nicht verstehen, du kannst es schon alles von Hand machen und steigst nun um auf den QT-Designer?
Meiner Meinung nach sollte man den Designer nicht benutzen und das Design lieber haendisch machen. Man hat dann zumindest ein paar Problemchen weniger.

Goos

[miketech]

Hi,

ich habe noch nicht wirklich mit dem Designer gearbeitet, deshalb kann ich nur Vermutungen anstellen Du hast also die ui_main mit dem Designer erstellt. Davon eine Klasse Main abgeleitet. Diese Klasse Main enthält nun eine Methode test(), die im Designer noch nicht festgelegt wurde, sondern per Hand ergänzt wurde beim Ableiten. Korrekt?

Dann musst Du nun im Grunde nur mit connect den Slot mit dem Signal verbinden. Also test() muss als slot definiert sein. Dann kannst Du mit

connect(this, SIGNAL(dassignalvondermenubar()), this, SLOT(test()));

die Connection herstellen. Das kannst Du ja direkt im Konstruktur Main() angeben. Ansonsten kannst Du im Designer, wenn Du mit der rechten Maustaste auf ein Element klickst die Connnections herstellen. Dafür müssen Slot und Signal aber bereits definiert sein, damit er das findet. Ich könnte mir vorstellen, dass Du die Methode test() irgendwie bereits in der ui_main mit angeben und dort bereits verbinden kannst und dann nur noch in der abgeleiteten Klasse Main überschreiben musst.

Weiß der Designer nichts von test(), musst Du das explizit angeben mit connect, wie oben beschrieben.

Gruß

Mike

[Lykurg]

Hi,

also der Designer erstellt mir eine Klasse namens "ui_main".

...bei jeder Änderung an der Grafik den Kompletten Code überschreibt

Ja, richtig, aber in der *.ui.h kann man schreiben, ohne dass es geändert wird, und bei der Neuerstellung wieder richtig mit eingebunden wird.

Aber die einfachste Möglichkeit das Signal mit dem Slot zu verbinden ist echt, dass direkt in der abgeleiteten Klasse zu machen. Hatte nur im ersten Moment gedacht, dass man das auch im Designer machen könnt, aber das ist dumm, und evtl. gar nicht möglich.

Und der Designer ist echt sinnvoll, wenn man eine Oberfläche mit "tausend" Layouts hat. (und bei mir geht das damit in den meisten Fällen schneller)

Lykurg

[Goos]

Und der Designer ist echt sinnvoll, wenn man eine Oberfläche mit "tausend" Layouts hat. (und bei mir geht das damit in den meisten Fällen schneller)

Lykurg

Nuja, es kommt darauf an, wieviel "tausend" nun wirklich sind
Du siehst ja, dass du nun noch zusaetzliche Zeit brauchst, weil du den Designer benutzt hast. (...ist natuerlich auch alles Uebungssache )
Ich kenne allerdings noch niemanden, der den Designer dauerhaft genutzt haette.

Goos

[miketech]

Guten Morgen,

wo wir schon beim Designer sind: Also ich habe bisher auch alles per Hand geschrieben, da ich vom Designer eben so gut wie keinen Plan habe und nur sehr selten bisher unter Linux etwas mit GUIs programmieren musste. Ist es denn möglich die einzelnen Widgets mit einem Layout-Manager anordnen zu lassen? Dass also Elemente automatisch an die aktuelle Fenstergröße angeordnet werden? Oder muss man sowas dann wieder von Hand machen?

Und: Wird normalerweies mit der Originalklasse gearbeitet, die im Designer erstellt wurde, oder wird die Klasse erst abgeleitet? Hat das jemand mal irgendwo nachlesen können, wie das normalerweise gehandelt wird? Ich bin selbst grad schon am googlen und derzeit schaut es so aus, dass man im QtDesigner wohl selbst noch neue Slots hinzufügen und die dann direkt mit den Signalen verknüpfen kann. Man kann dann bereits im QtDesigner die Slots mit Quellcode füllen, d.h. man könnte direkt mit der Klasse arbeiten, ohne vorher abzuleiten. Benötigt man Spezialisierungen der Slots, d.h. dass sich die Slots unterscheiden ist man dann doch gezwungen im eigentlichen Programm die Klasse abzuleiten und den Slot zu überschreiben.

Gruß

Mike

[miketech]

So,

bin bereits fündig geworden

http://doc.trolltech.com/3.3/designer-manual-5.html

Hier werden beide Konzepte vorgestellt. Kurz zusammengefasst:

Erstellt werden soll eine Klasse/GUI "Form":

Es gibt einmal die Möglichkeit die form.h und form.cpp erstellen zu lassen und in der eigentlichen Anwendung Form abzuleiten und nur mit der Ableitung zu arbeiten.

Seit QtDesigner 3 ist es nun aber auch möglich direkt eigene Slots zu integrieren, ohne dass der Quellcode jedes mal überschrieben wird. Der QtDesigner erstellt hierfür, wie Lykurg schon geschrieben hat noch eine form.ui.h, die von form.cpp eingebunden wird. Hier landet dann der Quellcode, der selbst geschrieben wurde. Wird diese Variante gewählt, kann ganz ohne Ableiten gearbeitet werden.

Also offensichtlich ist beides möglich. Es muss also jeder selbst entscheiden, was ihm lieber ist. Ob er mehr mit dem QtDesigner arbeiten und dort auch Implementierungen vornehmen möchte, oder QtDesigner wirklich nur zur Erzeugung der GUI nutzt.

Also ich persönlich favourisiere durch die Trennung von QtDesigner und Entwicklungsumgebung die zweite Methode: Im QtDesigner lediglich die GUI zusammenkleistern, dann zur Entwicklungsumgebung (in meinem Fall kdevelop) wechseln, bei Bedarf die Klasse ableiten und dann extern die Slots mit den Signalen verbinden.

Ich weiß nicht, wer von Euch auch kdevelop nutzt. Aber bald werden wir den QtDesigner in kdevelop integriert vorfinden. Ich könnte mir dann vorstellen auch die erste Variante zu nutzen: Dass man direkt in der form.ui.h rumbastelt, da man sich ja direkt in der IDE befindet und den Code testen kann, den man da baut. So wäre QtDesigner Bestandteil der Entwicklungsumgebung und nicht mehr ein reiner GUI-Creator. Aber ein ständiges Wechseln zwischen IDE und QtDesigner, um Fehler zu finden wäre mir dann doch zu aufwändig.

Gruß

Mike

[lepsai]

Also ich entwickle schon von Anfang an mit dem Designer und bin absolut zufrieden damit. Alles, was man sich vorstellen kann, lässt sich damit problemlos realisieren.

Meine Dateistruktur ist folgende:

form.ui - darin QMyForm

daraus erzeugt uic.exe

form.h und
form.cpp

form.ui.h - hier meine Implementierung

im Designer kann ich Slots, Variablen, Funktionen, Signals, forward declarations usw anlegen und dann in der ui.h editieren.

Wichtig: Um Konstruktor und Destruktor zu "überladen", deklariert man in dem Designer

void init()
void destroy()

diese spezielle Funktionen werden dann von Designer automatisch in form.cpp im Konstruktor bzw. im Destruktor eingefügt.

in der init() werden normalerweise dann alle benutzerdefinierte connect() Finktionen aufgerufen


Alternative Vorgehensweise ist die Vererbung von den vom QDesigner erzeugten Klassen, aber das führ zu einer hässlichen Struktur:

form.ui - Form
form.h - class Form
form.cpp
formimpl.cpp
formimpl.h - class EndlichMeineForm : public Form

also für eine form habe ich dann fünf dateien plus moc-dateien, die dann noch hinzukommen.

[pm_Snake]

Ich benutze den Designer nichtmehr. Hatte mein erstes Qt-Projekt damit angelegt und nun nervts mich jedesmal für Änderungen den Designer anwerfen zu müssen....

Ohne Desigern, mit Layouts alles per Hand kann ich besser arbeiten. Aber das ist wohl eher Geschmackssache