Ubuntu a Qt aplikace v budoucnosti

Mark Shuttleworth se ve svém blogu rozepsal o budoucí pozici Qt aplikací v Ubuntu. Doposud dostávají přednost aplikace v GTK+, ale do budoucna by hlavním vodítkem měla být kvalita aplikace a ne použitý toolkit.

19.1.2011 12:17 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Kaacz]

+1

[Kaacz]

Jo mimochodem .. myslim ze to byl prave on, kdo jednou dost vazne uvazoval o tom, ze nove Gnome by se mohlo postavit nad QT, protoze je to stejne rychle jako GTK, lepe optimalizovane na ruzne platformy a da se nad tim udelat takrka jakykoli design desktopu. Takze by to bylo Gnome se vsim vsudy ale na QT, ktere umi pouzit ruzne engine na zobrazovani. A navic by ubylo knihoven v systemu.

[Tomáš Bžatek]

Nehrozi

[Jardík]

Ještě aby jo. Pak bychom se např. museli prát s nesmyslnými metodami typu QByteArray QFile::read(qint64), když QByteArray indexuje a jeho velikost je daná typem int. Nebo je mizerně "exception safe". Nebo je možné ho zkompilovat v extra namespace s čímž _žádná_ aplikace nepočítá a spoléhají na to, že tomu tak není. Nebo lze zkopilovat bez podpory STL, ale půlka aplikací spoléhá na to, že to tam je, aniž by se ujistili nějakým tím #ifdefem.

Zlaté glib/gio, které pro načítání ze souboru do paměti používá vhodný typ (no, vhodný, je to gsize, samozřejmě size_t by bylo lepší, ale zatím je do velikosti stejný - bohužel je to ale "nový" typ a na takové vlastnosti tedy nelze spoléhat, typedef se může změnit, fakt nechápu tu demenci vývojáří a jejich dementní nutkání definovat vlastní typy, když standard jazyka nám příslušné typy již dává). Bohužel i v glib jsou některé fce na palici.

[Ravensun]

Takže Ubuntu bude "přecházet" na Kubuntu?

[Kaacz]

V tomto pripade by oboji bylo Qbuntu

[Ravensun]

Obojí? To snad ne! Pochybuju, že celé Gnome budou přepisovat do QT místo Gnome.org

[Kaacz]

viz jiz predesle uvazovani MS jak jsem psal vyse .. neni to nemozne a mozna mene pracne nez vylepsovat GTK .. protoze to vylepsovani muze prinest spousty bolesti, ktere ma uz QT za sebou

[chrono]

Ty asi nesleduješ spôsob, akým sa prijímajú zmeny do Qt. Skús napr. občas sledovať KDE a prídeš na to, že je kopec vecí, ktoré by mohli byť v Qt urobené o niečo lepšie, ale Nokia o tie zmeny nemá záujem (takže vylepšovať Gtk+ je oveľa jednoduchšie, ako vylepšovať Qt).

[Ravensun]

No né, já uvažoval tak, že kdyby Ubuntu chtělo mít prostředí Gnome v QT, tak by museli dělat tu samou práci jako dělá Gnome.org pro Gnome prostředí. COž mi příjde mrháním času a prostředků. Takže jestli chce Majkl misto GTK+ QT, tak musí zákonitě vyměnit vlajkové prostředí Gnome za KDE. Ale jestli blbě uvažuju, tak mě opravte. Jsem z toho nějak "jelen".

[Marián Kyral]

Upravit Kde tak, aby to vypadalo jako Gnome je sice méně práce, ale jednoduché to asi nebude. V menším měřítku k migraci některých aplikací na QT dochází - třeba VLC.

[belisarivs]

Udelat Qt aplikace aby vypadaly jako GTK je podstatne jednodussi nez si jeden mysli.

Kdyz jsem v GNOME spustil Ktorrent, mel theme jako GNOME. Vypadalo to hodne dobre.

Myslim, ze schopnost vypadat jako gtk aplikace je soucasti qt uz nejakou dobu.

[Marián Kyral]

GTK jo, to jo, ale mě se jedná o ten Gnome look. Třeba zkriplit file dialog alá GTK asi bude mnohem složitější. Přece jen, těch čudlíku je tam na běžné Gnome uživatele (BGU ) až moc. To musí pryč.

[Neel]

Zrovna GTK file-dialog ma vic cudliku nez Qt file-dialog. Prijde mi, ze Qt file-dialog asi nikdo nepouziva, protoze naposledy, kdyz na me vyskocil, tak neumel zobrazit skryte soubory, cimz se stava nepouztelnym. File-dialog v KDE se zda byt fajn, jen musite nainstalovat a nacist cele KDE a vsechny jeho soucasti a knihovny.

