Zimmerman: Az Ubuntu és a Qt

Címkék

Az Ubuntu mögött álló Canonical-nál műszaki igazgatói posztot betöltő Matt Zimmerman nemrég egy érdekes blogbejegyzést publikált, amelyben leírja, hogy szeretné azt gondolni, hogy az Ubuntu-nál gyakorlatiasan közelítik meg a műszaki dolgokat. Hogy mit jelent ez? Azt, hogy elfogulatlanul számításba veszik az alternatívákat és azokat objektíven kiértékelik. Ennek szellemében elmélkedett Matt az elmúlt időszakban a Qt-ről és arról, hogy az Ubuntu hogyan tudná felhasználni alkalmazások fejlesztéséhez. Az Ubuntu-nál gyorsan, fájdalommentesen szeretnének alkalmazásokat fejleszteni. Zimmerman pedig azon a véleményen van, hogy a Qt egy olyan opció, amin az alkalmazásfejlesztőknek érdemes elgondolkodniuk. A blogbejegyzés itt olvasható. Az Ars Technica-n egy hosszabb kommentár jelent meg Zimmerman gondolatai kapcsán.

Hozzászólások

Hat ja, van kubuntu ... Amugy nem ertem teljesen a dolgot, ha az "alap" (nem k*) ubuntu distro alapvetoen gnome/gtk alapu, akkor az miert lesz jo, ha nehany app qt-s nehany meg gtk-s lesz vegyesen, merthat irja is, hogy az qt csomag hozzaadasa szamottevoen nem lenne nagy fajdalom. Hat nem tudom ... Miert jo az, ha van 1 vagy 2 ubuntu specifikus cucc amihez qt kell mig a tobbi gtk? Akkor ilyen elven legyen fltk meg minden mas is keverve ... Azert memoriaban stb nem mindegy, foleg, hogy nincs minekinek eromuve, ha qt-t akarok, hasznalok csak qt-t (legalabbis tobbsegeben), de minek igy keverni ... Aztan lehet szepen majd theme stb dolgokban operalgatni hogy ugyanugy nezzen ki, egyseges megjelenes legyen attol, hogy valami qt ... Vagy akkor tegyek az egesz gnome-ot qt fole :) de ne keverjek, szerintem ...

Az elvet nem ertem ... Ilyen elven johet meg szamtalan egyeb megoldas, nem csak a qt. Aztan osszehangolni azok kinezetet stb extra energiat igenyel kulon-kulon. Van akinek mar az bantja a szemet, hogy a "linux vilag tul fragmentalt" van pl a ket kb legtobbet hasznalt DE a gnome es a KDE. Namost ha itt egy agon belul (pl Ubuntu, ahol ugye alapvetoen alaprendszerben gnome/gtk van) is keverjuk, az miert lesz jo? Emlekszem egy haver gnome-ot latva eloszor mar azon fennakadt, hogy mi az hogy "about" menupont van kulon a panel-re meg minden, "ezek kulon cuccok es csak ossze vannak ganyolva? mert ha nem eleg egy about menu az egesz rendszerrol nem kb minden pixelhez egy kulon". Na ezzel nem teljes mertekben es feltetlen ertek egyet, es mindig jo (szerintem) a valasztas szabadsaga egy fix megoldas helyett, de azert ennyire fragmentalodni is durva, hogy egyazon distro egyazon DE megoldasaba az alaprendszerbe most be akarnak vonni veletlenszeruen egy uj widget lib-et a meglevo melle, es akkor vegyesen hasznalni?

Pár szarfos r=1 usernek való programtól eltekintve (ezt az össz. 10 darabot a fenti cikk szépen össze is gyűjtötte) konzisztensebb, mint Linuxban az állandó GTK, Qt, Tk, Xaw közt vergődés. Mert mindig lesz 2-3 program ami nincsen meg vagy sokkal hiányosabb funkcionalitású, mint a másik widget libet használó társa, így muszáj lesz egy teljesen más betűtípus-méretezést, akár antialias nélküli megjelenítést, más menürendszert, stb használó programot használni. Hihetetlen idegesítő.

Winben a fenti programok és az összes többi esetén is legalább a betűméretezés, alap widgetek, pl. font select és file open mindenhol egyformák a 15 évnél újabb programokban; kizárólag a Linux/FOSS programok portjai lógnak ki a sorból.

UI: ki mondta hogy wint ajánlok, amúgy? A linkelt cikked is eléggé a macet favorizálja, nem véletlenül.

