Einfache Freepascal IDE

[schöni]

Hallo!

Jetzt möchte ich Euch mal ein kleines Projekt vorstellen. Es handelt sich um eine sehr einfach gehaltene IDE für den Freepascal Compiler.

Zu diesem Projekt motiviert wurde ich einerseits durch den Umstand, das der Freepascal Compiler, von Lazarus abgesehen, noch immer mit der etwas angestaubten Turbo Vision IDE geliefert wird, obwohl es leistungsfähige Windowas Entwicklungsumgebungen gibt. Wenn das Freepascal Team von dem einige, wie ich den Eindruck gewonnen habe, auch hier in der DP angemeldet sind, bereit ist, diese IDE an Stelle der alten, mit FreeVision geschriebenen zu verteilen, werde ich den Debugger noch versuchen, nachzurüsten und ebenso die Codevervollständigung. In diesem Fall wird diese IDE OpenSource.

Andererseits fasziniert mich der Formulardesigner von Delphi. Weil es da zahlreiche Nachbauten gibt, die ich gerne nachvollziehen möchte und außerdem mir eine Lösung hirfür unter Nutzung von Quellcode aus der DP und aus dem sonstigen Internet zusammengestellt habe, brauche ich vollständigkeitshalber eine IDE, in die ich diesen Designer einbauen kann. In der vorliegenden Version der IDE ist jedoch kein Form-Designer eingebaut.

In dieser Version gibt es noch keinen intergrierten Debugger, obwohl die Menüeinträge dafür bereits vorhanden sind. Auch gibt es noch keine Codevervollständigung, obwohl auch hier die Menüeinträge dafür vorhanden sind. Werden die betreffenden Menüeinträge ausgewählt, passiert nichts, außer dem Schließen des Menüs.

Auch funktioniert der Aufruf des Konsolenfensters noch nicht im Menü "Datei->DOS aufrufen".
Die integrierte Hilfe, folgt, wenn die IDE fertig ist. Das ist der Fall, wenn alle Funktionen, die im Menü sichtbar sind, auch alle funktionieren.

Der Freepascalcompiler muss über das Menü "Tools->Tools einrichten" in die IDE integriert werden.
Das funktioniert exakt so, wie das mit dem Einrichtungsdialog der Delphi IDE funktioniert. Ich habe diesen Dialog so gestaltet, wie er bis Delphi 7 gestaltet war. Alternativ kann der Programmpfad Eures Freepascal Compilers auch in die Datei "fp.tls" eingetragen werden. Ich habe vor den Pfad dort das Wort "Compiler" gesetzt, welches im Menü "Tools" erscheint, wenn der Compiler in der IDE bekannt ist. Nach einem Leerzeichen folgt der Compilerpfad.

ACHTUNG:
----------------------------------------------------------------

Der Aufruf des Compilers muss über das Menü Compiler erfolgen!

Bei Aufruf über das Tools Menü wird eine Exception ausgelöst!

----------------------------------------------------------------

Wer das gute alte Turbo Pascal noch kennt oder bereits mit der Textmode IDE von Freepascal gearbeitet hat, sollte mit dieser IDE auf Anhieb zurecht kommen.

Getestet habe ich das Design mit Registern für den Quelltexteditor, wie das aus der Delphi IDE bekannt ist. Die MDI Variante ist noch fehlerhaft und deshalb empfehle ich dieses Design nicht.

Unterhalb des Quelltexteditors gibt es 4 Fenster in Registern angeordnet. Diese sind:

-Compiler-Ausgaben
-Debugger Ausgaben(derzeit noch uninteressant)
-Ausgaben Ihrer Anwendung
-Meldungen

Compiler Ausgaben:

Hier erscheinen alle Meldungen des Compilers während der Übersetzung.



Ausgaben Ihrer Anwendung

Hierhin schreibt das übersetzte Programm alle Ausgaben. Unter "Optionen->Umgebungseinstellungen->Vorgaben kann dieses Verhalten so geändert werden, das die Programmausgaben in die Windowsconsole umgeleitet werden.


Meldungen

Hier sollen Fehlermeldungen der Anwendung sichtbar werden.

Jetzt warte ich auf Eure möglichst konstruktive Kritik.

