GTK+ toolkitet fog használni a Google Chrome linuxos portja

Internet, Közösségi média

Az OSNews egyik cikke szerint most már eldöntött tény, hogy a Google nemrég köztudatba berobbant böngészőjének linuxos portja a GTK+ toolkitet fogja használni. A Google megígérte, hogy lesz linuxos és OS X-es portja is a Chrome-nak, de közben kiderült, hogy kicsit nehezebb lesz a munka, mint amire először számítottak.

Ben Goodger, a Google Chrome felhasználói felületének fejlesztéséért felelős vezető egy, a Google Groups-ba postázott levelében beszél arról, hogy miért nem járják az egyszerűbb utat, fogják a Qt-t és dolgoznak azzal. Az OSNews cikke itt olvasható. Az OSNews cikk megemlíti azt is, hogy a Google reményei szerint valamikor júniusra várható a linuxos és az OS X-es Chrome.

( golgota | 2009. 02. 18., sze – 19:36 )

GTK+ ....nyihahaha.....lesznek itt még gondok....jó sokan :)

( Csigaa | 2009. 02. 18., sze – 20:02 )

Nevetséges.
A levél információtartalma nulla.
Hablatyol róla hogy nem akarnak Windows felületet OSX-re (érthető), de a GTK-t nem magyarázza meg.
Linuxon nincs industry standard GUI toolkit, ahogy standard ablakkezelő/desktop sem. Azon kívül hogy a Linux programozóik GNOME-t használnak, és ezért GTK-t akarnak maguknak, semmivel nem támasztja alá a választását - ezzel a hozzáállással a Linuxos változat feltehetően kizárólag pl. Fedorán fog elindulni, és kizárólag RPM formában jön, mert épp azt látta a fejlesztő amikor írta... A Google-től azért nem ezt vártam, főleg a Google Earth után.

"The reason many people are having problems is because google earth for linux is actually just a google earth for windows that uses wine technology to run on linux. so if you are having problems with the app then you could go see www.winehq.com they have a pretty good faq page."

http://www.hermann-uwe.de/blog/google-earth-for-linux--beta

********************
http://holo-media.hu
http://holo-media.hu/wordpress

Fáj az igazság, s ezért leszólsz? Inkább elismernéd, hogy hülyeséget írtál, s meghúzódnál.

Sosem volt ilyen kiadás. Csak össze lehetett hekkelni a wine-nal a wines verziót. Én is próbáltam anno, de iszonyat lassú volt és szétcsúsztak a betűk, magyarul használhatatlan volt nekem.

Azt írják, azért nem Qt-t használnak Windows-on (és OS X-en se fognak), hogy tökéletesen illeszkedjen a rendszerbe (aminek amúgy erősen ellentmond a minden más alkalmazástól eltérő kinézetével). Namármost Linuxon GNOME-ba egy GTK-s, KDE-be pedig egy KDE-s alkalmazás illeszkedik tökéletesen, egy plain Qt-s pedig nagyjából, tehát ezen az elven minimum egy GTK-s és egy Qt-s, és esetleg egy KDE-s (azaz: a Qt-n felül a KDE-specifikus rendszereket is használó) változatot kéne csinálniuk.

Az más kérdés, hogy KDE-n kevéssé érdekel a Chrome, ott lesz a QtWebKit-es Konqueror, plain Qt-sek pedig az Arora.

én gtkstyle ( http://labs.trolltech.com/page/Projects/Styles/GtkStyle ) nevü cuccot használom xfce alatt, qt4-es progik átveszik gtk felületet, priman müködik (krusader, gwenview, k3b, kdenlive, amarok2, dolphin...) , egyszer sem volt problemam vele, gyakorlatilag nem lehet észre venni a különbséget...ajánlom figyelmedbe...

szerk: ubuntu-hoz csomag: http://ubuntuforums.org/showthread.php?t=834784

Nem igazán értem, hogy jön ide a Gnome meg a KDE. Vagy arra gondoltál, hogy olyat választottak, ami a legelterjedtebb asztali környezetben képes "natívan" megjelenni?

Egyrészt akkor nagyot tévedtek, ha a pillanatnyi erőviszonyok alapján döntöttek, hiszen a KDE második helyre szorulása csak a 3.x -> 4.x váltás miatti ideiglenes állapot. Egy éven belül a KDE4 stabilizálódik, és akkor lenyomja a Gnome-ot mint a rajzszöget, hosszú évekre.

Másrészt a Qt-hoz készül olyan style (vagy téma vagy mi), amivel a GTK+ alapú desktop környezetekbe képes (lesz) beleolvadni.

Harmadrészt a Qt technológiailag kissé odaver a GTK+-nak...

(szerk: formázás)

Ennek azért szerintem oka az ubuntu nagy elterjedtsége is. Meg ugye qt-s de-ből csak egyféle van, gtk-sból több, így nagyobb csoportot tud lefedni.

Én amúgy úgy olvastam, hogy azért sem qt, mert azt nem tudják annyira átszabni. Lehet, hogy én vagyok idióta, de szeretem, ha a programok egységes kinézetűek. Úgyhogy nekem végülis mindegy, hogy gtk vagy qt, úgyse fogom használni. :)

