Qt přešlo pod otevřenou správu

Nokia oznámila přechod projektu Qt pod otevřenou správu. Do Qt projektu tak mohou přispívat jak firmy, tak jednotlivci a zároveň mohou tito vývojáři ovlivňovat směřování projektu. „KDE Free Qt Foundation“ pak zajišťuje, že Qt bude vždy dostupné jako svobodný software s licencemi LGPL 2.1 a GPL 3. KDE tento vývoj vítá.

21.10.2011 21:43 | Nicky726 | Komunita

Komentáře

[nodevel]

Aneb Nokia se konečně vykašlala na Qt, ale proč to neoznámit jako radostnou zprávu... (to, že to v případě ztráty zájmu Nokie přejde pod otevřenou správu je samozřejmě dobře, ale ten scénář už byl známý dlouho)

[nodevel]

Jen pro vysvětlení - tím nenarážím na tuto zprávičku, za tu jsem rád, ale na všemožné nadšené komentáře lidí okolo KDE.

[Karry]

Nediv se... V bugs.kde.org je spousta poměrně závažných chyb, které jsou uzavřeny s tím že "jedná se o chybu QT, nemůžeme s tím nic dělat"... Otevření QT tak dává možnost že se tento neutěšený stav pohne - tím mám na mysli že se začnou opravovat chyby, které nejsou "komerčně lákavé".

Sice bez finanční podpory Nokie by asi nevznikl framework QT Quick, na druhou stranu se nebojím že se vytratí inovace... Vždyť spousta úžasných věcí v QT (třeba Phonon) vznikla původně jako projekt v KDE!

[JeChW]

Jenže zároveň Nokia teď celý Qt Quick (QML) pohřbila. MeeGo už totiž poslal k ledu i Intel a jeho nástupce Tizen má jako vývojovou platformu používat HTML5 (kolik mrtvol typu WebOS ještě bude třeba, než někomu dojde, že to je blbost?). Jelikož UMPC kategorii pohřbili výrobci HW (prostě žádný takový HW nevyrábí), tak jedinou platformou, kde se dá Qt Quick používat, zůstává Android. A otázkou je, kolik lidí bude ochotných si instalovat na telefon Qt knihovny. Řekl bych, že zájem vyvíjet v QML pro Android je téměř nulový.

[mirec]

No Phonon by som zase nepovažoval za nejakú výhru. Zdá sa mi to ako najbugovitejšia časť Qt a to či už s VLC, Mplayer, Xine, alebo Gstreamer backendom.

[__dark__]

A nedopadne to tak, že se Nokia časem Qt zbaví? Pak by nastávala otázka, jak pujde Qt kupředu, když by přišlo o placené vývojáře.

[JeChW]

Nokia se samozřejmě Qt zbaví. Už odřízla PySide a další součásti a celý Qt bude logicky následovat. Otázkou je, co bude dál. Nějak se mi zdá, že to celý míří nějakym blbym směrem (HTML5/JS).

[Trained.Monkey]

Jen dodam k pripadnym spekulacim o osudu QT: tenhle proces zacal davno pred tim nez Nokia koupila Trolltech, v roce 2009.

[JoHnY2]

Navic pokud by se Nokia chtela Qt zbavit, tak prodat Trolltech v aktualnim stavu proste nemuze bejt problem. Firma/divize s takovym know-how a zastupem specialistu kupce proste ma.

[Neel]

Kdo podle vas(i ostatnich) mohl projevit zajem o Trolltech?

[__dark__]

MS

[JoHnY2]

RIM (tem by to vyresilo hodne potizi s API, zatim jsou na tom dost zle), Cinani vseho druhu, mozna Samsung nebo LG, Google kdyby to slo soudne s Applem a Oraclem vazne zle

[Rezza]

Jj, Open Governance je slibovana snad stoleti, mozna dve. Fakt me zajima, co vyleze z toho "next billion", zatim to vypada na osekane Maemo 7 pro Indii, ale ani tomu uz moc neverim. Jinak RIM ted ma Qt v NDK.

[JoHnY2]

Jestli je Qt v NKD RIMu, tak mi ke stesti schazi je poradna podpora SIP a jdu si koupit pristi generaci jejich telefonu.

[Cheaf]

Mohu se zeptat co se změní pro mě jako pro programátora nějaké komerční aplikace ?