[Vin]

Nebude (nebylo) - http://labs.qt.nokia.com/2008/10/01/native-file-dialogs-in-gnome/.

[Marián Kyral]

Nebude (nebylo) - http://labs.qt.nokia.com/2008/10/01/native-file-dialogs-in-gnome/.

Note that since the KDE file dialog provides somewhat different functionality from the Qt one, KDE applications will still use the KDE file dialog.

[stativ]

A jak to s tím souvisí? Pokud vím, tak tady se řeší Qt a ne KDE.

[Marián Kyral]

Ne. Tady se mluví o záměně KDE za Gnome - že by to bylo jednodušší. A dokáži si představit rozsah úprav v ubuntu KDE - aby to vypadalo jako Gnome.

[stativ]

Už vidím. Nicméně věřím, že odstranění jednoho testu (toho, zda Qt běží na KDE) by nemělo dát zvláštní práci.

[Rezza]

Ne, oni chteji jen Qt a nad tim si pisou Unity (zatim jen 2D verzi). Cil si myslim, ze je jasny - Windows a jina platformy a Ubuntu One.

[Kaacz]

Ty asi nesleduješ spôsob, akým sa prijímajú zmeny do Qt. Skús napr. občas sledovať KDE a prídeš na to, že je kopec vecí, ktoré by mohli byť v Qt urobené o niečo lepšie, ale Nokia o tie zmeny nemá záujem (takže vylepšovať Gtk+ je oveľa jednoduchšie, ako vylepšovať Qt).

Asi souhlas. Ale nebyla by pak Nokia funkcnejsi, kdyby na ni tlacil i Canonical ? Nemluve o tom jak by se to vylepsilo, pokud by jejich vyvojari pracujici na gtk (kteremu ujel vlak) presli pomoci Nokii na QT.

[Blaazen]

Takže místo Kočky a psa bude Kočka a Kočkopes. Ale to nevadí, protože každej, kdo používá Gnome má stejně nějaké KDE aplikace a naopak lidi s KDE4 mají obvykle nějaký napsaný pro GTK2. Takže Kočkopsa maj už stejně dávno všichni -> žádná změna.

[stativ]

Akorát, že Qt dovede vypadat identicky jako GTK2, tudíž minimálně z hlediska vzhledu by to žádný kočkopes být neměl (samozřejmě pokud to v Ubuntu tak nastaví). Ještě by to chtělo, aby něco podobného udělali vývojáři GTK.

[dfgdg]

Na to jak to vypada sere pes. Jde o to, jak to funguje. Me se napriklad libi, ze ve vsech souborovych dialozich vsech aplikaci mam stejne odkazy na me oblibene adresare a nemusim si to v kazde aplikaci nastavovat zvlast.

[imploder]

Není pochyb, že Qt patří budoucnost. Ať žije Qt!

GTK se mi moc nelíbí, je jakoby "objektové", ale ve skutečnosti není. Ani nemůže být, protože je napsané v C a to OOP nepodporuje. Je to prostě moc primitivní jazyk.

[robotics]

Sorry, ale budoucnost je v Enlightenmentu.

[Rovano]

A to zatím běží na GTK :D Budoucnost!

[stativ]

Odkdy?

[tom]

Proc podle vas nejde v C programovat objektove? Zapouzdreni, polymorfismus ani dedicnost neni problem.

[Jardík]

Není, ale pokud porovnáte množství kódu spojeného s vytvořením odvozené "třídy" v glib/C a v Qt/C++, tak je to velký rozdíl.

[tom]

Tak to je problem glibc, da se to udelat tak, ze rozdil je jen v tom, ze musite rucne udrzovat tabulku metod a volat konstruktory/destruktory pro obekty vytvarene prekladacem (nebo muzete pouzivat jen pointery, pak to odpadne).

[imploder]

No a je nějaký důvod bastlit OOP do jazyka, který ho nepodporuje (C), když můžu používat velice podobný jazyk, který OOP nativně podporuje (C++)?

[tom]

Ovsem, C je dostupne pro vice platforem nez C++ a ma mensi runtime. Pripadne neni podporovane pro dane ulohy (treba modul do kernelu).

[imploder]

Takže budeme všechno psát v C, protože je na nejvíc platformách a protože Linus nemá rád C++? Třeba u GUI mi uniká, proč by mělo být psané v C s dobastlenýma "objektama" a ne v opravdovém objektovém jazyce (a C++ má těch vylepšení víc, než jenom objekty).