Ami a levél 0 információtartalmát illeti, abban igazad van, meg én se örülök a GTK-nak. De éppen a GoogleEarth-al példálózni, a legrosszabb Qt-s program, amit valaha láttam Linuxon. A legújabb béta már felveszi a rendszerszíneket (KDE 3.5 alatt használom), de bár ne tenné, ahogy kinéz. És akkor még a karakterek megjelenéséről ne is beszéljünk. Ehhez képest az ff3 kultúráltan illeszkedik a KDE desktopba.

Konkrétan 3 komoly DE van és 5-6 disztró.

Ami azt illeti, a Vistából is van vagy 6 verzió, bár azt csak a lehúzás miatt csinálják. Inkább tényleg az a gond, hogy miért választ valaki gtk-t, amikor Qt4-et is lehet. KDE4 fut (vagy legalábbis szeretnék) Win alatt is. Az olyan KDE4-Qt4 appok, mint a Digikam, Amarok már futnak Win, OSX alatt, akkor meg a Google-nál miről beszélnek?

azért választ, amiért valaki más meg mondjuk fltk-t. Mindegyik másnak tetszik felhazsnálói/fejlesztői szempontból…

Ja meg van már buildjük Winre, és OSX-re is natívat csinálnak… Most gányoljanak a két platformon Qt-vel, mikor van a felülethez natív toolkit? Arról most nem is szólva, hogy gtk is van win illetve osx alá…

Szerintem írják meg csak linuxra, és futtassák bundled virtuális gépben… Duh. :D

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

GNOME-nak van egy rakás saját szolgáltatása, amitől a GNOME alkalmazások függnek (pl. gconfd), viszont XFCE-n külön be kell tölteni ha ilyet indítasz, mert az XFCE cuccai nem használják.

Egy "GUI platform" nem csak a widget toolkitből áll, hanem a toolkit, saját service-k, és felülettervezési irányelvek. Ebből pedig nem csak 3-4 van, mint GUI toolkitből.

Az XFCE-nek, mint platformnak is vannak saját szolgáltatásai, vagy egy XFCE alkalmazás abban különbözik egy GNOME alkalmazástól, hogy csak GTK-t használ? Egy tisztán GTK alkalmazás nem illeszkedik megfelelően a GNOME-ba? (Lehet, hogy nem, ekkor ott is beszélhetünk külön GTK és GNOME alkalmazásokról, mint ahogy Qt és KDE alkalmazásokról; az utóbbi oldalt jobban ismerem.) Milyen további DE-kre gondolsz, amik a widget toolkiten felül saját szolgáltatásokat nyújtanak, és fontos, hogy egy alkalmazás ezeket használja?

( wwrreecckk | 2009. 02. 18., sze – 21:56 )

Klafa, akkor itt is fél óra lesz, mire feljön egy printer lista remote cups esetén, mint a firefoxban...
google chrome... gratulálok...

Szerintem nem, mert qt alatt azonnal megkapom azt a listát, amit a cupsos gtk-print-backenddel, minimum 50s, de a megjelenő nyomtató akkor se választható ki.

Nálam nincs local cups szerver, csak remote fut /etc/cups/client.conf-ban szabályozva.
De igazad van, tök offtopic a dolog...

( golgota | 2009. 02. 19., cs – 08:55 )

