Welches Framework(?) ist für mich geeignet

rüdiger

@WebFritzi
Platformunabhängig sollte man programmieren, damit man sich nicht von einer Platform abhängig macht. Ich nutze kein Windows zum spielen. Warum sollte man nur für Windows entwickeln? Das ist engstirnig

Die WinAPI wird von MS nicht mehr weiter entwickelt und wird in longhorn nur noch ein kompatibilitätslayer sein. Die winapi ist einfach veraltet

Walli

Ja, nur was ist die Alternative? Ich kenne im Moment keine gute Technologie auf die man beim UI setzen kann, die auch noch unter Longhorn Bestand hat. Windows Forms finde ich persönlich sch****.

Sovok

es gibt bis jetzt keine alternative... das is ja der witz an der diskussion der mich genervt hat

rüdiger

@Mastah
Windows Forms sind ja in Longhorn auch keine Native-Sache, da Longhorn ja wieder eine andere GUI Schnitstelle besitzt.

Als Alternative bleiben dir eben nur die genannten Frameworks GTK(mm), wxWindows, QT und co

@Sovok
es gibt sehr viele alternativen. du willst diese nur nicht sehen. aber ich hab keine lust die ganze diskussion wieder aufzurollen.

Flamesword

Sicher gibts Alternativen. Ob die gut sind, ist natürlich fraglich.
Ich persönlich bevorzuge wxWindows, da es kostenlos, plattformunabhängig und einfach toll ist.
WinAPI ist veraltet und durcheinander.

Shade Of Mine

MaSTaH schrieb:

Ja, nur was ist die Alternative? Ich kenne im Moment keine gute Technologie auf die man beim UI setzen kann, die auch noch unter Longhorn Bestand hat.

Dann lies den Thread.

@kingruedi: Und worauf wird wxWindows, GTK usw. unter Windows aufsetzten, wenn es WinAPI nicht mehr gibt?

Ω

Shade Of Mine

Omega schrieb:

@kingruedi: Und worauf wird wxWindows, GTK usw. unter Windows aufsetzten, wenn es WinAPI nicht mehr gibt?

Das ist das schöne an Abstraktion: es ist unwichtig worauf es aufsetzt.

Vielleicht wird es WinForms verwenden, vielleicht was anderes. Vielleicht unterschiedliche Sachen.

Aber es wird immer wxWindows bleiben und das Interface wird sich nicht ändern.

Kann man denn WinForms in unmanaged C++ nutzen?

operator void

Nein.

Ich verstehe aber die Aufregung über Windows Forms vs. Avalon nicht. Selbst *wenn* Longhorn mal da ist, wird die Masse der Anwendungen nicht Avalon benutzen können, weil die vorherigen Windows-Systeme nicht sofort aussterben. Die Anwendungen sehen also immerhin noch ein paar Jahre wie vernünftige Windows-Anwendungen aus. gtkmm hingegen sah noch nie nativ aus.

Shade Of Mine

operator void schrieb:

Nein.

mal sehen was die Zukunft bringt. MS hat sich in dieser Richtung eine Menge vorgenommen.

Ich verstehe aber die Aufregung über Windows Forms vs. Avalon nicht. Selbst *wenn* Longhorn mal da ist, wird die Masse der Anwendungen nicht Avalon benutzen können, weil die vorherigen Windows-Systeme nicht sofort aussterben.

Es geht hier nicht um die Pflege alter Anwendungen, sondern um die Entwicklung von neuen.

Natürlich wird MS nicht alles wegwerfen was sie sich jahrelang erkämpft haben: eine volle Kompatibilität zwischen den einzelnen Windowsversionen.

Natürlich wird die MFC noch jahrelang nutzbar sein. Natürlich werden 'alte' Windowsprogramme problemlos auf Longhorn laufen.

Nur ein Narr würde diese Milliarden an Codezeilen wegwerfen.

