Windows 8 Metro Apps nur noch mit .NET möglich?
-
Hi Leute,
ich hab schon viel nach einer genauen Erklärung gesucht, finde aber immer nur Antworten bezüglich des alternativen und klassischen Desktops unter Windows 8.
Wie die Überschrift schon sagt, würde mich interessieren, mit welchen mitteln es NUR möglich ist, Metro Apps zu programmieren. Und ich meine wirklich nur Metro-Apps und keine Ausweichmöglichkeit auf den Desktop.
Und zwar interessiert es mich wegen den ganzen GUI-Toolkits wie zb Qt. Laut Quellen im Netz sollen Windows 8 Apps nur noch ausschließlich mit Visual Studio und dem .NET Framework zu programmieren sein. Alles andere landet auf dem normalen Desktop, welcher in meinen Augen kein richtiger mehr ist und Microsoft wahrscheinlich noch auf die Idee kommt, diesen komplett abzuschaffen.
Hier mal ein Link zu Qt und Metro: http://qt-project.org/wiki/Qt-5-on-Windows-8-and-Metro-UI
So wie ich das verstehe, soll es sehr wohl möglich sein, mit Qt 5 Metro-Apps zu realisieren...was aber leider JEDER von mir gefundenen anderen Quelle widerspricht. Auf dieser Seite seht ihr auch eine Grafik, welche Sprachen für die Metro-Apps verfügbar sind (aber nur Microsoftseitige "GUI-Lösung").Hier noch ein Link, welcher zeigt, dass Microsoft sehr fest an Metro halten wird: http://derstandard.at/1336697890363/Einschraenkungen-Windows-8-Kostenlose-Entwicklungstools-nur-mehr-fuer-Metro-Apps
Wenn man also diese Notlösung des klassischen und abgespeckten Desktops außer Betracht lässt, werden GUI-Toolkits für Windows in Zukunft doch kaum noch bedeutung haben, oder nicht? Wenn man schon extra .NET lernen muss, kann man für Linux ja auch extra nur GTK lernen oder für Mac Objective-C und Anhang
Ich spare mir an dieser Stelle meine Meinung über Windows 8, jeder hier sollte es bereits kennen.
-
"Windows Store Apps" basieren auf WinRT, welches im Prinzip auf einer Weiterentwicklung von COM basiert. Du kannst WinRT von .NET aus benutzen, aber eben nicht nur von .NET aus. WinRT selbst ist komplett native und damit auch in normalem C++ verfügbar. Dass man Windows Store Apps nur auf Basis von .NET bauen kann ist jedenfalls völliger Bullshit, ganz im Gegenteil...
-
Ok, das hört sich schon mal gut an.
Ich bezog mich zwar mehr auf Windows 8 für x86er Rechner, aber deine Info zur RT-Version ist auch interessant.
Ich habe halt auch noch gelesen, dass die Apps durch Microsoft geprüft werden und sie ausschließlich nur per App-Store bezogen und angeboten werden können. Auch hier soll Microsoft ein Auge drauf haben, dass man die Mircosoft-Lösung nutzt. Das ist dann wahrscheinlich auch Fehlinfo.Nur was mich hier noch interessiert:
Mit Qt ist es möglich ein Programm oft ohne große Änderungen auf ein anderes System zu portieren. Aber Metro ist doch ein komplett anderes Oberflächendesign. Schreibe ich mit Qt gezielt eine App für Metro, so kann ich diese doch nicht ohne weiteres für Linux portieren...das kann doch nur mit extremen Aufwand gehen?Ich bin mit der Cross-Plattform GUI-Entwicklung noch nicht so erfahren und habe bisher nur den klassischen Desktop im Kopf (Desktop + Fenstermanager + GUI-Elemente), wie es bei Mac, Linux und bis Windows 7 standard ist. Die Windows Programmierung mit Visual Studio ist bei mir lange her und hier musste ich mir nicht besonders Gedanken darüber machen...man zeichnete die GUI und schrieb den Code dazu...der Rest wurde erledigt und das Programm sah auf jedem Windows gleich aus. Jetzt mit Qt, GTK und FLTK (ich nutze fast nur noch Linux), ist es immer noch so...das Programm sieht überall (Systemunabhängig) gleich aus (mal abgesehen von Themes). Aber bei Windows-Metro kann ich es mir einfach nur so vorstellen, dass man gezielt dafür Programmieren muss und dass das Programm auch nicht ohne weiteres auf ein anderes Betriebssystem oder sogar Windows-Desktop portierbar ist. Metro scheint mir nicht mal einen wirklichen Fenstermanager zu haben...als würden die Widgets alle direkt im Vollbildmodus dargestellt
Ich denke Qt hat hier halt den Vorteil, dass man sich in EIN Toolkit einlernen muss und es dann überall gezielt anwenden kann. Aber wenn man einen Desktop, Android, iOS und Windows-Metro betrachtet muss man gezielt dafür entwickeln und eine Portierung zwischen diesen Oberflächen wäre mit viel Aufwand verbunden.
Ist das jetzt korrekt so?
-
Beefi schrieb:
Ok, das hört sich schon mal gut an.
Ich bezog mich zwar mehr auf Windows 8 für x86er Rechner, aber deine Info zur RT-Version ist auch interessant.Ich bezog mich allerdings auf WinRT, die Windows Runtime, im Prinzip das, was unter Metro der WinAPI entspricht und nicht Windows RT, der Metro-only Version von Windows 8. Metro Anwendungen bauen auf WinRT und laufen auf allen unterstützten Architekturen, x86 sowie ARM...
Beefi schrieb:
Ich habe halt auch noch gelesen, dass die Apps durch Microsoft geprüft werden und sie ausschließlich nur per App-Store bezogen und angeboten werden können. Auch hier soll Microsoft ein Auge drauf haben, dass man die Mircosoft-Lösung nutzt. Das ist dann wahrscheinlich auch Fehlinfo.
Microsoft hat hier vor allem ein Auge darauf, ein Mindestmaß an Qualität sicherzustellen, so wie praktisch alle anderen es in ihren jeweiligen App Stores auch machen...
Beefi schrieb:
Mit Qt ist es möglich ein Programm oft ohne große Änderungen auf ein anderes System zu portieren. Aber Metro ist doch ein komplett anderes Oberflächendesign. Schreibe ich mit Qt gezielt eine App für Metro, so kann ich diese doch nicht ohne weiteres für Linux portieren...das kann doch nur mit extremen Aufwand gehen?
Allein die Idee von "Cross Plattform GUI" ist imo von vornherein völlig fehlgeleitet. Wieso haben wir verschiedene Plattformen? Leute, die sich z.B. einen Mac zulegen, tun das doch unter anderem genau darum, weil sie eben den Look and Feel von OS X haben wollen, gleich wie Windows User den Windows Look and Feel haben wollen. So Zeug wie Qt haben wir es zu verdanken, dass es heutzutage Software gibt, die sich auf allen möglichen Plattformen gleich unnatürlich anfühlt. Wenn du mich fragst: Entweder man unterstützt eine Plattform ganz, was bedeutet, dass man eine auf die jeweilige Kultur abgestimmte Version seiner Anwendung anbietet, oder man unterstützt sie nicht...
Für mich als User ist eine Qt basierte Anwendung jedenfalls eine Anwendung, in der ich mich grundsätzlich nicht willkommen fühle und die ich genau so lange benutze, bis ich eine gangbare Alternative gefunden hab...
(Qt steht hier als populäres Beispiel natürlich synonym für alle derartigen Frameworks und Toolkits.)
-
.NET und COM liegen schon verdammt eng beieinander..
..ist halt alles im Zweiffelsfall Overhead.Bin auch mal gespannt wie gut es MS gelingt den Shop Virenfrei zu halten..
..will jemand wetten? /jk
Ich seh das mit den Crossplattform-GUI-Toolkits wie dot,
keine Firma will 1000+ Mitarbeiter schulen nur weil eine Tabelle plötzlich anders aussieht.
Andrerseits halten so "freie" Ansätze halt die Tür für Uns offen
das wir überhaupt noch "frei" programmieren können.
Ist ja nicht so das MS Visual Studio (Express oder was auch immer)
von vornherein für jeden frei verfügbar auf den Markt geschmissen hätte.Kann auch sehr schnell eine emotionale Geschichte werden
gerade in so einem Forum hier,
weil da halt ne´ Menge unterschiedlicher Interessen aufeinanderprallen..Um auf die Titelfrage zurückzukommen
http://forum.xda-developers.com/showthread.php?t=2092158
Jailbreaking ist grad gross in Mode
und ich sehe keinen Grund warum das nicht (wie Wine etc) so bleiben sollte,
zur Not gibts halt wieder eine EU-Klage
und MS muss die Hosen runterlassen..
-
pV schrieb:
.NET und COM liegen schon verdammt eng beieinander..
..ist halt alles im Zweiffelsfall Overhead.Inwiefern liegen .NET und COM denn bitte "verdammt eng beeinander"!?
-
Selbes OOP Design
-
Hast du überhaupt eine Ahnung was COM ist!?
-
Aus meiner Blickrichtung (eher nicht Windows-orientiert)
ist .NET nicht natives VB/C(++)/C#..
sondern eben nur Matsch der alles zusammenbringen soll.Ob man das ganze jetzt Managed nennt oder nicht,
es kommt doch schon arg wie ActiveX-Controls daher..
(Joa man kann "Manage"ing jetzt mit Java vergleichen machts aber auch nicht besser)Und ActiveX-Controls sind dann doch eher COM oder was denkst Du ?^^
Versuchs mal aus der Linux-Richtung zu betrachten
wo man sich das MS hin und her seit Jahren angucken muss,
integrierbar wurde der Krempel auch nach 4-5 Namensänderungen immer noch nicht..
-
Ich bezog mich allerdings auf WinRT, die Windows Runtime, im Prinzip das, was unter Metro der WinAPI entspricht und nicht Windows RT, der Metro-only Version von Windows 8. Metro Anwendungen bauen auf WinRT und laufen auf allen unterstützten Architekturen, x86 sowie ARM...
Windows RT hat auch einen klassischen Desktop, jedoch duldet Microsoft keine Fremdanwendungen dafür. Auf dem Desktop ausführbar ist nur Microsoft-Software, und nur die, die Microsoft will. Wir dürfen/können bei WinRT praktisch nur für Metro programmieren.
Mit dieser Cross-Plattform GUI Sache stimme ich dir teilweise zu. Ich mag es auch nicht, dass unter Linux so viele GUIs durcheinander gestreut sind (GTK2, GTK3, Qt, usw). Hat man nicht für alle gleichzeitig das passende Theme, schauts gleich unsympathisch aus. Jedoch hat man hier die Wahl an viele Alternativen. So kann man zb auch vom Unity und Gnome3 "Fehlprojekt" ganz simpel auf XFCE wechseln
Auch sind die GUIs unterschiedlich performant und man kann sie gezielt einsetzen.Von Windows bin ich eigentlich fast ganz weg und für mich persönlich ist die Programmierung dort auch nicht mehr so interessant. Wäre es bei Windows so wie bei Linux, dass ich die Desktopumgebung runterschmeißen könnte und mir die meiner Wahl installieren könnte, sähe es ganz anders aus. Ich kann Windows 8 einfach nicht mehr einordnen...es ist kein System für den Desktopeinsatz und auch kein System für ein Tablet...eher beides zusammen, aber von beidem nichts ganzes
Ich hätte aber doch gerne die Fähigkeit, für den Fall der Fälle mal schnell ein eingelerntes GUI parat zu haben. Deswegen eigentlich die ganze Frage wegen Qt und Metro.
Also um nochmal zur Ursprungsfrage zurückzukommen. Ich kann also mit C++ weiterhin komplett nativ per API auch Metro Anwendungen erstellen. Und das eben auch mit dem GNU GCC. Das ist schon mal gut.
Gibt es auch ein GUI-Toolkit mit welchem man solche Metro-Anwendungen erstellen kann? Bzw eine andere Hilfestellung für die GUI-Zeichnung, abgesehen von Visual Studio? Ich bin hier eher der Typ, der sich das mit der Maus zusammenklickt.
Es interessieren mich auch alternativen zu Qt, aber eben auch Qt. Es soll anscheinend mit Qt5 gehen, aber man findet nirgends einen Beweis, sondern nur das "Gerücht".
-
pV schrieb:
Aus meiner Blickrichtung (eher nicht Windows-orientiert)
ist .NET nicht natives VB/C(++)/C#..
sondern eben nur Matsch der alles zusammenbringen soll.Dann hast du offenbar irgendwas grundlegend falsch verstanden.
pV schrieb:
Ob man das ganze jetzt Managed nennt oder nicht,
es kommt doch schon arg wie ActiveX-Controls daher..
(Joa man kann "Manage"ing jetzt mit Java vergleichen machts aber auch nicht besser)Und ActiveX-Controls sind dann doch eher COM oder was denkst Du ?^^
ActiveX basiert auf COM und nichts davon hat mit .NET auch nur ein bisschen was zu tun.
pV schrieb:
Versuchs mal aus der Linux-Richtung zu betrachten
wo man sich das MS hin und her seit Jahren angucken muss,
integrierbar wurde der Krempel auch nach 4-5 Namensänderungen immer noch nicht..Mir ist nicht wirklich klar, was Linux mit dieser Dikussion zu tun hat!?
Beefi schrieb:
Also um nochmal zur Ursprungsfrage zurückzukommen. Ich kann also mit C++ weiterhin komplett nativ per API auch Metro Anwendungen erstellen.
Ja
Beefi schrieb:
Und das eben auch mit dem GNU GCC. Das ist schon mal gut.
Sollte theoretisch möglich sein, wobei ich keine Ahnung hab, ob das auch tatsächlich bereits funktioniert. Ich seh aber auch keinen rationalen Grund, wieso man GCC verwenden sollte, wenn die Zielplattform Windows ist.
Beefi schrieb:
Gibt es auch ein GUI-Toolkit mit welchem man solche Metro-Anwendungen erstellen kann?
WinRT?
Beefi schrieb:
Bzw eine andere Hilfestellung für die GUI-Zeichnung, abgesehen von Visual Studio? Ich bin hier eher der Typ, der sich das mit der Maus zusammenklickt.
Jeder kann einen Editor für XAML bauen, ob es bereits einen alternativen Editor zu dem in Visual Studio eingebauten gibt, weiß ich allerdings nicht. Aber auch hier wieder: Wer für Windows entwickelt und dafür was anderes als Visual Studio verwendet, dem kann man imo sowieso nicht helfen...
-
dot schrieb:
pV schrieb:
Aus meiner Blickrichtung (eher nicht Windows-orientiert)
ist .NET nicht natives VB/C(++)/C#..
sondern eben nur Matsch der alles zusammenbringen soll.Dann hast du offenbar irgendwas grundlegend falsch verstanden.
Musste mich durch "genug" virtuelle Tabllen hangeln
um zu sehen was da unter der Haube werkelt.Würde mich aber schonmal interessieren wie man natives VB/C(++)..
mit .NET erklärt (technisch - nicht als MS PR Berater)pV schrieb:
Ob man das ganze jetzt Managed nennt oder nicht,
es kommt doch schon arg wie ActiveX-Controls daher..
(Joa man kann "Manage"ing jetzt mit Java vergleichen machts aber auch nicht besser)Und ActiveX-Controls sind dann doch eher COM oder was denkst Du ?^^
ActiveX basiert auf COM und nichts davon hat mit .NET auch nur ein bisschen was zu tun.[/quote]
Was bliebe denn von .NET übrig wenn man COM/DCOM von .NET loslösen würde ?pV schrieb:
Versuchs mal aus der Linux-Richtung zu betrachten
wo man sich das MS hin und her seit Jahren angucken muss,
integrierbar wurde der Krempel auch nach 4-5 Namensänderungen immer noch nicht..Mir ist nicht wirklich klar, was Linux mit dieser Dikussion zu tun hat!?[/quote]
Das man RPC s ohne proprietären Bloat besser umetzen kann.
-
pV schrieb:
Würde mich aber schonmal interessieren wie man natives VB/C(++)..
mit .NET erklärt (technisch - nicht als MS PR Berater)Was genau meinst du damit?
pV schrieb:
Was bliebe denn von .NET übrig wenn man COM/DCOM von .NET loslösen würde ?
Alles? COM/DCOM hat mit .NET nichts zu tun, das sind zwei völlig unabhängige Technologien.
-
Wer für Windows entwickelt und dafür was anderes als Visual Studio verwendet, dem kann man imo sowieso nicht helfen...
Ja eigentlich stimmt das ganze schon. Ich musste jetzt auch feststellen, dass ich bei Visual Studio auch wieder einiges verpasst hab:
1. Mir ist bekannt, dass die MFC in der Express Version fehlt. Windows Anwendungen mit purem C++ wären daher nicht möglich, richtig? Aber .NET ist ja vollständig enthalten oder? Wenn es um Windows-Anwendungen geht, würde ich hier dann sowieso die .NET Variante mit C# vorziehen.
2. Ich war immer der festen Überzeugung, dass man mit der Express Version keine kommerziellen Programme schreiben darf. Bzw seine Programme nicht verkaufen darf. Aber ich sehe ja gerade, dass das ja totaler Quatsch ist. Zwar habe ich nie Programme verkauft...aber es ist halt doch immer so ein Punkt im Hinterkopf, dass man sich wohler fühlt, wenn man mit seiner Arbeit auch wirklich machen kann, was man will.
3. Ich hatte gestern in einem anderen Thread geäußert, dass Visual Studio sehr aufgebläht wurde. Es läuft im Vergleich zu sämtlichen IDEs einfach echt zäh. Früher als ich regelmäßig Visual Studio 6 im Einsatz hatte, war das absolut nicht der Fall. Lag es vielleicht daran, weil ich das komplette Visual Studio Ultimate installiert hatte?
EDIT:
COM/DCOM hat mit .NET nichts zu tun, das sind zwei völlig unabhängige Technologien.
Da geb ich dot recht. Damit hatte ich schon in den 90ern zu tun, wo es NET noch gar nicht gab.
-
Beefi schrieb:
1. Mir ist bekannt, dass die MFC in der Express Version fehlt.
Richtig, aber MFC ist sowieso hoffnungslos veraltet...
Beefi schrieb:
Windows Anwendungen mit purem C++ wären daher nicht möglich, richtig?
Man kann immer noch direkt die WinAPI oder andere Libraries verwenden...
Beefi schrieb:
Aber .NET ist ja vollständig enthalten oder?
Klar
Beefi schrieb:
Wenn es um Windows-Anwendungen geht, würde ich hier dann sowieso die .NET Variante mit C# vorziehen.
Wenn es um die Entwicklung eines komplexeren User Interface geht, dann ich auch...
Beefi schrieb:
3. Ich hatte gestern in einem anderen Thread geäußert, dass Visual Studio sehr aufgebläht wurde. Es läuft im Vergleich zu sämtlichen IDEs einfach echt zäh. Früher als ich regelmäßig Visual Studio 6 im Einsatz hatte, war das absolut nicht der Fall. Lag es vielleicht daran, weil ich das komplette Visual Studio Ultimate installiert hatte?
Weiß nicht, was genau du mit aufgebläht meinst, Visual Studio läuft auf allen meinen Rechnern wunderbar...
-
Weiß nicht, was genau du mit aufgebläht meinst, Visual Studio 2012 läuft bei mir eigentlich wunderbar...
Naja, es ist einfach total schwergewichtig und läd lange...als würde ich in Windows nochmal ein Betriebssystem laden
Es geht dann halt einfach nicht anders...da bin ich einfach von den kleinen flinken IDEs verwöhnt. Oder ich bin von meinem aktuellen Rechner verwöhnt, wo ich noch kein VS nutzte
Du scheinst dich gut auszukennen...hab ich jetzt alles richtig verstanden?:
- Man kann die Express Versionen völlig frei mit Ihren Funktionen verwenden und sogar die Programme verkaufen.
- Es gibt mit der 2012 Ausgabe kein einzelnes Visual C#.Net oder Visual VB.Net, sondern nur noch das komplette Express Studio mit allen Sprachen.
- Die einzige Einschränkung an der Express Version (nur auf NET-Programmierung betrachtet) die einen etwas stören könnte, ist, dass man nur 32-Bit kompilieren kann.
- Wenn ich für Metro programmieren möchte, brauche ich das VS für Windows 8? Wenn ich für den normalen Windows 8 Desktop oder Win-Versionen davor programmieren möchte, brauche ich das VS für Desktop? Will ich beides, muss ich zwei getrennte Visual Studios installieren?
Ich freue mich über deine Hilfe
-
Beefi schrieb:
Weiß nicht, was genau du mit aufgebläht meinst, Visual Studio 2012 läuft bei mir eigentlich wunderbar...
Naja, es ist einfach total schwergewichtig und läd lange...als würde ich in Windows nochmal ein Betriebssystem laden
Es geht dann halt einfach nicht anders...da bin ich einfach von den kleinen flinken IDEs verwöhnt. Oder ich bin von meinem aktuellen Rechner verwöhnt, wo ich noch kein VS nutzte
Weiß nicht, wenn ich ein mittelgroßes Projekt aufmache, dann dauert das bei Kaltstart auf meinem Rechner unter 10 und ansonsten 4 Sekunden, was ich als durchaus sehr gut empfinde...
Beefi schrieb:
- Man kann die Express Versionen völlig frei mit Ihren Funktionen verwenden und sogar die Programme verkaufen.
Ja
Beefi schrieb:
- Es gibt mit der 2012 Ausgabe kein einzelnes Visual C#.Net oder Visual VB.Net, sondern nur noch das komplette Express Studio mit allen Sprachen.
Ja, endlich...
Beefi schrieb:
- Die einzige Einschränkung an der Express Version (nur auf NET-Programmierung betrachtet) die einen etwas stören könnte, ist, dass man nur 32-Bit kompilieren kann.
Das ist falsch.
Beefi schrieb:
- Wenn ich für Metro programmieren möchte, brauche ich das VS für Windows 8? Wenn ich für den normalen Windows 8 Desktop oder Win-Versionen davor programmieren möchte, brauche ich das VS für Desktop? Will ich beides, muss ich zwei getrennte Visual Studios installieren?
Möglicherweise, da bin ich mir ehrlich gesagt nicht sicher, aber du kannst es ja einfach ausprobieren...
-
dot schrieb:
pV schrieb:
Würde mich aber schonmal interessieren wie man natives VB/C(++)..
mit .NET erklärt (technisch - nicht als MS PR Berater)Was genau meinst du damit?
Das VB/C++/ vorher schon als MS Variante existierten
und der "Wandel" zu .NET minimal war..Wenn man dann noch überlegt das .NET so ziemlich paralell zu Web 2.0 "rauskam"..
..sieht man was MS damit vorhatte:ActiveX war vorher kräftig gefailed und hätte das werden soll was Ajax wurde..
..da brauchte man eine Alternative
..und weil MS nunmal MS ist..
..neuer Name.. alter Krempel.. kleister einfach etwas Java obendrauf und nochmal von vorne..
..Beweise ? "Rückkehr von COM" in Win8dot schrieb:
pV schrieb:
Was bliebe denn von .NET übrig wenn man COM/DCOM von .NET loslösen würde ?
Alles? COM/DCOM hat mit .NET nichts zu tun, das sind zwei völlig unabhängige Technologien.
Nein,
im Kern geht es immer noch darum Objekte zwischen den Programmiersprachen
und im Browser auszutauschen und VB/C(++).. sind nunmal nicht .NET
sondern lediglich "eingeflossen".Was sind denn DLLs zb ? ^^
Wie oben beschrieben wollte MS Standards setzen
nur hatten die Entwickler von ActiveX bereits dermassen die Nase voll
das dann andere das Rennen gemacht haben..
..und da half auch das Kopieren bei Java nicht.Was meinst Du warum ebay (Java), google (Python), Facebook (PHP)
-alle im .NET Zeitalter entstanden-
nicht auf .NET gesetzt haben ?
-
Ich schlag vor, dass du dich erstmal mit den Dingen beschäftigst, von denen du hier redest, bevor wir diese Diskussion weiterführen, weil so ist mir das zu anstregend...
-
dot schrieb:
Ich schlag vor, dass du dich erstmal mit den Dingen beschäftigst, von denen du hier redest, bevor wir diese Diskussion weiterführen, weil so ist mir das zu anstregend...
Muss ich doch gar nicht mehr die Welt hat sich doch schon für bessere Systeme entschieden..