[webcss]

von wegen plattformunabhängige Umgebung:

Riskier' doch mal einen Blick auf fpGUI von Graeme Geldenhuys. Das ist ein platformunabhänges GUI Toolset,
welches nativ in objectpascal geschrieben ist, und einfach in der Handhabung. Ein VisualFormDesigner ist bereits vorhanden.
Wie ich dem Repository entnehme, plant Graeme ebenfalls die Entwicklung einer IDE.
Vielleicht wäre da eine Möglichkeit für eine Zusammenarbeit?!

Ich arbeite bereits mit diesem Toolkit und bin begeistert. Es ermöglicht die Entwicklung für Windows, Linux, MacOS und WinCE Plattformen, dank der unabhängigen Oberfläche.

Hier mal der link zum Repository
und zur homepage des Entwicklers hier


Gruss

[schöni]

Zitat von webcss:

von wegen plattformunabhängige Umgebung:

Riskier' doch mal einen Blick auf fpGUI von Graeme Geldenhuys. Das ist ein platformunabhänges GUI Toolset,
welches nativ in objectpascal geschrieben ist, und einfach in der Handhabung. Ein VisualFormDesigner ist bereits vorhanden.
Wie ich dem Repository entnehme, plant Graeme ebenfalls die Entwicklung einer IDE.
Vielleicht wäre da eine Möglichkeit für eine Zusammenarbeit?!

Ich arbeite bereits mit diesem Toolkit und bin begeistert. Es ermöglicht die Entwicklung für Windows, Linux, MacOS und WinCE Plattformen, dank der unabhängigen Oberfläche.

Hier mal der link zum Repository
und zur homepage des Entwicklers hier


Gruss

Das fpGUI Projekt kenne ich. Nur die doert entwickelte IDE noch nicht. In der Repository ist außer deren Existenz noch nicht wirklich was los. Hatte mal die Version 0.5 der fpGUI nach Delphi portiert. Da kommen aber dann Exceptions an Stellen, wo die Freepascal Version einwandfrei ihren Dienst verrichtet. Und ein zweites Mal will ich mir die Arbeit nich machen.

Mit der Plattformunabhängigkeit ist das so ne Sache, weil der Freepascal Dialekt nich 100% Delphi kompatibel ist und auch die FCL-Schnittstelle stellenweise anders implementiert ist. So hatte ich die IDE mit Delphi angefangen. Eine Portierung nach Lazarus ist mir damals mit Version 0.9.22/0.9.24 nicht geglückt. So habe ich dann mit Delphi weiterentwickelt.

Eine Zusammenarbeit wäre willkommen, aber nur dann, wenn ich dann auch echte Zuarbeit erhalte. Das wäre im aktuellen Zustand meiner IDE der fertige Debugger, den ich nur noch aufrufen muss, mal abgesehen von den einzelnen Action-Methoden, in denen das passende Debuggerkommando noch aufgerufen werden muss. Ich habe auch noch nicht geschafft, die Images, die auf der Werkzeugleiste zu sehen sind, im Menü neben dem Menüeintrag sichtbar zu machen. Zusammenarbeit sieht deshalb für mich ausschließlich so aus, das das was ich nicht selber schaffe, von Mitprogrammierern übernommen wird. Ganz so, wie es wahrscheinlich auch in Softwareschmieden wie Embarcadero abläuft. Auch bei Lazarus sind und waren mehrere Entwickler beteiligt. Da muss man sich zwangsläufig die Arbeit teilen, um das sprichwörtliche Fahrrad nicht mehrmals zu erfinden. Solange ich aber auf mich alleine gestellt bin, geht meine IDE nur mit Delphi zu machen, da ich mit Delphi damit angefangen habe und jetzt nicht noch mal bei Null anfangen will. Es sei denn, letzteres brächte mir Unsummen von Geld ein.

.

[webcss]

Zitat von schöni:

Das fpGUI Projekt kenne ich. Nur die doert entwickelte IDE noch nicht. In der Repository ist außer deren Existenz noch nicht wirklich was los. Hatte mal die Version 0.5 der fpGUI nach Delphi portiert. Da kommen aber dann Exceptions an Stellen, wo die Freepascal Version einwandfrei ihren Dienst verrichtet. Und ein zweites Mal will ich mir die Arbeit nich machen.

