Einfache Freepascal IDE

[schöni]

Hallo!

Zitat:

Das heisst, dass IDE, Compiler und Debugger auf einem fremden System unter möglicherweise anderem Betriebssystem laufen. Lediglich die Anzeige läuft auf dem lokalen Computer.
Da fp in einem Textterminal angezeigt wird, sind die Anforderungen an die Übertragungskapazität vom/zum entfernten Rechner niedrig.

Zitat:

Ich muss die Lazarus Version des Debuggers verwenden, wegen der Portabilitätsprobleme und wegen des
von Embarcadero verschiedenen Debuginfo Formates.

Wie umfangreich werden da die Änderungen, um die Übertragung der Botschaften statt mit Windows Messages mit SSH zu machen?

Das wäre dann gdb. Die Dokumentation ist hier:
http://sourceware.org/gdb/current/onlinedocs/gdb/
Beachte vor allem den Bereich GDB/MI.
Bei Remote-Debugging läuft lediglich ein Teil des Debuggers (gdbserver) und das zu testende Programm auf dem entfernten Rechner. Die Verbindung von gdb (läuft auf dem lokalen Rechner) und gdbserver (läuft auf dem entfernten Rechner) geschieht dabei z.B. mit TCP/IP und passiert gdb intern, darum musst du dich nicht kümmern.

Martin

Aber, wo kriege ich die Quelltexte des Debugservers her. Habe soeben im Lazarus Verzeichnis danach gesucht und nur die Binärdatei desselben gefunden. Für GDB/MI gibt es die Klasse TGDBMIDebugger, die im Quelltext dabei ist. Ich kämpfe noch immer um den Erhalt der relevanten Debuginfo.

Falls die gedbServer und Cvdwarf Quellen nur in c verfügbar sind, ist die Interfacebeschreibung wichtiger. In c kennen ich mich nicht so gut aus, das ich von den Quellen allzu viel profitiere.

Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"

Dort erhalte ich die Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.

Ich würd gerne diese Teil als Debugserver verwenden, weil ich da, so das fehlerfrei arbeitet, alle wichtigen Debuginfos bereits erhalte. Im debugtest-Beispielprogramm werden alle Ausgaben in ein Textfenster geschrieben. Unter Windows kann ich dieses Programm so starten, das es beim Start der IDE unsichtbar bleibt, so das ich nur einen Mechanismus implementieren muss, der die Debuginfo zur IDE überträgt.

Aber vielleicht ist ja das Interface des gdbServer und Cvdwarf wirklich günstiger.

Ich habe in einem zweiten Tab meines Mozilla Browsers die oben genannte GDB Dokumentation geöffnet.

In welchem Abschnitt derselben finde ich die relevanten Informationen gdbServer und Cvdwarf. Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode. In der Unit Debugger.pp gibt es den Typ TGDBLocationRec, der diese Information bereit stellt.

AUßerdem brauche ich den Verlauf des Aufruf Stack und ggf. die Liste der Haltepunkte.

Ne richtige standardiesierte Schnittstelle zum bereits vorhandenen Debugger ist ja allemal besser, als irgendeine zuasammengefrickelte eigene Lösung.

Bei der Textmode-IDE habe ich die Units gdbInt.pp und gdbCon.pp gefunden, die aber nicht vollständig implementiert sind, Das wird erst später in einer anderen aif die IDE bezogenen Unit nachgeholt. Lazarus nutzt wiederum ein anders aufgebautes Debuggerinterface.

MinGW-Verzeichnis von Lazarus hab ich nur die Binärdateien. Im FPC Verzeicnis gibt es noch debugsvr.pp im Verzeichnis debudSvr oder ähnlich. Die dort befindlichen Units setzen aber die Unit Linux voraus. Damit scheiden die auf der Windows Plattform aus.

[schöni]

Zitat:

Zitat von Hisoka