[Jardík]

Ale zrovna Qt ja takový půl-C++ bastl. Používá svoje vlastní typy (a ještě k tomu někdy naprosto nesmyslně, viz jeden můj komentář výše), typy nehodící se k danému účelu ... až se vývojáři toolkitů naučí používat již existující typy, tak jim klidně políbím prdel. Příkladem budiž výtažek z dokumentace glib:

gint
Corresponds to the standard C int type. Values of this type can range from G_MININT to G_MAXINT.

Může mi někdo říci jediný normální důvod, proč "vytváří" nový typ gint, který je podle dokumentace stejný jako typ int a proč na rozsah nepoužijí již existující definice INT_MAX a INT_MIN? (jméno typu začínající na g není normální důvod). A spousta dalších typů, jenom s g na začátku, nebo s odkrojeným _t. Nebo třeba gsize, který dokumentace definuje takto:

An unsigned integer type of the result of the sizeof operator ... blabla

Standard jasně říká, že výsledek sizeof operátoru je právě size_t, což je právě neznaménková hodnota. Proč si tedy glib musí to samé "definovat" ještě jednou - navíc je jejich definice zavádějící - sice je to typedef na size_t, ale "nutí" vás používat jejich typ. Proč proboha?

Qt v tomto není o nic lepší.

[Jardík]

K tomu zavádějící - standard jazyka nikde netvrdí, že do size_t se dá uložit pointer, dokumentace glib to ale v podstatě tvrdí.

[tom]

Ono to z toho vpodstate vyplyva - standard rika, ze operace rozdilu 2 pointeru ma smysl jen v pripade, ze oba ukazuji do stejneho obektu. Tudiz musite byt schopen vytvorit obekt, kam oba padnou a na velikost toho obektu se jde samozrejme zeptat pres sizeof. Prevod na integer si pak predstavte jako rozdil (char*)ptr - (char*)0;

[imploder]

Kde se říká, že rozdíl dvou pointerů musí být taky pointer?

[tom]

V mem prispevku a ve standardu urcite ne.

[imploder]

V tom případě nechápu, jak z příspěvku vyplývá, že do size_t se dá uložit pointer.

Jsou to 2 různé věci: pointer - umístění objektu v paměti, size_t - velikost objektu. Podle mě nedává smysl je míchat.

[tom]

Cetl jste vubec ISO/IEC 9899? Podivejte se do draftu http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf (ten je zadarmo) na 9 na strane 83.

[imploder]

Četl jsem jenom některé části, tohle zrovna ne. Nevidím tam napsané, že ptrdiff_t je pointer ani to tam IMHO z ničeho nevyplývá. Píše se tam, že je to "signed integer type".

[tom]

Proc si myslite, ze by ptrdiff_t mel byt pointer?

[imploder]

Aha, už to chápu: jde jen o to, že do size_t se pointer musí vejít, ne že size_t je pointer. Omlouvám se za nechápavost.

[Jardík]

Pointer se musí vejít do intptr_t a do uintptr_t, do size_t se vejít nemusí a jenom prase pointer přetypovává na nějaký číselný typ.

[Jardík]

Rozdíl dvou pointerů je typu ptrdiff_t. tečka. žádný int.

[tom]

Ja napsal prevod na integer ne na int. A ze ptrdiff_t je integer je napsane v standardu.

[Jardík]

Tak za to sry, jsem se přehlédl.

[Jardík]

Jinak vemte si příklad. Na systému je možné alokovat objekt o max velikosti 32K. Na takovém systému stačí, aby sizeof(size_t) bylo 2. Počet alokovaných objektů ale může být třeba 4G, na to bude teda potřeba pointer o velikosti minimálně 4. Můžete do size_t uložit pointer?

* pro případ tiše předpokládám, že char má na tomto systému 8b, což mi standard negarantuje.

[tom]

jj, to muze, ale pak uz nebude posix kompatibilni. Na posix systemu neni omezeni na velikost obektu, ale pouze na dostupnou pamet. Takze muzete hypoteticky vytvorit obekt pres celou pamet a na ten se pak ptat pomoci sizeof. Samozrejme by ale bylo lepsi, kdyby pouzivali intptr_t, ten je ale bohuzel moc novy.

[Jardík]