Az viszont vita felett áll, hogy a Linuxon uralkodó állapot minden, csak nem optimális.

Nalam van boven RAM (es KDE-vel hasznalom, szoval nalam alapbol bent van), de aki mondjuk a netbook editiont hasznalja, az nem hiszem, hogy orulne neki.

--
The iPad: Because the iPhone was too small for other people to notice you.

Egy átlag asztali gépen már annyi felesleges hülyeség csücsül a memóriában, hogy éppen egy hasznos dolognak ne lehetne helyet szorítani? A közösség és a fejlesztők is sokkal többet nyernek a Qt alkalmazásán, mint amennyit veszítenek az erőforrások szűkösségégével képmutatóan megindokolt mellőzésén.

Hat nekem pont ezert is "herelve" vannak a dolgok, hogy lehetoleg kevesebb felesleges dolog legyen. De tenyleg baromsag, hogy (most nem kubuntu-rol van szo) minden gtk, de legyen 1-2 alaprendszerben is levo app, amihez qt kell. Akkor majd jon az fltk (amint fentebb irtam) stb stb, hogy azokat is lehetne hasznalni. Ennek tenyleg mi ertelme?! azt meg megertem/elfogadom, hogy a kstars (amit szeretek gnome alatt is) qt/kde mar eleve, ez van. Nade most egy ubuntu-s util fejlesztesnel mindik qt-t hasznalni mondjuk egy amugy gtk-s kornyezetben ahol a funkcionalitas esetleg minimalis (nem egy kstars) csak azert hasznalnanak gtk helyett qt-t mert valakinek jobban tetszik, meg hogy legyen qt is a rendszerben mar, mert ez milyen igazsagtalan ...

Az meg nem is lenne baj, sot! De ne keverjek mar ilyen brutal modon egy DE-n belul. Vagy lehet en ertettem felre, nekem az jott le, hogy az alap gnome/gtk alapu ubuntu-ban minden marad gnome/gtk, de lehet, hogy nehany uj project-nel qt alapu lesz, akkor is az alaprendszer tovabbra is alapvetoen gnome. En ezt nem ertem igazan, azzal _semmi_ bajom nincs, ha van ket hivtalosan is tamogatott DE. mondjuk ...

Miért olyan érthetetlen ez? A feladatra legmegfelelőbb program kiválasztásánál nem szeretnék, ha a háttérben alkalmazott eszközkészlet lenne mérvadó a minőség helyett. A Qt fejlesztői megtették az első lépéseiket a kompatibilitás érdekében, a GTK esetében ez sajnos nem mondható el.

most is van benne mono, ehhez képes a qt bakkfity :)
a qt képes annyira integrálódni gtk-ba (gtk > qt-val szemben) hogy észre sem veszed. az a +10mega meg nem oszt nem szoroz. Főleg úgy ha qt-val gyorsabb/könnyebb fejleszteni. több idő marad bugmentes toolok/alkalmazások írására. DE-ket ne keverd ide, azért mert valami qt-t használ még nem lesz kde-s függősége (kivéve ha hozzák az ubuntus sráccok a formájukat és össze-vissza gányolnak mindent.).

\troll on
Qt alavetoen nem, az egy igaz karakter kodolast hasznalja. Ez sullyos hiba, hosszu tavon foleg.
UTF-8 for president!!11!!!
\troll off

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Belul UTF-16. Konvertalgatnia kell.

Az utobbi idoben, majdnem kvazi standard lett a legtobb tarolt es forgalmazott adatnal az UTF-8.

(Ha C++ std:string -et hasznal az egyik libed azt szinten oda-visza kovertalgatni kell QString-re, nem tul hatekony)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nyilván tudod, de az UTF-8 egy unicode karaktert változó bájthosszon tárol, ezért nem praktikus a használata olyan esetekben, amikor egy karakter-pozícióra rá kell mutatni, mert végig kell olvasni a teljes tartalmat, hogy biztosak legyünk benne, hányadik pozícióban vagyunk. Az UTF-16-nál meg egy egyszerű tömb-pozícionálás kell csak.
Ezért van az, hogy tárolásra és hálózati továbbításra szeretik az UTF-8-at, de minden normálisabb programnyelv belül UTF-16-ot használ (UTF-32 használatról eddig nem nagyon hallottam, de elképzelhető hogy már az is van).

"QString stores a string of 16-bit QChars, where each QChar corresponds one Unicode 4.0 character. (Unicode characters with code values above 65535 are stored using surrogate pairs, i.e., two consecutive QChars.)"