Der Name Hinter WINE sagt nicht alles. Aber der wichtige Punkt ist, niemand will eine halb funktionierende IDE

Ok, die IDE ist auch noch nicht richtig fertig. Da gibt es noch ordentlich Arbeit für mich.

Zitat:

Zitat von Hisoka

und erst recht will niemand ein Windows Programm unter Linux laufen lassen wenn es nicht notwendig ist. Da sich WINE Anwendungen nicht ins System einpflegen und da die WinAPI nur teilweise funktioniert, ist eine solche Lösung nie optimal.

Hmmm! Unten in Deinem Beitrag sagst Du ja auch, das zum Beispiel die Tabs dort nicht funktionieren.
Das ist natürlich ein schlagendes Argument für Native Anwendungen! Ok!

Zitat:

Zitat von Hisoka

Also so würde es wohl kein ersatz werden. Auch glaube das die Free Pascal Entwickler keine IDE wollen würden die nicht portabel ist. Denn viele der Lazarus/FPC Entwickler stammen aus dem Linux Lager und dort will man native Anwendungen.

Verständlich! Schade, das sich die Pascal Dialekte von Delphi und Lazarus unterscheiden, sonst wäre eine Portierung möglich.

Zitat:

Zitat von Hisoka

Ich glaube ich Spreche für viele Linux Nutzer wenn ich sage: Ich nutze lieber VIM zum Entwickeln als eine IDE die WINE nutzt. Gerade im Delphi Bereich dürften die Linuxnutzer immer noch ein Trauma von Kylix haben, denn das war genau das was du versuchst und es wurde schlecht akzeptiert.

VIM kenne ich nicht. Ich kenne den Editor VI. Der ist mir aber zu kryptisch.

Zitat:

Zitat von Hisoka

Zur IDE selbst:
sie startet zumindest unter WINE, aber wirklich toll ist sie nicht. Also selbst der Lazarus Code Editor scheint besser zu sein. Da muss also noch etwas nach gebessert werden.(Tabs funktionieren nicht)

Hmmmm, da haben wir's. Da ist eine Native Anwendung wirklich besser. Wie gut funktioniert MDI? Oder wäre dann, wenn schon WINE, SDI das Konzept der Wahl?

Zitat:

Zitat von Hisoka

dazu können "X" zum schließen von Tabs nicht schaden.

Das ist ein ganzes Stück schwieriger zu realisieren, denn bei der PageControl Komponente fehlen die "X" oder ich habe die passende Einstellung noch nicht gefunden. Einen TSpeedbutton auf das Tabregister setzen? Hab ich noch nicht probiert. Kann ich aber mal testen.

Bei den SpTBX Komponenten gibt es ein PageControl, das diese "X" auf jedem Tab standardmäßig bereit stellt. Aber der Test auf WINE hat ja mit der bisher von mir verwendeten PageControl Komponente schon mal ergeben, das dann die Tabs nicht funktionieren. Um die Tabs aus dem SpTBX PageControl zu testen müsste ich einen Dummy Applikation bauen, die diese Page Control verwendet. Die müsste dann auf WINE getestet werden.

Das dürfte aber dann nicht mehr auf Freepascal zu portieren sein, es sei denn die nueu Freepascal Version kann wirklich Delphi Quelltext ohne Änderung übersetzen, wie das schon behauptet wurde.
Allerdings weiß ich nicht, ob diese Komponenten auch für Linux verfügbar sind.

Zitat:

Zitat von Hisoka

Auch frage ich mich was die Leiste unten soll. Sie nimmt Platz weg und bringt nichts oder?

Die Leiste wird in der nächsten Version nicht mehr sichtbar sein! Die hatte ich eingebaut, weil sie in der Textmode IDE vorhanden ist. Das die Liste nix bringt, kannst Du nicht so sagen, denn die Buttons sind mit der angegebenen Funktionalität hinterlegt. Entweder die angegebene Funktionstaste drücken oder den Button mit der Maus anklicken. Außer F1. Die Hilfe folgt erst noch.

