Neduhy GNOME (a GTK) (diskuse)

[Ilfirin]

Dobrý, dávám +

[Lu-Tze]

Já ne, takový blogísek dokáže napsat každý, Jardá Šmídů by se neměl rozptylovat od psaní jxpcommanderu...

[Ilfirin]

Chudák, ani blog mu nedopřeješ

[Luk]

JXP Commander je mrtvý

[Jardík]

JXPCommander mrtvý není, jednou ho dodělám. Jen čekám na implementaci ListView a stabilizování API u widgetů ve WDE. Rozhodl jsem se ho použít místo pomalého GTK (i když JXP chtěl commander pro GTK). Do té doby nemá smysl začít něco psát.

[Luk]

To bylo jen rýpnutí, já jsem na tom s free-SW projekty podobně, hlavně ale kvůli nedostatku času a nálady (incron a inotify-cxx mají v BTS mnoho nevyřešených reportů, LWTT má už nějakou dobu novou verzi, ale zatím jsem ji nevydal)

Jinak je samozřejmě dobře, že bude JXPCommande postaven na něčem lepším místo na obludného GTK.

[Deleted [8409]]

Ja bych to spis nazval "lehci"

[happy barney]

a čo tak to nechať na userovi, aby sa rozhodol, či chce "obludné GTK+", "ten QT moloch", či niečo "úžasne iné a rovnako nefunkčné" ?

[Luk]

Každý uživatel ať si používá, co chce. Já prostě GTK+ nemám rád, to je vše. Pokud dělám nějakou aplikaci, volím něco jiného - například onen "Qt moloch" nebo (rovněž některými lidmi neoblíbený) Swing v Javě.

[Deleted [8409]]

Ja s Vama i souhlasim

Dival jsem se do pomerne hodne GUI knihoven, a mam pocit ze nejkvalitnejsi kod je v Qt, jsou tam sice i silene a blbe optimalizovane veci, ale jako celek je to kvalitni a plne integrovana knihovna. Kdyz se po chvili brouzdani v Qt podivam do Gtk+, tak si rikam, ktery blazen to vymyslel. Nemyslim to ani spatne a jsem rad, ze maji lidi moznost programovat GUI i v cistem C, ale na druhou stranu C++ vrstvy typu Gtkmm jeste vic brzdy tuto knihovnu a vysledek neni moc prijemny. Navic Gtk+ pro Windows je katastrofa.

Me osobne by se libil na ty opravdu jednodussi veci javascript s nejakou mensi GUI knihovnou (zadne Qt Gtk). Podle me by se neco takoveho vlezlo i do 1MB a neuselo by to byt vubec spatne.

Zadny flame, je to muj subjektivni nazor:)

[Luk]

Me osobne by se libil na ty opravdu jednodussi veci javascript

Proboha, jen to ne! Když vidím, co jsou schopni někteří lidé vyvádět v Javascriptu, nejradši bych ho z browserů vybrakoval.

[Deleted [8409]]

Existuji i hezke veci v javascriptu Ja jsem mel spis namysli neco opravdu rychleho, treba Tamarin, ale to uz jdu asi hodne daleko :)

[Jiří (BoodOk) Kadeřávek]

Myslíte jako, že by JXPC byl napsán ve všech toolkitech a uživatel by si vybral ten oblíbený? To je myslím docela revoluční myšlenka

[kavol]

na tom není nic revolučního, naposledy se něco takového diskutovalo pod zprávičkou o netlabáckém (jabbim) jabber klientovi ... ale než klikneš na link, ještě jednou si uvědom, v jakém kontextu ti ho dávám (pro případ že bys pak četl flame níže ...)

[Jiří (BoodOk) Kadeřávek]

Diskutovat o tom možná revoluční není, ale prakticky jsem snad něco takového neviděl funkčního (nebavíme se ovšem o frontendech).

[happy barney]

Revolučná ani nie, viacero projektov som už podobným spôsobom videl napísaných (libka callbackov + zobrazovacia aplikácia).

[Deleted [8409]]

Jenze toolkit je neco mnohem vic nez par callback funkci. Napriklad udelat toolkit, ktery vyuzije kompletni moznosti Qt a Gtk+ je podle me nemozne. Druha vec je ta, ze kazda vrstva zere pamet i rychlost. KAzda vrstva navic omezuje funkcnost veci, ktere nejsou v te druhe knihovne implementovane, takze se musi budto emulovat nebo nepodporovat.

