Mathias hat geschrieben:Und: Freepascal unterstützt ja noch Konsolenprogramme. Da kann ich das ja auch nutzen. Sonst könnte ja die Möglichkeit, Konsolenprogramme zu schreiben, auch aus dem Compiler entfernt
Ich denke mal, Konsolenprogramme werden in nächster Zeit nicht verschwinden. Ein apt-get ist auch nichts anderes als ein Konsolenprogramm.
Wen du das hier anguckst, sieht man, was man mit der Konsole alles machen kann:
viewtopic.php?f=22&t=11063&p=98205&hilit=freevision#p98205
Ich bin 100% sicher, nicht nur ich sondern auch andere akzeptieren als Benutzeroberfläche ausschließlich richtige GUI. Die ist auch im Konsolenmodus möglich, es gibt die altbekannte Unit Graph, als PTC-Graph sogar rasend schnell. Es gibt außerdem die PTC-Bibliothek. Und es gibt sogar noch was besseres, nämlich Matthias Köppes GVIsion3, ein grafisches Turbo Vision im Windows 3.11 Stil. Und es gibt GVision von Jason Burgon, der auch schon den Gedanken hatte, sein Produkt als Open Source frei zu geben. Sollte ja dann mit der 16 Bit Version von Freepascal übersetzbar sein. Sollten dort zu viele DOS spezifische Aufrufe enthalten sein, dann funktioniert diese Variante eben erst mal ausschließlich in DOS, es sei denn die Portierung ist nicht allzu aufwendig. Wenn doch, dann gibt es für Linux die svgalib, auf der die gute alte Graph Unit aufsetzt. Je nach Design dieser svgalib ist möglicherweise die Graph Unit unter Linux recht flott und damit um so besser geeignet, eine GUI zu bauen. Ich kenne auch alte DOS GUI Programme, in denen das Verschieben der Fenster aus Geschwindigkeitsgründen derart vorenommen wird, dass erst mal nur der Rahmen verschoben wird und erst beim Loslassen der Maustaste das Fenster neu gezeichnet wird. Heutige Rechner können auf jeden Fall richtige GUI, um so mehr, wenn es sich um eine GUI handelt die ohne den doch recht ressourcenaufwendigen XServer auskommen, weil sie auf der besgten svgalib aufsetzen. Es hat schon zu DOS Zeiten aufwendige GUIs gegeben, nur konnte die sich damals kein Normalsterblicher leisten. Es gab damals StarWord, mit GUI (nicht Textmode) Oberfläche.
Wenn so eine Konsolen GUI wirklich eine Neuentwicklung von Grund auf nötig machen sollte, wäre nach praktischen Erfordernissen zu überlegen, was in diese GUI Bibliothek unbedingt rein gehört und was man nicht braucht. Immerhin könnte man damit auch ohne XServer Frontends für die Kommandozeilenprogramme bauen oder Konsolenanweendungen halt mit GUI Oberfläche, ohne den XServer zu benötigen und so auch auf schwächeren Rechnern GUI zu ermöglichen.
Allerdings ist es heute eher so, dass die Kommandozeilenfetischisten lieber mit besagter Kommandozeile arbeiten, die brauchen dann gar keine Benutzeroberfläche, weder Textmode noch GUI. Und die andere Fraktion, zu der auch ich gehöre, bevozugt GUI und ich sagte ja schon, dass heutige Rechner das locker schaffen, dann aber eben auch mit XServer oder Windows.
Aber als Anhänger der GUI akzeptiere ich wegen der besseren Optik eben auch bei Konsolenprogrammen Ohne Windows oder XServer nur richtige GUI, zumal es ja die Bibliotheken dafür längst gibt. In C/C++ geschrieben gibt es da einige. Für Linux könnte die OpenGUI die Lösung sein für diesen Zweck, so die ohne XServer auskommt, sonst wäre die ein weiterer Fenstermanager.
Download hier:
https://sourceforge.net/projects/opengui/Hier gibt es Schreenshot's:
http://www.freecode.com/projects/openguiSollte die aktuelle Version auf XServer aufsetzen, lohnt es sich möglicherweise, nach älteren Versionen zu suchen, die noch mit Konsolengrafik arbeiten und diese dann einzusetzen. Und dann natürlich einen passenden Mechanismus in FPC zu integrieren, die Open GUI Bibliotheken in Freepascal zu verlinken, um deren Funktionen auch in Freepascal nutzen zu können.
.