Portál AbcLinuxu, 30. dubna 2025 10:46
Jo, můžeš si buď zmenšit písmo všude, nebo nikde.Řekl jsem: "Písmo lze změnit jako v ostatních GTK aplikacích, příp. pouze v Pidginu (přes nějaký modul...)."
ale ať to neintegrujou takovým způsobem, že bez Geditu pidgina nenainstal횎e někdy před pěti lety byla v OpenSUSE nebo obdobném výrobku závislost Geditu na Totemu, to není chyba Pidginu... Pidgin se skládá ze tří částí balíčků: pidgin, pidgin-data a libpurple, přičemž tyto nezávisí na ničem mimořádném: standardních knihovnách C, D-Busu, knihovnách X, knihovnách GTK...
GTK není špatné, ale přiznejme si, ty gňoumí registry jsou hodně velká neunixová prasárna, stejně jako třeba .kde/share/apps/najdisisvůjkonfigurákvbludišti. Konfiguráky by měly být čitelné, přehledné a oddělené.Ale fuj, Martine... Nechci tu pomilionté vysvětlovat GConf, takže jen ve zkratce. Databáze GConf je strukturovaná do adresářů. Jedná se o prostý text ve formátu XML. To je všechno "unixové" -- až na XML, nicméně kdy vznikly Unixy? Sedmdesátá léta? Nechtěl bych se tam zaseknout. Samotný GConf je démon -- což je unixovější než cokoli jiného. A teď benefity. Standardní databáze s nastavením. Přítup k této databázi pomocí jednoduchého API (zkus si třeba ze skriptu měnit nějaký konfigurák ve stylu "veličina=hodnota" -- jsem si jistý, že to bude těžší než měnit databázi GConfu). Jednotlivá nastavení je možné vynucovat, či zakázat editovat. Správce může jednoduše všem uživatelům něco nastavit -- vynikající pro správu více účtů. Konfiguráky pracovních prostředí jsou mi nicméně ukradené -- uživatel je má editovat pomocí oken, dialogů atd. Mimochodem, slyšel jsem, že třeba Solaris má nějakou konfiguraci v binární podobě, přičemž binárka se generuje z textového konfiguráku. (Ale nevím, co je na tom pavdy.) Tak kde je "unixovost" teď? A ještě bych chtěl upozornit na několik věcí: a) GTK nijak nezávisí na GConf, b) GConf nijak nezávisí na GNOME.
Přítup k této databázi pomocí jednoduchého API (zkus si třeba ze skriptu měnit nějaký konfigurák ve stylu "veličina=hodnota" -- jsem si jistý, že to bude těžší než měnit databázi GConfu).Vsadíme se? Varuju Tě, znám regulární výrazy :o) Napsat část kódu, která načítá a ukládá jeden textový soubor je skutečně trivivalita.
Správce může jednoduše všem uživatelům něco nastavit -- vynikající pro správu více účtů.Mno, slyšel jsem o jednom adresáři zvaném /etc a taky o staré dobré svobodě - kromě systémových omezení nemá správce do toho, jestli mám v GNOME na pozadí lišku nebo medvěda, moc co žvatlat. Stejně by mne zajímalo, jak správce může všem uživatelům pomocí GConfu zakázat používat motiv vzhledu Human. Nemá každý uživatel vlastní GConf databázi?
Konfiguráky pracovních prostředí jsou mi nicméně ukradené -- uživatel je má editovat pomocí oken, dialogů atd.Eh? Možná na Windows (a čím dál víc na OS X), ale tady nejsi v Kansasu, Dorotko. Pokud Linusovi někdo taky řekl, že něco jako uživatel "má editovat pomocí oken", ani se nedivím, že se rozčiloval :o) Jinými slovy existuje tady nějaká historie, nějaká kultura, úroveň aplikací, a kdo ji porušuje, ten je na 99% prasátko.
Mimochodem, slyšel jsem, že třeba Solaris má nějakou konfiguraci v binární podobě, přičemž binárka se generuje z textového konfiguráku. (Ale nevím, co je na tom pavdy.) Tak kde je "unixovost" teď?Jak jinak odpovědět na citaci než citací?
Ostatně, to, jak se chová nějaký jiný standard, je k této diskusi naprosto irelevantní. To je argument typu "A vy zase bijete černochy!".
Megadatabáze všech konfiguráků rozhodně není unixová - a to má jak KDE, tak tady kolega GConf.Databáze je velká dle toho, kolik je v ní dat, ne? Ty používáš nějaké VůbecNicWM, které má zdroják na čtyři řádky v Cčku, tak se nediv, že je tzv. "nenáročné".
XML je jenom další módní výstřelekTo byl i Fortran, C nebo Unicode.
citelně lepší jsou konfiguráky, které si přečteš i bez parseru.Jak lze přečíst, upravit a zapsat bez toho, abys ta data zpracoval? :-O
Vsadíme se? Varuju Tě, znám regulární výrazy :o) Napsat část kódu, která načítá a ukládá jeden textový soubor je skutečně trivivalita.Vsadíme. Ty změníš tapetu v KDE a já v GNOME, dobrá?
Mno, slyšel jsem o jednom adresáři zvaném /etc a taky o staré dobré svobodě - kromě systémových omezení nemá správce do toho, jestli mám v GNOME na pozadí lišku nebo medvěda, moc co žvatlat. Stejně by mne zajímalo, jak správce může všem uživatelům pomocí GConfu zakázat používat motiv vzhledu Human. Nemá každý uživatel vlastní GConf databázi?Jak v /etc vytvoříš uživatelské profily pracovního prostředí? Jak zakážeš uživatelům ukončovat webový prohlížeč (např. na veřejném počítači s internetem)? Co by uživatel nemohl kecat do vzhledu? Co když třeba tvoří výchozí profil (a profilů je víc)?
Eh? Možná na Windows (a čím dál víc na OS X), ale tady nejsi v Kansasu, Dorotko. Pokud Linusovi někdo taky řekl, že něco jako uživatel "má editovat pomocí oken", ani se nedivím, že se rozčiloval :o) Jinými slovy existuje tady nějaká historie, nějaká kultura, úroveň aplikací, a kdo ji porušuje, ten je na 99% prasátko.Linux je standardně ovládán pomocí příkazové řádky. Ne všem to vyhovovalo, a tak vznikla pracovní prostředí s úkolem dát uživateli okna -- to je historie a kultura.
Linux je standardně ovládán pomocí příkazové řádky. Ne všem to vyhovovalo, a tak vznikla pracovní prostředí s úkolem dát uživateli okna -- to je historie a kultura.Nejde o to, jestli to vyhovovalo někomu, ale o to, jestli to vyhovuje k dané činnosti. Každý kdo se pokoušel o nějaké editace fotek z terminálu nejspíše uzná, že v gimpu je to poněkud pohodlnější...
Napsat část kódu, která načítá a ukládá jeden textový soubor je skutečně trivivalitaA proč bys to psal!? Proč psát duplicitní kód, přidělávat si práci, riskovat, že v něm uděláš chybu, když už před tebou někdo napsat standardní ASI pro přístup k nastavení? Taky si můžeš napsat třeba program, který si bude svoje dokumenty ukládat rovnou na /dev/hda místo aby pracoval se soubory, ale proč bys to dělal, když tu máme souborové systémy? Za ideální považuji, když má každý program svůj XMl soubor s definovaným DTD/Schématem - pak jde s každým konfigurákem pracovat spolehlivě a standardním způsobem. Vyšším vývojovým stupněm může být jednotné API společné různým programům (GConf), ale tam se asi bude narážet na problém s přílišnou obecností (přecejen tam asi nepůjde udělat všechno, co s DTDčkem/Schématem napsaným na míru danému programu)...
x + 2 = 5
v ruce, proč raději nepoužít kalkulačku. Vždyť ona je rovněž méně náchylná udělat chybu, než já! Nebo možná ještě lepší řešení by bylo nasázet to do nějakého toho programu, co řeší rovnice sám, spolehlivě a standardním způsobem.
(...)
Až si GConf přéstane hrát na Windows Registry a začne produkovat konfiguráky, které jsou snadno dohledatelné, zdokumentované (myšleno přímo v textu, ne v nějaké roletce ve Visual Studiu) a lidmi čitelné (čekal bych něco jako "~/.pidgin/pidgin.conf"), tak mne vzbuďte.
Až budeš někdy potřebovat znaky konců řádků, diakritiku a zvlášní znaky (které se escapují), tak zjistíš, že ani obyčejné přiřazení klíč=hodnota není tak triviální, jak se na první pohled zdá. Pak si můžeš psát vlastní mechanismus, kde tohle všechno ošetříšPrávě při práci tímto stylem člověk nejlépe zjistí, jak moc je GConf nebo obdobný systém potřeba. Vidím to tak, že člověk si píše vlastní systém, ten se pak začne GConfu blížit a nakonec se to zahodí s tím, že se použije rovnou GConf.
colour=red;
na
colour=green;
opravdu nezvládnu. A kdybych to vážně udělal špatně, tak mne slušný program seřve :o)
Otevřel sis někdy ten konfigurační soubor? Neřekl bych, Ty to vždycky jen edituješ tím vaším GJedinýmSprávnýmANejvalidnějšíXMLGenerujícímVelmiKlikacímEditorem, ne? Jak říkám, chtělo by i to i dokumentaci mimo roletky.
<entry name="uris" mtime="1207148449" type="list" ltype="string">
Kvalitka. Komentáře kde nic, tu nic. Víc viz ~/.gconf/apps/virt-manager, ale nevěřím, že si to v tom texťáku otevřeš...
Mno, vim zatím neměl problém soubory korektně otevírat a dokonce i ukládat, měl jsem-li na to právo. Tak nevím, který editor používáš, co to správně nedělá? Nějaký GNOMácký?Já ale mluvil o tom skriptu, jak jsme se vsadili. Ta sázka mimochodem trvá. Už bys mi měl kupovat medaili...
Otevřel sis někdy ten konfigurační soubor? Neřekl bych, Ty to vždycky jen edituješ tím vaším GJedinýmSprávnýmANejvalidnějšíXMLGenerujícímVelmiKlikacímEditorem, ne? Jak říkám, chtělo by i to i dokumentaci mimo roletky.Otevřel. A mimochodem, existuje i editor v CLI, nejen v GUI. Ty jsi ovšem nějak zapomněl pracovat s nástrojem tím stylem, jakým ten nástroj vyžaduje. Možná jsi ani nechtěl. Když budu držet kladivo jako tužku, bude se mi dobře pracovat, nebo řeknu, že to kladivo je špatné?
<entry name="uris" mtime="1207148449" type="list" ltype="string"> Kvalitka. Komentáře kde nic, tu nic. Víc viz ~/.gconf/apps/virt-manager, ale nevěřím, že si to v tom texťáku otevřeš...Asi ti to tvůj regulární výraz ve vimu ve spolupráci s nejnenáročnějším správcem oken na světě nějak pomotal, jinak bys dodal i zbytek toho pole... Takhle jsi jenom vzal kus textu, asi doufajíc, že to ostatním bude připadat složité, a tak to označí za špatné a tím pádem s tebou budou souhlasit, což je tak trošku demagogie... Kdo GConfu rozumí a zároveň to (z nějakého zvláštního důvodu) chce editovat ručně, tomu jsou všechny atributy toho prvku jasné. Já ale bohužel musím konstatovat, že ty tomu nerozumíš (což ti nevyčítám -- vyčítám ti to, že to zároveň haníš). Já zas nerozumím tvému správci oken, co startuje dřív než ho spustíš, a tak ho nekritizuju.
Za ideální považuji, když má každý program svůj XMl soubor s definovaným DTD/Schématem - pak jde s každým konfigurákem pracovat spolehlivě a standardním způsobem. Vyšším vývojovým stupněm může být jednotné API společné různým programům (GConf), ale tam se asi bude narážet na problém s přílišnou obecností (přecejen tam asi nepůjde udělat všechno, co s DTDčkem/Schématem napsaným na míru danému programu)...V GConfu má aplikace (nebo knihovna) tolik XML souborů, kolik potřebuje. To se hodí třeba (ale nejen) modulárním nebo hodně rozsáhlým aplikacím. Přitom je ale vše tříděno do adresářů (aplikace nebo knihovna tedy má spíš adresář než soubor). Nemyslím, že by byl GConf příliš obecný. Pokud neděláš něco extra speciálního, tak ti stačí klasická dvojice klíče a hodnoty, přičemž hodnoty mají různé jednoduché (např. číslo nebo řetězec) nebo složené (pole) typy, což je ve většině případů to, co je potřeba. Co se týče hodnoty jako takové: sice neexistuje (na úrovni GConfu) kontrola hodnoty (dejme tomu ve smyslu DBC), ale ani to moc není potřeba. Aplikace si to kontrolují samy, a pokud by někdo upravoval databázi GConfu ručně a chtěl kontrolu obejít, tak by ji obešel, takže by byla k ničemu. Podle mě je to takhle v pořádku.
Mě se na pidginovi nelíbí jeho velké okna,Co?
příliš málo nastavení různých vychytávekZkus přídavné moduly.
obrovský, místem plýtvající kontakt list.Lze to nastavit, a to i v běžném menu (např. lze skrýt ikonky).
No okno zmenšit můžu za roh, horší je že těch 30px velký tab (možná trochu přeháním) tam zůstane a tucet dalších podobných prvků (možná zase přeháním) taky.Hmm. Karta je široká podle toho, kolik jich v okně je (jedna zabírá 100 % šířky okna, dvě 50 %, tři 33 % atd.). Vysoká je podle textu. Podrobné informace pod kartou lze vypnout -- ve standardním nastavení.
Přídavné moduly? ty má kopete taky a i bez nich vypadá k světuJá mimo telepatického režimu nepoužívám žádné a nic mi nechybí. To je ale jedno. Důležité je to opovržení vůči modularitě. Proč?
Ubunťáci mohou stahovat např. z Get Deb.A proč ještě není v oficiálním repositáři?
Protože v oficiálním repozitáři (pro Ubuntu 7.10)Používám Hardyho.
je Pidgin řady 2.2.A právě to mě štve. Pokud nezařadí Pidgina 2.4.1 do Hardyho než oficiálně vyjde(o čemž pochybuji, jelikož na začátku byla každá nová verze v repositáři do jednoho dne, ale čím více se oficiální vydání blíží tím více se prodlužuje nebo úplně zastavuje vydávání nových verzí programů do oficiálního repositáře), tak zase budu muset čekat půl roku a nebo používat zase vývojovou verzi Ubuntu.
(A doufám, že to není provokace.)Určitě ne, jen se rozčiluju nad tím proč, když mají už balíček zkompilovaný a připravený, ho prostě nestrčí do oficiálního repositáře a je pokoj. Zlatý portage.
Určitě ne, jen se rozčiluju nad tím proč, když mají už balíček zkompilovaný a připravený, ho prostě nestrčí do oficiálního repositáře a je pokoj. Zlatý portage.Protože v každém vývojovém cyklu se udělá tlustá čára, kdy už se nové balíky nepřidávají a jen se testuje, jestli všechno funguje správně, opravují se chyby atd. Kdyby se stále dál přidávaly balíky, dopadlo by to jen špatně. V Hardym je 2.4.0 a pokud 2.4.1 je čistě opravná verze, tak tu šanci dostat se tam má. Uvidíme.
Přiznejme si, že balíky z Get-Deb nejsou přímo od těch vývojářů, a pochybuju, že se jejich tvorbě věnuje taková péče.Já rozděluji programy do dvou skupin: jedeto/nejdeto. A v Linuxu(resp. GNU nebo OS systémech) vše zpravidla funguje a pokud ne, tak je to výjimka potvrzující pravidlo, která musí být co nejdříve nahlášena/opravena aby pravidlo fungovalo.
Protože v každém vývojovém cyklu se udělá tlustá čára, kdy už se nové balíky nepřidávají a jen se testuje, jestli všechno funguje správně, opravují se chyby atd. Kdyby se stále dál přidávaly balíky, dopadlo by to jen špatně.Ok, sám vím co je to "život na staveništi", takže to jen schvaluji. Ale z toho důvodu byly v portage zavedeny maskované balíčky.
V Hardym je 2.4.0 a pokud 2.4.1 je čistě opravná verze, tak tu šanci dostat se tam má. Uvidíme.Tak zrovna v tomto případě jo. Ale co kdyby tento bug/featura byla opravena/přidána v 2.5.X. Zase bych musel čekat půl roku nebo "žít na staveništi", jako v případě jádra.
(gtk_accel_path "<main>/Conversation/Close" "Escape")Pokud je zakomentovaná, tak stačí odkomentovat
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.