Hallo! Ich habe bereits einige kleine Programme in C geschrieben. Jetzt möchte ich gerne einige davon als grafische Oberfläche programmieren. Also mit Buttons etc. wie Windows Programme. Wie kann ich das am besten machen und mit welcher Sprache? Mfg Argon
Ich würde QT von Trolltech benutzen. Das ist meiner Meinung nach für Einsteiger das einfachste. Oder eben gleich Labview, aber du willst ja C machen.
QT ist eine C++-Klassenbibliothek, als C-Programmierer kann man damit nicht sehr viel anfangen.
Zuerst solltest du dich mit c++ und oop vertraut machen. Ohne diese beiden Grundlagen wirst du mit den meisten GUI-Libs arge Probleme haben
Ich finde ehrlich, daß C für GUI-Programmierung eher ungeeignet ist. Klar geht es auch, wie man an gtk sieht, aber ich finde den Code hässlich und unübersichtlich. Das geht in C auch kaum anders, wenn man die ganzen Konzepte der objektorientierten Programmierung, Überladung, Templates, u.s.w., die C++ mitbringt, "zu Fuß" nachbilden muß.
QT und gtk sind aber keine Sprachen. Nur Bibliotheken. GUI-Programmierung ist immer an das jeweilige OS gebunden, weil's in C (und C++) keine Unterstützung dafür gibt. Glücklicherweise gibt es aber Bibliotheken (QT, gtk, ...) die für verschiede OS die gleiche Programmier"-Schnittstelle" bieten. Es geht aber auch OS-abhängig direkt mit den im OS vorhandenen Programmer Interfaces (API), auf die ja die Bibliotheken auch nur zurückgreifen (allerdings ziemlich komfortabel): Windows - API (kann man direkt als C-Code benutzen, oder mit MFC in C++ -Anwendungen) Linux - KDI, in C++ Anwendungen. Blackbird PS.: Trotz C: die Sourcen sollten immer mit einem C++-Compiler compiliert werden - also Endung .cpp verwenden
Hi! Ich hab auch mal Versucht, GUI in C zu schreiben und wollte da möglichst Plattformunabhängig bleiben. Ich bin am Ende bei FLTK hängen geblieben und bin von der Einfachheit relativ überrascht gewesen. Das geile ist, dass man EXE-Files mit 200 kByte Größe erhält die selbstständig laufen (keine Runtime oder DLL's nötig). Hab ein USB-Oszi damit geschrieben das eigentlich auch plattformunabhängig sein sollte (LIBUSB + FLTK). Siehe www.ime.jku.at/tusb Vermerk auf die Doku bzw. die Präsentation. mfg Weichinger Klaus www.weinga-unity.at.tt
> QT und gtk sind aber keine Sprachen. Nur Bibliotheken. Natürlich. Aber Qt ist in C++ implementiert, gtk in C, und für eine Verwendung in diesen Sprachen sind die auch primär gemacht. In anderen Sprachen können sie nur indirekt über Wrapper-APIs verwendet werden. > GUI-Programmierung ist immer an das jeweilige OS gebunden, weil's > in C (und C++) keine Unterstützung dafür gibt. Glücklicherweise > gibt es aber Bibliotheken (QT, gtk, ...) die für verschiede OS die > gleiche Programmier"-Schnittstelle" bieten. Das ändert aber nichts daran, daß GUI-Programmierung in C meines Erachtens unschön ist. gtk ist ein Beispiel, weil es genau dafür gemacht ist. > Es geht aber auch OS-abhängig direkt mit den im OS vorhandenen > Programmer Interfaces (API), auf die ja die Bibliotheken auch nur > zurückgreifen (allerdings ziemlich komfortabel): > Windows - API (kann man direkt als C-Code benutzen, oder mit MFC > in C++ -Anwendungen) MFC ist nicht direkt das Grund-API, sondern setzt auch nur auf das GDI auf. Plattformspezifisch ist es trotzdem. > Linux - KDI, in C++ Anwendungen. Was soll das sein? Meintest du X11 bzw. die xlib? Das ist unter Linux das üblicherweise verwendete GUI-System, auch wenn es dort zunächstmal kein bestimmtes erzwungenes System wie unter Windows gibt. xlib ist auch in C gehalten. > PS.: Trotz C: die Sourcen sollten immer mit einem C++-Compiler > compiliert werden - also Endung .cpp verwenden Wie kommst du auf den Trichter? C-Code sollte auf jeden Fall mit einem C-Compiler übersetzt werden, nicht mit einem C++-Compiler.
> Linux - KDI Mich würde es auch interessieren was Linux - KDI ist. KDI ???? > Trotz C: die Sourcen sollten immer mit einem C++-Compiler compiliert werden - also Endung .cpp verwenden Wäre auch interessant zu erfahren, warum das so gemacht werden soll. @Argon >Programme in C geschrieben Wenn du in C programieren möchtest ist definitiv GTK das sinnvollste, aber wie gesagt der Code sieht hässlich aus und die Dokumentation ist auch nicht die beste. @Weinga-Unity Danke für den Tip mit FLTK. So ein Toolkit mit dem auch Doofe programmieren können habe ich gesucht.
"Linux - KDI" sorry, Schreib- und Ausdrucksfehler: gemeint hatte ich KDevelop für die grafische Oberfläche KDE unter Linux. Blackbird
Ich halte ehrlich gesagt nichts davon GUI-Programme in C (oder C++) zu schreiben. Die manuelle Speicherverwaltung, das Lowlevel-Gebastel ist bei manchen Anwendungen von Vorteil (embedded), bei GUIs aber einfach nur ein riesiger Klotz am Bein. Müsste ich ein GUI bauen, dann mit Java + Swing, weil das plattformübergreifend ist, die Laufzeitumgebung überall schon vorhanden ist, und weil Java dem Programmierer viel Arbeit abnimmt.
@Blackbird: > Rolf, beantwortet das alles die Frage des Threaderstellers? Ja. @Andreas: > Ich halte ehrlich gesagt nichts davon GUI-Programme in C (oder > C++) zu schreiben. Die manuelle Speicherverwaltung, das > Lowlevel-Gebastel ist bei manchen Anwendungen von Vorteil Hast du Qt schon mal ausprobiert? Die Speicherverwaltung der Qt-Klassen ist automatisiert. > (embedded), bei GUIs aber einfach nur ein riesiger Klotz am Bein. > Müsste ich ein GUI bauen, dann mit Java+ Swing, weil das > plattformübergreifend ist, die Laufzeitumgebung überall schon > vorhanden ist, und weil Java dem Programmierer viel Arbeit > abnimmt. Was ich bei Java absurd finde, ist, daß immer wieder hervogehoben wird, daß der Speicher automatisch verwaltet wird. Dafür müssen aber alle anderen Ressourcen manuell verwaltet werden, weil es in Java keine Destruktoren und keinen determinischten Zeitpunkt der Zersörung von Objekten gibt. Mal ein sehr einfaches Beispiel: void readFile(const std::string& name) { std::ifstream mystream(name.c_str()); readStream(mystream); } Hier braucht man sich nicht um das Schließen der Datei zu kümmern, weil es autmoatisch passiert, und zwar auch dann, wenn readStream eine Exception wirft. In Java muß man das manuell machen und dazu irgendwelche finally-Geschichten verwenden, um auch für den Fall einer Exception sicherzustellen, daß die Datei geschlossen wird. Und das zieht sich dann durch alle anderen Ressourcen (Fenster, Datenbankverbindungen, Sockets, ...).
@Martin Ich hab keine Ahnung, wie ich das mit dem '... auch Doofe ...' auffassen soll aber noch eine Bemerkung dazu: Ich weiß net ob etwas oder jemand doof ist, wenn er mit einem Hilfsmittel sein Ziel in allen Punkten erreicht, was ich von der Realisierung des USB-Oszis mit FLTK behaupten kann. Eine EXE-Datei, die einfach funktioniert (WIN95 bis XP und ohne Abhängigkeiten von DLL's). mfg Weichinger Klaus
@Klaus >keine Ahnung[...]auffassen soll Ich wollte dich damit keinesfalls kritisieren oder angreiffen. >Ich weiß net ob etwas oder jemand doof ist... Nein ist es nicht.Es ist völlig in Ordnung. Ich benutze dauernd irgendwelche Toolkits oder Libs.Ohne könnte ich garnicht programieren. FLTK steht jetzt auch auch meiner Liste. Nun aber wenn ich nach 5min und ohne irgendwas grossartig zu lesen das ganze Konzept, wie man mit diesem Toolkit programmiert, verstanden habe, wird es wohl auch ein Doofer hinbekommen. Deshalb auch Doofe.
@Martin ...dann freuts micht, dass ich dir mit FLTK etwas helfen konnte.
Wenn es C sein soll und auch Graphisch, dann empfehle ich LabWindows CVI von National Instruments. Ist beim Labview Paket dabei.
Der klassische Weg Windows in C zu programmieren läuft über den Low-Level-Weg der Windows-API (Application Programming Interface). Ein guter Buchtipp hier wäre ein API-Buch von Charles Petzold. Sonst einfach mal googlen oder bei "http://en.wikipedia.org/wiki/Windows_API" schlau machen. Grüße Hans-Jörg
Bitte 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.