Python 2 vs 3 ist ja nun auch keine gaaanz neue Frage...
Das war zumindest teilweise auch Einstellungssache. Die Frage kam dort im Forum (und sicherlich auch auf anderen Platformen) immer mal wieder auf und er hat da durchklingen lassen, dass er von Python 3 nicht überzeugt ist und nicht plant zu migrieren. Generell hatte er dazu eine etwas seltsame Einstellung. Als jemand mal bzgl. Wechsel von QtWebkit auf QtWebengine nachgefragt hatte war sein Kommentar so mehr oder weniger "kein Problem, dann übernehme ich es eben auch QtWebkit selbst zu pflegen".
Aber gut, dass er offensichtlich doch noch einsichtig geworden ist, dass er sich mit der Pflege von (unter anderem) Python 2 und QtWebkit zusätzlich zu Calibre doch ein bisschen übernimmt und die Migration auf neuere Versionen/Varianten langfristig nachhaltiger ist.
Ansonsten bezweifle ich, dass Qt hier eine wirklich schlechte Wahl war. Die Migration von Qt4 auf 5 zumindest war eigentlich ein ziemlich einfaches Unterfangen. Ich stimme aber zu, dass der Wechsel von QtWebkit auf QtWebengine seitens Qt mehr als suboptimal war. Das haben sie an anderen Stellen um ein Vielfaches besser hinbekommen.
> Ich stimme aber zu, dass der Wechsel von QtWebkit auf QtWebengine seitens Qt mehr als suboptimal war.
Ja. Qt ist im Allgemeinen technisch nicht verkehrt. Die Firma dahinter zeigt erste Mozilla'sche Allüren imho, aber das ist ein anderes Thema... Technisch ist das prima. Bis auf dieses Geturne um die Web Engine. Das kompiliert dann für Windows mit Mingw bspw. schonmal garnicht, weil Chrome selbst auch exklusiv am Visual Studio (bzw dessen Compiler) hängt. Natürlich war Chrome verlockend. Aber auf meiner Seite hat es das Vertrauen in Qt als 'ernsthaft plattformübergreifend' mit einer ernsthaften Nähe zu FOSS ein bisschen getrübt.
Ich durfte in meinem Tool entscheiden, entweder kein Mingw zu machen, oder auf QtWebEngine zu verzichten. Na super. ^^ Und man hat auch überhaupt nicht auf dem Zettel afaik, sich aus dieser Lage wieder rauszumanövrieren.
Generell hatte er dazu eine etwas seltsame Einstellung.
Als jemand mal bzgl. Wechsel von QtWebkit auf QtWebengine nachgefragt hatte war sein Kommentar so mehr oder weniger "kein Problem, dann übernehme ich es eben auch QtWebkit selbst zu pflegen".
Aber gut, dass er offensichtlich doch noch einsichtig geworden ist, dass er sich mit der Pflege von (unter anderem) Python 2 und QtWebkit zusätzlich zu Calibre doch ein bisschen übernimmt und die Migration auf neuere Versionen/Varianten langfristig nachhaltiger ist.
Ansonsten bezweifle ich, dass Qt hier eine wirklich schlechte Wahl war. Die Migration von Qt4 auf 5 zumindest war eigentlich ein ziemlich einfaches Unterfangen.
Ich stimme aber zu, dass der Wechsel von QtWebkit auf QtWebengine seitens Qt mehr als suboptimal war.
Das haben sie an anderen Stellen um ein Vielfaches besser hinbekommen.
> Ich stimme aber zu, dass der Wechsel von QtWebkit auf QtWebengine seitens Qt mehr als suboptimal war.
Ja. Qt ist im Allgemeinen technisch nicht verkehrt. Die Firma dahinter zeigt erste Mozilla'sche Allüren imho, aber das ist ein anderes Thema... Technisch ist das prima. Bis auf dieses Geturne um die Web Engine. Das kompiliert dann für Windows mit Mingw bspw. schonmal garnicht, weil Chrome selbst auch exklusiv am Visual Studio (bzw dessen Compiler) hängt. Natürlich war Chrome verlockend. Aber auf meiner Seite hat es das Vertrauen in Qt als 'ernsthaft plattformübergreifend' mit einer ernsthaften Nähe zu FOSS ein bisschen getrübt.
Ich durfte in meinem Tool entscheiden, entweder kein Mingw zu machen, oder auf QtWebEngine zu verzichten. Na super. ^^ Und man hat auch überhaupt nicht auf dem Zettel afaik, sich aus dieser Lage wieder rauszumanövrieren.
... aber lieben Dank für diese Hintergrundinfos! Ich habe das Projekt nicht großartig verfolgt, aber sowas ist immer ganz interessantes 'Trivia'...