Zimmerman: Az Ubuntu és a Qt

 ( trey | 2010. október 24., vasárnap - 13:15 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Én nem haragudnék érte, ha végre számításba vennék a Qt-t is.

SKL - leírásgyűjtemény és informatikai portál

+1

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

+1

+1

- waiter -

Szerintem a szükséges mértékben számításba vették eddig is. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ezért van olyan csodás állapotban a KDE-s Ubuntu-One kliens...

ne is említsd, ettől agyf@szt kapok. Frissítés után teljesen használhatatlan lett a mocsok.

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 ...

Amennyi szemetet betölt a ramba, +/-1 Qt nem sokat oszt-szorozz :)

----------------
Lvl86 Troll

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?

Ez a probléma kb a Linux alapú OS-ekkel egyidős, és azóta is sokak szerint ahogy van az a legnagyobb rendben van, a felhasználók meg szívnak.
Megszoksz vagy... szerzel más rendszert és nem szopsz.

Igen, az a jó a Windowsban, hogy az alkalmazásoknak olyan szép, konzisztens a felhasználói felülete... ;)

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.

O papikam, ha a Linux legalabb ilyet tudna produkalni, akkor mar a Dekstop Eve (tm)(r) lenne....

Tud (ld: chrome) , csak egyelőre (szerencsére) fontosabb a programok funkciója, mint az, hogy csicsásan jelenjen meg.

köszönjük a szakértést!

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.

10 éves urban legend rulz. Már akkor is hülyeség volt amikor először elterjedt, hogy a Qt több erőforrást eszik mint a GTK 2.x... a GTK 1.x-nél valóban, de azt talán már így 2010-ben el kéne felejteni.

szerintem arra gondolt, hogy gtk+qt egyszerre lesz használatban.

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.

kicsit több qt cucc, mondjuk a moso-sok helyett, és pábáám
--
Dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5

Ha a monóra gondoltál, akkor +1.

elírtam...
--
Dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5

én egyetértek, csak leírtam mire gondolt Nyosigomboc.

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 ...

Bár nem figyelem a dolgokat, de nem lehet, hogy így akarják előkészíteni a KDE-s Ubuntu verziót? Az OpenSUSE esetében is két támogatott DE van, miért ne lehetne az Ubuntunál is ez? A Kubuntu ha jól láttam nem Canonical érdekeltség, hivatalos support sincs rá, stb.

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 ...

Szerintem a Gnome3-t újraírják Qt alapokon, ezért a verzióváltás! :)

----------------
Lvl86 Troll

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.).

Rosszul láttad. A Kubuntu is a Canonical hivatalos terméke, így támogatás is igényelhető hozzá.
https://wiki.kubuntu.org/Kubuntu/Support

Ma is okosabb lettem! Köszi!

+1

+1

+1


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+1

\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.

Mire gondolsz? (( kicsit értelmetlenek a szavak, amiket írtál ))

Szóval Qt csak UTF-8-at tud? Vagy csak azt nem tud? Az UTF-8 az egy igaz karakterkódolás? Ha igen, az miért súlyos hiba? És miért főleg hosszú távon?

Ha jól értem azt akarja mondani, hogy a Qt alapértelmezetten nem UTF-8 kódolást használ.

természetesen az utf8 az egy igaz kódolás, de nem tudok róla, hogy a qt nem szeretné, de mindjárt felvilágosítanak minket itt

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).

"Az UTF-16-nál meg egy egyszerű tömb-pozícionálás kell csak." Nem. 2^16-nal tobb unicode code pont van.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"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

(Pl wchar Win-en nem UCS2?) - 2000 ota nem.
wchar_t Unixon/Linuxon 32 bit, Windowson 16 bit.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

UTF16-nál is lehet 2 bájtosnál hosszabb karakterkód. Amire te gondolsz, az az UCS2.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

És tényleg.

"Because of the technical similarities and upwards compatibility from UCS-2 to UTF-16, the two are often erroneously conflated and used as if interchangeable"

Az UTF-16-ban sikeresen egyesítették a különböző kódolási módszerek hátrányait: 0 is van a bytesorozatok belsejében és a kódolás hosszúsága sem fix. UTF-8-ról itt.
--
CCC3

+1, Synternnek igaza van, utf16 mérföldekkel gyorsabb belső feldolgozást tesz lehetővé.

Akik sírnak az utf8 miatt, azok se ejtsenek túl sok könnyet:
http://doc.trolltech.com/4.7/qstring.html#toUtf8

É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.

Hm. Köszi a felvilágosítást. Legközelebb utánaszámolok, mielőtt szövegelnék.

"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)

http://www.kephost.com/images3/2crqrwaamoi3sfsxvzso.png

sztem semmi baj a kinézetével. Nem kell állítgatni semmit sem és így néz ki.

Hozzáteszem az új Qt Creatornál nem sikerült ugyanezt elérnem ezért visszatértem a 4.6.2-es verzióra.

Pont ez a lényeg. Qt alkalamások open/save dialogokkal együtt integrálódnak a gtk-ba, viszont fordítva botrányos a helyzet. Ezért nagyon jó hogy meglépték ezt a lépést ubuntuék'. Bizakodva várom a fejleményeket, vesszen a gtk ;)!

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.

Az smplayer tiszta Qt, a GTK kinézettel a Qt GTK engine-jét használja. Jó példa arra, hogyan kéne az összes többi szart is megírni. De nem teszik... (GTK/GNOME oldalon sem - mintha a másik rendszer nem is létezne)

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

+sok. azzal a kiegészítéssel, hogy én hagynám sorvadnia gtk-t. a gimp meg menjem a p!c$ába, amíg nem lesz qt-s felület :D:D:D

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

"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."

A file open dialógusa (file küldésnél) nem natív gtk-s, csak valami "hasonló".

Akkor ez Skype fail.

"...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ó:

Qt Referencia Dokumentáció írta:
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á.

A KDE stílus módosítása systemsettings, a nem KDE-s, de Qt-s programok stílusának módosítása a qtconfig programokkal lehetséges. Nálam a VLC és a Skype is a KDE Oxygen stílusát használja.

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.

Én megtaláltam már rá a tökéletes megoldást: Kivágtam a büdös francba a GTK-s szutykokat és mindenből Qt-set használok, ahol csak tehetem. :) Kivéve a Gimpet és az AWN-t, azok nem zavarnak.

Nagyjából én is így vagyok ezzel. KDE-t használok, plusz egykét GTK-s alkalmazást, amik kellenek. Sajnos elég sok van.

Gyakran én is hasonlóan érzek, csak ellentétes irányba. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

> 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 [...]

http://en.wikipedia.org/wiki/QtCurve

Ahogy az általad linkelt oldal első bekezdése is írja: QtCurve is a desktop theme for the GTK+ and Qt widget toolkits.
Tehát ez csak egy téma, nem egy toolkit.

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 :)

Ctrl + Alt + F1 ;)

majd az új zubuntu betűtipus megoldja! :D
egyébként minden font liberation sans 8pt-ra.