Hallo Jürgen, Juergen Sachs wrote:

Ich muß zugeben das ich mich mit dem Debugger noch nicht so beschäftigt habe. Sollte ich villeicht doch besser mal machen.

Ich persönlich setze sehr gern den Debugger ein, da man dann sehr gut sieht, ob tatsächlich alles so abläuft, wie man sich das gedacht hat. Ohne Debugger scheint oft alles in Ordnung zu sein, obwohl irgendwo etwas falsch berechnet wird und dergleichen. Unter Linux habe ich gute Erfahrungen mit kdbg gemacht. KDevelop kommt mit einem integrierten Debugger. Hab ich aber nie benutzt, kann also zu den Qualitäten keine Aussage machen. Unter Windows hat man mit dem Visual Studio ein hervorragendes Werkzeug. Der dort integrierte Debugger ist sehr leistungsfähig.

Ich will kein "Unnötiges" Fenster offen haben. Ich war schon am Überlegen das ganze in einem Fenster ablaufen zu lassen und nur den inhalt auszutauschen.

Da ich nicht weiß, was überhaupt Dein Programm können soll, kann ich nicht viel dazu sagen. Prinzipiell könntest Du auch das ganze als MDI-Anwendung aufziehen (dazu gibts auch ein Qt-Beispiel).

Was mich daran stört ist, das ich oft nur Seiten habe mit 10 Feldern aber auch mal größere Listen, was ein Bildschirmfüllendes Fenster voraussetzt.

QWidgetStack könnte Dein Freund sein.

Ich muß auch gestehen das ich im Moment nicht wüsste wie ich Dialoge, die im QTDesigner erstellt worden sind nur als "VGroup" oder "HGroup" einbinde.

Das ist nicht vorgesehen. Aber Du kannst natürlich jedes QWidget zu einem Dialog umgestalten, dann allerdings nur nichtmodal. Viele Grüße, Tilo -- Tilo Riemer & Frank Hemer GbR mailto:support@lincvs.com http://www.lincvs.com Dresden, Germany

Hallo, Am Thu, 10 Nov 2005, Bernhard Walle schrieb: [Debugger]

ddd ist auch nicht schlecht, zwar etwas älter aber sehr mächtig.

Aeh, gibt's da keine neuen Versionen? Ich hab hier in meiner ex-6.2 nen ddd-3.2.1 (SuSE 6.4, gebacken am Maerz 2000) und in der 9.1 nen ddd-3.3.8 von April 2004... Das UI kommt halt ohne QT oder GTK aus, laeuft dafuer aber unter jedem X11, auch ohne irgendne QT oder GTK-Version. Da alle Debugger fuer Linux, die ich kenne, sowieso letztlich auf dem gdb (GNU Debugger) aufsetzen ist mir eine GUI, die mir die Bedienung erleichtert, aber nicht gleich das ganze GTK/Gnome oder QT/KDE Geraffel nachzieht angenehm. BTW: als ich mir kdbg (der muesste auch von kdevelop verwendet werden, zumindest als kpart oder wie die aktuelle Version bei KDE-Komponenten heisst) angeschaut habe war das Teil ziemlich unbrauchbar. DDD hingegen war damals schon ausgereift. Ich finde es sowieso deprimierend, dass gerade "Programmierer" sich immer nur des allerneuesten Krams bedienen. Das ist ein Hauptgrund, warum ich QT/KDE praktisch nicht mehr verwende. Dieses staendige grundlos(!) aktualisieren muessen geht mir dermassen auf den Sack... -dnh -- Der IQ ist ein Wert, der aussagt, wie gut jemand in der Lage ist, eine bestimmte Sorte Tests zu absolvieren. Mir auf diesen Wert irgendwas einzubilden wäre genauso sinnlos, wie vor Stolz über meine riesigen Füsse zu platzen. [..] beides war einfach im Lieferumfang enthalten. -- G. Conrad

Hallo, Am Fri, 11 Nov 2005, Bernhard Walle schrieb:

David Haller [2005-11-11]:

...

Am Thu, 10 Nov 2005, Bernhard Walle schrieb: [Debugger]

...

ddd ist auch nicht schlecht, zwar etwas älter aber sehr mächtig.

Aeh, gibt's da keine neuen Versionen?

Doch, sind halt kleinere Bugfixes. Aber ich wollte eigentlich nichts gegen ddd sagen, meiner Meinung nach ist es die beste GDB-Oberfläche (von den unabhängigen, nicht in eine IDE integrierten).

Ich auch ;)

...

Ich hab hier in meiner ex-6.2 nen ddd-3.2.1 (SuSE 6.4, gebacken am Maerz 2000) und in der 9.1 nen ddd-3.3.8 von April 2004...