Ja osobne nevim, proc by si vsichni chteli vybirat, v jakem toolkitu je aplikace napsana, to je proste vec programatora, v cem umi psat nejlip. Prece je nesmysl porad dokola prepisovat uz hotove aplikace pro ten a ten toolkit no ne? Takze otazka spis pro programatora zni, jaky toolkit pouzit pro "novou" aplikaci.

[Josef Kufner]

Ale né. Oddělením GUI od logiky programu přece nemusíš implementovat žádnou mezivrstvu, natož další toolkit. Prostě napíšeš jádro programu, které nebude nijak vázané na použitý toolkit, a které bude mít jasně definované API. Tohle API bude jednak mít pár funkcí pro spouštění nějakých akcí či pro získávání/upravování dat a jednak bude umět zaregistrovat callbacky pro oznamování událostí zpět do GUI. Takže budeš mít dvě vrstvy, které budou zcela oddělené. A pak můžeš klidně GUI zkompilovat zvlášť a přilinkovat až po spuštění třeba pomocí dlopen().

[Deleted [8409]]

No v pripade jednoho "okna" a jednoho "tlacitka" by to urcite slo:) Ale jsou aplikace, kde to proste nejde. Zkuste treba popremyslet jak by se udelal takovy KDevelop pro Qt a Gtk+ zaroven (nebo KOffice).

Toolkit v pravem slova smyslu by mohl byt treba Fltk, opravdu se stara jen o GUI, ale gnihovny jako Gtk+ nebo Qt jsou hotove frameworky, ktere obsahuji i kontejnery a tridy (struktury), ktere nejsou primo svazane s GUI (viz glib, QtCore). Jak chcete udelat napriklad mezivrstvu nad GString a QString, nad kontejnery? To je extremne slozite a nedivim se, kdyz programator proste sahne po hotovem reseni a pouzije ho se vsim vsudy (takze treba jen Gtk+, jen Qt, ...)

Aplikace, ktere maji pluginove rozhrani nad Gtk+ a Qt je strasne malo a jeste hure se vyviji

[happy barney]

Nakódiť medzivrstvu, niekde na trištvte cesty medzi podmnožinou a nadmnožinou. Najprv tučnú, postupne prispôsobovať jednotlivú implementáciu widgetset-om.

Jednoduchý spôsob tvorby dialógov a bindovania callbackov, ideálne XML. A user si len nastaví (napr) export WIDGETSET=gtk+.

[Deleted [8409]]

Teorie je to krasna, ale z praktickeho hlediska by to jako desktopu takovemu vubec nic neprineslo a pro programatora by to byla dalsi mega knihovna navic:). Ja osobne chci radeji nativni Qt nebo Gtk+ aplikaci, nez nejaky wrapper a myslim ze to je postoj vetsiny.

A ten callback by vypadal jak? Jste schopen zarucit v mezivrstve treba introspekci a dalsi vyhody konkretnich toolkitu?

[happy barney]

pre programátora by to nebola knižnica naviac. On by ju totiž nepoužíval len by písal callbacky a definoval dialógy. Prečo by sa napr programátor mal trápiť s nejakými pozíciami tlačítiek či inputov? nech to robí designer.

Príkladom nech sú ajaxoidné weby, tiež majú multiwidgetového molocha (firefox, opera, ie), jednotný komunikačný protokol (http) a na programovacom jazyku nezávislý systmém callbackov.

[Deleted [8409]]

Ono AJAX muzete pouzivat i ted a staci vam www prohlizec Na slozitejsi alikace se da pouzit toolkit. Ja jsem to odzacatku myslel tak, ze kazda mezivrstva mezi aplikaci a GUI je jen omezujici:)

[J. M.]

No, když zmiňuješ pomalé GTK+, tak proč jsi jej nezmínil jako bod v tomto blogovém zápisu? To je přece základní věc, která celé GNOME (negativně) ovlivňuje, ty věci co jsi zmínil v tom výčtu, oproti tomu vypadají jako maličkosti. Pro mě je to dokonce důvod č. 1, proč GNOME nepoužívám.

[Josef Kufner]

