Warum machen wir uns nicht eine neue schöne C++ GUI Bibliothek?
-
kann man den nicht eigentlich einfach den sourecode von qt oder wxwidgets nehmen und sie so kürzen/vereinfachen (namespace einbauen) dass der code wieder klarer wird?
würde das nicht mehr arbeit sparen als wenn man von boden aus alles neuprogrammiert?
-
xBlackKnightx schrieb:
kann man den nicht eigentlich einfach den sourecode von qt oder wxwidgets nehmen und sie so kürzen/vereinfachen (namespace einbauen) dass der code wieder klarer wird?
würde das nicht mehr arbeit sparen als wenn man von boden aus alles neuprogrammiert?
Ja, klingt logisch dein Ansatz. Leider reden wir hier über Libraries mit jeweils über 100 Klassen.
Der Aufwand das alles anzupassen, ist weit größer, als es vernünftig neu zu machen.
QT ist ja schon recht gut vom Design her, aber leider nicht OS und auch nicht wirklich STL freundlich.
Uns allen hier schwebt eine Standard GUI Lib vor, nichts was wxWidgets oder QT ähnelt, sondern etwas was besser ist.
Deshalb kann man auch nicht eine andere Lib kurz mal nach "Besser" portieren, man würde ja all die Designentscheidungen (Fehler?) der Entwickler mittragen,
anstatt etwas eigenes und evtl. besseres implementieren zu können.phlox
-
Ja, kann phlox81 zustimmen. Sicherlich ist der Sinn von freier Software das man diese dann halt auch nach eigenen Bedürfnissen anpassen kann. Aber wxWidgets mal umdesignen fällt schon nicht mehr unter "Anpassen". Und die Namespaces sind es ja nicht alleine die eine Rolle spielen. Wenn man schon mal dabei ist es zu ändern, würde einem noch dies und das auffallen, das man dann doch noch gleich ändern kann. Tja, und dann ist der Umfang so groß, das mans gleich neu machen kann.
Die wxWidgets-Leute haben ja auch für die 3er Version sich dagegen entschieden einen radikalen Umbau vorzunehmen. Ich finde es schade, das nicht wenigstens die trivialen Sachen geändert werden, aber ist ja deren Verantwortung.
Einen Umbau hat dagegen fltk gemacht: viele Sachen wurden von 1.x auf 2.0 modernisiert.
Es sind zwar immer noch hier und da ein paar Sachen, die mir nicht gefallen, aber immerhin haben sie den Mut zur Veränderung bewiesen! fltk ist aber auch "nur" ein GUI-Toolkit und somit überschaubar. Das ist bei wxWidgets nicht der Fall. Es ist ein komplexes Framework, wie Qt und MFC. Wir müssen hier immer zwischen einem GUI-Toolkit und einem Application-Framework unterscheiden. Vergessen hier einige wahrscheinlich.
So, zu der Sache mit dem "selber machen". Es gibt viele Versuche von vielen C++-Entwicklern eine Alternative zu entwickeln. Wenn hier jemand aus dem Forum etwas anfängt, ist er nicht der einzige. Natürlich scheitern viele, meistens an der Akzeptanz. Aber das ist ein normaler Prozess, das es eine Auslese gibt. Ich halte es sogar für besser, wenn es mehrere Versuche gibt die wahrscheinlich scheitern, als wenn nichts passiert. Denn vielleicht kommt ja doch noch etwas, was akzeptiert wird? Schaut euch mal Ultimate++ an: es lebt! Auch wenn es keine große Publicity hat, aber es hat eine Akzeptanz bei einer ausreichend großen Gruppe gefunden.
Andere sind gescheitert, da fallen mir SmartWin++ und VACA ein. Obwohl diese einen sehr guten Ansatz hatten. Die haben aber irgendwas anderes falsch gemacht, das nicht akzeptiert wurde. Thats Racing!
Übrigens, auch auf anderen Plattformen, die ja sooo GUI-freundlich sind (Java und .NET) haben sogar mehrere GUI-Toolkits. Komisch, oder? Eben weil selbst die Standard-GUI nicht jedem gefällt, und jeder meint, er muß jetzt was anderes machen, das seinen Vorstellungen entspricht. Ein sehr gutes Beispiel ist SWT oder seit kurzem Jambi (Qt für Java). Es ist also nicht nur in C++ so, das immer mal wieder ein neues GUI-Toolkit auftaucht. Das zeigt eigentlich nur, das eine Sprache lebt!
-
Hmmm. Man muss ja nicht gleich alles Re-Designen und überarbeiten.
Warum nicht einfach nur ein vernünftiges API auf das vorhandene aufsetzen? Ich habe mir z.B. für wxWidgets eigene Thread und Event-Klassen geschrieben, die per boost::function funktionieren, intern aber natürlich das orginale WX-API verwenden. Das könnte man mit Leichtigkeit auf andere Bereiche ausbauen.
Das ist zwar sicherlich nicht der Weisheit letzter Schluss, aber auf jeden Fall sehr viel weniger Arbeit als ein Toolkit von Grund auf neu zu machen. Klar das ist auch nur ein weiterer Wrapper um den Wrapper, aber das würde ich für ein vernünftiges, zeitgemässes API ohne zu Zögern in Kauf nehmen.
-
Unter wxGTK wäre das dann doch sogar ein Wrapper um einen Wrapper um einen Wrapper, oder?
Man kanns auch übertreiben...
-
Bin ich der einzige der C++ fuer GUI-Programmierung total ungeeignet findet?
Ansonsten, nehmt doch lieber diese V Bib (oder eine andere gute, aber veralterte Lib), und bringt sie aufn neusten Stand. Die Einarbeitungszeit ist sicher besser genutzt als das Rad zum 5000x neu zu erfinden.
-
DEvent schrieb:
Bin ich der einzige der C++ fuer GUI-Programmierung total ungeeignet findet?
Ja, du bist der einzige, der sich so was ausgedacht hat. Sogar BS spricht von GUI Bibliotheken im TC++PL!
-
DEvent schrieb:
Bin ich der einzige der C++ fuer GUI-Programmierung total ungeeignet findet?
Ansonsten, nehmt doch lieber diese V Bib (oder eine andere gute, aber veralterte Lib), und bringt sie aufn neusten Stand. Die Einarbeitungszeit ist sicher besser genutzt als das Rad zum 5000x neu zu erfinden.
Gibt es denn eine vergleichbare Alternative? Welche sich auch statisch Linken lässt, und keine Abhängigkeiten zu einer Plattform/Runtime hat?
-
phlox81 schrieb:
DEvent schrieb:
Bin ich der einzige der C++ fuer GUI-Programmierung total ungeeignet findet?
Ansonsten, nehmt doch lieber diese V Bib (oder eine andere gute, aber veralterte Lib), und bringt sie aufn neusten Stand. Die Einarbeitungszeit ist sicher besser genutzt als das Rad zum 5000x neu zu erfinden.
Gibt es denn eine vergleichbare Alternative? Welche sich auch statisch Linken lässt, und keine Abhängigkeiten zu einer Plattform/Runtime hat?
Was spricht gegen dynamisches Linken? Wo ist der Unterschied ob man alles in einer Datei hat oder eben ein paar Dlls mitliefert? z.B. Java kannst du auch kompelieren (alles in eine exe).
Ausserdem, besonders bei einer GUI-Anwendung sollte Portabilitaet das wichtigeste sein. Die Logik, Hardwarenahes Zeug und sein GanzGeheimerAlgorithmusFoo sollte man eh von der GUI trennen.
Ich finde es genial das meine pure GUI-Anwendung auf Windows, Linux, Max, BSD, Solaris und Hastenichtgesehen laeuft. Am coolsten finde ich aber Webanwedungen. Das ist nicht nur portabel, sondern deine Daten sind Weltweit verfuegbar. Leider ist Ajax/JS ein wenig Schwach fuer komplexere Anwedungen und man hat nicht ueberall Internet.
@Zdravko: wer ist BS?
-
Bjarne Stroustrup.
-
Zdravko schrieb:
Bjarne Stroustrup.
Versteht mich nicht falsch. Meiner Meinung nach ist C++ absolut ungeeignet fuer GUI-Anwedungen, nicht fuer eine GUI-API. Die WinAPI sollte schon in C++ (oder in C) geschrieben sein, aber fuer ein Framework oder eine Anwendung ist C++ ungeeignet.
QT und GTK+ ist fuer mich eine GUI-API, kein Framework. Naja war halt nur meine Meinung, wollt keinem aufn Schlipps treten.
-
DEvent hör bitte auf zu trollen.
-
DEvent schrieb:
phlox81 schrieb:
DEvent schrieb:
Bin ich der einzige der C++ fuer GUI-Programmierung total ungeeignet findet?
Ansonsten, nehmt doch lieber diese V Bib (oder eine andere gute, aber veralterte Lib), und bringt sie aufn neusten Stand. Die Einarbeitungszeit ist sicher besser genutzt als das Rad zum 5000x neu zu erfinden.
Gibt es denn eine vergleichbare Alternative? Welche sich auch statisch Linken lässt, und keine Abhängigkeiten zu einer Plattform/Runtime hat?
Was spricht gegen dynamisches Linken? Wo ist der Unterschied ob man alles in einer Datei hat oder eben ein paar Dlls mitliefert? z.B. Java kannst du auch kompelieren (alles in eine exe).
Ausserdem, besonders bei einer GUI-Anwendung sollte Portabilitaet das wichtigeste sein. Die Logik, Hardwarenahes Zeug und sein GanzGeheimerAlgorithmusFoo sollte man eh von der GUI trennen.
Ich finde es genial das meine pure GUI-Anwendung auf Windows, Linux, Max, BSD, Solaris und Hastenichtgesehen laeuft. Am coolsten finde ich aber Webanwedungen. Das ist nicht nur portabel, sondern deine Daten sind Weltweit verfuegbar. Leider ist Ajax/JS ein wenig Schwach fuer komplexere Anwedungen und man hat nicht ueberall Internet.
Ja, Internetanwendungen sind aber hier nicht das Thema.
Und es ist toll, das man die Plattform Java auf so viele OS portiert hat, aber es ändert nichts an den Problemen die auch Java hat.
C++ steht da in nichts nach, alles was du mit Java machen kannst, kannst du auch mit C++ machen.Das statische Linken kann manchmal wichtig sein, wenn man keine Abhängigkeiten haben will, und alles was man statisch linken kann, kann man auch dynamisch linken.
Und wozu nicht das Rad neu erfinden, es gibt keine C++0x GUI Lib, aber der Bedarf ist sicher da.
phlox
-
Dravere schrieb:
Unterstützt doch dieses Projekt -> www.vcf-online.org
MVC, modernes C++, Windows/Mac/LinuxWäre mir nämlich ganz recht, da ich mit VCF vorhabe etwas zu entwicklen und ich habe das Gefühl, die fehlen noch etwas an Programmierer ^^'
Grüssli
Ich versuche es!
-
Leider wird VC2008 nicht unterstützt. Bye bye, vcf!