Zitat:

Zitat von Hisoka

Für später wären Programmvorlagen vielleicht nicht schlecht.

Ok, werde ich berücksichtigen. Hab ich eh vor, einzubauen!

Zitat:

Zitat von Hisoka

Ansonsten ein netter Anfang aber wie schon erwähnt nichts für mich. Ich mag es wenn die Anwendungen in meinem System einheitlich sind.

Das ist subjektiv. Mit gefällt dafür VI nicht.

[mse1]

Zitat:

Zitat von schöni

Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode.

In GDB/MI.
Zur Kommunikation mit gdb gibt es mehrere Möglichkeiten. Eine erste IDE (die ich nicht erwähnen darf) benützt die Library libgdb, zwei andere IDE's (die ich ebenfalls nicht erwähnen darf) benutzen pipes zur gdb Applikation. Ersteres ist problematisch, da libgdb nicht mehr zum Lieferumfang der gdb Distribution gehört.

Zitat:

Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"

Dort erhalte ich die Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.

Ich würd gerne diese Teil als Debugserver verwenden, ...

Dieser Code ist möglicherweise GPL was bedeutet, dass du den gesamten Quelltext veröffentlichen musst, falls du dein Produkt weitergibst. Möglicherweise auch den Code der Delphi units was durch die Delphi Lizenz verboten wird.
Das ist natürlich auch wieder OT, sorry.

[mkinzler]

Man darf andere hier schon nennen, aber hier bitte nicht deren Fehler usw diskutieren

[schöni]

Zitat:

Zitat von mse1

Zitat:

Zitat von schöni

Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode.

In GDB/MI.
Zur Kommunikation mit gdb gibt es mehrere Möglichkeiten. Eine erste IDE (die ich nicht erwähnen darf) benützt die Library libgdb, zwei andere IDE's (die ich ebenfalls nicht erwähnen darf) benutzen pipes zur gdb Applikation. Ersteres ist problematisch, da libgdb nicht mehr zum Lieferumfang der gdb Distribution gehört.

Am liebsten wäre mir auf der IDE Seite ein einheitliches Interface, das so beschaffen ist, das ich später auch einen Embarcadero Debugger anschließen kann, wenn ich mit einem Delphi Compiler VCL Code übersetzt habe. Dann könnte mir einfallen, die IDE auf Visual C++ zu erweitern und brauche vielleicht einen Microsoft Debugger, wegen der unterschidlichen Formate der Debuginformationen.

Solch einheitliches Interface hab ich für zukünftige Versionen der IDE eh geplant und zwar so, das ich, während ich jetzt Klassen anspreche, die mir meine Aufgabe erledigen, stattdessen ein geeignetes Interface baue und dann anspreche, wobei die Implentation als Plugin realisiert wird. Mehere .dll mit der Funktionalität. Kommt aber erst später, wenn die Basisfunktionen der IDE alle drin sind.

Gibt es dieses einheitliche Debuggerinterface oder ist es da geschickter, 3 verschidene Interfaces zu bauen? Die Erkennung des aktuell auszuwählenden Interfaces könnte über eine Kennung in der .exe erfolgen, ob dwarf, omf oder coff Format. Oder an Hand des Compilernamens. fpc.exe -> dwarf; gcc.exe->dwarf; bcc*.exe->omf; dcc*exe,oxygen.exe->omf vcc.exe->omf.

Warum darfst Du die IDEs nicht erwähnen? Das Du mir davon den Quellcode nicht unbedingt zugänglich machen darfst, verstehe ich. Aber die IDE verschweigen?

Mit Pipes hab ich experimentiert. Problem ist dort, das ich bei Informationsaustausch nicht weiß, was für ein Ereignis da den Empfang von Daten signalisiert. Sobald ich aber Windows Messages verwende, bin ich Plattformabhängig.

