Poďme zlepšiť/opraviť mc bindings!

10.12.2005 19:23 | Přečteno: 2685× | poslední úprava: 24.7.2008 18:13

Zdravím Vás,

všimli ste si niekto, aký sú defaultné bindings pre prezeranie súborov v Midnight Commanderovi neúplné, zastaralé či nezvládajúce české/slovenské prostredie? Nebolo by dobré, keby hneď po inštalácií ponúkal čo najviac možností?

Mne to vadí dosť a tak som sa rozhodol pre nasledujúci projekt. Pokúsim sa, spolu s Vami, dať dokopy čo najkompletnejší súbor bindings, ktorý bude následne ponúknutý vývojarom mc, čoby novinka (bindings.cs.example).

Pomôžete? Na úvod pár poznámok:

• zamerajte sa na View= (Open= nie je imho príliš dôležité)
• ak je to možné, v komentári zadajte i možné alternatívy
• ideálne je umožniť otvorenie súbor v konzoli i v X

Návrh:

# RTF document
regex/\.(rtf|RTF|Rtf)$                                                                          
        View=%view{ascii} unrtf --html %f | lynx -dump -stdin

# Microsoft Word document                                                                  
regex/\.([Dd]o[ct]|DO[CT]|[Ww]ri|WRI)$                                                     
        View=%view{ascii} antiword -m 8859-2.txt %f &
#       View=%view{ascii} catdoc -x %f || word2x -f text %f - || strings %f

# Microsoft Excel spreadsheet
regex/\.([Xx]l[sw]|XL[SW])$                                                                                                              
        View=%view{ascii} xls2csv %f || strings %f
#       View=%view{ascii} xlhtml %f | lynx -dump -stdin
#       View=%view{ascii} xlhtml %f | elinks -dump

# Microsoft PowerPoint presentation
regex/\.([Pp][Pp][sStT])$
        View=%view{ascii} ppthtml %f | cstocs utf8 il2 - | lynx -stdin -dump
#       View=%view{ascii} catppt %f

# MS Word 'swap' file
regex/^~WRL.*\.tmp$
        View=%view{ascii} catdoc %f

# OpenOffice.org Writer document
regex/\.(sxw|stw|sxc|stc|sxi|sti|sxd|std|sxm|sxg)$                                         
        View=%view unzip -p %f content.xml | o3totxt | cstocs utf8 il2 - 

# PDF                                                                                      
type/^PDF                                                                                                                                               
        View=%view{ascii} pdftotext -enc Latin2 %f 2>/dev/null - || strings %f

# HTML document
type/^HTML
        View=%view{ascii} lynx -dump -force_html %f

# cacaview supported images
regex/\.(jpg|JPG|Jpg|jpeg|PNG|png|gif|GIF|[Tt][Ii][Ff][Ff]{0,1}|[Bb][Mm][Pp])$
        View=DISPLAY="" cacaview %f

# .ico icon
regex/\.(ico|ICO)$
        Open=pho %f >/dev/null 2>/dev/null &
        View=%view{ascii} identify %f
#       View=%view{ascii} file %f

# video file
include/video
        View=%view avinfo %f