To je možné. Jinak intptr_t nový není. Není sice momentálně v C++ není (s trochou štěstí tam do roka bude), ale v C99 je od roku 1999, což je přes 10 let. glib2 vyšlo snad někdy v roce 2001 (?), a GCC v té době jistě již takové typy mělo (pár typedefů je pro vývojáře prkotina, jež se může implementovat za 10 minut pro všechny podporované architektury). U Qt je sice teda pochopitelné, že intptr_t nepoužijí, ale proč to vlastně používat? C++ podporuje forward deklarace a není problém je použít, když chtějí něco "schovat". Nehledě na to, že si definovali vlastní qintptr a pak ve zdrojákách jak hlupani stejně přetypovávali na longy. Jinak já sice nejsem nějaký super programátor, ale mě takovéhle "chyby" prostě vadí. A vadily by mi i kdyby měl program běžet jen na jedné pevně dané architektuře, kde to zrovna platí. Pro někoho je prostě asi pohodlnější napsat long a = (long)CreateWindowEx(...) než HWND a = CreateWindowEx(...), int diff = pointer2 - pointer1 místo intptr_t diff = pointer2 - pointer1 či int len = strlen(řetězec) místo size_t len = strlen(řetězec). Ale můžeme se tu hádat do nekonečna, ale v Qt a glib je už na změny pozdě, v Qt mohli alespoň s těmi inty něco udělat, když vyšla první verze Qt4, bohužel jim ujel vlak.

[imploder]

Qt si buduje něco jako vlastní STL - duplikuje hodně věcí z něj. Myslím, že je to proto, že to chtějí mít prostě svoje a lepší.

Pořád aspoň Qt využívá na objekty standardní vlastnosti C++ a nevytváří si jako GTK vlastní pseudo-objekty

[Jardík]

Pochopím třeba, že nechtějí STL, ale aby je implementovali tak kriploidně jako např. velikost kontejneru daná typem int ... ale mě je to jedno, ať si dělají, co chtějí.

[imploder]

Takže správně by podle tebe měli na velikost kontejneru použít size_t, aby bylo zaručené, že tím půjde indexovat i kontejner s 1B objektama zabírající celou paměť? To dává smysl, rozsah intu může být moc malý.

[Jardík]

Cože? Já mám např. 16GB RAM a i na kontejner plný intů by ten int na indexování byl málo (záporné hodnoty). Sice asi takto zaplněný kontejner bude mít málokdo, ale to neznamená, že se to nemůže udělat pořádně. Nehledě na to, že int může být klidně dokonce větší než size_t a je v tom případě blbost, aby mi Qt dovolovalo alokovat pole o INT_MAX prvcích, když to na daném systému třeba nejde (s takovým systémem jsem se sice nesetkal, ale ...).

[imploder]

Na máloco je potřeba kontejner s takovým množstvím prvků, že na indexování int nestačí. Ale souhlasím s tebou, je to umělé omezení a správně by nemělo existovat.

Takže chápu to správně, že podle tebe by se mělo na indexování používat size_t nebo nějaký vlastní typ? Indexovat intem (pole, řetězce atd.) je IMHO běžné, tohle by bylo takové netradiční. Otázka je, proč se teda indexuje intem, když je to špatné.

[Jardík]

Já intem neindexuju, já všude indexuju typem size_t (pro náhodný přístup), nebo neindexuju (sekvenční přístup) a používám pointery nebo iterátory, podle toho, jestli mi v daném případě záleží na každé nanosekundě.

[imploder]

No, když nad tím uvažuju... asi začnu indexovat zásadně size_t taky

[tom]

Mozna si to neuvedomujete, ale komerecne se pise tak, aby veci byly co nejlevnejsi. Vetsina dnes prodavanych CPU jsou 8bity, kde se C++ proste nemusi vyplatit (usetri min casu nez o kolik prodrazi produkt).

[imploder]

Jo, na osmibitu si pustím Linux s nějakou GTK aplikací Že se jich prodá hodně je úplně irelevantní, bude na nich běžet úplně jiný SW.

[tom]

Mozna jste to nepostrehl, ale ja se vubec nevyjadroval ke GTK (ktere ma mimochodem i C++ binding gtkmm). Ptal jsem se:

Proc podle vas nejde v C programovat obektove?

Na coz jste vubec neodpovedel, ale kladl jste sam otazky (proc nepouzit C++ atd), na ktere jsem se Vam snazil odpovedet. Jazyk, ktery vyvojari gnome pouzivaji me zajima asi tak jako v kolik hodin jezdi v Wellingtonu popelari.

[imploder]

Samozřejmě netvrdím, že C se nemá používat nikde. Myslel jsem že se bavíme o GUI na PC.

[dest]