[Pavel Stárek]

Nevím co se pro tebe změní, ale asi zatím stále platí, že pro vývoj Qt komerčních aplikací s uzavřeným zdrojovým kódem, by si měl použít Qt commercial licenci.

[tm]

Qt je už nejakú dobu pod LGPL, tú licenciu potrebujete len ak chcete z nejakého dôvodu linkovať staticky (asi hlavne pre embedded zariadenia), alebo ak chcete podporu.

[Pavel Stárek]

Pravda, dle licensing se pro něj asi nezmění nic. Jen musí dodržet podmínky license LGPL 2.1 .

[stativ]

Nic.

[mirec]

Zaujímavé, že na zahraničných serveroch vidím skôr pozitívne reakcie zatiaľ čo tu skôr negatívne. V každom prípade negatívne názory prevládali aj pri spojení Trolltech-u s Nokiou. S odstupom času by som tento krok hodnotil pozitívne. Dúfam, že aj uvoľnenie vývoja budem s odstupom času vidieť pozitívne.

[pjoter]

Mi ke klidu bohate staci, ze jsou stale na Qt palube lide jako je Thiago M.

[s0]

no, právě s tímhle chlapíkem teď vedu nějakou podivnou diskusi... v podstatě se snaží z C++ toolkitu udělat javascriptovou knihovnu pro mobily (přestože Qt na mobilech nikdo nepoužívá). Jsem z toho dost rozladěněj.

[Miloslav Ponkrác]

Jakto?

Qt původně chtěla z C++ udělat ObjectiveC knihovnu a proto zavedla řadu maker, preprocesor moc a opovrhla výjimkami a dalšími.

Tváření se Qt jako něco jiného, než C++ je dáno do vínku.

[volvox]

Ten důvod, proč v Qt nejsou výjimky, by mě docela zajímal. Je k tomu nějaký zdroj?

[hanzz]

V dobe kdy Qt zacalo exceptiony nebyly podporovane ve vsech prekladacich, ktere "chteli" v Qt podporovat.

[Espinosa]

Qt snad pomalu začíná vyjímky používat, ale jen velmi zvolna, snad od Qt4 nebo až od Qt 4.4
http://developer.qt.nokia.com/forums/viewthread/1150/

Velmi dlouho brojili proti vyjímkám. Pamatuji na jejich stránkách dlouhý traktát proč jsou C++ exceptions učiněné zlo. Teď ten článek nemohu najít. Asi přišli k rozumu a dali ho pryč :) Pro mě jako Javistu je nepoužívání vyjímek něco nepochopitelného.

Qt není jediné kdo zakázalo v kódu nepoužívat vyjímky. Další je například Firefox (Mozilla). https://wiki.mozilla.org/Exceptions

Mozilla kdysi stanovila ještě tvrdší podmínky pro kód, takže z vlastností C++ toho moc nezbylo. Extrémní konzervatismus. Důvodem bylo aby byla Mozilla zkompilovatelná na platformách, hlavně Unixových, které měly C++ kompilátory sto let za opicema. Časy se naštěstí mění, konkurence od WebKitu šlape na paty, gcc se zlepšuje, klasický Unix z desktopu zmizel (pokud můžeme tvrdit že se kdy moc rozšířil) a tak se restrikce na pokročilé vlastnosti C++ uvolňují i v Mozille/Firefoxu.

[__dark__]

Ono otázka je, na co všechno by se měli výjimky používat. Já je třeba při tvorbě knihoven nepoužívám, a zatím jsem nenarazil na problém. Na většinu chyb stačí číslo - je to jednoduché, snadno rozšiřitelné a rychlé.

Problém Qt byl (a možná ještě je), že jejich kontejnery a obecně většina tříd žádnou chybu nevrací, takže v případě neúspěchu se to nemá programátor jak dozvědět. Na druhou stranu třeba taková glib/gtk při nedostatku paměti aplikaci raději zabijou, což mi přijde jako úplně ta nejhorší možnost.

[Espinosa]

> Na většinu chyb stačí číslo - je to jednoduché, snadno rozšiřitelné a rychlé.

Z toho C kódu co jsem viděl, to pak vypadá, že co volání funkce, to kontrola výstupového kódu a reakce na chybový stav. Pak 2/3 kódu funkce je "nerelevatní" k primárnímu poslání funkce. To mi opravdu nepřijde výhodné.

