1. Foren
  2. » Kommentare
  3. » Software-Entwicklung
  4. » Alle Kommentare zum Artikel
  5. » Cross-Plattform…

Ergebnis nach kurzer Analyse: Leider unbrauchbar

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor KuhTee 20.12.12 - 01:21

    Ich bin wirklich ein Qt Fan, nutze Qt4 jetzt seit etlichen Jahren und habe mehrere große Programme damit umgesetzt. Aber Qt5 ist ein echter Griff ins Klo. Man könnte meinen, heute dreht sich alles nur noch um Apps Apps Apps. Mit Qt4 konnte man wirklich professionelle Software entwickeln, Software welche mehr ist als nur eine Quitsch-Bunt-App. Natürlich war das dann nicht unbedingt so "schick" wie eine kleine App, aber nötig. Mit QML möchte ich mir das nicht antun.

    Aber wenns nur das wäre... Wenn ich mir anschaue, welche Klassen nur noch zur Kompatibilität vorhanden sind, bekommt man wirklich Bedenken, noch lange auf das Pferd Qt zu setzen. Zum Beispiel Webkit: QtWebkit2 scheint mir ein Witz zu sein verglichen mit QtWebkit1. Es reicht sich schon die Beispiele anzuschauen: bei QtWebkit1 ein vollwertiger Browser, bei QtWebkit2 ein Youtube Viewer und ein Flickr Viewer. Ich entwickle gerade eine Software die ein wenig mehr können muss, da fällt QtWebkit2 derzeit wohl raus.

    Oder die Scriptunterstützung: Steht da doch, man solle jetzt bitte die "QJS..." Klassen aus dem QML Modul nutzen. Und was haben wir da? "QJSEngine", "QJSValue" und "QJSValueIterator". Na toll. Und wo sind der Ersatz für "QScriptEngineDebugger" und "QScriptContext" und diversen anderen Klassen? Klar, für "Apps" braucht man das wahrscheinlich nicht. Aber Qt war bisher kein Kiddie Framework, warum verwandelt es sich in eins?

    Wenn QtWebkit1 (also die Variante ohne QML) zukünftig auch auf neueste Webkit Versionen aktualisiert würde, könnte ich ja sogar noch damit leben. Aber das ist wohl nur eine Frage der Zeit, und dann wars das. Leider muss ich sagen, dass mein aktuelles Qt4 Projekt mit Qt5 ohne Verwendung der "Kompatibilitätsklassen" gar nicht umsetzbar wäre ohne unangenehme Abstriche. Und dann fällt die Entscheidung Pro oder Contra Qt nicht mehr sehr schwer.

    Schade, Qt war bis heute das beste C++ Framework um Business-Software plattformübergreifend zu entwickeln.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor QCoder 20.12.12 - 03:06

    Ich kann leider nicht zustimmen. Klar wurden einige Änderungen vorgenommen und viele module als als veraltet markiert. Auch sind fuer einige Neuentwicklungen wie webkit2 nicht die gleiche Funktionalität wie fuer das Vorgängermodell vorhanden. Dies wird sich aber mit Sicherheit mit Qt5.1 oder 5.2 ändern.
    Die Modularisierung, Fokussierung auf opengl2 und qtquick2 sind aber mit Sicherheit der richtige Weg in die Zukunft. Fuer all die jenigen die weiterhin statische user interfaces schreiben und wollen gibt es die kompatobilitaetsmodule. Oder Qt4.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor Mace 20.12.12 - 09:59

    KuhTee schrieb:
    --------------------------------------------------------------------------------
    > Ich bin wirklich ein Qt Fan, nutze Qt4 jetzt seit etlichen Jahren und habe
    > mehrere große Programme damit umgesetzt. Aber Qt5 ist ein echter Griff ins
    > Klo. Man könnte meinen, heute dreht sich alles nur noch um Apps Apps Apps.
    > Mit Qt4 konnte man wirklich professionelle Software entwickeln, Software
    > welche mehr ist als nur eine Quitsch-Bunt-App. Natürlich war das dann nicht
    > unbedingt so "schick" wie eine kleine App, aber nötig. Mit QML möchte ich
    > mir das nicht antun.
    >
    > Aber wenns nur das wäre... Wenn ich mir anschaue, welche Klassen nur noch
    > zur Kompatibilität vorhanden sind, bekommt man wirklich Bedenken, noch
    > lange auf das Pferd Qt zu setzen. Zum Beispiel Webkit: QtWebkit2 scheint
    > mir ein Witz zu sein verglichen mit QtWebkit1. Es reicht sich schon die
    > Beispiele anzuschauen: bei QtWebkit1 ein vollwertiger Browser, bei
    > QtWebkit2 ein Youtube Viewer und ein Flickr Viewer. Ich entwickle gerade
    > eine Software die ein wenig mehr können muss, da fällt QtWebkit2 derzeit
    > wohl raus.
    >
    > Oder die Scriptunterstützung: Steht da doch, man solle jetzt bitte die
    > "QJS..." Klassen aus dem QML Modul nutzen. Und was haben wir da?
    > "QJSEngine", "QJSValue" und "QJSValueIterator". Na toll. Und wo sind der
    > Ersatz für "QScriptEngineDebugger" und "QScriptContext" und diversen
    > anderen Klassen? Klar, für "Apps" braucht man das wahrscheinlich nicht.
    > Aber Qt war bisher kein Kiddie Framework, warum verwandelt es sich in
    > eins?
    >
    > Wenn QtWebkit1 (also die Variante ohne QML) zukünftig auch auf neueste
    > Webkit Versionen aktualisiert würde, könnte ich ja sogar noch damit leben.
    > Aber das ist wohl nur eine Frage der Zeit, und dann wars das. Leider muss
    > ich sagen, dass mein aktuelles Qt4 Projekt mit Qt5 ohne Verwendung der
    > "Kompatibilitätsklassen" gar nicht umsetzbar wäre ohne unangenehme
    > Abstriche. Und dann fällt die Entscheidung Pro oder Contra Qt nicht mehr
    > sehr schwer.
    >
    > Schade, Qt war bis heute das beste C++ Framework um Business-Software
    > plattformübergreifend zu entwickeln.


    Ich werde einfach weiterhin für meine privat entwickelten Programme Qt 4 benutzen ;)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor Max L 20.12.12 - 12:07

    KuhTee schrieb:
    --------------------------------------------------------------------------------
    > Ich bin wirklich ein Qt Fan, nutze Qt4 jetzt seit etlichen Jahren und habe
    > mehrere große Programme damit umgesetzt. Aber Qt5 ist ein echter Griff ins
    > Klo. Man könnte meinen, heute dreht sich alles nur noch um Apps Apps Apps.
    > Mit Qt4 konnte man wirklich professionelle Software entwickeln, Software
    > welche mehr ist als nur eine Quitsch-Bunt-App. Natürlich war das dann nicht
    > unbedingt so "schick" wie eine kleine App, aber nötig. Mit QML möchte ich
    > mir das nicht antun.
    >
    > Aber wenns nur das wäre... Wenn ich mir anschaue, welche Klassen nur noch
    > zur Kompatibilität vorhanden sind, bekommt man wirklich Bedenken, noch
    > lange auf das Pferd Qt zu setzen. Zum Beispiel Webkit: QtWebkit2 scheint
    > mir ein Witz zu sein verglichen mit QtWebkit1. Es reicht sich schon die
    > Beispiele anzuschauen: bei QtWebkit1 ein vollwertiger Browser, bei
    > QtWebkit2 ein Youtube Viewer und ein Flickr Viewer. Ich entwickle gerade
    > eine Software die ein wenig mehr können muss, da fällt QtWebkit2 derzeit
    > wohl raus.
    >
    > Oder die Scriptunterstützung: Steht da doch, man solle jetzt bitte die
    > "QJS..." Klassen aus dem QML Modul nutzen. Und was haben wir da?
    > "QJSEngine", "QJSValue" und "QJSValueIterator". Na toll. Und wo sind der
    > Ersatz für "QScriptEngineDebugger" und "QScriptContext" und diversen
    > anderen Klassen? Klar, für "Apps" braucht man das wahrscheinlich nicht.
    > Aber Qt war bisher kein Kiddie Framework, warum verwandelt es sich in
    > eins?
    >
    > Wenn QtWebkit1 (also die Variante ohne QML) zukünftig auch auf neueste
    > Webkit Versionen aktualisiert würde, könnte ich ja sogar noch damit leben.
    > Aber das ist wohl nur eine Frage der Zeit, und dann wars das. Leider muss
    > ich sagen, dass mein aktuelles Qt4 Projekt mit Qt5 ohne Verwendung der
    > "Kompatibilitätsklassen" gar nicht umsetzbar wäre ohne unangenehme
    > Abstriche. Und dann fällt die Entscheidung Pro oder Contra Qt nicht mehr
    > sehr schwer.
    >
    > Schade, Qt war bis heute das beste C++ Framework um Business-Software
    > plattformübergreifend zu entwickeln.

    Eine Evolution ist nun mal nicht immer für alle schön. Bedenklich finde ich nur Ihre Aussage was QML angeht. Diese Diskussion hatte ich mit unseren alten Hasen in meiner Firma auch. Fakt ist, dass für embedded System es fast nichts besserer gibt als QML. Das Graphics-Framework vielleicht, wo man alles selber schreiben darf. Aber auf keinen Fall den QWidget ansatz. Das wurde dann auch irgendwann eingesehen. Spätestens die schnellere Entwicklungszeit konnte überzeugen. Resourcen zuwachs von Graphics-Framework war erheblich, aber vertretbar durch die geringere Entwicklungszeit. QML im Vergleich zu QWidget nicht nenneswert. Ins Besondere RAM Verbrauch lag teilweise deutlich unter dem QWidget-Ansatz.

    Auf dem Desktop sieht das wieder anders aus. Da wird sich Anfangs ein Mix aus QML und QWidget ergeben. Früher oder später wird die Tendenz aber auch Richtung QML gehen. Es ist einfach (sofern die nötigen Komponenten da sind) schneller zu entwickeln. Das ist allerdings nur meine persönliche Erfahrung. Sich aber vor dem QML Ansatz komplett zu versperren ist riskant.

    Das Schöne ist aber, dass man in diesem Thema aktuell ja nicht schwarz weiß denken muss. Beide Ansätze sind nach wie vor nutzbar. Intelligente Kombination aus beiden Welten bringt aus meiner Sicht den besten Benifit.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor KuhTee 20.12.12 - 12:26

    Oh, ich nutze derzeit schon QML. Allerdings mit embedded QWidgets, womit dann QtQuick2 wohl rausfällt. Leider gibt es da auch keine Option. QML ist zwar sehr nett for "normale" Oberflächen, sobald ich aber tiefergehend etwas ändern muss, steh ich da etwas im Regen. Das schlägt in die gleiche Kerve wie bei der ScriptEngine: Einfach was ausführen kein Problem, tiefergehende Kontrolle aber ist schwierig bis nicht machbar.

    Für Apps ist QML sicher ganz toll, für eine Desktopanwendung mit einer sehr spezialisierten Ausrichtung aber nicht. Das ist aber so wie ich das sehe eines der großen Einsatzgebiete von Qt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor Max L 20.12.12 - 12:38

    Embedded QWidgets? Du nutzt also die QWidgets auf embedded systemen?

    Im Grunde kannst du ja jedes normale QWidget in ein QML Objekt unwandeln. Also bisher hab ich in meinem Fall alles lösen können. Und ich kam auch über all dran. Zu mindest mit Qt 4. Allerdings nutze ich QML auch schon seit der ersten Stunde. Muss man für sich selbst halt ausmachen, wo dieser Ansatz einem Zeit kostet und wo es einem Zeit schenkt. Ist halt ein Werkzeug. Einen Schlitzschraubenzieher kann ich auch bei einer Torxschraube nutzen. Aber ob das effizient ist. ;-)

    Bei Qt 5 warte ich noch ab, bevor ich es produktiv nutze. Da bin ich bei dir. Ausprobieren sollte man es allerdings, damit später der Umstieg nicht zu lange dauert.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor KuhTee 20.12.12 - 17:10

    Nein, ich möchte nicht QWidgets auf embedded Systemen nutzen, sondern ein QWidget in QML einbetten. Bei QtQuick1 geht das, bei 2 nicht mehr. Und genau das brauche ich für ein aktuelles Projekt, habe es in QML so gehandhabt, der Weg ist jetzt aber mit Qt5 versperrt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor derats 21.12.12 - 01:27

    Mach dich mal locker, das ist der erste Release der Serie, bisher kamen mit dem Followups immer ordentlich was dazu.
    Immer locker durch die Hose atmen.
    Bis Qt5 in den Repos der Distros angekommen ist, dauerts eh noch ne Weile.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor Seitan-Sushi-Fan 21.12.12 - 03:04

    KuhTee schrieb:
    ------------------------------
    > Für Apps ist QML sicher ganz toll, für eine Desktopanwendung mit einer sehr
    > spezialisierten Ausrichtung aber nicht. Das ist aber so wie ich das sehe
    > eines der großen Einsatzgebiete von Qt.

    Statt unqualifizierte Kommentare zu posten, solltest du dich mal lieber informieren. QML ist nämlich noch gar nicht für den Einsatz in Desktop-Anwendungen gedacht. Die Desktop-Komponenten werden erst mit Qt 5.2 oder so nachgereicht.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: Ergebnis nach kurzer Analyse: Leider unbrauchbar

    Autor Seitan-Sushi-Fan 21.12.12 - 03:16

    Mace schrieb:
    ------------
    > Ich werde einfach weiterhin für meine privat entwickelten Programme Qt 4
    > benutzen ;)

    Fast alle Qt4-Komponenten sind vollständig in Qt5 vorhanden, inkl. QWidgets usw.
    Die „kurze Analyse“ von KuhTee war so kurz, dass es nicht einmal für 3 Minuten Google gelangt hat.
    Wenn man nur ein wenig aufpasst, kann man auch große Projekte sowohl mit Qt4 als auch Qt5 kompilieren, wie man an Qt Creator sehen kann.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Test Fifa Fußball-WM Brasilien 2014: Unkomplizierter Kick ins WM-Finale