Jo ty menu jsou děsná věc, ale ono to tak trošku souvisí s tím, že combobox, menu a treeview jsou v Gtk vlastně totéž.

[Josef Kufner]

Což mě tak napadá,... nechcete někdo napsat patch do gtk, aby výška položky menu byla minimálně na výšku ikonky v menu? tedy na to co vrátí gtk_icon_size_lookup(GTK_ICON_SIZE_MENU, ...). Tím by se to mělo vyřešit a případy s většíma ikonkama by nic neponičily.

[J. M.]

Není to taky důvod, proč jsou menu v GTK+ tak pomalá? Mám na mysli to, že pouhé otevření ať comboboxu nebo kontextového menu (vyvolané stiskem pravého tlačítka) sežere v GTK+ 5-10krát víc výkonu procesoru než u jiných toolkitů, jako např. Qt 3 (bohužel už nikoli Qt 4),a je to i pouhým okem vidět, jak se tomu nechce.

[Josef Kufner]

Jo, je to možný. Ten model co pod tím je, je celkem obludná věc, ale tohle spíš může za pomalost prakticky všech seznamů. V Gtk jsou všechno tohle prolinkované seznamy a navíc jen jednosměrně. To už samo o sobě je neefektivní. Obyčejné pole tam chybí (je tam jen strom a seznam), což se velmi negativně dotkne prakticky všeho, co má aplikace zobrazovat. A psát si model na každou věc je dosti zdlouhavé.

Pomalost menu bych svedl spíš na to, že při každém zobrazení se vytváří nechutně velké množství objektů. Pro každou položku se vytváří jednak položka, pak i textový popisek a obrázek a to všecko se do sebe ještě balí a přepočítávají se rozměry. Když k tomu má ještě aplikace překreslit co bylo pod právě zmizelém menu o kousek vedle, tak už je to sakra znát.

IMHO by bylo nejlepší dát dohromady novou knihovnu, která by vyhovovala moderním požadavkům, odstranila všechny neduhy, které současné knihovny mají a přitom byla implementována co nejefektivněji a nejjednodušeji to jde. Možná by to ani nemusel být toolkit jako ty současné. Prostě vzít něco, co by řešilo UI celkově a ne jen jednotlivé čudlíky.

[Luk]

Vnitřek GTK sice neznám, ale jestli je to opravdu tak (ty seznamy atd.), tak potěš koště. Ještě bude někdo vyprávět, jak je ten toolkit skvělý?

MHO by bylo nejlepší dát dohromady novou knihovnu, která by vyhovovala moderním požadavkům, odstranila všechny neduhy, které současné knihovny mají a přitom byla implementována co nejefektivněji a nejjednodušeji to jde. Možná by to ani nemusel být toolkit jako ty současné. Prostě vzít něco, co by řešilo UI celkově a ne jen jednotlivé čudlíky.

No, takových knihoven už je docela hodně a trpí různými neduhy. Proč? Protože se snaží o přenositelnost a tak se porůznu napasovávají jak na X, tak na Win32. Výsledkem jsou kompromisy a problémy, protože každé prostředí je naprosto odlišné.

Možná by nebylo od věci udělat to úplně od základu, tedy změnit celý X Window System a jeho protokol, aby byl efektivnější a kompatibilnější s Wokny. Koncepce X je poplatná době vzniku a dnes je situace dost odlišná, takže by šlo postupovat jinak.

[freshmouse]

Ještě bude někdo vyprávět, jak je ten toolkit skvělý?

Že je GTK skvělé, moc často neslýchám. Druhou věcí je, že lidi (i já) spíš tvrdí, že aplikace v GTK jsou dobré.

[thingie]

No nevím o čem mluvíte. Pokud jde o modely pro tyhle zobrazovací widgety, lze si naimplementovat jaké chcete. GTK+ obsahuje jeden na stromy a jeden který je vnitřně řešen seznamem. Na menu o deseti položkách to je celkem jedno. Pokud by na tom záleželo (hodně náhodných přístupů, třeba), pak je samozřejmě nutné napsat si vlastní, jinak to prostě bude pomalé, protože seznam. Není to tak hrozné, glib nabízí víceméně všechny potřebné datové struktury.

[Josef Kufner]

