Qt jest teraz wydany pod LGPL, polecacie go nad wxWidgets? [zamknięte]

Obecnie używam pyqt w pracy i jestem całkowicie zadowolony. Masz lepszą dokumentację (IMHO), lepsze zarządzanie zdarzeniami( wzór gniazda sygnału jest w jakiś sposób bardziej wydajny niż stary prosty styl wywołania zwrotnego), a importowanie niestandardowego widżetu do projektanta graficznego, takiego jak qt-designer, jest o wiele łatwiejsze. Z tego, co wiem, qt-designer jest potężniejszy niż jakikolwiek odpowiednik wxpython, jak Boa Constructor i pyGlade). Masz również świetne wsparcie dla tłumaczenia ciągów programu w różne języki (przynajmniej lepsze wsparcie niż wxlocale i możesz użyć narzędzia takiego jak Qt-Linguist, które jest w pełni zintegrowane z systemem qt).

Używam wxpythona w niektórych pracach hobbistycznych, ale nadal jestem tam noobem. Myślę, że jego większą przewagą nad pyqt jest natywny wygląd na różnych platformach. Jest to ogromny punkt, jeśli tworzysz aplikacje dla systemu windows/linux, na przykład. W rzeczywistości można użyć "skórki", aby uzyskać natywny wygląd z aplikacji windows-qt, ale Nie mam pojęcia jak to osiągnąć (sorry, nigdy nie używałem qt na windows :D).

Należy pamiętać, że od stycznia 2009 roku, podczas gdy Qt 4.5 miał być dostępny na licencji LGPL, Riverbank Computing nie ogłosił żadnych licencji na przyszłe wersje PyQt . PyQt jest nadal tylko komercyjny / GPLv2 / GPLv3 .

Jak zaznaczono w komentarzach do tej odpowiedzi, Nokia ogłosiła projekt na licencji LGPLPySide w sierpniu 2009 roku.

Szczerze mówiąc, nie sądzę, aby ludzie masowo przełączyli się z WxWidgets.

Dla Pythona istnieją wiązania PyQt i wiązania wxPython. Pomimo tego, że Qt jest znacznie bardziej praktyczny niż wxWidgets, większość programów GUI python open source jest pisana za pomocą wxWidgets. Ponieważ te programy są open source, GPL vs LGPL nie miało większego znaczenia w wyborze zestawu narzędzi.

To samo dotyczy Gtk. Wiele aplikacji open source pisanych jest w Gtk, w systemie windows, mimo Gtk jest bardzo trudne do pracy w systemie windows. Z Qt aplikacje te byłyby o wiele łatwiejsze do utrzymania na różnych platformach, ale tak się nie stało.

Wybór zestawu narzędzi zależy więc od wielu parametrów, przy czym licencje są tylko jednym z nich.

Nadal nie rozumiem, dlaczego Qt nie jest bardziej mainstreamowe, ponieważ jest moim zdaniem najprostszym i bardziej praktycznym zestawem narzędzi GUI, jaki kiedykolwiek napisano.

Qt jest bardzo wszechstronnym i wysokiej jakości frameworkiem. Jestem pewien, że wiele nowych projektów, które użyłyby wxWidgets, będzie teraz używać LGPL Qt. Ale projekty, które już używają wxWidgets, bez wątpienia będą nadal używać wxWidgets, zamiast robić masowe ponowne zapisywanie.

Wybrałem wxPython z 2 głównych powodów:

1. Konstruktor Boa, który jest nadal produktem beta, daje mi zunifikowaną kontrolę nad 100% procesu, podczas gdy PyQt rzeczywiście ma lepszego projektanta, ale nie ma związku między edycją "obsługi zdarzeń".

Moje idealne IDE projektuje, tworzy zdarzenia, pozwala mi edytować tylko potrzebny kod funkcjonalny i uruchamiać; bez "kompilowania UIC" , bez przełączania edytorów, bez wchodzenia w linię poleceń. Podczas gdy dla zastosowań na dużą skalę to sprawy bardzo mało, moja obecna domena to szybkie i małe programy.

1. Licencjonowanie... to nie ma teraz znaczenia, ale będzie, gdy zacznę sprzedawać moje rzeczy na małą skalę.

2. Autocompletion inside event functional code wydaje się nie działać w QTDesigner, dla kodu zdarzenia. Może mi czegoś brakuje, ale opisany powyżej proces "zepsuty" uniemożliwia mu bycie radem.

Nigdy nie byłem w stanie skonfigurować Qt do kompilacji krzyżowej. Pamiętam, że widziałem coś z Trolltech mówiącego, że oficjalnie nie obsługują kompilacji krzyżowej, chociaż nie mogę jej teraz znaleźć.

Jest wiele przewodników i takich szczegółowych informacji jak zmusić Qt do krzyżowej kompilacji, więc możliwe (prawdopodobne), że robiłem coś złego.

Wybierając framework, zalecam rozważenie i przetestowanie ich zdolności kompilacji krzyżowej.