A GTK+ maga csak egy widget set, semmi több. Úgyhogy majd jól meg kell kavarni egy kis fontrenderinggel (pango?), egy kis 2d megjelenítéssel (cairo?), plusz egy csomó dologgal.
Olyan lesz mint a Gnome. Egymilliárd lib-től függ majd, miket majd véletlenszerűen választanak ki. Lesz így milliárd dependency rendesen. A legtöbb rendszerre majd jön egy 60 megás statikusan linkelt verzió, hogy működjön is tök lassan, hibás html rendering-gel. Aztán majd lesz a dinamikusan linkelt, ami gyakran össze-össze fossa majd magát attól, hogy idő közben ezt azt javítottak az aktuális libekben.
Ha a Chrome GTK-s lesz, akkor jó lesz ha adnak hozzá egy saját OS-t is ami össze van csiszolva. Mert hogy használhatatlan lesz különben az tuti.
Olvasgatva a HTML5-öt (video tag, meg ilyenek) elkondolkodtam rajta, hogy még annál is gányoltabb lesz majd, mint amit egy HTMl4 esetén kénytelen elszenvedni az ember, ha nem egy platformot (Qt), hanem csak egy widget készletet használnak fel.
A GTK nem sokban különbözik egy FLTK-tól. A widget az csak widget.

Félreértés ne esék. A GTK, mint widget készlet elég jó. De csak az. Amellé még ezer másik dolgot kell integrálni, hogy működjön is a progi. A Qt ezzel szemben egy platform a média kezelésétől a hálózat kezeléséig mindennel.

És nem kellene keverni a Qt-t a KDE-vel. A KDE a QT-re ÉPÜL és nem azonos vele. Ugyanúgy, ahogy a Gnome is egy jó kis widgetset-re épül, de nem azonos a GTK-val!!!

Olybá' tűnik, hogy a GTK+ alapból dependel ezekre, szóval nem tudom, hogy miért gáz az, ha több kisebb csomag a függősége, mintha egy nagyobb, amelyből esetleg messze nem használ ki mindent.

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

rendben van ezekre dependál alapból:atk, cairo, pango, glib. Na most ezekkel semmit nem lehet kezdeni, azon kívül, hogy megjelenítesz egy gombot, vagy egy legördülő listát, stb.
Ennél azért egy bömgészőhöz kicsit több minden kell. Valamilyen image lib, backend data lib, stb, stb. Ezért mondtam, hogy a chrome-hoz majd összeszednek valamit, ami vagy lesz a rendszerekhez vagy nem. Vagy fogják és szépen maga alá pakolja a libeket, hogy ne legyen gond ha nincs a rendszerben valami. Lesz egy /chrome/lib amibe bele lesz hányva valahogy minden. És ezzel el is veszítettük a Linux architektúra előnyét.
Nem akarom túlmagyarázni, hogy egy widget készletnek mennyi hátránya van egy platformhoz/framework-höz képest és hogy eetleg mennyi előnye (kis grafikus alkalmazásokhoz kivállóak a widget set-ek). Ez olyan, mintha a windowsban a gombkirakás mellett nem lehetne használni a winapi-t (vagy mit, én nem igazán értek a winhez). A .Net is egy egész framework és nem "csak" egy widget készlet (bár a .Net-hez se értek, majd valaki kijavít).

Én nem a GTK+-t szidtam, hanem azt mondtam, hogy a GTK+ mellé majd jól összegányolnak valamit a google-nél. És hogy nem kellene keverni a GTK+-t a Gnome-al, a Qt-t meg a KDE-vel.

Én többé kevésbbé meg vagyok elégedve a GTK+-al mint widget set-tel. Az más kérdés, hogy mi a véleményem a Gnome-ról.

Hint: ha Qt-s lenne, akkor is bele lenne hanyva a /chrome/lib ala a qt, es annak osszes fuggosege. Marpedig a Qt-nek is van fuggosege, jocskan.

Kulonben meg nezd meg a firefox-ot, pontosan mire dependal. Pont annyi kell egy gtk-s bongeszonek.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

lásd a fenti hozzászólásomat.
Ki beszét itt arról, hogy egy vagy sok kis lib-ből áll e valami?
A lényeg, hogy egy framework-öt használ e valaki ami jól össze van csiszolva, vagy sok kis lib-et, amiből csak néhány van összecsiszolva, a többit meg megírja, vagy egzotikus lib-eket használ, vagy a legelterjettebbeket. Aztán ha valamelyikben változás történik, lehet cserélni a hozzá kapcsolódó dolgokat.
Nézd nekem tök mindegy, hogy a google milyen fejlesztési modelt használ. Én nem ezt a módszert használnám és kész. Ettől még lehet hogy a terméküket is fogom használni.
Ugyanakkor elrettentő példa lehet pl. a Gnome. És megint nem arra célzok, hogy használhatatlan lenne, vagy nem működne. Pusztán a csilivili möggötti dolgokra gondolok. És hogy mennyi munka és reszelés van vele amiatt, hogy nem egy tisztességes framework-öt használnak. De mint mondtam, semmi bajom a gnome-mal. Éppen most is azt használom. Vannak benne hülyeségek, de ez van és kész.