Jo, naimplementovat si to můžeš jak chceš, ale jde o to, že jsou v základní nabídce jen dva, které se hodí pro zlomek věcí. Minimálně to pole by se tam sakra hodilo. A co si budem namlouvat... programátoři jsou líní a mnohdy je prostě jednoduší použít něco připraveného i za cenu, že to bude pomalejší.

[thingie]

Asi jak kde. Každopádně tohle je myslím část GTK+ se kterou mají lidi nejvíc problémy (ono je to taky v C dost, no, změť nejmíň). Takže se asi oprávněně dá čekat, že s tím bude v hůře psaných programech nejvíc problémů.

[Josef Kufner]

To jo, ale rozhodně by tam měl být aspoň jeden model, který by umožnil efektivní libovolný přístup a nikoli jen sekvenční procházení.

[Vinicius]

Ani C++ interface na tyhle veci neni uplne nejlepsi. Nejvic mi ale na GTK+ vadi pomerne malo funkcemi vybaveny GUI designer - GLADE 2 - presunout komponentu z jednoho kontejneru do druheho je "nadlidsky" ukol. A Glade 3 mi zatim dusledne a uporne pada.

[Josef Kufner]

Zkoušel jsi ctrl+x, ctrl+v ?

[Fëannatar]

Pokud padá, tak není od věci napsat bug report, místo stěžování si v diskusi pod blogem...

[eee]

Ano, jak klidne, ja GTK na rozdil od tebe znam . S cim mas problem? Jenom bych rad podotknul, ze GTK je napsano v C, takze zadne objekty ve skutecnosti nema. Ale i kdyby melo, tak je naprosto v poradku, ze polozka menu se sklada z ikonky a labelu, co je na tom spatneho?

[Luk]

Jenom bych rad podotknul, ze GTK je napsano v C, takze zadne objekty ve skutecnosti nema.

Kdo mluvil o objektech? Já určitě ne. Kromě toho se objekty emulují, takže by to stejně nebylo úplně mimo mísu.

Ale i kdyby melo, tak je naprosto v poradku, ze polozka menu se sklada z ikonky a labelu, co je na tom spatneho?

Řekl jsem snad, že ne?

Každopádně trvám na tom, že GTK+ je pomalá obluda, ať už je to uvnitř uděláno jakkoli.

[J. M.]

Samozřejmě, že GTK+ má objekty. Je to objektový toolkit, celé je to založené na GObject. To, že jsou ty objekty napsané v jazyce C, na tom nic nemění.

[Jiří (BoodOk) Kadeřávek]

A čo vy si, Kefalín, pod tymi objektmi predstavujete (ve skutecnosti totiz procesor zadne objekty nema

[Heron]

freshmouse z toho padl, že tu nemá komentář?

[freshmouse]

Kecy.

Já se těšil na pořádný výčet neduhů, ale tohle jsou malé problémky. I jako milovník GNOME bych našel závažnější a horší věci, stejně jako by milovníci KDE našli na KDE závažnější a horší věci.

[hugis]

No neviem ako kto, ale ja mám emblémy vľavo dole, presne tam kde ich chcem mať.

[Fëannatar]

Eh? Mě to opravdu přijde jako blbosti... Proč měnit ikonu adresáře mi uniká, pro snadnější rozlišení jsou emblémy. Položky menu mám všechny stejně vysoké a je jedno, jestli je tam ikona, checkbox, radiobutton nebo nic. Emblémy se tuším někde nastavit dají, kde se budou zobrazovat, nicméně standardní pořadí je od pravého horního rohu po směru hodinových ručiček... Já osobně je mám radši nahoře, dole mi lezou do textu. A co se týče pomalého menu... tak mě se normálně otevře a zobrazí, akorát chvilku trvá, než se zobrazí ikony, pak už si je nacachuje a pokud má člověk dost paměti, tak to pak chodí jako blesk. Nevím, proč plejtvat s pamětí už při startu, když do většiny podmenu se člověk stejně nepodívá. Navíc, linux není windows, a vydrží běžet bezproblémově bez restartu třeba měsíc, takže těch pár sekund po startu není zase až tolik...

[Jardík]

Já nevím, co všichni máte proti tomu vypínání. Já třeba počítač vypínám a zapínám v průměru 4x denně. Každý totiž nepotřebuje platit za pro nic spotřebovanou elektřinu.

[Heron]

Pravda, potřebuje platit za zničený HW.

[Fëannatar]

Když u něj celý den sedím... Navíc mám notebook, ten zase tolik nežere... A když už jsem si za jeho spotřebu na koleji zaplatil (a doma to tvoří zanedbatelnou položku, vzhledem ke zbytku domácnosti), tak nevidím důvod ho vypínat ani na noc... Jinými slovy, vypínám ho pouze když s ním někam cestuju a restart provádím de-facto akorát při upgradu kernelu...

[maník]

Moc pěkná logika. Když už platíte ten kolejní paušál, nechcte celý den téct také vodu, co říkáte?

[Fëannatar]

Vodu nepoužívám přes noc jako ftp server (z venku se ale na něj nedostanete). Jinak původně to bylo míněno spíše jako nadsázka

[Robo]

Ja ho tiez vypinam ale iba ako suspend/hibernate.

[Josef Kufner]

Pokud máš font větší než ikonku, tak se ta chyba neprojevuje. Pokud menší, tak je to děsný.

[Fëannatar]

Mám font menší než ikonku a ta chyba se neprojevuje ani tak.

[Josef Kufner]

Tak v tom případě to máš rozbitý a ta chyba ti nefunguje.

[Fëannatar]

[freshmouse]

ad 1) Souhlasím.