Aber hier geht es nicht um die Wartung von alter Software - sondern um die Entwicklung von Neuer. Und da sollte man winAPI schon garnicht verwenden und MFC
sollte man auch meiden. Schließlich will man ja nicht das die Programme 'in Zukunft trotzdem laufen', sondern, dass sie in Zukunft erweiterbar sind. Man will neue Features verwenden können - denn was bringt einem eine Software die technisch hinter der der Konkurrenten steht? Da diese eben die neuen Technologien verwenden, man selber aber es nicht kann, bzw. nur über große Umwege.

WebFritzi

Hört sich vernünftig an, was du da redest.

operator void

Shade of Mine schrieb:

Und da sollte man winAPI schon garnicht verwenden und MFC
sollte man auch meiden.

Ups. Ich hab mich mal wieder nicht klar ausgedrückt: Ich wollte nicht die MFC oder WinAPI, sondern nur Windows Forms verteidigen Die würde ich nämlich nicht als "stirbt bald, gar nicht erst lernen" einsortieren, nur weil Avalon irgendwo am Horizont winkt. Das größere Problem ist im Moment doch sogar noch, dass sie zu neu ist und einige Leute sich gegen das .NET-Framework wehren.

Ich persönlich hoffe jedenfalls darauf, dass ich CLI/C++ noch erleben darf und Windows Forms-Coden dann Spaß macht.

Walli

Ich denke ich werde mich wenn ich Zeit habe mal eingehend mit wxWidgets beschäftigen. Scheint im Moment das vernünftigste zu sein.

Shade Of Mine

operator void schrieb:

Ups. Ich hab mich mal wieder nicht klar ausgedrückt: Ich wollte nicht die MFC oder WinAPI, sondern nur Windows Forms verteidigen Die würde ich nämlich nicht als "stirbt bald, gar nicht erst lernen" einsortieren, nur weil Avalon irgendwo am Horizont winkt.

Oh, sorry. Mein Fehler.

Ich denke, dass WinForms momentan dennoch etwas unstabil sind. Obwohl sie momentan die beste Möglichkeit für Windows GUIs bieten - würde ich dennoch versuchen mich möglichst nicht allzustark daran zu binden.

Ich bin sowieso auf die neuen Versionen von dotNET gespannt. Momentan ist alles n bisschen unsicher - wobei man nicht sehr falsch liegen kann, wenn man auf dotNET setzt.

Das größere Problem ist im Moment doch sogar noch, dass sie zu neu ist und einige Leute sich gegen das .NET-Framework wehren.

Jo, und das es noch nicht 'Interface stable' ist, wie WebForms und WinForms zeigen.

Ich persönlich hoffe jedenfalls darauf, dass ich CLI/C++ noch erleben darf und Windows Forms-Coden dann Spaß macht.

Dass du es erlben wirst, bin ich mir ziemlich sicher Die Frage ist nur wie gut CLI/C++ wirklich wird, und wie es sich in dotNET integriert.

Das ist das Problem momentan: man weiss nichts genau, aber man kann ne Menge vermuten. Wobei langsam alles immer klarer wird.

zB beim release von VC++7.1 waren ja einige Leute ganz schön erstaunt (mich eingeschlossen), warum MS einen super C++ Compiler releast, wo sie doch auf dotNET setzen. Jetzt mit CLI/C++ ists wieder etwas klarer

c++eus

Hi,

habt ihr euch schonmal http://download.microsoft.com/download/a/2/f/a2fc47d2-8bdf-4977-8364-1f38b893dba5/lharch_pdc2003.png angesehen? Da werden die Beziehungn zwischen Avalon, Indigo, WinFS, WinForms... sehr gut gezeigt (aber ein wenig unübersichtlich.)

tasti

Vielleicht ist auch ein Blick au FLTK nicht verkehrt (www.fltk.org), schön klein und schnell.
Kein Feature Monster, aber für meine Ansprüche hats bis jetzt gereicht (ok, ist auch nicht wirklich über ein paar Buttons hinausgegangen...).

Artchi

