Professionelle GUI erstellen.
-
B.Larg schrieb:
Es sind mittlerweile dermaßen viele (professionelle) Applikationen, die ehemals MFC waren mittels wxWidgets auf OSX/Linux/Win/WinCE portiert worden, dass es mich wundert, dass MS dieses Framework noch nicht als Bedrohung identifiziert hat.
Da hast Du nicht ganz unrecht... und ich glaube manchmal, das MS in so einem Turm lebt, wo sie nichts anderes sehen und schon gar nicht auf andere Leute hören... es gibt einige MVPs die schon seit langem (>8 Jahre) dies sagen, aber es scheint als ob niemand zuhört...
Es wird auch gerade eine "hitzige" Debatte zwischen einigen MVPs und der Prudugtgruppe geführt. Hieraus nur mal ein Satz (der wohl nicht gegen NDA verstöst) (es geht um MFC):
In short that it has become the equivalent of Cobol in our industry in the year of 2010
-
Was soll das bedeuten Jochen? Warum sollte sich M$ mit wxWidget beschäftigen? Solche Frameworks sind doch völlig irrelevant. Erläutere doch mal bitte eingehender wie du das meinst.
-
Wir reden hier von C++. (Punkt) also nicht von C# oder anderen (angeblich portablen) Sprachen.
Und hier gibt es nun mal nur drei große Frameworks: MFC, QT, wx
MFC wurde entwickelt als es noch gar kein "richtiges" C++ gab... deshalb sind die ganzen Klassen auch nicht so toll.
QT/wx ist hier schon viel konsequenter.Wenn man nicht so sehr viel auf prortabilität achten muss, sollte man heute klar C# nehmen... wobei sich hier auch die Frage stellt: WinForms oder WPF! Diese Frage ist leider auch nicht so einfach zu beantworten.
-
Mit WinForms kann man zumindest nichts verkehrt machen. Das würde ich ja benutzen @Op.
Ob sich dieses WPF Zeug durchsetzt, bleibt erstmal abzuwarten. Würde mich nicht wundern, wenn M$ in 2 Jahren schon wieder mit was neuem ankommt, oder WinForms wieder verstärkt pushed und WPF wieder im stillen Kämmerlein verschwindet. Wäre ja nicht das erste mal.
-
hack0r schrieb:
.net wird bald schneller sein als nativ kompilierter code unter wind00f
wie kommt ihr alle auf so nen schmarn da geht mir ja die galle hoch das ist wie jeder benchmark der mir zeigt dass java schneller als c oder c++ ist, das kann doch keiner glauben...
-
weil der .net jitter laufzeitinformationen berücksichtigen kann.
-
weil der .net jitter laufzeitinformationen berücksichtigen kann.
so wie das java teil oder;)
-
kA mit java kenn ich mich nicht aus
-
C#, naja ich denke die Hälfte der User könnte meine Application dann nicht ausführen, weil sie nicht die C# restributables haben (zumindest nicht die neuesten^^)
aber egal, was wäre denn wenn M$ hören würde und wx als bedrohung einstufen würde? Gibt es dann eine Rundmeldung "Achtung bitte kein wx auf windows verwenden" oder was?
-
afaik ist es doch so das am ende alles über die cpu muß und die braucht maschienencode wer den generiert ist mir gleich, obs nun java c# (.net xyz) oder sonst was ist wenn ich mir nun anschau wielang größere software für die erstellung eben diesen codes braucht dann kann ich mir nicht vorstellen dass die laufzeitinformationen das noch umbiegen können evtl. zeigst mir mal ne große software die besser ist statt nen spezialisierten benchmark wo man immer die eine oder andere sprache besser aussehen lassen kann...
-
sry für offtopic
-
hack0r schrieb:
weil der .net jitter laufzeitinformationen berücksichtigen kann.
Noch nie was von "Profile-Guided Optimization" gehört?
-
wtff? schrieb:
C#, naja ich denke die Hälfte der User könnte meine Application dann nicht ausführen, weil sie nicht die C# restributables haben (zumindest nicht die neuesten^^)
aber egal, was wäre denn wenn M$ hören würde und wx als bedrohung einstufen würde? Gibt es dann eine Rundmeldung "Achtung bitte kein wx auf windows verwenden" oder was?Nee... dann würden sie entweder was besseres rausbringen oder zumindest die MFC komplett überarbeiten...
-
Jochen Kalmbach schrieb:
hack0r schrieb:
weil der .net jitter laufzeitinformationen berücksichtigen kann.
Noch nie was von "Profile-Guided Optimization" gehört?
nö hatte ich ned. ist aber auch nicht so flexibel.
-
hack0r schrieb:
Warum sollte sich M$ mit wxWidget beschäftigen? Solche Frameworks sind doch völlig irrelevant.
Irrelevant? Wenn sie MS das Wasser abgraben, weil die ganzen schönen Windows-Applikationen plötzlich auch ganz ohne MFC und vor allem ohne Windows funktionieren?
MS hat ja auch sehr viel für wxWidgets getan: justament als wxWidgets einen Status erreicht hat, in dem es eine vollwertige und zu dem noch leicht zu portierende Alternative für die MFC war, wurde selbige quasi abgekündigt.
Und was macht eine Firma, wenn sie eine Riesenapplikation auf Basis der MFC hat? Bestimmt nicht der neuesten Sau folgen, die MS durchs Dorf jagt und alles auf Basis von .NET von Grund auf neu implementieren. Speziell dann nicht, wenn es eben eine Alternative gibt, bei der die Portierung zu über 90% ein reines Text-Replace ist.
Auf die Art hat MS sehr viele Firmen ins wxWidgets-Lager getrieben. Da hilft es ihnen jetzt auch nichts mehr, wenn sie die MFC nun doch wieder weiterentwickeln. Da wird nicht eine der Applikationen mehr zurück portiert - zumal die jetzt auch ganz sauber auf anderen Plattformen laufen.
-
ohne wind00f is ja jetzt mal quatsch, nur weil das frontend in wxwidget programmiert ist.
musst in net auch nicht großartig neuimplementieren, kannst ja c++/cli krempel erstmal benutzen, da musste ja nicht viel ändern. und ich war auch immer ein feind von .net, aber es ist eigtl ganz nett. wenn ich für wind00f entwickeln würde, würde ich es auf jeden fall nutzen. allein schon weils managed ist. c++ ist ne unnötige gefahrenquelle.
-
So, habe mal ein wenig mit WPF experimentiert. Was ich noch nicht herausgefunden habe, ist wie diese ausfahrbare Toolbox (rechte Seite) und diese Registerkarten wie z.B. der Projektmappen-Explorer (linke Seite) aus der Visual Studio GUI in der WPF heißt. Diese Elemente würde ich nämlich gerne mit in meine GUI übernehmen.
Und um richtiges DirectX in einem Fenster darzustellen (also nicht das eingeschränkte DirectX der WPF) brauche ich ja eine Windows-Form? Wie heißt diese in der WPF bzw. unter welchem Namen ist diese in MS Expression zu finden?