Más kérdés, hogy szerintem a teljes kínai abc belefért ebbe a 16-bit-be.
(Pl wchar Win-en nem UCS2?)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Én úgy tudom, hogy nem az összes Unicode karakter ábrázolható UTF-16-ban uniform (azaz minden karakter 16 bit) módon, de erre az összes UTF-16-ban tároló rendszer "tesz".

Azaz olyan nyelveken, ahol használják a 16 bitesnél hosszabban ábrázolható karaktereket a programozónak kell megoldani a stringen belüli karakter szerinti címzést, illetve a string hossza (karakterben mérve) lekérdezést. Hasonlóan, mintha UTF-8-at használnánk egy eredetileg (0 végű) ASCII-re tervezett rendszeren.

Ezt jól tudom? Vagy tévedek, és "valódi" UTF-16 implementáció van a rendszerekben, ezzel lassítva, és bughalmazzá alakítva az alkalmazásokat?

Mivel mi itt Kelet Európában beleférünk a 16 bitbe, ezt a problémát ugyanúgy letojhatjuk, mint az USA-ban letojták sokáig az ASCII kódolás problémáit :-).

Az egyetlen igaz megoldás pedig a 32 bites karakterábrázolásra való áttérés lenne, vagy akkor már inkább 64 bites. Akkor a Föld minden atomjához rajzolhatnánk új karaktert.

Mf=5.9742*(10^24) kg
(5.9742*(10^24))/(2^64)
323862.03094314502948236622 kg
Amenyiben egy atom tomege a fenti adat.
Nem akkarom 2^64 -t megint a Fold atomjai peldaban latni.
FYI: ipv6 128 bit. Ami meg mindig sovany. (Talan homokszembe meg nem kotok bele)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Azaz olyan nyelveken, ahol használják a 16 bitesnél hosszabban ábrázolható karaktereket a programozónak kell megoldani a stringen belüli karakter szerinti címzést, illetve a string hossza (karakterben mérve) lekérdezést. Hasonlóan, mintha UTF-8-at használnánk egy eredetileg (0 végű) ASCII-re tervezett rendszeren."

Valami ilyesmi.

"Mivel mi itt Kelet Európában beleférünk a 16 bitbe, ezt a problémát ugyanúgy letojhatjuk, mint az USA-ban letojták sokáig az ASCII kódolás problémáit :-)."
http://en.wikipedia.org/wiki/Unicode_plane

Nézd meg mik vannak a plane 1-3-ban. Na ezért nem akkora probléma, ha egy program csak ucs2-es és nem utf-16-os.
(Persze ha ősi perzsa szövegeket fordítasz, akkor valószínűleg nehéz megtalálni a megfelelő szövegszerkesztőt..)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Valosagban gyakran eleg lenne csak az UCS2 sok esetben.
A 16 bittes abrazolast meg akkor vezettek, be amikor az eleg volt az osszes kod pont abrazolasara. Ma mar nem az.

A 32 bittes abrazolas meg tulsagosan pazasrlo lenne ma is, altalanos (default) String implementacionak nem ajanlott.

Ha pedansan kodolsz akkor figyelmbe kell venned, hogy n DB UTF-16 character akkar 4n byte helyet is foglalhat. (Nem tudom volt -e mar sulyos FAIL a benezese miatt (CVE))
Ha tenyleg talalsz olyan use caset a mai vilagban ahol tenyleg fontos a gyors karakter szerinti index es nem a 8 bites charakteres vilagbol rank maradt csokevenytol van szo, akkor talan ott volna ertelme az UTF-32 -nek.

Manapsag gyakoribb, hogy elvalaszto jelet keresel, ahol egy mutatod lesz, nem karakter indexed.
Nagyon megeroltetve a fantaziamat sikerult egy-ket mestersegesen generalt peldat talanom ahol hasznos lehet a karakter szerinti indexeles (fixed-size fontokat felteteleztem). De a legtobb esetben siman elkerulhato volt.

Mivel valodi UTF-16 kezeles rendelkezik ugyan azokkal a hatranyokkal, mint a valodi UTF-8 kezeles, raadasul meg nagyobb is, valamint elter a tarolt es forgalmazott kodolastol, ezert el kene felejteni az UTF-16 -ot.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