Naja, seit der Version 0.5 hat sich einiges getan...
Ich verstehe auch nicht die Gründe für eine Portierung nach Delphi:
Du willst eine IDE für FPC erstellen, warum nicht auch FPC dafür benutzen?

Zitat von schöni:

Mit der Plattformunabhängigkeit ist das so ne Sache, weil der Freepascal Dialekt nich 100% Delphi kompatibel ist und auch die FCL-Schnittstelle stellenweise anders implementiert ist. So hatte ich die IDE mit Delphi angefangen. Eine Portierung nach Lazarus ist mir damals mit Version 0.9.22/0.9.24 nicht geglückt. So habe ich dann mit Delphi weiterentwickelt.

Ich denke, es geht darum FPC zu unterstützen, und nicht, so wie Lazarus ein zu allem kompatibles Ungetüm zu schaffen. Letztendlich ist Delphi's ObjectPascal Emabaracaderos Implementierung, FPC geht seinen eigenen (anderen) Weg.
Du solltest also erstmal wissen, was Du eigentlich erreichen willst: Delphi Kompatibilität oder eine IDE, welche FPC perfekt unterstützt (und dabei vielleicht noch plattformunabhängig ist).

Zitat von schöni:

Eine Zusammenarbeit wäre willkommen, aber nur dann, wenn ich dann auch echte Zuarbeit erhalte. Das wäre im aktuellen Zustand meiner IDE der fertige Debugger, den ich nur noch aufrufen muss, mal abgesehen von den einzelnen Action-Methoden, in denen das passende Debuggerkommando noch aufgerufen werden muss. Ich habe auch noch nicht geschafft, die Images, die auf der Werkzeugleiste zu sehen sind, im Menü neben dem Menüeintrag sichtbar zu machen. Zusammenarbeit sieht deshalb für mich ausschließlich so aus, das das was ich nicht selber schaffe, von Mitprogrammierern übernommen wird. Ganz so, wie es wahrscheinlich auch in Softwareschmieden wie Embarcadero abläuft. Auch bei Lazarus sind und waren mehrere Entwickler beteiligt. Da muss man sich zwangsläufig die Arbeit teilen, um das sprichwörtliche Fahrrad nicht mehrmals zu erfinden. Solange ich aber auf mich alleine gestellt bin, geht meine IDE nur mit Delphi zu machen, da ich mit Delphi damit angefangen habe und jetzt nicht noch mal bei Null anfangen will. Es sei denn, letzteres brächte mir Unsummen von Geld ein.

Ja, das ist der Geist von Opensource! Wie wäre es, mit oben genannten Entwickler Kontakt aufzunehmen und eine Zusammenarbeit auszuloten?

[schöni]

Zitat von webcss:

Zitat von schöni:

Das fpGUI Projekt kenne ich. Nur die doert entwickelte IDE noch nicht. In der Repository ist außer deren Existenz noch nicht wirklich was los. Hatte mal die Version 0.5 der fpGUI nach Delphi portiert. Da kommen aber dann Exceptions an Stellen, wo die Freepascal Version einwandfrei ihren Dienst verrichtet. Und ein zweites Mal will ich mir die Arbeit nich machen.

Naja, seit der Version 0.5 hat sich einiges getan...
Ich verstehe auch nicht die Gründe für eine Portierung nach Delphi:
Du willst eine IDE für FPC erstellen, warum nicht auch FPC dafür benutzen?

Zitat von schöni:

Mit der Plattformunabhängigkeit ist das so ne Sache, weil der Freepascal Dialekt nich 100% Delphi kompatibel ist und auch die FCL-Schnittstelle stellenweise anders implementiert ist. So hatte ich die IDE mit Delphi angefangen. Eine Portierung nach Lazarus ist mir damals mit Version 0.9.22/0.9.24 nicht geglückt. So habe ich dann mit Delphi weiterentwickelt.

