Warum machen wir uns nicht eine neue schöne C++ GUI Bibliothek?
-
Ich bin entspannt auf Artchie's Lib!
-
Für alle Nicht-Forscher: http://algierlib.tigris.org/
-
Artchi schrieb:
Ehm, meinste in der bekannten GUI-Übersicht oder Genauere Infos?
Genauere Infos. Kann mich wage daran erinnern, dass du kurz auf deiner Seite deine Lib präsentiert hattest und dazu dann, das es noch in der Entwicklung sei. Könnte unter "Eigene Projekte" oder so damals gewesen sei. Hoffe mal das war deine HP
Ich schaue mal nach ob ich was finde ...
-
Hazzel schrieb:
Für alle Nicht-Forscher: http://algierlib.tigris.org/
Das sieht ja interessant aus. Hat das schon mal jemand eingesetzt und kann ein kleines Feedback geben?
-
Ich denke das der Ansatz, das jeder für sich an einer Lib strickt falsch ist.
1 Mann Projekte sind einfach zu unzuverlässig um darauf bauen zu können.Imho bräuchte es schon mindestens 2-3 gute Leute, um mal so eine GUI Lib auf die Beine zu stellen:
mindestens einer für das Interface design, also die Pure Libimplementierung,
und dann jeweils mindestens einen pro Plattform, der dies dann für die Plattform implementiert.
-
Du hast auf jeden Fall Recht, wenn es um die Entwicklungsgeschwindigkeit und Zukunftfähigkeit geht, das da ein Ein-Mann-Projekt benachteiligt sein kann. Nur wird man nicht darum herum kommen, das jemand erstmal etwas anfängt. Denn das mehrere Leute gleichzeitig anfangen, wird schwer. Weil einer muß die Führung und das Sagen übernehmen. Weil sonst gibts drei Personen mit drei Meinungen, und dann wird es erst Recht nicht voran gehen. Es wird auf jeden Fall scheitern!
In einer Firma gibts immer einen Chef oder einen Projektleiter, der das letzte Wort hat. Und genau das gleiche wirst du auch in einem Opensource-Projekt haben (müssen). Der Unterschied bei OSS ist nur, das jemand das Ding nehmen und es nach eigenen Vorstellungen erweitern oder sogar umbauen kann... "Fork" nennt sich das, oder?
Wenn ein Projekt und dessen Konzept keine Anhänger findet, wird es sterben. Wird es soweit gefallen, das jemand sogar etwas beisteuern will, wird es überleben. (s. Ultimate++) Aber es muß einen geben, der einen Anfang macht. Nur weil ein Projekt mit einer Person startet, muß es nicht auf alle Ewigkeit ein Ein-Mann-Projekt bleiben. (da gibts viiiele Beispiele)
-
Wenn man ne GUI fuer die Masse entwickeln will, sind die ansprueche auch dementsprechend weit gefaechert ....
Dann kommen dinge wie: mit meinem Compiler musses aber auch gehen ... namespaces ciao
einfache bedienbarkeit auch fuer neulinge: ciao complexe templates in der Userschnittstelle
der Umfang wird sehr maechtig, weil jeder alles unterstuetzt haben will ...Wenn man daraus nen guten kompromiss macht, glaubt Ihr das wuerde so viel anders aussehen wie QT oder wxWidgets ???
Und ner neuentwicklung wird es schwer fallen, weil es eben diese GUI's bereits gibt, ....
Noch was zur QT:
Qt - sogar noch enormer als wxWidgets, benutzt auch selten STL, sondern eigene Schnittstellen
Es hat eigene container, die muss man aber ned nutzen ... die meisten Widgets oder andere klassen bieten alternative schnittstellen an um die QT container umgehen zu koennen. Das das bissi umstaendlicher ist, ist aber auch klar ...
Mittlerweile hat QT auch auf noch mehr Bibs gesplittet, wxWidgets glaub ich schon von anfang an. Glaub viel mehr geht nimmer, oder man muesste Programme mit eigener intilligenz schreiben, um das linken handelbar zu machen ....
Also so schlimm find ich die bibs nimmer ...
ciao ...
-
RHBaum schrieb:
Dann kommen dinge wie: mit meinem Compiler musses aber auch gehen ... namespaces ciao
Ein Compiler ohne namespaces Support ist halt Müll.
RHBaum schrieb:
einfache bedienbarkeit auch fuer neulinge: ciao complexe templates in der Userschnittstelle
Ich finde Template Programmierung viel viel einfacher. Neulinge sollen mit C spielen, nicht mit C++.
-
RHBaum schrieb:
Dann kommen dinge wie: mit meinem Compiler musses aber auch gehen ... namespaces ciao
Ähm, dann ist das aber nicht mal annähernd ein C++-Compiler!
Dieses "Alte-Compiler müssen unterstützt werden!" ist gerade das, was wxWidgets u.a. so hässlich macht. Kein Wunder das immer wieder neue Toolkits aus dem Boden spriessen. Ich z.B. supporte als ältesten MSVC-Compiler den 2003er (7.1), und das ganz bestimmt auch nicht die nächsten 10 Jahre. Wollte eigentlich schon den MinGW fallen lassen, weil der serienmäßig nicht mal Wide-Streams mitbringt. Und wer keinen einigermassen C++-konformen Compiler hat, hat halt Pech. 
-
Artchi schrieb:
RHBaum schrieb:
Dann kommen dinge wie: mit meinem Compiler musses aber auch gehen ... namespaces ciao
Ähm, dann ist das aber nicht mal annähernd ein C++-Compiler!
Dieses "Alte-Compiler müssen unterstützt werden!" ist gerade das, was wxWidgets u.a. so hässlich macht. Kein Wunder das immer wieder neue Toolkits aus dem Boden spriessen. Ich z.B. supporte als ältesten MSVC-Compiler den 2003er (7.1), und das ganz bestimmt auch nicht die nächsten 10 Jahre. Wollte eigentlich schon den MinGW fallen lassen, weil der serienmäßig nicht mal Wide-Streams mitbringt. Und wer keinen einigermassen C++-konformen Compiler hat, hat halt Pech. Gut gesagt
-
Ich denke das es sich nicht mehr lohnt, eine GUI Lib in C++ auf zu setzen, man sollte dann direkt mit C++0x arbeiten, gerade das Stringhandling würde dies Vereinfachen.
Zumal die Templates dann wesentlich mehr Möglichkeiten bieten. Und eine gute GUI0x Library wäre sicher auch Konkurrenzfähig zu den schon bestehenden "alten GUI Libs".
-
Ich glaube Artchi wird TR1 benutzen. Wenn C++0x offiziel erscheint, dann wird die Umwandlung relativ einfach sein.
-
Wollte nur wissen ob das Projekt gut geht...?
-
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!