Test Fifa Fußball-WM Brasilien 2014
Unkomplizierter Kick ins WM-Finale

Am 8. Juni 2014 bezieht die deutsche Nationalmannschaft ihr Trainingslager "Campo Bahia" in Brasilien, um einen Anlauf auf den Gewinn des WM-Pokals zu nehmen. Wer sichergehen will, dass es diesmal mit dem Titel klappt, kann zu Fifa Fußball-WM Brasilien 2014 greifen.

  1. Fifa WM 2014 Brasilien angespielt Mit Schweini & Co. nach Südamerika
  2. EA Sports Fifa kickt in Brasilien 2014

OpenSSL: Wichtige Fragen und Antworten zu Heartbleed
OpenSSL
Wichtige Fragen und Antworten zu Heartbleed

Der Heartbleed-Bug in OpenSSL dürfte wohl als eine der gravierendsten Sicherheitslücken aller Zeiten in die Geschichte eingehen. Wir haben die wichtigsten Infos zusammengefasst.

  1. OpenSSL OpenBSD mistet Code aus
  2. OpenSSL-Lücke Programmierer bezeichnet Heartbleed als Versehen
  3. OpenSSL-Bug Spuren von Heartbleed schon im November 2013

A Maze 2014: Tanzen mit der Perfect Woman
A Maze 2014
Tanzen mit der Perfect Woman