Ich denke, es geht darum FPC zu unterstützen, und nicht, so wie Lazarus ein zu allem kompatibles Ungetüm zu schaffen. Letztendlich ist Delphi's ObjectPascal Emabaracaderos Implementierung, FPC geht seinen eigenen (anderen) Weg.
Du solltest also erstmal wissen, was Du eigentlich erreichen willst: Delphi Kompatibilität oder eine IDE, welche FPC perfekt unterstützt (und dabei vielleicht noch plattformunabhängig ist).

Zitat von schöni:

Eine Zusammenarbeit wäre willkommen, aber nur dann, wenn ich dann auch echte Zuarbeit erhalte. Das wäre im aktuellen Zustand meiner IDE der fertige Debugger, den ich nur noch aufrufen muss, mal abgesehen von den einzelnen Action-Methoden, in denen das passende Debuggerkommando noch aufgerufen werden muss. Ich habe auch noch nicht geschafft, die Images, die auf der Werkzeugleiste zu sehen sind, im Menü neben dem Menüeintrag sichtbar zu machen. Zusammenarbeit sieht deshalb für mich ausschließlich so aus, das das was ich nicht selber schaffe, von Mitprogrammierern übernommen wird. Ganz so, wie es wahrscheinlich auch in Softwareschmieden wie Embarcadero abläuft. Auch bei Lazarus sind und waren mehrere Entwickler beteiligt. Da muss man sich zwangsläufig die Arbeit teilen, um das sprichwörtliche Fahrrad nicht mehrmals zu erfinden. Solange ich aber auf mich alleine gestellt bin, geht meine IDE nur mit Delphi zu machen, da ich mit Delphi damit angefangen habe und jetzt nicht noch mal bei Null anfangen will. Es sei denn, letzteres brächte mir Unsummen von Geld ein.

Ja, das ist der Geist von Opensource! Wie wäre es, mit oben genannten Entwickler Kontakt aufzunehmen und eine Zusammenarbeit auszuloten?

Muss ich da einen der Autoren der fpGUI ansprechen, oder ist das für die IDE jemand anders? AUs der Repository werde ich leider nicht schlau. Da existiert zwar ein Verzeichnisbaum, aber sonst gar nix.

[omata]

@schöni: Mach doch bitte nicht immer TOFU

[webcss]

Soweit ich das aus meiner Korrespondenz mit dem Author von fpGUI weiss, ist eben dieser (Graeme Geldenhuys) der einzige Entwickler. fpGUI wird schon in einer (od. mehreren?) kommerziellen Anwendungen verwendet (MasterMath) und daher gehe ich davon aus, daß die Entwicklung nicht gleich wieder einschläft. Er hat wohl vor (aus ähnlichen Gründen wie Du) eine eigene IDE zu schreiben; wäre also ne gute Gelegenheit, nicht nur zuarbeiten zu lassen, sondern zusammenzuarbeiten

[schöni]

Zitat von webcss:

Soweit ich das aus meiner Korrespondenz mit dem Author von fpGUI weiss, ist eben dieser (Graeme Geldenhuys) der einzige Entwickler. fpGUI wird schon in einer (od. mehreren?) kommerziellen Anwendungen verwendet (MasterMath) und daher gehe ich davon aus, daß die Entwicklung nicht gleich wieder einschläft. Er hat wohl vor (aus ähnlichen Gründen wie Du) eine eigene IDE zu schreiben; wäre also ne gute Gelegenheit, nicht nur zuarbeiten zu lassen, sondern zusammenzuarbeiten

Ok, Danke! Habe den Autor angeschrieben. Werd ja sehen. Aber bissl Zuarbeit brauche ich. Es sei denn, ich schaff das mit dem Debugger noch. In älteren Freepascal Distribs gab es mal das Projekt Shedit, einen Texteditor mit Syntaxhervorhebung, aber nur für Pasdcal und Xml. Da ist SynEdit weiter fortgeschritten. Für das Debuggen innerhalb der IDE nutze ich als Schnittstelle eine Modifikation des SimpleIDEDemo aus dem SynEdit Projekt, wo beispielhaft ein Quellcodedebugger programmiert ist. Ich brauche aber nun noch aufbereitete Debuginfo von einem echten Debugger, die dann den Debuggercursor in der IDE steuert. Daran arbeite ich gerade. Wird aber noch bissl dauern. Alleine geht das halt nich so schnell.