ad 2) Souhlasím.

ad 3) Nastavuje si je téma ikon (dle zkušeností). Já je třeba mám vlevo dole.

ad 4) Buď jsem to nepochopil, nebo jsem se s tím ještě nesetkal.

ad 5) Souhlasím.

Celkově mi to ale přijde jen jako lamentování nad ikonami, ne jako pořádný souhrn neduhů GNOME... Jsou to malé problémy -- a snadno řešitelné. Jsou oznámeny v bugzille?

Že GNOME musí být co nejjednodušší, je lež, a pakliže je pro idioty, proč ti vadí jeho chyby, když nejsi idiot?

"Kdybyste náhodou někdo přišel na to, jak v nautilovi změnit ikonu adresáře tak, aby se brala z tématu, tak mi dejte vědět." -- A odkud se podle tebe bere, když ne z tématu?

[eee]

To menu s ruzne vysokymi polozkami chci videt, pouzivam vyhradne gnome a nic takoveho jsem nepozoroval . Na ikony je nejlepsi pouzivat vektorovy svg format, pak se jejich velikost meni plynule bez rozmazavani. Kdo pouziva prehistroricke bitmapy si nic jineho ani nezaslouzi .

[Josef Kufner]

Kuk.

[Fëannatar]

Co to je? Takhle staře vypadající GTK jsem už dlouho neviděl... Mimo jiné... velikost položek menu se nastavuje v gtkrc použitého tématu...

gtk-icon-sizes="panel-foobar=20,20:panel-menu=22,22:gtk-dnd=32,32:gtk-menu=16,16:gtk-large-toolbar=24,24:gtk-small-toolbar=18,18:gtk-button=20,20:gtk-dialog=48,48"

je to ta položka gtk-menu.

Ale stejně mě zajímá... to je co za verzi gtk, co je na tom screenshotu?

Ale koukaje na ten screenshot mi to nedalo a začal jsem se trochu vrtat ve všech aplikacích, co jsem měl puštené a skutečně se mi jeden podobný případ povedlo najít - tedy dvě položky vedle sebe, jedna s ikonou, jedna bez - a skutečně mají jinou výšku, ale liší se v mém případě o 1 px, což není téměř poznat. Lépe řečeno, je to poznat, pouze pokud jsou derektně vedle sebe...

[Fëannatar]

Hm... tak jsem se v tom trošku šťoural a zkusil jsem nastavit velikost položek menu na 18x18 a skutečně. Položky s ikonami se zvětší, zbytek zůstane stejný. Máte pravdu. Zajímavé ale je, že menu, co mám v panelu, tímto neduhem netrpí...

[Josef Kufner]

Je to okno vytvořené v Glade 2 a verze Gtk je 2.10. Neboj, nic stařičkého

A to ještě buď rád, že ten screenshot nebyl celý, protože okna mají dekorace z Windows 3.1.

[Jardík]

Tak to ještě neznáš nautilus. To jsem také zkoušel. On to SVG vyrenderuje v 48x48 a pak ho stejně zmenší, tekže je stejně rozmazaný.