# DVD (vob) movie
regex/\.(vob|VOB|Vob)$
        Open=(mplayer dvd:// -dvd-device %d -channels 6 >/dev/null 2>&1 %f &)

# mid(i) file
regex/\.(midi?|MIDI?|Midi?|rmid?|RMID?|Rmid?|kar|KAR)$                                                               
        View=%view{ascii} midic -jf %f

# macromedia flash video
regex/\.(swf|SWF)$
        View=%view{ascii} swfdump %f | grep "^\[HEADER\]"

# ogm container
regex/\.(ogm|OGM|Ogm)$
        Open=mplayer %f
        View=%view{ascii} ogminfo %s

# disk image
regex/\.(iso|ISO|img|IMG|bin|BIN)$
        Open=%cd %f#iso9660
        View=%view{ascii} disktype %f

# mp3 audio file
regex/\.(mp3|MP3|Mp3)$
        Open=mocp -c; mocp -a %f;mocp -p;mocp;rm ~/.moc/last_directory
#       View=%view{ascii} mpg123 -vtn1 %f 2>&1 | sed -n '/^Title/,/^Comment/p;/^MPEG/,/^Audio/p'
        View=%view{ascii} mp3info -x %f

# Waveform audio file
regex/\.(wav|WAV|Wav|snd|SND|Snd|voc|VOC|Voc|au|AU|Au)$
       View=%view{ascii} sox %f -e stat 2>&1
       Open=play %f

# show space occupied by a directory
directory/*
        Edit=%view du -s --si %p

# pdb document
regex/\.([pP][dD][bB])$ View=%view{ascii} txt2pdbdoc -d %f | iconv -f cp1250 -t latin2

# vcf - electronic business card
regex/\.(vcf|VCF)$
        View=%view sed -e "s/^BEGIN:VCARD.*/***/" %f | grep '^FN:\|^EMAIL;\|^TEL\|^\*\*\*\|^ADR\|^BDAY\|^X-ICQ\|^X-JABBER\|^X-MSN\|^X-YAHOO' | iconv -f utf-8 -t latin2

# Default target for anything not described above
default/*
        View=%view cstocs $(enc=$(enca -s %f);if [ $enc = "???" ]; then enc="il2";fi;echo $enc) il2 %f &
        Edit=vim %f

Rád tento súbor doplním na základe Vašich komentárov. Nezabudnite aj nejaké to info do CREDITS

       

Komentáře

[Spike]

No, přece tady nebudu pastovat celý defaultní soubor bindings z Gentoo...

Já si doplnil zatím jen regex/\.(mkv|MKV|Mkv)$ Include=video

A to channels 6 u mplayeru je hodně pitomé, to ať si snad každý nastaví v mplayer.conf.

[jose17]

nemyslím si, že u každého video (audio) súboru je nutné/vhodné zapínať 6 kanálový zvuk..

[David Watzke]

Jsou lidé, kteří 6 kanálů nemají, víš?

[Luboš Doležel (Doli)]

Ano, někteří mají ještě víc (já bohužel jen 6)

[Lukáš Zapletal]

Když už se točí u mc, dost mě štve, že při diskových operacích s mnoha soubory je mc děsně pomalý, a to jen a jen díky tomu, že se musí minionkrát aktualizovat obrazovka (progress bar). IMHO by se to mohlo překreslovat každý desátý soubor (chce to asi důkladnější rozbor)...

[Luk]

Zrovna jsem dneska potřeboval přetáhnout 30GB soubor přes síť. Dal jsem to kopírovat přes MC, ale jelo to hóóódně pomalu (3 MB/s na nezatížené 100Mb síti je bídný výsledek), a MC navíc žral skoro 100 % výkonu. Tak jsem to típl a zkopíroval z příkazové řádky. Totéž hromadné mazání souborů, tam se mi to zdá pomalejší až o několik řádů.

[jose17]

nie je to náhdou nastavením Počítať súčty v konfigurácií mc?

[Luk]

To nevím, mohu to zkusit. Mám MC v defaultním nastavení, takže bych očekával, že tam žádné záludnosti nebudou.

[Zdeněk Burda]

Nekopírovals to náhodou přes ssh v mc? To je strašnej paskvil a jel lepší použít normální scp z příkazového řádku.

[Luk]

Nekopíroval. Kopíroval jsem přes FTP. Pokud kopíruji řádkovým FTP klientem, blíží se rychlost teoretickému maximu pro 100BASE-Tx, kdežto s MC je na třetině až čtvrtině.

[Libor Klepac]

a to jeste v kazdem smeru jinak pomale ....akorat ted nevim jak ..ale proste, kdyz kopirujes z A na B a mc mas pustene na A, tak je to jinak rychle, nez kdyz to mc mas pustene na B on to v jednom pripade jeste kopiruje do nejake cache, nebo nejakou takovou ukrutnost dela... no to je zase veta, ale ....

[Josef Kufner]

Já bych byl nejradši, kdyby mc žádný svoje bindings neměl. Ať používá jen věci okolo mailcap...

[mimi.vx]

OpenOffice pouziva take .od? pripony .... neboli opnedocument

[Miloslav Ponkrác]

Trochu off topic: Bylo by pěkné, kdyby mc byl také pro Windows. Mohl bych pak pod Linuxem a Windows používat jeden souborový manažer. Moc by se mi to líbilo.

A jen tak mimochodem, jedna z věcí, která se mi na Windows opravdu líbí je, že není potřeba žádné bindings.

[David Watzke]

To by asi nešlo, ne? Nebo snad ve Windows je něco jako NCurses?

[JP]

Ano, pod CygWinem NCurses existují a existuje i port mc pro Windows + CygWin. Nezkoušel jsem, ale použitelné by to být mohlo.

[Miloslav Ponkrác]

Ano, existuje jeden port mc pro Windows, který kdosi kdysi udělal. Ale je to jenom nějaká stará verze několik let, nikdo se o to dál nestará. A navíc dost ořezaná, spousta věcí z mc v tom portu pro Windows není. Tedy v podstatě jako kdyby ten port neexistoval. Sice použitelné na nejzákladnější věci to je, ale to bych musel být masochista, abych to ve Windows používal. Už jsem jí dávno zkoušel, takže vím co píšu.

A pokud seriózně, tak prosím žádné CygWin porty! CygWin port něčeho pod Windows mě vždycky vytočí. Vždycky je na takovém programu poznat, že je to jenom šidítko, napůl emulované.

[Miloslav Ponkrác]

Samozřejmě, že existuje ncurses i pro Windows. Ve Windows je toho naportováno daleko více, než si vůbec dokážete představit. Jediné, co tomu brání je fakt, že programátoři mc neumí psát dostatečně portabilně.

To mimo jiné byl dlouhý problém i databáze PosttgreSQL před několika lety. Nakonec autoři PostgreSQL se pochlapili a zlepšili i verzi pro Windows.

To samé problém Apache, který nebyl ve Windows moc optimální, ale dnes už je to dobré.

Snad skoro všechno, co se mi líbí v Unixech jde i na Windows, tak proč ne mc? A věřte, není to problém knihoven, vše potřebné už naportováno do Windows je.

[D-Evil]

Pod Windows jsou potřeba taky, jenže s tim Microsoft počítal a zavedl je system-wide (a nazval asociacema). Software si pak při instalaci sám zadá svoje záznamy (a při odinstalaci je zapomene smazat :))

Mimochodem o něco podobnýho se tušim snaží i KDE (ale nevim, do jaký míry to funguje a jak to ostatní programy respektujou).

[Miloslav Ponkrác]

Abych se přiznal, tak co se mi opravdu hrubě nelíbí na Linuxu je, že KDE se tváří jako svět sám o sobě a definuje věci, které by měly být definovány na úrovni celého systému a být k dispozici celému systému. Takže zavádění asociací na úrovni KDE považuji za hrubou chybu návrhu systému, to jen tak mimochodem.

Osobně se domnívám, že řešení asociací ála Windows je dobré řešení. Každý program v systému pak ví, co má se kterým souborem dělat, jaké akce s tím jdou provádět, jaké programy použít a je to definované pouze jednou! Není potřeba to jednou definovat pro mc, pak znovu pro něco jiného, apod.. Fuj!

[D-Evil]

S tim celkem souhlasim, nicméně pokud člověk používá pouze KDE aplikace, je konkrétně v tomhle případě rozdíl minimální.

[Miloslav Ponkrác]

Jenomže mc není KDE aplikace a přesto by asociace velmi dobře využila. Dokonce si dovolím tvrdit, že souborový manažer je jedno z nejlepších využití asociací, budou-li v systému. Přesto to nepůjde, protože nijaký neznaboh definoval asociace pouze na určité vrstvě - tedy na KDE namísto toho, aby to definoval pro celý systém.

Abych se přiznal, snahu definovat spoustu věcí na úrovni KDE tam, kde by se to mělo definovat spíše pro celý systém pozoruji už dlouho a divím se, že někdo s autoritou nebouchne pěstí do stolu a neřekne dost. No, asi jsem se nechal trochu unést emocemi, ale považuji výše uvedenou věc za jednu z výrazných mínusů Linuxu.

[VícNežNic]

On už možná i nějaký návrh takové věci (třeba u freedesktop.org) je (a pokud ne, určitě v dohledné době vznikne), ale dost pochybuju, že se to kdy dostane až na úroveň mc.

[Miloslav Ponkrác]

Já to řeknu natvrdo. Linuxu by vůbec neškodila nějaká standardizace, sjednocení základních věcí v systému tak, aby to každá distribuce neřešila po svém, stejně tak, jako aby systémové věci neřešila grafická vrstva, apod..

Vždyť je to až k pláči! K zavedení asociací na úrovni celého systému by stačil jeden blbý konfigurační soubor v Linuxu! Nic víc. Je to směšně jednoduché až primitivní. Pokud bych to chtěl komfortně, vznikla by nějaká dynamická knihovna, která by četla ten konfigurák a obsahovala by komfortní API pro zjišťování informací z toho konfiguráku.

[VícNežNic]

Systémové věci… Kolik aplikací, které tvoří základ systému to potřebuje? Když se tak porozhlédnu, tak v podstatě nepoužívám žádnou aplikaci, u které bych cítil potřebu určovat nějaké asociace a když už, tak jde maximálně o nějaké políčko v nastavení, které určuje texťák na editaci čehosi.

Určitý kousek nečeho jako asociace představuje systémová proměnná EDITOR, byly i nějaké snahy o proměnnou BROWSER nebo tak nějak, teď nevím.

[Miloslav Ponkrác]

Moment, co považujete za základ systému? Abychom se domluvili.

Ale řeknu to jinak, mnohé věci zjišťuji jen tím, že je používám. Když jsem se poprvé v životě před řadou let setkal s regulárními výrazy, můj první dojem byl, že tohle bude mít zatraceně malé využití a moc programů to nevyužije. Mýlil jsem se, spočítejte si jak moc jsou regulární výrazy v Linuxu rozlezlé a kde všude je máte zašité. Takřka všude.

Stejné je to s asociacemi. Na první pohled to vypadá jako málo užitečná věc, ale pokud budou v systému, zjistíte, že naopak bude velmi málo aplikací, které je alespoň ždibíček nevyužijí.

Mám začít? Včera jsem konfiguroval webový server Apache. V konfiguračním souboru httpd.conf se nastavují asociace souborů, které se mají zobrazovat jako seznam souborů ve webovém prohlížeči. Kdyby existovala asociace souborů v systému, nemuselo by se to definovat v httpd.conf. Dokonce ve mě už delší dobu zraje plán, že napíšu modul do Apache pro Windows, který nahradí původní mod_autoindex.so a využije přímo informace o asociaci souborů s Windows. Věřím, že je to tak dobrá myšlenka, že bych ten modul mohl prosadit jako oficiální část Apache na apache.org.

O využití asociací pomocí mc se nebudeme bavit, tam je to až moc zřejmé.

Mohl bych takto pokračovat dál a dál, ale nemá to smysl. Pokud máte trochu zkušenosti s Windows, pochopíte, že asociace jsou prolezlé naprosto všude a považuji to za jeden z mála skutečně dobrých věcí ve Windows. Normálně chválím spíš Unix, ale v tomhle se musím zastat Windows.

[VícNežNic]

Možná bychom se měli spíš domluvit co se myslí těma asociacema. Já to chápu jako popis co v čem otevřít a jako takové mi to přijde použitelné pro desktopy a správce souborů a víc už nic moc.

Je v apachi soubor magic pro zjišťování co je co, to existuje i víceméně na systémové úrovni (file). V konfiguráku vidím nastavování ikonek pro dané soubory, nic jiného tam nemám. Nevyznám se v Apachi moc, tak je možné, že tam toho bude víc. Ale stále mi není jasné, k čemu asociace v Apachi.

Snažím se, ale stále mi asociace přijdou jako okrajová vlastnost, která na úrovni systému být nemusí. Možná to je tím, že s Windows mám jenom omezené zkušenosti na uživatelské úrovni a nic moc víc.

[Miloslav Ponkrác]

Ne, asociace ve Windows jsou mnohem obecnější nástroj, než jen pouhé zjišťování co v čem otevřít. Asociace pro Windows obsahují obecný popis všech akcí, které s daným souborem můžete provádět. Jako příklad dám, že třeba u mě Windows mají HTML soubory pomocí asociací definovány 3 akce:

1) akce open - otevření HTML souboru pomocí browseru 2) akce edit - editace HTML souboru pomocí vhodného HTML editoru 3) akce print - tisk HTML souboru na tiskárnu

Akcí může být definováno libovolně mnoho. Nemusí být taky definována žádná akce. Minimální jistota je v tom, že pokud mám definovánu akci open, vím, v jakém programu mám soubor otevřít. Pokud mám definováno akci edit, umím soubor i editovat a vím jak. Atd..

Kromě toho má každý typ souboru řadu doplňkových informací. Takže třeba textový popis typu souboru, ikonu, která se má zobrazit u grafických programů, různé příznaky, jak se má s takovým typem souboru zacházet. Nebo třeba vztah s příponou souboru a MIME typem. Atd., informací je samozřejmě daleko více.

Pokud se na výše uvedené podíváte, zjistíte, že máte podstatně víc informací a třeba pro Apache máte nadefinováno naprosto všechno, co je potřeba včetně té ikonky. Kromě ikonky se v Apachi definuje i textový popis typu souboru, ten byste z asociací získal též. A v Apachi se ještě nastavuje vztah mezi příponou souboru a MIME typem, to byste z asociací získal také.

[VícNežNic]

Akce vypadají pro UNIX zbytečně (možná v nějakém DE, ale to ať si řeší sami).

Nějaký ten popis souboru mohu zjistit přes file. Pak taky existuje nějaká obecná databáze MIME typů, kterou asi bude používat minimálně velký kus GNOME a určitě i něco víc.

Ale stále mě to moc nepřesvědčilo, že jde o věc, která by musela existovat na systémové úrovni. Vypadá to sice hezky jednotně, ale moc přínos z toho IMHO nebude.

[Miloslav Ponkrác]

Pořád to co navrhujete pokulhává na obě nohy. Třeba popis souboru můžete zjistit přes file, ale jen tehdy pokud ho file bude znát. Pak o tom musí vědět nějaká obecná databáze MIME. Proboha, co když můj soubor prostě nebude mít žádný MIME typ? To je osud dost velké části souborů.

Ve Windows informace o asociacích udržují shodně všechny programy. Představte si, že třeba vytvoříme nový zvukový formát, který bude komprimovat lépe, než mp3 a ogg. Ten formát nazvete třeba xxx. Uděláte tedy program, který bude s formátem xxx pracovat. Ve Windows prostě program při instalaci doplní informace o formátu xxx do asociací a všechny programy v systému to budou umět používat. Vy ovšem navrhujete řešení, které je poněkud těžkopádnější a byrokratičtější. Mít všechny informace na jednom místě je ta nejčistější věc, kterou můžete udělat. Nic lepšího neexistuje.

Systémovou úrovní se myslí jeden jediný konfigurák, který by to všechno zařídil. Jestli s tím je problém, tak prosím.

Přínos je z toho veliký, což by se ukázalo až by se to začalo používat jak se děje ve Windows. Už jsem tu vyjmenoval Apache, mc, desktop, webový browser, mail klient, program file, je vám to pořád málo?

Mě naopak pořád napadají další a další věci, kde by to šlo využít. Třeba teď jsem ukládal program do správce verzí CVS. Zrovna CVS jinak zachází s textovými soubory a jinak s binárními soubory. Pokud ukládáte binární soubor musíte to CVS říct pomocí speciálního přepínače, jinak vám ho zmrší a zničí. Dokážu si představit, že tohle by za mě udělal prográmek, který by využíval asociací, zjistil by, zda soubor je textový, nebo binární a podle toho nastavil přepínač.

Prostě skoro s každým programem, který chytnu do ruky mě napadne další využití asociací. Když mi budete ještě chvíli tvrdit, že to nemá využití, možná se postupně dostaneme třeba i na stovku aplikací

[VícNežNic]

Já si zase probírám, co tak zhruba dělám a jak by mi v tom asociace mohly pomoci. Dokonce jsem si na to pustil texťák abych si to měl kam sepsat, ale zatím to zejete prázdnotou

Já hlavně nenavrhuju řešení, já říkám, že žádné nepotřebuju. Když vytvořím zvukový formát xxx, doplním nějak podporu do mého oblíbeného přehrávače a tím všechny změny končí. K čemu mi pomůže, že GIMP teď bude vědět, že xxx je nějaký zvuk?

Použití asociací v browseru nebo mail klientu mě nenapadá při způsobu jakým je používám žádné. Samozřejmě, pak by browser spolehlivě věděl, že tohle je soubor ten a ten, který nejčastěji otvírám tím a tím a může k němu picnout líbivou ikonku. Ale to já vím taky, to mi nemusí říkat!

[Miloslav Ponkrác]

Ok, tomu rozumím, že pro něj nenacházíte využití. Rozumím i tomu, že GIMPu nejsou naprosto k ničemu informace o zvukových formátech.

Co se týká browseru, nebo mail klienta, tak browser nejnomže ví, o co jde, ale umí s tím rovnou pracovat. Kliknu na odkaz, který obsahuje nějaký soubor a browser už ví, co s tím dělat. Takže otevření třeba dokumentu z OpenOfficu provede za mě automaticky a nenutí mě, abych si soubor nejdříve ukládal, pak ho někde vyhledal a až tam ho otevřel. Jsou to drobnosti, ale potěší.

[Miloslav Ponkrác]

Teď jsem si všimnul, že pořád máte problém představit si, k čemu by mohly být asociace dobré, a napadá vás jenom desktopy a správce souborů. Já už vám navíc nabídl Apache, zkusím tedy dál. Co webový browser? Ve Windows browser běžně prohlíží různé typy souborů, na které narazí a používá k tomu asociace. Je to docela pohodlné a díky asociacím si umí poradit se všemi typy souborů, které najde na webu a jsou definovány v systému. Co mailový klient? No přeci prohlížení příloh v mailu vhodnými soubory, které otvírá pomocí informací z asociací.

A můžete přemýšlet ještě dál, brzy přijdete na to, že využití asociací je právě daleko větší, než se zdá.

Bohužel, jsem-li v Linuxu, tak neustále bůhvíkolikrát po sobě zadávám informace o typech souborů na více místech a tím dosahuji toho, že jednak jsou informace o typech souborů jen špatné a jednak je to torchu byrokratické. Logicky, když něco zadávám na deset různých míst to samé, tak to odbydu, zvláště když každý konfigurák chce po mě typy souborů v jiném formátu. Jediné řešení, které je ovšem trochu škrabání se levou rukou za pravým uchem je to, co nazývám Debianovskou cestou. Prostě napsat program, který vezme jeden konfigurák s typy souborů a automaticky vygeneruje zbývajících x dalších konfiguráků na další místa. Podobné řešení jsem u Debianu viděl několikrát pro řešení různých problémů, je to sice nalepovák a trochu dirty řešení, ale funkční.

[VícNežNic]

Hm, když to bude, bude, ale pochybuju, že já poznám rozdíl

Já si opravdu nevšiml, že by asociace zrovna byl nějaký skvělý vynález windows který by mi chyběl. Chybí jiné věci, tohle jsem pocítit nestačil.

[Miloslav Ponkrác]

Ok, budu hodně drzý. Vy tedy preferujete řešení, při kterém zapíšete naprosto ty samé informace o typech a formátech souborů na řekněme deset různých míst v Linuxu, jen je pokaždé zapíšete v jiném konfiguračním formátu? Pořád vám to nepřipadá jako rozumný důvod pro sjednocení na jedno místo do jednoho konfiguráku? Jestli ne, tak asi mluvím čínsky a pak chápu, že moje argumenty jsou liché. Prostě pokud preferujete bordel a nepřehlednost před čistým řešením, přehledností a pořádkem, pak si asi nebudeme nikdy rozumět a přesvědčuji vás marně. Spíš mám ale pocit, že kdybych navrhnul to samé, akorát bych nezmínil, že to má Windows, možná bych byl přijat lépe. Kdybych přišel s tím, že asociace jsou řekněme z VAXu, nebo ze Solarisu, věřím, že bych cítil mnohem větší vstřícnost.

Jasněže mi v Linuxu chybí spousta věcí, ale asociace jsou jedním z nich. Asociace se dokonce řeší tak často, že se v tom musel alespoň částečně udělat pořádek chca nechca. Konekonců vynález MIME typů není nic jiného, než první pokus o asociace, sice neodtažený dokonce, ale je to tu. Ta potřeba udělat v tom jednotný pořádek prostě tady je a asi je to velmi užitečná věc, když se do toho napřely síly. Bohužel MIME typu je velmi málo obecná záležitost, aby to mohlo být užitečnější i na desktopu. Prostě vynález MIME typů řešil původně jen možnosti příloh v mailech a o moc dál se nedostal.

[VícNežNic]

Jaké by to měly být informace po kterých tak hrozně toužím? Použiju občas file abych zjistil co je to za potvoru ten soubor. Občas použiju něco z GNOME (kde už obdoba asociací z Windows podle všeho docela hezky existuje), kde mi to nabídne, že ten soubor asi chci otevřít tamtím. Ale to je asi tak všechno. A tohle málo mi určitě nestojí za to abych vyhodil řešení z GNOME a magic pro file a zaváděl nějaký jednotný konfigurák. Výsledek bude určitě hezčí, ale za tu práci to nestojí. Když to někdo udělá, tak ať, ale sám to dělat nebudu a když se mě někdo zeptá, doporučím mu ať udělá něco užitečnějšího.

[D-Evil]

No lidem z KDE projektu to asi nevadí. Pokud něco potřebujou, vytvořej si to a používaj to. Ono by samozřejmě šlo tu věc navrhnout systémově, ale problém by asi byl s prosazením do mainstream distribucí. Jako samostatnej balík si to nikdo na triko nevezme, každej uživatel je drahej. Ale když se to schová do takový velký obludy a nejde to vyndat, prohlásí se to za feature a je to bez práce :)

[Miloslav Ponkrác]

Jasně, z programátorské praxe takový způsob řešení znám. Říká se tomu nalepováky a není to příliš čistá technika.

Právě to vidím jako velký problém Linuxu. NEEXISTUJE žádná cesta, jak prosadit něco dobrého do systému Linuxu.

Otázkou je, jestli tenhle bordel, kdy se v Linuxu vrší nalepovák za nalepovákem nakonec nebude brzdou Linuxu.

[Josef Kufner]

Mno, když se podívám na svůj ~/.mailcap tak to také není špatné... ale problém je v tom, že si každá aplikace používá svůj systém, místo toho, aby prostě soubor k editaci otevřela programkem edit a dál se nestarala.