Bei Zusammenarbeit wird das erste, was ich vereinbare, ein Interface sein, bei dem ich mich auf den Arbeitsanteil meinen Partners verlassen kann. Ich beziehe mich dann auf das Interface und stelle meinen Anteil der Arbeit bereit. Ich geh fest davon aus, das die Industrie auch so arbeitet. Bei der Emarcadero-Delphi IDE dürfte einer die Oberfläche bauen, ein anderer baut die Komponentenpalette, wieder ein anderer den Quellcodeeditor, ein anderer den Debugger.... Am Ende muss aber alles zusammen passen, was nur über eine vereinbarte Schnittstelle funktionieren kann. Wenn ich Datei-Öffnen anklicke, muss eine Aktion ausgelöst werden, die mir meine Datei in den Quellcodeditor lädt. Da reicht es aus, wenn der Verantwortliche für die Oberfläche die TActionList verwendet und leere Methoden bereitstellt. Es könnte auch eine Klasse für die Ausfügrung der Aktionen definiert werden. Davon müsste der Oberflächendesignwer nur die dann für die jeweilige Aktion passende Methode kennen. Inplementieren könnte diese Klasse jemand anders. So und nur so kann Zusammenarbeit funktionieren.

[omata]

@schöni: Hast du eigentlich gelesen, was ich geschrieben habe? Oder bist du lernresistent?

[schöni]

@omata: Hab Deinen Beitrag mit der Aufforderung leider überlesen. In der Hinsicht bin ich wirklich lernresistent, nämlicvh darin, das ich möglichst jeden Tag meine Threads im Internet verfolgen sollte, weil jemand geantwortet haben könnte. Da ich diese Zeit aber nicht bezahlt kriege guck ich eben nich jeden Tag überall rein und damit hab ich Deine Aufforderung zu "TOFU" schlicht und einfach überlesen. Sorry aber auch!!!!

Gerade heute ist das Internet mal wieder besonders langsam, da werd ich heute nur das allernätigste im Internet erledigen. Für schnelleren Zugang hab ich kein Geld übrig. Hab schon DSL 1000 und die Daten tröpfeln trotzden bloß träge durchs Netz. Wenn ich heute den tollen DSL 16000 Zugang bestelle, werden die Daten in 2 Jahren genauso träge durchs Netz tröpfeln, weil entweder bis dahin die Zahl der Nutzer gestiegen ist oder die Internetseiten mit weiterem überflüssigen Müll überlastet sind. Diesen Wettlauf mach ich nicht mit! Punkt uns Aus!

Den Profiprogrammierern sag ich dazu noch: Eine Internetseite mit Produktangeboten klick ich weg, sobald die Ladezeit 6zu groß wird. Pech für den Anbieter der Produkte, die ich dann nicht zu sehen kriege und dann natürlich auch nicht kaufe. Ich verlange ordentlichen Service von Anfang an. Und dazu gehört auch ne optimale Präsentation. Eine, die nicht durch lange Ladezeiten unangenehm auffällt. Beachtet das bei Euren Webanwendungen!

Was solls, wenn wegen solcher Diskussionen dieser Thread immer wieder an die Oberfläche kommt. Da bleibt meine IDE wenigstens bei Euch im Gedächtnis. Vielleicht ist das gar nich so falsch. Wer mal ne Möglichkeit einbauen, einen beliebigen externen Debugger zu verwenden, der überbrückungsweise verwendet werden kann, bis ein venünftiger Quellcodedebugger verfügbar ist.

[omata]

Das du meinen Beitrag überlesen hast ist doch kein Problem.

Aber was du sonst so von dir gegeben hast verstehe ich nicht. Es geht doch nicht im Geschwindigkeit, sondern um richtiges und sinnvolles zitieren bzw. beantworten von vorangegangenen Texten. Es macht einfach keinen Spaß alles nochmal zu lesen und dann raus suchen zu müssen, auf was du da eigentlich gerade im einzelnen antwortest.

Also wie auch immer, nichts für ungut. War nur ein gut gemeinter Rat, ich werde jetzt nichts mehr von dir lesen, also mach einfach so weiter...