Že je to rychlejší? To bych se divil. Vždyť je za každým voláním funkce testování podmínky. U vyjímek nic takového není, kód je výrazně lineárnější.

Že je zpracování vyjímek pomalé? No a co, vyjímky jsou od toho vyjímky, že jsou vyjímečné.

Viděl jsem ale i dost zpraseného Java kódu, kdy každá metoda, i s jedním řádkem, má try-catch a snaží se vypořádat vyjímku sama, dělají to hlavně méně zkušení vývojáři. Netuší nic o propagaci vyjímek, wrappingu. V lepším případě vypíší něco do logu a thread ukončí, v horším se neděje nic a pak hledej šmudlo, kde je chyba. Na mě pak je abych se sa tím paskvilem vypořádal, když už s tím nikdo nedokáže pohnout. Naštěsté jsou teď v módě frameworky, jako Spring, používající unsigned exceptions, ty jsou víc idiot-proof.

[__dark__]

Z toho C kódu co jsem viděl, to pak vypadá, že co volání funkce, to kontrola výstupového kódu a reakce na chybový stav. Pak 2/3 kódu funkce je "nerelevatní" k primárnímu poslání funkce. To mi opravdu nepřijde výhodné.

A jaký kód jsi viděl;)?

Že je to rychlejší? To bych se divil. Vždyť je za každým voláním funkce testování podmínky. U vyjímek nic takového není, kód je výrazně lineárnější.

Testování podmínky při návratu z funkce jsou 2 instrukce. Pokud nechci psát IF, tak můžu použít makro.

Že je zpracování vyjímek pomalé? No a co, vyjímky jsou od toho vyjímky, že jsou vyjímečné.

Otázka zůstává pořád stejná, na co všechno chceš použít výjimky? Já bych třeba pro chybnou alokaci paměti použil spíš výjimku, ale u chyby při otevírání souboru raději chybový kód.

Možná je problém v tom, že se na C++ díváš jako na Javu. Pro mě jsou to 2 odlišné světy. Chtít po C++ aby to bylo jak Java, nebo naopak, prostě nemá cenu.

[Espinosa]

> Testování podmínky při návratu z funkce jsou 2 instrukce.

2 instrukce jsou stále pomalejší než žádná instrukce jako je tomu při použití vyjímek ;) Prostě vaše tvrzení, že návratové kódy jsou rychlejší, není pravdivé. A to byla moje pointa. Že je to nárůst nepatrný vám neberu.

> A jaký kód jsi viděl;)?

Například kód Firefoxu. Řádky jako:
if (NS_FAILED(rv)) return rv;
tam vidím až moc často. A to na to mají také elegantní makro.
Namátkou nsHttpHandler.cpp. Pamatuji mnohem horší kusy kódu, nemohu je teď najít, přeci jenom, je to pár let zpět, a možná na tom vývojáři zapracovali. 2/3 kódu to nejsou, uznávám, tak slabá 1/3 čistého kódu. I tak mi to ale přijde dost.

> Chtít po C++ aby to bylo jak Java, nebo naopak, prostě nemá cenu

Java vs. C++ jako jazyk, ne jako JVM versus nativní kód, samozřejmě srovnávat lze. Java je jazyk z C++ vzešlý, snažila se vyhnout chybám předchůdce, a vesměs se jí to i podařilo. Někde se snažila být průkopníkem, a tam si občas spálila prsty, například integrace thread safety do sémantiky jazyka se ze zpětného pohledu nezdá být dobrý nápad. Napodruhé, jako knihovna, už jim to snad vyšlo.

Proč Cckaři nepoužívají vyjímky je dán historicky. Starší kompilátory neměli dobrou implementaci (alespoň se to všude tvrdí), programátoři se je nenaučili používat. Jednak tendenčnost odvětví (programátoři) je značná a jednak a hlavně jsou napsány milióny kódu bez vyjímek, tisíce knihoven používající návratové kódy. Prostě historické břemeno. V případě vyjímek šli tvůrci Javy najisto. Tedy až na fakt, že preferovali checked exceptions. To tvůrci skriptovacích se poučili a vesměs přidali jen unchecked exceptions.

> Já bych třeba pro chybnou alokaci paměti použil spíš výjimku, ale u chyby při otevírání souboru raději chybový kód.

