- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Én nem haragudnék érte, ha végre számításba vennék a Qt-t is.
- A hozzászóláshoz be kell jelentkezni
+1
--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- waiter -
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
Ezért van olyan csodás állapotban a KDE-s Ubuntu-One kliens...
- A hozzászóláshoz be kell jelentkezni
ne is említsd, ettől agyf@szt kapok. Frissítés után teljesen használhatatlan lett a mocsok.
- A hozzászóláshoz be kell jelentkezni
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 ...
- A hozzászóláshoz be kell jelentkezni
Amennyi szemetet betölt a ramba, +/-1 Qt nem sokat oszt-szorozz :)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Igen, az a jó a Windowsban, hogy az alkalmazásoknak olyan szép, konzisztens a felhasználói felülete... ;)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
O papikam, ha a Linux legalabb ilyet tudna produkalni, akkor mar a Dekstop Eve (tm)(r) lenne....
- A hozzászóláshoz be kell jelentkezni
Tud (ld: chrome) , csak egyelőre (szerencsére) fontosabb a programok funkciója, mint az, hogy csicsásan jelenjen meg.
- A hozzászóláshoz be kell jelentkezni
köszönjük a szakértést!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
szerintem arra gondolt, hogy gtk+qt egyszerre lesz használatban.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ha a monóra gondoltál, akkor +1.
- A hozzászóláshoz be kell jelentkezni
elírtam...
--
Dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5
- A hozzászóláshoz be kell jelentkezni
én egyetértek, csak leírtam mire gondolt Nyosigomboc.
- A hozzászóláshoz be kell jelentkezni
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 ...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 ...
- A hozzászóláshoz be kell jelentkezni
Szerintem a Gnome3-t újraírják Qt alapokon, ezért a verzióváltás! :)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.).
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ma is okosabb lettem! Köszi!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
\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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Ha jól értem azt akarja mondani, hogy a Qt alapértelmezetten nem UTF-8 kódolást használ.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
(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.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
É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"
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+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
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Hm. Köszi a felvilágosítást. Legközelebb utánaszámolok, mielőtt szövegelnék.
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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."
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Í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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 ;)!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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 hozzászóláshoz be kell jelentkezni
"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ó".
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
> 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 [...]
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
en csak azt szeretnem, ha nem foglalna el a menusor, meg a gombok a fel kepernyot :)
- A hozzászóláshoz be kell jelentkezni
Ctrl + Alt + F1 ;)
- A hozzászóláshoz be kell jelentkezni
majd az új zubuntu betűtipus megoldja! :D
egyébként minden font liberation sans 8pt-ra.
- A hozzászóláshoz be kell jelentkezni