Hallo zusammen, über kurz oder lange würde ich gerne auf Linux umsteigen. Da ich hobbymäßig viel Software entwickele wollte ich mich schon mal schlau machen, welche Möglichkeiten es da so gibt. Insbesondere würden mich GUI-Frameworks interessieren, die eine strikte Trennung von GUI (z.B. XML) und Logik (Sourcecode) erlauben. Bei Android (ist ja ein Linux) wird dieses (IMHO sehr elegante) Schema ja schön umgesetzt. Und auch bei Windows ist es mittlerweile sehr verbreitet. Bei Linux wird eigentlich immer nur auf Qt verwiesen, was aber meines Wissens nach nicht auf dieses Prinzip setzt. Zusätzlich ist es ja eigentlich nur mit C++ sinnvoll zu verwenden, und auf eine bestimmte Sprache möchte ich mich eigentlich nicht festlegen. Was käme sonst noch in Frage? Gibt es vielleicht auch noch irgendwelche spannenden Neuentwicklungen von denen ich nichts weiß?
:
Verschoben durch Moderator
Hallo, bei Qt werden die UserInterfaces in sogenannten .ui Dateien beschrieben. Das besteht aber gerade aus XML. Der Code ist dann reines C++. Aber wenn Du dich nicht auf die Verwendung einer Sprache festlegen willst, dann musst Du .NET nehmen <Ironie>, dann fällts mit dem Umstieg auf Linux auch leichter</Ironie>. Gruß Olaf
Olaf Dreyer schrieb: > Aber wenn Du dich nicht auf die Verwendung einer Sprache festlegen > willst, > dann musst Du .NET nehmen Es wird doch wohl ein Sprachunabhängiges GUI-Framework für Linux geben? Bei Linux gibt es doch nichts, was es nicht gibt ;-)
Soweit ich weiß gibt es doch für die großen Frameworks immer Bindigs für alle mnöglichen Sprachen, oder nicht? Also bei GTK+ bin ich mir sicher, aber ich glaube das erfüllt nicht deine Forderung nach der Trennung von Code und Design. Gruß Dennis
Boris B. schrieb: > Es wird doch wohl ein Sprachunabhängiges GUI-Framework für Linux geben? Was für Sprachen schweben dir denn vor? Neben C++ kannst du Qt zumindest in irgendwelche Scriptsprachen einbinden.
Jedes Framework ist sprachenabhängig. Außer .NET. Aber bei Qt kannst Du native in C++ programmieren oder in einer anderen Sprache in denen Qt-Bindings existieren. Zitat: Programming Language Support & Language Bindings The Qt API is implemented in C++, and provides additional features for easier cross-platform development. QML – introduced with Qt Quick is a CSS and JavaScript-like declarative, language designed to describe the user interface of a program: both what it looks like, and how it behaves. Bindings to Qt exist for several other languages, including Ada, Pascal, Perl, PHP, Ruby, Python and Java™. Gruß Olaf
Olaf Dreyer schrieb: > bei Qt werden die UserInterfaces in sogenannten .ui Dateien beschrieben. > Das besteht aber gerade aus XML. Genau. Zur Erzeugung der Fenster gibt es dann einen ensprechenden GUI-Builder (Qt Designer), mit dem man diese .ui-Files erstellen kann. Genutzt werden können die wahlweise über einen Codegenerator (uic), der aus den .ui-Files C++-Code erzeugt, den man dann in sein Programm einbinden kann oder über den QtUiLoader, der .ui-Files auch dynamisch zur Laufzeit laden und entsprechende Fenster erzeugen kann. Man hat aber immer noch auch die Möglichkeit, direkt "von Hand" im C++-Code alle GUI-Elemente zu nutzen. So kann man auch mal was machen, das diese dynamisch erzeugt abhängig von irgendwelchen eigelesenen Daten zum Beispiel. Olaf Dreyer schrieb: > Jedes Framework ist sprachenabhängig. Außer .NET. So sprachunabhängig ist das auch nicht. Man kann es z.B. nicht mit C++ benutzen, sondern nur mit einer von Microsoft speziell für .NET modifizierten C++-ähnlichen Sprache.
Frage: was ist denn da der Vorteil, wenn ich GUI und Logik trenne?
radiostar schrieb: > Frage: was ist denn da der Vorteil, wenn ich GUI und Logik trenne? Mehr Flexibilität und Übersicht. Du kannst zum Beispiel fehlerhafte Algorithmen verbessern ohne, dass das komplette Programm (also auch die GUI) davon betroffen ist. Genauso kannst du die GUI anpassen ohne, dass sich die Logik ändert. Such mal nach Drei-Schichten-Architektur oder so! Gruß Dennis
:
Bearbeitet durch User
Das wüsste ich auch gerne. Die beiden sind doch immer verknüpft. Ausserdem kenne ich keinen Anwendungsfall wo ich mit der gleichen GUI mal in C++ mal in zB. JAVA programmiertechnisch ran will. Dann müsste ich ja das Programm 2 mal schreiben. Plattformunabhänigkeit ist mir da immer viel wichtiger.
Oliver schrieb: > Ausserdem kenne ich keinen Anwendungsfall wo ich mit der gleichen GUI > mal in C++ mal in zB. JAVA programmiertechnisch ran will. Wenn dann auch eher umgekehrt. Gleiche Business Logik, andere GUI.
radiostar schrieb: > Frage: was ist denn da der Vorteil, wenn ich GUI und Logik trenne? Der gleiche, den man beim Modularisieren immer hat. Übersichtlicherer Code und mehr Flexibilität für spätere Änderungen.
Boris B. schrieb: > Es wird doch wohl ein Sprachunabhängiges GUI-Framework für Linux geben? Für jeden Toolkit gibt es erst einmal die Sprache des nativen API. Das ist bspw. C für GTK+, C++ für Qt und Tcl für Tk. Dann gibt es für die meisten Toolkits so genannte Language-Bindings, über die der jeweilige Toolkit auch von anderen Sprachen aus benutzt werden kann. Das sind im Wesentlichen Bibliotheken mit angepassten Datentypen und Wrapper-Funktionen. Die gängigen Toolkits haben so zwischen 10 und 30 solcher Bindings. Olaf Dreyer schrieb: > Jedes Framework ist sprachenabhängig. Außer .NET. Die .NET GUI-Toolkits haben den Vorteil, dass man prinzipiell auch ohne Wrapper-Funktionen und angepasste Datentypen auskommen kann, weil alle .NET-Sprachen auf dem gleichen Daten- und Ausführungsmodell basieren. Der Nachteil besteht darin, dass dieses Modell so stark einschränkend ist, dass die meisten klassischen Sprachen nicht darauf implementiert werden können. Somit können die .NET-GUI-Toolkits nicht von C, C++, Java, Pascal usw. genutzt werden, sondern – wenn überhaupt – nur von stark vom Original abweichenden Dialekten dieser Sprachen. radiostar schrieb: > Frage: was ist denn da der Vorteil, wenn ich GUI und Logik trenne? Zum einen sollte jede Software in logische Blöcke mit möglichst schlanken Schnittstellen zwischen diesen Blöcken strukturiert werden, weil dies die Übersichtlichkeit, Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit fördert. Zu anderen lässt sich bei sauberer Trennung des GUIs leicht eine TUI-Version (TUI = textuelles User-Interface :)) von der Anwendung erstellen, die dann auch in Skripten u.ä. benutzt werden kann. Bei einigen Unix/Linux-Anwendungen geht diese Trennung sogar so weit, dass die Anwendung und deren GUI zwei getrennte Programme sind, die nur über Pipes oder TCP-Sockets miteinander kommunizieren. Oliver schrieb: > Die beiden sind doch immer verknüpft. Dieser Eindruck entsteht dadurch, das Microsoft seinerzeit mit der MFC-Bibliothek die Vermauschelung von Anwendung und GUI regelrecht gefördert hat und auch bei den selber entwickelten Anwendungen mit schlechtem Beispiel voranging. So haben es viele Anwendungsentwickler für Windows einfach nie anders gelernt. Die moderneren GUI-Toolkits (auch die von Microsoft) unterstützen die Trennung von Anwendung und GUI meist recht gut. Trotzdem muss auch der Entwickler seinen Teil dazu beitragen. Wie stark die Trennung sinnvollerweise ist, hängt aber sehr stark vom Anwendungstyp ab. So ist sie bspw. bei einem Zeichenprogramm, das zu 90% aus GUI besteht, nicht nur schwer zu realisieren, sondern auch nicht ganz so wichtig. Bei einem Schachprogramm hingegen ist die Trennung sehr leicht und auch wichtig, da die Schachzüge evtl. nicht nur über das GUI, sondern auch über ein externes Sensorbrett mit realen Figuren oder durch ein anderes Schachprogramm über eine Socket-Schnittstelle eingegeben werden sollen.
Achso jetzt verstehe ich das. Gleicher Code aber andere GUI. Das können spezielle Schnittstellen sein oder auch nur eine Art SKIN Interpreter. Aber auch hier hat man doch immer eine gewisse Abhängigkeit. Der Schnittstellen Code der GUI wird immer zur GUI passen müssen. Ein SKIN Interpreter erwartet immer gewisse Elemente. Weg lassen geht meistens, aber neue kennt doch dann niemand und wird damit auch nichts anfangen können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.