És arról még nem is beszéltünk, hogy az UTF-8 az egyetlen olyan tárolási formátum, ahol nincs little endian és big endian szarakodás. Érdekes módon ezt nem említik az UTF-16 hívők.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Remélem rájönnek arra, hogy lehet úgy fejleszteni ubuntu extrákat, hogy ne legyen a függősége a fél gnome, és remélem megjelennek azok az ubuntu specifikus appok, amik működnek kde, gnome, akármi alatt anélkül, hogy várni kell, hogy mindegyik változatra külön elkészüljön.

Fel nem bírom fogni, hogy miért nem készült még egy toolkit ami egyesíti a QT-t és a GTK-t, legalábbis ami a grafikai részét illeti, ami megoldaná azt, hogy egy app kde alatt qt felülettel, gnome alatt gtk felülettel jelenjen meg, és ne kelljen kétszer megírni, kétféleképp fordítani. Talán ez a kezdeményezés egy idő után elvezet ehhez.

Írj meg egy egyszerű grafikus programot, pár elemmel (pl. lista, legördülő menü, OK gomb) C++-ban Qt és GTKmm GUI-val is... meglátod, miért nem született máig (és miért nem is nagyon lesz) wrapper a kettő egységesítésére.
Az, hogy hasonló koncepciót valósítanak meg, nem jelenti, hogy hasonló logikával működő rendszer van ezek mögött.

(arról nem is beszélve, hogy a GTK appok nagy része nem is C++ hanem sima C, ami meg még távolabb áll a Qt-től így méginkább esélytelen az egységesítés)

Qt -nak van gtk theme engine, es forditva is van. Tehat kinezetre nem feltetlenul kell, hogy feltunjon, hogy masik toolkitet hasznal.

A Linux Standard Base magban foglalja a Qt -t es gtk+ is, illik mindketonek lenni egy Linux rendszeren.

Maga Qt/Gtk+ lib boven eleg grafikus elemek hasznalatahoz, es onmagaban nem draga.

wxwidget az a framework, ami tobb masik gui framworkot szolit meg elfedve a kulonbsegeket. A platfromon szokasos backendedet hasznalja Windowson es OS X -en is. Gtk+ -t egyeb rendszeren (pl. Linux).

Amenyire en tudom Qt4 egyik rendszeren sem tunik idegen kinezetunek, ha nem akkar.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azért a QT alkalmazások többsége elég nehezen integrálódik gnome alá.

Például amikor indítom a QT-s skype-t, Gnome alatt, és fekete szöveggel ír a fekete szövegbuborékra, hiába állítom be a chrome-t alap böngészőnek, a skype mégis a foxot nyitogatja.

Vagy KDE alatt haszálnám akármelyik gtk-s progit, és a GTK-ra jellemző fájlböngészés ablakot kapom amikor mentenék/megnyitnék. Ugyanez fordítva. Lehet nem életbevágó, de zavaró. Ráadásul rontja a "látképet" ugyanis nem ugyanazt az ikontémát használja a gtk-s és a qt-s fájlböngésző.

Ellenpélda: elindítom az smplayert, ami qt, beállítom a gtk témát rá, és gtk. De minden. A fájl megnyitás ablak, ui elemek, minden. Nem tudom, hogy szimulál-e, vagy tényleg GTK-t használ, de azért becsülendő, és jó lenne, ha ezt meg lehetne oldani minden programban.

Egyébként a wxwidget pont jó példa, csak annyit kéne még tudnia a win, osx, gtk mellé, hogy támogatja a QT-t is.

A Skype elég gázul van összerakva, KDE alá ugyanúgy nem integrálódik, mint Gnome alá, hiába Qt-s.

A Chrome-mal meg ha jól tudom olyan probléma van, hogy több különböző www-browser metacsomag is létezik és a Chrome nem provide-olja mindet. Ugyanezen jelenség miatt nem tudsz pl Java Plugint telepíteni ha a Chrome-on kívül más böngésző nincs a gépen.

KDE-s appokat ne keverjük ide.

A jó példa az smplayer. Így kéne működnie az összes qt-s programnak.
Az, hogy ugyanúgy nézzen ki mint a több app, és hogy a platform alapértelmezett fájl megnyitás ablakát használja, az a default viselkedés a Qt-ban 2-3 verzió óta.
(Értsd.: külön kell dolgoznod, hogy ne így legyen.)

Én csináltam nagyobb projektet wxWidget-tel, kicsit gtk+-szal és gtkmm-mel, sok nagyot qt-val, és teljesen egyértelmű, hogy melyik a legkényelmesebb.

A gtk egyszerűen túl macerás mai szemmel, a gtkmm kicsit workaround érzés. Nem véletlen, hogy pl a mono is terjed. Kényelemes.