Das UI kommt halt ohne QT oder GTK aus, laeuft dafuer aber unter jedem X11, auch ohne irgendne QT oder GTK-Version.

Ja, gut, es braucht halt Motif (ob OpenMotif oder Lesstif). Ob ich jetzt Gtk oder Motif brauche ist letztlich egal.

Meins nicht: ldd `which ddd` | awk -F" => " '{print $1;}' | xargs echo libXp.so.6 libXpm.so.4 libXaw.so.6 libXmu.so.6 libXext.so.6 libXt.so.6 libSM.so.6 libICE.so.6 libX11.so.6 libncurses.so.5 libstdc++-libc6.1-2.so.3 libm.so.6 libc.so.6 /lib/ld-linux.so.2 Das der 9.1 aber schon (die libXm): libXm.so.3 libXaw.so.7 libXmu.so.6 libXt.so.6 libXpm.so.4 libXp.so.6 libXext.so.6 libX11.so.6 libSM.so.6 libICE.so.6 libncurses.so.5 libstdc++.so.5 libm.so.6 libgcc_s.so.1 libc.so.6 libdl.so.2 /lib/ld-linux.so.2

Ein großer Nachteil von Motif wegenüber Gtk und Qt ist der fehlende UTF-8 Support. Bei einem Debugger kann man aber damit leben, bei einem Texteditor (NEdit) ist es schon wieder nervig.

Naja, UTF-8 verwende ich sowieso noch nicht. Und eigentlich ist das doch nicht Sache des Grafik Toolkits sondern des Editors, der (X)Emacs kann ja auch UTF-8 und das bei mir als nicht mal Motif Anwendung (gleiche Xlibs wie ddd oben). Dass QT (>= ??) und Glib2 auch "convenience" Funktionen mitbringen ist halt ein Bonus dieser Libs. Dafuer hat man eben auch den Malus, dass die libs nicht gerade schlank sind ;) Und schliesslich gibt's ja auch die iconv-Routinen der glibc die ein Editor zum umkodieren verwenden kann...

kdb ist unabhängig von KDevelop (soweit ich weiß auch keine KParts-Komponente).

Scheint so, ja. -dnh -- cat /kat/ n. A furry keyboard cover

Hallo, Am Thu, 10 Nov 2005, Juergen Sachs schrieb:

Ah jetzt ja, hide gleich geschlossen. Jetzt wird einiges klarer. Ich ging von deleted = geschlossen aus.

Weder noch (oder zumindest sehr missverstaendlich formuliert). "hide" == versteckt -> Fenster ist nur "unsichtbar" "deleted" == geloescht -> Fenster existiert nicht mehr Ist ein Fenster "hidden", dann existiert es genauso wie zuvor (auch ohne "show" o.ae.), es koennen dessen Inhalte nach wie vor manipuliert werden, es wird _NUR_ nicht dargestellt. Ist es "deleted", ist es weg (oder sollte es zumindest sein). Termina koennen je nach Toolkit variieren. Beispiel: $ perl -e 'use Tk; use Data::Dumper; my $mw = new MainWindow(); $mw->Button( -text => "Hide", -command => sub { $mw->UnmapWindow(); print Dumper($mw); sleep 5; $mw->MapWindow(); print Dumper($mw); } )->pack; $mw->Button( -text => "Quit", -command => sub { $mw->destroy(); print Dumper($mw); } )->pack; Tk::MainLoop;' Das eigentliche "MainWindow" (das nach dem destroy noch uebrig ist) wird erst spaeter von perl/Tk abgeraeumt... Das Beispiel zeigt aber den Unterschied zwischen show()/hide() (hier MapWindow() / UnmapWindow()) und "new()/delete()" (hier new() / destroy())... Zu beachten ist noch, dass Tk::MainLoop[1] bzw. perl selbst noch diverses erzeugt und wieder aufraeumt usw. was bei anderen Toolkits und Programmiersprachen ggfs. per Hand zu erledigen ist (u.a. ist das saubere Beenden nach dem "destroy()" des Tk::MainWindow implizit, das script geht aber nach dem "MainLoop" noch weiter, vgl. [2]). -dnh [1] das auch ohne das 'Tk::' geschrieben werden kann, da von Tk exportiert [2] Fuege nach dem MainLoop noch ein 'exit 42;' ein und vergleiche per 'echo $?' den exitstatus des perlscriptes mit und ohne das 'exit 42;' am Ende... # ... Tk::MainLoop; exit 42;' -- "Wer nicht merkt das er Merkbefreit ist, dem sollte man eine Merkbefreiung für's Leben verpassen. D.B.D.D.H.K.P. Das macht Spass und tut nicht weh." [WoKo in dag°]