Prinzipiell finde ich es sehr schoen, auch unter Pascal mit GTK Oberflaechen zu gestalten. Dummerweise ist der Syntax voellig unterschiedlich zu der alten Turbo Pascal (Windows) OWL widget library. Weiss jemand zufaellig ein Projekt, dass diese Schnittstelle fuer Linux abbildet? Irgendwie haette ich schon Lust, meine ersten Programmierversuche nach Linux zu portieren...
Von Hansi Glaser am Mo, 1. September 2003 um 14:19 #
Schau mal auf http://gtkpas.sf.net/. Ich habe mal angefangen, die GTK-Funktionen in einen Pascal-Klassenbaum zu kleiden. Es besteht fast nur aus Wrapper-Klassen, ermöglicht dadurch ein sehr schönes Programmieren. GTK ist ja selbst objektorientiert, muß aber viele grauslige Tricks anwenden, um das in C zu schaffen.
Wenn sich jemand findet, bei diesem Projekt mitzuhelfen, wäre ich sehr dankbar.
Ähnlich zur OWL ist das aber überhaupt nicht. Da würde ich mal bei Lazarus (http://www.lazarus.freepascal.org/) vorbeischauen.
Ich verfolge die Entwicklung von Lazarus seit ~2Jahren. Anfangs (klar) unbrauchbar hat sich meine letzte CVS-Version (vor ca. 3 Monaten) als durchaus brauchbar erwiesen. Probleme mit Schriften gabs, den Projectnamen verändern mochte es auch nicht. Die Executables sind aber riesig: Hello-World 3MB, mit upx ca 0,9MB.
Allerdings fande ich es absurd, was alles in der ersten brauchbaren Version so alles drin sein soll. Statt klein anzufangen mit den Basis-Komponenten alles von Anfang an. Die könnten schon die erste Version rausgebracht haben. In der kommerziellen Variante gibts ja auch Version 1,2,3... Die fangen imho so etwa bei Version 5 an. Von 0 auf 5.
Wenn (Free)Pascal jetzt noch unter GNU/Linux eine bessere Beachtung finden würde, könnten mit diesem Tutorial sicherlich noch mehr was anfangen. Die Sprache wird einfach ihren Ruf als Schul- und Lehrsprache für Kids nicht los, derweilen doch gerade unter Windows recht viel mit Pascal (Delphi) gemacht wird... Allerdings stellt sich wiederum die andere Frage: da die meiste Software unter GNU/Linux sowieso Quelloffen ist, warum nicht gleich eine topmoderne (interpretierende) OO-Sprache wie Ruby einsetzen?
Auch eine "topmoderne" Interpreter-Sprache kann in Sachen Performance einer "echten" Compiler-Sprache niemals das Wasser reichen. Bei kleinen Projekten - OK, aber groessere Sachen compiliert man eben doch besser neu.
Ausserdem - haste schonmal versucht einen Betriebssystem-Kernel in einer Interpreter-Sprache zu schreiben ... :-)
Wo ist das Problem Kannst ja Dinge die Performancelastig sind in Erweiterungsmodule auslagern (die dann in C geschrieben sein können) und den Interpreter für die Dinge wie GUI usw. nehmen. In der Kombination der verschiedenen Möglichkeiten liegt der Schlüssel ;)
Auf Betriebssystemebene sieht das natürlich anders aus. Aber man soll nie sagen "geht nicht" Heute vielleicht unvorstellbar, in der Zukunft sieht das evtl. anders aus.
Was haette das fuer einen Sinn, die weniger Performance benoetigenden Dinge in einer anderen Sprache zu entwickeln als den eigentlichen Code??? Warum nicht direkt alles in einem Rutsch ordentlich compiliert und gut ist? Wuerde auch weniger Abhaengigkeiten hervorrufen.
Geoffrey
Wenn sich jemand findet, bei diesem Projekt mitzuhelfen, wäre ich sehr dankbar.
Ähnlich zur OWL ist das aber überhaupt nicht. Da würde ich mal bei Lazarus (http://www.lazarus.freepascal.org/) vorbeischauen.
Bye
Hansi
Anfangs (klar) unbrauchbar hat sich meine letzte CVS-Version (vor ca. 3 Monaten) als durchaus brauchbar erwiesen. Probleme mit Schriften gabs, den Projectnamen verändern mochte es auch nicht. Die Executables sind aber riesig: Hello-World 3MB, mit upx ca 0,9MB.
Allerdings fande ich es absurd, was alles in der ersten brauchbaren Version so alles drin sein soll. Statt klein anzufangen mit den Basis-Komponenten alles von Anfang an. Die könnten schon die erste Version rausgebracht haben.
In der kommerziellen Variante gibts ja auch Version 1,2,3...
Die fangen imho so etwa bei Version 5 an. Von 0 auf 5.
Allerdings stellt sich wiederum die andere Frage: da die meiste Software unter GNU/Linux sowieso Quelloffen ist, warum nicht gleich eine topmoderne (interpretierende) OO-Sprache wie Ruby einsetzen?
Ausserdem - haste schonmal versucht einen Betriebssystem-Kernel in einer Interpreter-Sprache zu schreiben ... :-)
Auf Betriebssystemebene sieht das natürlich anders aus. Aber man soll nie sagen "geht nicht"
Heute vielleicht unvorstellbar, in der Zukunft sieht das evtl. anders aus.