Welches Framework(?) ist für mich geeignet
-
Kann man denn WinForms in unmanaged C++ nutzen?
-
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.
-
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.
-
Hört sich vernünftig an, was du da redest.
-
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.
-
Ich denke ich werde mich wenn ich Zeit habe mal eingehend mit wxWidgets beschäftigen. Scheint im Moment das vernünftigste zu sein.
-
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
-
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.)
-
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...).
-
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.
-
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.
-
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.
-
Egal ob man diese Option nutzt oder nicht, wxWidgets ist spitze!
(und wird es auch auf zukünftigen Plattformen bleiben)MfG Max
-
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.Ja, das das stimmt zumindest wenn man Standard Benutzer vor sich hat, die nur mit Windows vertraut sind.
Wenn man eine Anwendung schreibt, die hauptsächlich fortgeschrittene Benutzer nutzen,
ist das nicht ganz so wichtig.MfG Max
-
Auch als fortgeschrittener Benutzer kann man dem ganzen UI-technischen Schrott ausweichen *tu*. Eine windowsige UI ist für mich oft genug ein Kaufgrund gegenüber Open Source.
Dafür habe ich beobachtet, dass richtige Computerneulinge sich an einer völlig uneinheitlichen UI gar nicht so sehr stören. Vielleicht, weil sie die Buttons meistens eh einzeln anhand der Caption raussuchen
-
Dafür habe ich beobachtet, dass richtige Computerneulinge sich an einer völlig uneinheitlichen UI gar nicht so sehr stören. Vielleicht, weil sie die Buttons meistens eh einzeln anhand der Caption raussuchen
Jo und bei Mac oder Unix Usern ist das wieder was ganz anderes. Jeder mag eben das am liebsten, an das er gewöhnt ist. Ich mag unter Windows übrigens die GTK Applikationen am liebsten, weil ich die von Linux her kenne
(und im Endeffekt gibt es auch viele Professionelle Software, die auf komplett eigenen Widget Systemen basieren, die dann auf jeder Platform gleich sind aber zu den gewohnten Standards Inkompatibel. Aber für solche Software macht man ja idr. eh Schulungen)
archi schrieb:
Es war nur ein Beispiel von mir, um zu zeigen wie flexiebel wxWidgets mittlerweile ist.
nö, dass zeigt einfach, dass es sich um einen Wrapper Library handelt. Das kann auch jede andere Widget Library. Du kannst ja auch die WinAPI (die eben LowLevel ist) auf X11 Basis nachbilden (siehe zB. libwine)
-
kingruedi schrieb:
Die WinAPI wird von MS nicht mehr weiter entwickelt und wird in longhorn nur noch ein kompatibilitätslayer sein. Die winapi ist einfach veraltet
http://msdn.microsoft.com/Longhorn/Support/lhdevfaq/default.aspx#Q_Avalon_AvalonVsWin32
-
Zeus schrieb:
kingruedi schrieb:
Die WinAPI wird von MS nicht mehr weiter entwickelt und wird in longhorn nur noch ein kompatibilitätslayer sein. Die winapi ist einfach veraltet
http://msdn.microsoft.com/Longhorn/Support/lhdevfaq/default.aspx#Q_Avalon_AvalonVsWin32
Und? Was willst du uns damit sagen?
-
Lesen bildet
-
Zeus schrieb:
Lesen bildet
Dann bin ich ja sehr gebildet.
Aber anscheinend nicht genug um zu verstehen was du mit dem Link sagen willst...Willst du damit kingruedis Aussage bestätigen - was ich dem Link entnehme, oder widerlege, was ich deinem Auftreten entnehme. Ich weiss es nicht