"Ki beszét itt arról, hogy egy vagy sok kis lib-ből áll e valami?"
Te.

De hogyha pl. _csak_ egy widget lib-re volt szükségük, akkor miért kellene egy full framework-öt használniuk? Felteszem elég sok elég okos ember dolgozik ott ahhoz, hogy el tudják dönteni, hogy mire van szükségük...

ha igazad lenne, akkor a komolyabb gtk-s appok (inkscape, abiword, gnumeric, pdf nézők, minden ami mást is megjelenít mint gtk) mind lépten-nyomon maguk alá csinálnának.

Én ezt csak a KDE programoktól láttam (a stabil kiadásokban), ergo valamit csak tudhatnak azok a gtk-s fiúk;)

A hibás html renderinget meg nemtom miért is hoztad fel, hiszen a motort éppen hogy ők írják meg… felteszem feltolnak pár diffet a webkitgtk-ba, és csókolom;) a webkitgtk meg nekem jobban bejön, mint a qt-s (nem, ennek semmi köze nincs ahhoz, hogy nochdazu az arora nem kezeli rendesen a qtgtk motort)

A függőség mint olyan ismert dolog linuxban. Az általad ecsetelt probléák kb. mindenre igazak, ami dependál más libre… 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( hans1985 | 2009. 02. 19., cs – 17:20 )

+1 GTK
________________________________
blog: horvathjanos.wordpress.com

( marcabru | 2009. 02. 19., cs – 20:40 )

Eddig általában csak a GTK/QT vita technikai oldalát említettétek, vagyis a programozó és az alkalmazást csomagoló szempontját, és így lehet, hogy nehezen védhető meg, hogy miért a GTK toolkitet választották.

Ha viszont a felhasználói élmény szemszögéből nézzük a kérdést, akkor a Google Chrome minimalista UI-ja sokkal jobban illik a Gnome szintén minimalista környezetébe. Nem tudom, miért alakult így, de a QT alkalmazásokba valahogy több menüpont, több eszköztárgomb, több testreszabási lehetőség került, míg a GTK/Gnome alatt a "Normális alapértelmezés" (?) (sane defaults) elve érvényesült: ne legyen állítható, legyen eleve jó.

Namost, ha van a Google-nak egy windowsos böngészője, ami menü és eszköztár nélkül, minimális kezelőfelülettel "alkalmazásként" jeleníti meg a weboldalakat, akkor joggal feltételezhetik, hogy ezt a böngészőt a GTK/Gnome közösség fogja többre értékelni. Hiszen akik KDE-t használnak, elvárnák, hogy összevissza testreszabható legyen a felület, és folyton olyasmik miatt panaszkodnának, hogy hogyan lehet az eszköztárat szerkeszteni, meg milyen skinek vannak hozzá.

Példaként megemlítem, hogy QT alá ott az Opera, jellemző módon szöges ellentéte a Google Chrome UI-jának: tele menüponttal, oldalsávval, MDI + tabok összevisszasággal, skinekkel, gadgetekkel, beépített levelezővel, és tucatnyi beállításablakkal.

Az UI elrendezést és funkciókat nem a toolkit/framework határozza meg, az hogy a GNOME túl keveset vagy a KDE túl sokat tud, nem lehet szempont az ezektől független alap függvénykönyvtárak kiválasztásánál.

A GNOME pedig nem "eleve jó", hanem egy egybeöntött műanyag autóüléshez hasonílt, amit 160 cm-es sovány testalkatú emberekre terveztek - a felhasználók egy részének tökéletes, másik részének viszont nagyon kényelmetlen és/vagy teljesen használhatatlan. Ez marad a lehető legrosszabb tervezési szemlélet, amíg a sorozatklónozás nem válik általánossá...

Az UI elrendezést és funkciókat nem a toolkit/framework határozza meg