Habe dann ein DP Beispiel zu named pipes mit Formularen angeguckt. Da kann ich einen Datensatz senden. Der Emfänger sinalisiert den Emfang der Daten jedoch durch ButtoClick. Ich brauch aber ein Ereignis, das den Datenempfang signalisiert und bei Auftreten des Ereignisses die Daten anzeigt.
Gibt es da was in den Tiefen der VCL?

Dann bin ich auf WM_CopyData gestoßen, was aber wieder eine Windows Botschaft ist und damit plattformabhängig.

Ich könnte mir vorstellen, das die Namenskonvention für Pipes plattformübergreifend gültig ist. Aber das Öffnen der Pipe? Es ließe sich natürlich eine Schnittstelle mit eigenen Aufrufroutinen- oder Methoden bauen.

Zitat:

Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"

Dort erhalte ich die Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.

Ich würd gerne diese Teil als Debugserver verwenden, ...

Dieser Code ist möglicherweise GPL was bedeutet, dass du den gesamten Quelltext veröffentlichen musst, falls du dein Produkt weitergibst. Möglicherweise auch den Code der Delphi units was durch die Delphi Lizenz verboten wird.
Das ist natürlich auch wieder OT, sorry.[/quote]

So weit wie ich die GPL verstanden habe, dürfte ich nur verpflichtet sein, den Quelltext der GPL Teile weiter zu geben. Das wäre dann das angepasste Programm des Debuggerbeispiels. Für den Rest dürfte die Nennung einer Bezugsquelle ausreichen. Dabei berufe ich mich auf Lazarus 0.9.22, da dort der aktuelle EConverterror nicht aufgetreten ist, den ich in der 0.0.24er Lazarus Version erhalte, sobald ich nach der Initialisierung des Debuggers den ersten Programmschritt ausführe.

Quelltext den ich dann auf jeden Fall weitegeben muss, wäre wie gasgt mein verändetes Programm. Konkret betrifft das die Unit DebugtestForm. Werde wohl dann das geänderte Programm samt seinem Quellcode der IDE beilegen. Zum erneuten Übersetzen sind dann halt noch die von mir nicht veränderten Dabuggerunits nötig, die dann nicht Bestandteil meiner IDE werden, sondern im Lazarus Projekt zu finden sind.

Werde sehen, welchen Workaround ich für den EConvertError finde. Vielleicht sollte ich mir Lazarus 0.0.22 wieder installieren. Dann müsste ich auf jeden Fall nur das von mir geänderte Beispielprogramm weiter geben.

Bei der Suche nach dem EConvertError verlangt der Lazarus Debugger nämlich ständig neue .inc Dateien, die ich dann mühsam suchen muss, um sie ins Projekt einzubinden, damit ich mich zur Fehlerstelle vortasten kann. Eh ich mich da verpflichte diese .inc Dateien mit weiter zu geben, weil da vielleicht Änderungen nötig werden, installier ich mir eheer wieder die vorangegangene Lazarus Version. Mit der gab es den EConvertError nicht. Dann muss ich auch keine geänderten .inc Dateien weiter geben.

Andere Quellen, die ich genutzt habe, hab ich ja nicht verändert und sind daher im Lazarus Projekt einzusehen. Ich weiß, das ich, statt die Quelltexte selber weiter zu geben, auch eine Quelle nennen kann, wo die Quelltexte zu erhalten sind. Wenn die IDE nicht Bestandteil von Freepascal wird, werden die von mir nicht veänderten Quellcodes auch nicht zum Übersetzen gebraucht.

Das hier habe ich soeben in der Wikipedia zur GPL gefunden:

Zitat:

Alle abgeleiteten Programme eines unter der GPL stehenden Werkes dürfen von Lizenznehmern nur dann verbreitet werden, wenn sie von diesen ebenfalls zu den Bedingungen der GPL lizenziert werden.