Gnome-osoknak a vala-ra kéne ráfeküdni, illetve az egész framework fejlesztésére, mert a Qt jelen pillanatban nagyon ellépett...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Hát, a Skype a Qt-s GTK témahasználat legszebb példája. Ha rágugliztál volna a problémára, megtaláltad volna a megoldást, de én is leírom neked.

Elindítod a Skype-ot -> Ctrl-O (megnyitja a beállításokat) -> baloldali lista legfelső eleme: "General" -> az ablak közepe táján: "Choose Style", ezt legördíted, és kiválasztod a GTK+-t.

Nem, ez nem "emulálja" a GTK-t, ez konkrét GTK-s API hívásokkal rajzol, tehát ~100% GTK kinézetű lesz az appod.

Remélem segítettem.

GTK+ módot használok, és adott a tooltip bug (igaz, hogy csak a csevegőablakban a gondolatbuboréknál, de pont ott használnám. De most had legyek kicsit a hülyefelhasználó: nem akarok én beállítani olyasmit, hogy qt meg hogy gtk, el akarom indítani a skype-ot, és használni akarom, látni akarom a tooltipet anélkül, hogy nekem rá kéne gugliznom.

Nincs gondom meghekkelni a rendszert, de egyre inkább eljutok oda, hogy használni szeretném a rendszerem, és nem építgetni, mert nincs időm a munka mellett.

"De most had legyek kicsit a hülyefelhasználó: nem akarok én beállítani olyasmit, hogy qt meg hogy gtk, el akarom indítani a skype-ot, és használni akarom, látni akarom a tooltipet anélkül, hogy nekem rá kéne gugliznom."

Normális esetben nem is kell, egy rakás Qt-s programnál megoldották, csak skype-nál nem.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A következőről van szó:

The easiest way to create a QFileDialog is to use the static functions. On Windows, Mac OS X, KDE and GNOME, these static functions will call the native file dialog when possible.

Azaz van a fájldialógusnak olyan opciója, amit a standard GTK-s nem tud, ekkor a saját implementációt hívja meg. Nekem van olyan programom, amely a GTK-sat használja, és egyszer én is megijedtem, mert valami állítgatás végére megnyílt ez az ismeretlen szerzemény.

Persze elhiszem, hogy van olyan, akit ez zavar, és lehet, hogy inkább a plusz fícsörről lemondhatnának a Skype-fejlesztők annak érdekében, hogy biztos minden platformon a natív jelenjen meg.

> Fel nem bírom fogni, hogy miért nem készült még egy toolkit ami egyesíti a QT-t és a GTK-t, legalábbis ami a grafikai részét illeti, ami megoldaná azt, hogy egy app kde alatt qt felülettel, gnome alatt gtk felülettel jelenjen meg

Már leírtam máshol is, de ide is még egyszer: http://labs.qt.nokia.com/2008/09/05/qgtkstyle-now-part-of-qt/
Érdemes megnézni a screenshotokat. A Qt képes arra, hogy natív GTK hívásokkal rajzoljon, így néhány apróbb grafikai bug kivételével (alig láttam eddig ilyen témát) teljesen GTK-s kinézete lesz az appnak.

Más kérdés, hogy pl.: Ubuntu alatt, ha felteszel egy KDE-s (nem szimplán Qt-s, hanem KDE-s) appot, akkor az nem Qt-s témabeállításokkal jön, hanem a hányadék KDE4-essel - hirtelen én sem tudom, hol lehetne ezt könnyedén átállítani, de a systemsettings valószínűleg kell hozzá.

Igen, ezt írtam én is. Hát nosza, próbáljuk is ki:
A systemsettings 148MB-ot pakol fel, és ha beállítom a GTK+ témát, még így is átszínezi a KDE-s színbeállításokkal (Window bg colort kézzel kell kiválasztani)

Én ezt megteszem, de elhiszem, ha sokaknak nincs kedvük ezzel szarakodni.

Ez tényleg nem toolkit, de szerintem ez épp arra való, amire reagáltam:

" [...] miért nem készült még egy toolkit ami egyesíti a QT-t és a GTK-t, legalábbis ami a grafikai részét illeti, ami megoldaná azt, hogy egy app kde alatt qt felülettel, gnome alatt gtk felülettel jelenjen meg, és ne kelljen kétszer megírni, kétféleképp fordítani. "

A QtCurve ezt egész jól megoldja.

en csak azt szeretnem, ha nem foglalna el a menusor, meg a gombok a fel kepernyot :)