Ezt direkt leírtam az elején. Viszont érdemes az alkalmazás kinézetét-viselkedését a legapróbb részletekig a célközönség elvárásaihoz igazítani. És ehhez még mindig az a legmegfelelőbb megoldás, ha GTK-t (vagy ellenkező esetben QT-t) használunk, hiszen a QT-GTK közti tökéletes vizuális megfelelésre való eszközök (QGTKSyle, stb) még messze nem stabilak (azaz neked lehet, hogy működnek, a stabil, támogatott disztrókban még nincsenek benne). A QT Cleanlooks témája meg nagyon nem illeszkedik a Gnome környezetbe.

A GNOME pedig nem "eleve jó", hanem egy egybeöntött műanyag autóüléshez hasonílt

Én nem foglaltam állást a KDE/Gnome terméketlen vitában. Ezért írtam, hogy KDE mellé proprietary böngészőnek ott az (egyébként nagyszerű) Opera, ők más felhasználókat céloznak meg, más böngészőt írtak, és más UI-t terveztek.

( gee v | 2009. 02. 19., cs – 20:46 )

Mit értenek az alatt, hogy: "miért nem járják az egyszerűbb utat, fogják a Qt-t és dolgoznak azzal"?

Engem nem zavar egyébként, hogy GTK+ lesz, több okból:

1, úgyse használok Chrome-ot :-)
2, GTK-s a firefox is, mégse néz ki rosszul. OK, a cancel gomb rossz helyen van, meg ostoba primitív a file requester, de kb. ez minden. Ennél jobban zavar, hogy nem integrálódik a KDE-be, és ha mondjuk egy fájlt letöltök, akkor nem tudja, hogy milyen programmal kéne megnyitni... de ebből a szempontból egy Qt-s firefox se lenne jobb, gondolom, csak egy KDE-s.
Persze nézhet ki valami ocsmányul is, mint mondjuk a gnucash, de az nem a Qt/GTK eltérés miatt csúf

"OK, a cancel gomb rossz helyen van"

Hogy érted? Hogy fordítva van az okéval? Aztatat .gtkrc-vel át lehet nyomni, ha jól emlékszek. Már csak annál az alkalmazásnál amelyik támogatja, ami ha jól emlékszek csak a Gimp (?). :-))))

gtk-alternative-button-order=1

ez köll a .gtkrc-2.0-ba. Talán a FF3 is támogattya azóta.

---
;-(

( gabor v | 2009. 02. 19., cs – 22:11 )

Apro erdekesseg: egyetlen kiveletellel (Amarok) a HOVD 2008 szavazasokon GTK-s programok nyertek: Pidgin, Thunderbird, Firefox, Gnome, Gimp, Eclipse. (Mar ahol persze volt ertelme ennek a kerdesnek.)

Eppen az Amarok az egyetlen QT-s program amit szinte naponta hasznalok. Valamint, kb. az Amarok az egyetlen alkalmazas ami naponta egyszer-ketszer eldobja a kanalat, vagy elkezd hulyesegeket csinalni. De lehet, hogy ez utobbi veletlen, persze.

A Thunderbird és a Firefox akkor is vezetett, mikor még közük nem volt a GTK-hoz. A Gnome népszerűségének köze lehet a KDE4 kezdeti népszerűtlenségéhez. A Gimpnek eleve nincs ellenfele.
Az Amarok atomstabil. Nem tudom, te mit csináltál. Talán használj valami rendes asztalkörnyezetet (KDE 3.5.10) ;).

Az Amarok atomstabil. Nem tudom, te mit csináltál. Talán használj valami rendes asztalkörnyezetet

Hat minden relativ, ugye. Van amikor harom napig is elfut. De altalaban azert nem. Olyan aprosagokrol, mint a last.fm-hez valo kapcsolodaskor hasznalt busy-waiting mar inkabb nem is ejtek szot.

Azt nem gondolod komolyan, hogy a zenelejatszo miatt lecserelem a fel rendszeremet?

Worksforme (arch, kdemod, amarok2). Sőt, amióta amarokot használok (5 év körül), nem találkoztam az instabilitásával (kivétel akkor, amikor túl sok instabil CFLAGS-sel használtam a Gentoo-t, de az user error).

"PHP's coding style pulls common elements from C++, Java, PERL, Python, BASIC, Assembly, Dragonspeak, and Microsoft Office Excel."

JuK-ot kell hasznalni. Igaz, dependal a fel KDE-re, cserebe atomstabil, tobb napos uptime utan is jol megy (oke, van neha egy kis hibernalas is, na es?). Persze nem tud minden szines-szagos feature-t mint az Amarok, de zenet lejatszani, azt nagyon tud.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.