Welches Framework(?) ist für mich geeignet
-
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
-
[quote:2a8a766e92="Shade Of Mine
"]und wenn da jetzt alles Lahm wie Java ist
Laber keinen Schrott.
-
*lol*, das war jetzt natürlich nötig, den Thread wieder aus der Versenkung zu holen.
-
-
lol
-
Kann mir das wer übersetzen