Jako omlouvam se, ale komu se muze libit qt? Vypada naprosto priserne - jako nejaky nepovedeny klon Windows smichany s Mac vzhledem. Navic je to od Nokie.

Kdyz se podivam na GTK, tak to radost se na to divat a vubec se nedivim, ze linux pro lidi je Ubuntu s Gnome (GTK).

[Luboš Doležel (Doli)]

LOL, o možnosti nastylovat to jste neslyšel? Může to například vypadat jako GTK...

[pacholik]

s/qt/kde/

a pak to dává aspoň smysl

[Marián Kyral]

Jako omlouvam se, ale komu se muze libit gtk/gnome? Vypada naprosto priserne... a umí to jen osminu věcí co qt/kde. Všechno je k uzoufání primitivní. Uživatel zvyklý dělat věci více způsoby má smůlu. Existuje pouze jediný™ správný™ způsob™ ©,

>> Jó ty by jsi chtěl soubor před otevřením ve file dialogu přejmenovat? Jsi padlý na hlavu či co? Tohle přece musíš udělat ve file manageru.

[Kiron]

Nebo si zkopírovat cestu adresáře ve kterém se nachází? Vložit si tam soubor z clipboardu?? ..... Prostě hnus, co ti uživatelé dneska požadujou! :o))

[Kiron]

A co Vám na to radí lékař? :o)) (jenom ftip, nebrat vážně) :o)

[Kaacz]

Plete si QT a KDE. QT (a GTK) jsou graficke engine, na kterych se pak buduji vrchni vrstvy desktopu. KDE je jiz vrchni vrstva, ktera definuje vzhled. Stejne tak Gnome je vrchni vrstva, ktera definuje vzhled. Rozdil je ale v tom, ze nad GTK neudelate KDE, kdezto nad QT udelat vzhled Gnome neni zadny problem. QT ma cosi, co se da prirovnat ke skin ci css.

Viz priklad MeeGo, kdy vzhled a ovladani se lisi podle toho ci je v netbooku, tabletu, mobilu, aute ci TV. Nad soucasnym GTK to znamena pouzivat modifikovane GTK pro kazdy projekt. Tezko se do toho zanasi patche z hlavniho stromu a vznika spousta novych chyb. V cilovem MeeGo s QT bude vsude nemodifikovane QT a ruzny template vzhledu a ovladani pro kazdy projekt. V tom je sial a budoucnost QT.

PS: Gnome nemusim, desne mne na nem sere neergonomie - vsude halda prazdnych ploch, cimz je mene mista na obsah. Mozna dobre pro deti a duchodce se spatnym zrakem (kdyz se i zvetsi pismenka). To se ale pro ne da lehce vyrobit i na KDE.

[dest]

Tak to bych rád viděl Qt + Gnome v akci. Budoucnost není C++ ale C knihovny + managed prostředí (Java, .Net).

[Yohannsson]

dokud bude mít Red Hat, Debian a další defaultně Gnome tak se o GTK rozhodně nebojím. Za Qt stojí jen Nokia, a i nové MeeGo (což je spolupráce Nokie a Intelu) je vlastně Gnome (+ je tam teda přidaný to qt)

http://www.abclinuxu.cz/clanky/meego-1.1-na-netbooku

[Kaacz]

Ohledne MeeGo: soucasne MeeGo 1.x je defakto vylepseny Moblin s par vecma z Maemo, oboji postavene puvodne na (hildonized) GTK. Ale asi sis nevsiml mnoha clanku, kde je jasne psano, ze gtk se zahazuje a cele to prejde na QT.

[Rezza]

MeeGo je totiz jen nazev projektu - to o cem se mluvi je MeeGo Netbook UX. To je skutecne jen rebrandovany a dal delany Moblin. Naopak ostatni UX se delaji v Qt. Kdyz se nekdo rozhodne delat UX v toolkitu ABCDkockaPrede verze 0.001234, tak muze. To je to co se me libi na MeeGo Core, tedy zakladu systemu. Ktery je jako platforma - je v nem ta Gtk cast, Qt cast a pripadne dalsi nutne knihovny.

Proste ja jen nechapu, proc Gnome aplikace (jako prostredi, jednotne HIGs atd.) se nemuzou napsat v Qt (za predpokladu toho g/dconfu v QSettings), to same opacne. Prostredi by nemelo byt o toolkitu, ale o tom, jak se chova. To same - pokud se nekomu pise lip v Gtk/C, proc ho nutit do Qt/C++ (i kdyz bych takoveho cloveka krom par masochistu chtel potkat, pisu v obojim :D).