Viele Spiele auf dem Indiegames-Festival A Maze 2014 wirkten auf den ersten Blick abwegig. Doch die kuriosen Konzepte ergeben Sinn. Denn hinter Storydruckern, Schlafsäcken und virtuellen Fingerfallen versteckten sich erstaunlich plausible Spielideen.

  1. Festival A Maze Ist das noch Indie?
  2. Test Cut The Rope 2 für Android Grün, knuddlig und hungrig nach Geld
  3. Indie-Game NaissanceE Wenn der Ton das Spiel macht

  1. Bärbel Höhn: Smartphone-Hersteller zu Diebstahl-Sperre zwingen
    Bärbel Höhn
    Smartphone-Hersteller zu Diebstahl-Sperre zwingen

    Eine schnelle Einführung einer Diebstahlsperre für Smartphones könnte per Gesetz kommen. Doch die IMEI-Blockierung ist als Diebstahlschutz umstritten.

  2. Taxi-App: Uber will trotz Verbot in weitere deutsche Städte
    Taxi-App
    Uber will trotz Verbot in weitere deutsche Städte

    Durch ein Verbot in Berlin lässt sich das US-Unternehmen Uber nicht entmutigen. Jetzt will Uberpop in weitere deutsche Städte.

  3. First-Person-Walker: Wie viel Gameplay braucht ein Spiel?
    First-Person-Walker
    Wie viel Gameplay braucht ein Spiel?

    Walking-Simulator-Spiele nennen sie die einen, experimentelle Spiele die anderen. Rainer Sigl hat einen neuen Begriff für das junge Genre der atmosphärisch dichten Indie-Games erfunden: First-Person-Walker - Spiele aus der Ich-Perspektive mit wenig Gameplay.


  1. 18:28

  2. 16:31

  3. 12:00

  4. 09:20

  5. 16:32

  6. 14:00

  7. 12:02

  8. 11:47