Samozřejmě bych volil vyjímku. Jestliže nastane vyjímka, což znamená chybu, neb chyba by vždy měla být vyjímečně, ideálně vůbec, čili jasně vyjímka, není nad čím mudrovat. Něco jiného je otázka, zda soubor kam budu zapisovat nejdříve otestovat, zda je zapisovatelný, nebo to "risknout" a nechat to "spadnout" až na operaci samotné. Záleží jak moc analyzujete stav jako vyjímečný, záleží na kontextu. Každopádně by ale knihovní funkce/metoda pro zápis neměla vracet úspěšnost v podobě kódu.

[__dark__]

2 instrukce jsou stále pomalejší než žádná instrukce jako je tomu při použití vyjímek ;) Prostě vaše tvrzení, že návratové kódy jsou rychlejší, není pravdivé.

2 instrukce jsou naprosto zanedbatelné, když bereš v úvahu volání funkce. Navíc pokud je volaná funkce inline, tak testování návratové hodnoty odpadá úplně (ten jump se vygeneruje už v té inline funkci).

A to byla moje pointa. Že je to nárůst nepatrný vám neberu.

Při povolení výjimek je nárůst binárky mnohem větší, než při zpracování návratové hodnoty. Důvod je ten, že ty unwind tabulky se někam musí uložit. Navíc každá "exception enabled" funkce musí obsahovat peciální prolog a epilog.

Například kód Firefoxu. Řádky jako: if (NS_FAILED(rv)) return rv;

Já osobně používám RETURN_ON_ERROR(kód), nenaroste počet řádků a v 90% situací postačuje. Jinak kód FF je zrovna velmi špatný příklad;)

Java vs. C++ jako jazyk, ne jako JVM versus nativní kód, samozřejmě srovnávat lze. Java je jazyk z C++ vzešlý, snažila se vyhnout chybám předchůdce, a vesměs se jí to i podařilo.

Já si zase myslím, že C# se vyhl chybám Javy, a můžeme se tu hádat;)

Proč Cckaři nepoužívají vyjímky je dán historicky. Starší kompilátory neměli dobrou implementaci (alespoň se to všude tvrdí), programátoři se je nenaučili používat.

I nové projekty, např. Chromium nebo V8 nepoužívají výjimky. Hodit všechno do jednoho pytle nejde. Jsou situace, kdy jsou výjimky zbytečné, a platit za ně daň v podobě většího a pomalejšího kódu nemá smysl. Druhá věc je ta, že pokud vytvořím knihovnu, která používá výjimky, tak ji už nikdo nemůže použít v kódu, který ty výjimky nepoužívá.

Samozřejmě bych volil vyjímku. Jestliže nastane vyjímka, což znamená chybu, neb chyba by vždy měla být vyjímečně, ideálně vůbec, čili jasně vyjímka, není nad čím mudrovat. Něco jiného je otázka, zda soubor kam budu zapisovat nejdříve otestovat, zda je zapisovatelný, nebo to "risknout" a nechat to "spadnout" až na operaci samotné. Záleží jak moc analyzujete stav jako vyjímečný, záleží na kontextu. Každopádně by ale knihovní funkce/metoda pro zápis neměla vracet úspěšnost v podobě kódu.

Pro mě osobně ta situace není nijak výjimečná. I kdybych si otestoval, zda soubor X.Y můžu otevřít, tak během doby, než zavolám open(), ten soubor už může být třeba smazaný. Takže ve výsledku se ta výjimka stejně musí odchytit a zpracovat (jen v podobě větší režie).

[dad]

jak se reaguje v c++ na kill -9 ?

[David Šmíd]

Blbě

[Ferdinand]

Ony výjimky v C++ jsou opravdu hrůzné. Nejen, že to poměrně dlouho různé překladače nepodporovaly, ale na různých platformách to pak ještě další dost dlouhou dobu tytéž překladače podporovaly pokaždé jinak. A v každém případě je obsluha výjimek velmi pomalá záležitost. Pro přenositelné UI tedy pohroma.

Zrovna Nokii tohle ale docela vyhovovalo. C++ pro Symbian taky nemělo rádo výjimky. Teprve až tuším od verze 8 je šlo používat (ale nebylo to doporučené), a až od devítky je šlo používat ve větším měřítku - to když symbianní leave byl implementován jako obsluha výjimky.

[pjoter]

Ano šéfe!