Der Debugserver wäre dann das abgeleitete Programm, das aus dem Testbeispiel hervorgegangen ist. Die IDE greift darauf nur zu. Das passiert mit Nachrichten. Als .dll einbinden dürfte am Binärformat scheitern. Hab da scon mal Versuchre gemacht. Statisch in die IDE einbinden klappt somit auch nicht. Habe Versuche sowohl mit LoadLibrary() als auch mit DLL-Interfaceunit gemacht. Hat beides nicht funktioniert. Und mit Delphi die Debuggerteile übersetzen scheitert an den Unterschieden im Pascaldialikt. So bleibt der Debugserver ein selbständiges Programm, womit ich bei der IDE weitehin volle Entscheidungsfreiheit bezüglich der Lizenz haben dürfte.

Anders wäre es, wenn ich als Quellcodeeditor den aus Lazarus verwenden würde. Dann wäre auch die IDE unter GPL zu stellen.

[schöni]

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Werd mal versuchen, die Toolbar, die ich mittels der Toolbar 2000 Komponenten gebaut habe, so zur Laufzeit zu Instantiieren, das die Kompos nicht mehr installiert sein müssen. SpTbx macht noch nix weiter, ist zur Laufzeit unsichtbar. Die Bezüge dazu in der .dfm Datei können daher bedekenlos entfernt werden. Werde das mal in meiner IDE auch für Toolbar 2000 probieren und dann die Toolbar komplett zur Laufzeit erzeugen. Das gleiche habe ich mit den Sysnedit KOmpos auch vor, da ich hier wegen der Codevervollständigung eh einen neuen Syntaxeditor ableiten will. Den kann ich dann auch gleich so in die IDE einpflegen, das alles nötige zur Laufzeit passiert.

Zitat:

Also an schöni: Mein Lob, weiter so!

Danke!

[cookie22]

Zitat:

Zitat von schöni

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Werd mal versuchen, die Toolbar, die ich mittels der Toolbar 2000 Komponenten gebaut habe, so zur Laufzeit zu Instantiieren, das die Kompos nicht mehr installiert sein müssen. SpTbx macht noch nix weiter, ist zur Laufzeit unsichtbar. Die Bezüge dazu in der .dfm Datei können daher bedekenlos entfernt werden. Werde das mal in meiner IDE auch für Toolbar 2000 probieren und dann die Toolbar komplett zur Laufzeit erzeugen. Das gleiche habe ich mit den Sysnedit KOmpos auch vor, da ich hier wegen der Codevervollständigung eh einen neuen Syntaxeditor ableiten will. Den kann ich dann auch gleich so in die IDE einpflegen, das alles nötige zur Laufzeit passiert.

Zitat:

Also an schöni: Mein Lob, weiter so!

Danke!

was ist an toolbar 2000 schlecht, ausser das man sie installieren muss. durch sptbx kannst du dein programm halbwegs professionell aussehen lassen warum willst du auf sowas verzichten.

[schöni]

Zitat:

Zitat von cookie22

Zitat:

Zitat von schöni

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Werd mal versuchen, die Toolbar, die ich mittels der Toolbar 2000 Komponenten gebaut habe, so zur Laufzeit zu Instantiieren, das die Kompos nicht mehr installiert sein müssen. SpTbx macht noch nix weiter, ist zur Laufzeit unsichtbar. Die Bezüge dazu in der .dfm Datei können daher bedekenlos entfernt werden. Werde das mal in meiner IDE auch für Toolbar 2000 probieren und dann die Toolbar komplett zur Laufzeit erzeugen. Das gleiche habe ich mit den Sysnedit KOmpos auch vor, da ich hier wegen der Codevervollständigung eh einen neuen Syntaxeditor ableiten will. Den kann ich dann auch gleich so in die IDE einpflegen, das alles nötige zur Laufzeit passiert.

Zitat:

Also an schöni: Mein Lob, weiter so!

Danke!