Hab erst kürzlich bei msdn etwas rumgestöbert, bzgl. C++, MFC, Win32 für die Zukunft (Avalon, WinForms usw.). Microsoft schreibt dort auch eindeutig rein, das unmanaged Code immer noch eine Bedeutung haben wird, wegen Performance-Gründen. Ich fand es doch sehr beeindruckend, lesen zu dürfen, das MS sagt, das der managed Code nicht 100% zum Einsatz kommen muß, in einer C++-Anwendung. Es wurde beschrieben, das man die GUI mit der zukünftigen Technik nutzen sollte (Managed C++ und WinFX) und das wohl aus Performancegründen die meisten Applikationen den restlichen Code in Unmanaged C++ laufen lassen werden.

Auch wenn viele immer wieder MS für schlecht halten, bin ich doch immer wieder sehr über ihre Ehrlichkeit positiv überrascht. Sie sagen nicht: setzt 100% auf Managed Code, um jeden Preis. Aber da wo es Vorteile bringt (z.B. die sehr leistungsfähige zukünftige GUI-Technik unter WinFX), sollte man Managed Code einsetzen.

Ich glaube auch, das wxWidgets zukünftig auf die neue WinFX umstellen wird/muß. Allein die WinFX-GUI wird sehr viele nette Feature mitbringen. Achja, und die WinFX-GUI wird ja auch endlich Hardware-beschleunigt.

Noch eine kleine Info bzgl. wxWidgets: es gibt ja mittlerweile auch wxUniversal. Dieser neue Layer zeichnet nämlich seine GUI-Elemente selbst (vergleichbar mit Javas Swing), und lässt wxWidgets nicht mehr direkt auf die OS-GUI-Elemente zugreifen. Daran kann man sehr schön sehen, wie flexiebel wxWidgets mittlerweile ist. Insofern wird es auch später kein Problem sein, das wxWidgets direkt mit WinFX zusammen arbeitet.

Shade Of Mine

Artchi schrieb:

Auch wenn viele immer wieder MS für schlecht halten, bin ich doch immer wieder sehr über ihre Ehrlichkeit positiv überrascht. Sie sagen nicht: setzt 100% auf Managed Code, um jeden Preis. Aber da wo es Vorteile bringt (z.B. die sehr leistungsfähige zukünftige GUI-Technik unter WinFX), sollte man Managed Code einsetzen.

Verstehe nicht was daran besonders ist.
Schließlich ist die Performance von dotNET ja _sehr_ wichtig. Denn dotNET wird der Kern von Longhorn sein - und wenn da jetzt alles Lahm wie Java ist - habe ich n paar verdammt gute Gründe Linux zu verwenden, wenn dort meine aufwendigen Anwendungen wie zB Grafikbearbeitung, Modellierung, etc. dort doppelt so schnell laufen. Da spare ich mir unmengen Geld an Hardware.

Folglich muss Longhorn schön schnell sein, und das kann es nicht, wenn alles managed ist.

Noch eine kleine Info bzgl. wxWidgets: es gibt ja mittlerweile auch wxUniversal. Dieser neue Layer zeichnet nämlich seine GUI-Elemente selbst (vergleichbar mit Javas Swing), und lässt wxWidgets nicht mehr direkt auf die OS-GUI-Elemente zugreifen.

An Java.swing und gtk auf Windows sieht man, wie mies dieser Ansatz ist.
Du kannst den User nicht einfach aus seiner gewohnten Umgebung reissen - jede Anwendung muss Nativ wirken, und sich schön ins System integrieren.

Artchi

Shade Of Mine schrieb:

An Java.swing und gtk auf Windows sieht man, wie mies dieser Ansatz ist.
Du kannst den User nicht einfach aus seiner gewohnten Umgebung reissen - jede Anwendung muss Nativ wirken, und sich schön ins System integrieren.

wxUniversal ist eine OPTION! Niemand muß wxUniversal mitverlinken, aber er KANN. Dadurch kann man z.B. wxWidgets auf Betriebssysteme portieren, die z.B. nicht alle Feature nativ unterstützen.

Es war nur ein Beispiel von mir, um zu zeigen wie flexiebel wxWidgets mittlerweile ist. Natürlich kann man weiterhin wxWidgets als Wrapper auf die native API des jeweiligen OS benutzen. Alles kein Problem.

Aber ist schon klar, hauptsache immer die negativen Punkte versuchen zu finden und ordentlich Contra geben.