was ist an toolbar 2000 schlecht, ausser das man sie installieren muss. durch sptbx kannst du dein programm halbwegs professionell aussehen lassen warum willst du auf sowas verzichten.

Gar nicht. Werde ein Interface bauen, das solche Toolbars oder das PageControl von SpTBX aber auch PageControl wahlweise verwenden kann. Sollte ja mit Interfaces gehen. Wem dann die Toolbar2000 KOmpos oder die SpTBX nicht gefallen, kann ja andere verwenden.

Ist allerdings noch ein Stück Arbeit. Will erst mal Debugger + Codevervollständigung abschließen.

Zitat:

Zitat von ein anderer DP User

Das heisst, dass IDE, Compiler und Debugger auf einem fremden System unter möglicherweise anderem Betriebssystem laufen. Lediglich die Anzeige läuft auf dem lokalen Computer.
Da fp in einem Textterminal angezeigt wird, sind die Anforderungen an die Übertragungskapazität vom/zum entfernten Rechner niedrig.

Stimmt natürlich, wenn die IDE auf dem entfernten Rechner läuft. Das spräche für den Textmode. Wie aber wäre es, wenn die IDE so konfiguriert wäre, das sie wie ein Internetbrowser die Quelldateien von Server holt und am lokalen Rechner anzeigt und bearbeitet? Das Kommando zum Übersetzen müsste natürlich dann abgesetzt werden, das sind aber nicht allzu viele Bytes, es sei denn, der Compiler könnte den geänderten Quelltext von meinem lokalen Rechner übersetzen, obwohl der Compiler auf dem entfernten Rechner liegt. Dann müssten natürlich nahezu alle IDE Kommandos als Netzwerkanforderungen ausgelegt werden. Wäre ein anderes, aber hochinteressantes Konzept. Dann könnte die IDE auf dem lokalen Rechner grafisch sein, weil ja über Netz nur Kommandos übertragen werden. :gruebel:

Werd aber erst mal mein bisheriges Konzept weiter verfolgen. Erweiterungen folgen später.

Hmmm, werd mir mal die Compilerfarm auf Sourceforge angucken. Hab mich bisher immer davor gedrückt. :gruebel:


Kleiner Nachtrag:

Werde mir bezüglich Debugger ne ganz andere Lösung einfallen lassen müssen. Lazarus spinnt mit der Fehlermeldung "MyDBGprg.lpr(15,1) Error:Can't create object file: MyDBGprg.exe"

ALs Folgefehler kommt natürlich die Meldung, das die .exe nicht erzeugt werden kann. Keine Ahnung, was da wieder schief läuft. Aber ich bleibe dran. Allerdings wird der Debugger unter diesen Umständen auf jeden Fall Closed Source. Anderenfalls brauch ich wirksame Hilfe.

FR. 12.02.2010:
Hab aber heute Morgen eine Lösung mit Schnittstelle gefunden. Die ist aber eh nich plattformunabhängig. Der gdbServer sieht allerdings viel versprechend aus. Mal schauen..

[Florian Hämmerle]

Hi

Ich wollte mal fragen wie weit die Entwicklung schon vorangeschritten ist?

mfg Florian

[schöni]

Zitat:

Zitat von Florian Hämmerle

Hi

Ich wollte mal fragen wie weit die Entwicklung schon vorangeschritten ist?

mfg Florian

Nun ja, ich habe die Optik bissl verbessert und kämpfe noch mit der Debuggerschnittstelle.

Die neue Optik, (nur geringfügig verändert), kann hier schon mal bewundert werden. Will sie nicht an den Threadanfang stellen, da die Änderungen marginal sind. Nur die Werkzeugleiste bissl erweitert. Das sind jetzt auch nur 2 Screenshots, weil der Debugger noch nicht enthalten ist. Die Schnittstelle arbeitet noch nicht korrekt. Deshalb gebe ich die neue Version auch noch nicht raus.