Z Banshee multimediální prostředí

Hudební přehrávač Banshee už dostal podporu pro video a pro další vydání se připravuje podpora správy fotografií. ArsTechnica rozebírá vývoj a plány do budoucna.

17.7.2009 08:03 | ʚĭɞ 🍉 | Zajímavý článek

Komentáře

[Jan Grmela]

Skvělé. Takže budeme mít i na Linuxu časem programy stylu Nera, u kterých má instalačka půl giga a umí vám mimo vypalování CD uvařit kafe, přebalit dítě a automaticky vygenerovat webové stránky?

[vain]

Hehe, jj Nero je od verze k verzi něco příšernějšího, všichni co znám a používají Nero tak zásadně staré verze co třeba dostali k vypalovačce a podobně (řada 6 nebo kolik?).

[DJnero]

na PC s windows mám verzi 8, 9 se používat nedá páč odstranili funkce, který dělali nero více použitelným

[Max]

Souhlas. Šestková verze přestala být kompatibilní s SP2 v XP. Ale pak se vydala ještě nějaká oprava, takže nějaký poslední build 6 by měl fachčit. Osobně na celý nero kašlu a klientům instaluji alternativy jako ashampoo apod.
Jinak instalace 9 nera, to je na hodinu. Fakt peklo. A o odinstalaci ani nemluvě.
Zdar Max

[Martin Lebeda]

+1 

[ʚĭɞ 🍉]

Takové aplikace tady už jsou. Třeba Canola, kterou používám v MID. A vždycky je tu možnost volby, ostatně Banshee bylo vždycky podivným přehrávačem.

[qpal]

V pristi verzi Nero nabidne vlastni operacni system a o verzi pozdeji uz bude prodavan jako NeroPC a NeroNB

[frdrx]

Další důvod proč nechtít Banshee jako default v Ubuntu.

[ʚĭɞ 🍉]

Já to teď používám a je to hrozná sračka. Po dokončení přehrávání fronty se automaticky začne přehrávat kolekce, "Zastavit při dokončení" jen přes menu a jen pro přehrávanou skladbu, podivné dialogy pro import do kolekce, nelogické chování kolečka nad ikonou v upozorňovací oblasti... To si Ubuntu moc nepomáhá co do použitelnosti.

Ale znáš něco lepšího? (Pod GTK, s kolekcí,...)

[vain]

Nevím jestli dobře chápu význam pojmu kolekce, ale nesplňuje něco takového Listen?

[Lojzek]

2x jsem zkoušel teď ten novej Listen a je tam nějakej bug nebo něco, vytěžuje mi to CPU na 85 % stabilně. :( Jinak Exaile vede, taková vzpomínka na starej dobrej AmaroK ...

[vain]

Já mám Listen 0.6.2 a naštěstí v pohodě.

[ʚĭɞ 🍉]

Podle screenshotů to vypadá špicově, jenže mně se polovina těch panelů nezobrazuje --- nemám tam kolekci, ty dodatečné informace, prostě skoro nic. Jen playlist a oblíbené skladby/alba. Navíc mi to při importu kolekce na několik minut zaseklo celá X.

Jinak jsem zkoušel ještě Decibel (funguje, ale ty pro mne důležité funkce (tj. fronty, zastavení při dokončení přehrávání) nemá.

[vain]

Zkus upřesnit screen/co ti to neukazuje, mě to při Zobrazit > Plné zobrazení (nebo Ctrl+F) vypadá stejně jako na screenech. Zkus ještě když tak v tom prostředním panelu vybrat mezi možnostmi zobrazení, Kontext, Událost, Hudba atd.. mění se tam to rozložení té pravé části panelů.

[ʚĭɞ 🍉]

Příloha:

• Snímek obrazovky-Listen.png (159675 bytů)

Ten prostřední panel tam právě vůbec nemám. A vypadá to ve všech pohledech stejně.

[vain]

Podle mě je "splácnutý" mezi Právě přehráváno a Oblíbená alba, jak tam jsou ty tečky ve čtyřech sloupcích, mají tam být ve dvou, takže si myslím, že to jsou prostě dva panely hned vedle sebe a mezi nimi je splácnutý ten třetí, zkus to roztáhnout =)

[ʚĭɞ 🍉]

Aha, fakt tam jsou dvě úchytky vedle sebe!

Ale na mém XGA displeji to s mými 152 alby vypadá trošku namačkaně až nepřehledně.

[vain]

Njn, miniaturní přehrávač to zrovna není, proto taky na desktopu mám listen a na notebooku audacious =)

[ʚĭɞ 🍉]

Příloha:

• listen.png (196895 bytů)

Tak do toho "ehm-zobrazení" se to přepne vždy po aktivaci "party" pohledu.

Jinak v příloze je to namačkání.

[ʚĭɞ 🍉]

Navíc mi v tom nefunguje Scrobbler, pryč s tím.

[vain]

Taky mi jednu dobu nefungoval (moc sem to neřešil, nezakládám si na tom moc), ovšem ve verzi 0.6.2 fičí. Jakou máš verzi?

[ʚĭɞ 🍉]

Starou. Normální repo Ubuntu. Jo, vím, že existuje repo na Launchpadu.

[vain]

To je dobře, že to víš, já třeba ne Používám RPM Fusion =) Nemám páru, jaká verze může být v repo Ubuntu.

[ʚĭɞ 🍉]

0.5.6 nebo tak něco.

[vain]

Aha.. no to bylo +/- fakt ta verze, kde to prostě nefičelo, ale od updatu na 0.6.2 jede, buď počkat na novější verzi v repo nebo doinstalovat jinak... Osobně si myslím, že to je dobrý přehrávač a pokud ti na něm nic jiného už nevadí, tak vydrž na novější verzi =)

[ʚĭɞ 🍉]

Novější verze v Ubuntu? Až s KK. Nebo to repo z Launchpadu, ale deset repozitářů už začíná být moc. Uvidím, jak mi sedne Exaile, na první pohled se mi líbí víc, možná ještě Listen zkusím.

[stepo]

 Ja pouzivam Sonata+MPD :) Kazdopadne pred nedavnem jsem zkousel Exaile. Celkem se mi libilo

[frdrx]

Quod Libet. Poslouchám ho už tři roky. Je psaný v Pythonu, je rychlý perfektně zvládá velkou knihovnu, přijde mi dobře navržený se správným množstvím funkcí a pluginy a proto ho mám moc rád. Rhythmbox se poslední dobou taky vyšvihl.

[ʚĭɞ 🍉]

Rhytmbox jsem zkoušel před několika měsíci. Fakt ne-e. Ale Quod Libet se mi líbí, Exaile taky, takže se rozhodnu mezi nimi.

[Laco]

no pekne sa to zacina nabalovat.. asi sa im nezda f-spot a banshee dost pomale..

[Michal Fecko]

malo by byt 1 program = 1 funkcia/zameranie... a nie zgrupovat funkcie do programov.... :(

[ʚĭɞ 🍉]

Jeden program pro zobrazení ID3 tagu skladby, jeden program pro spuštění přehrávání skladby, jeden program pro přeskočení na další skladby, jeden program pro přeskočení na další skladbu,... ^_^

[Jan Grmela]

Ono by stačilo udělat holý program, co umí kolekce a fronty a k němu přibalit dvacet pluginů alá Firefox, ať si každý vybere, co chce používat.

[ʚĭɞ 🍉]

Ty programy pod GNOME takto dost často vypadají (konkrétně Exaile a Quod Libet určitě), ale ne že by mi to vyhovovalo... ^_^

[frdrx]

Nebo třeba Pidgin, Epiphany a Liferea. Přijde mi to ideální, udělat program se základní funkčností kterou chtějí všichni a opičárny okolo mít v pluginech.

[ʚĭɞ 🍉]

Záleží na tom, co se myslí tou základní funkčností. Třeba u hudebního přehrávače do základní funkčnosti zahrnuji funkci "zastavit přehrávání po skončení skladby". Kolik přehrávačů to umí? To si mám psát modul kvůli takové základní funkci?

[frdrx]

Nevím. Když chci přehrát jednu skladbu, nechám si zahrát jednu skladbu. Quod Libet to umí. Dokonce po jejím skončení přestane hrát.

[ʚĭɞ 🍉]

To si nerozumíme: Poslouchám album. Potřebuji odejít večeřet, valit na autobus nebo tak něco. Protože nechci skladbu přerušovat v polovině, řeknu přehrávači, aby zastavil přehrávání na konci skladby. Po skončení skladby odejdu a až se vrátím, pokračuji v přehrávání alba tam, kde jsem skončil. Výhoda je v tom, že se nemusím soustředit a pokoušet se trefit do konce skladby, přitom ale nemusím manipulovat s playlistem.

[frdrx]

To je dobrá funkce. Čas na feature request. Dodělat tohle do Quodlibetu by měla být otázkou maximálně půl hodiny práce.

[ʚĭɞ 🍉]

Zajímavé je, že to umí, co já vím, jen Amarok a blbě Banshee. Možná ještě Audacious.

[DJnero]

Banshee používám hlavně  kvůli ekvalizéru, jinak mi stačí totem.

[Martin]

Jsem staromódní, zapšklý unix-dědek, když se mi tyhle monolity nelíbí a jsem pořád zastáncem starého dobrého

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Doug McIlroy, The Art Of Unix Programming str. 12

? Nebo už je to vážně tak "out"?

[Martin]

(Ano, je mi to jasné: user-friendly, GNOME, C#, .NET, atd. Tam (a mnohde jinde) to asi není tak populární přístup. A že to tak i vypadá.)

[Ladicek]

Write programs to handle text streams, because that is a universal interface.

Jo, a proto máme tolik zhovadile kryptických chybových hlášek, šílených generátorů parserů, bezpečnostních chyb typu buffer overflow, protože všichni píšou Céčku , a hrozivých shellů, které přebírají úlohu glue jazyka, ačkoli na to nejsou stavěné. Přesně v duchu unixové filosofie. Proboha, lidi, dyť z toho děláte modlu! To vás nikdy nenapadlo se zeptat, jestli to nejde dělat líp?

[Shadow]

Však my se ptali, ale odpovědí je "ne, nejde".

[ʚĭɞ 🍉]

Hlavně psát hudební přehrávač tak, aby pracoval s proudem textu, to je jaxi úchylné.

[Martin]

Další takový.

[ʚĭɞ 🍉]

Psal jsem výše:

Jeden program pro zobrazení ID3 tagu skladby, jeden program pro spuštění přehrávání skladby, jeden program pro přeskočení na další skladby, jeden program pro přeskočení na další skladbu,... ^_^

[Martin]

Abych ale nebyl neférový a neskrýval nic před těmi slabšími. Možná ti jenom nejde angličtina, to nevadí.

Citace výše je jedním se shrnutí nejdůležitějších myšlenek celé jedné dlouhé kapitoly. Programy by měly dělat jednu věc a měly ji dělat pořádně. Měly by být navrženy tak, aby v případě potřeby v budoucnu nebránily komunikaci s dalšími programy (způsoby, které třeba autory původního programu ani nenapadly). Pokud je alespoň nějaká šance, že by to vůbec někdo chtěl dělat (existují určitě i programy, jejichž výstupy by těžko posloužily jinému programu jako vstupy a není potřeba tak zbytečně komplikovat jejich implementaci). A do třetice, pro komunikaci *mezi* nezávislými programy by měly být používány streamy textu.

Takže jde o to, co si představíš pod "pracovat s proudem textu". Pokud to, že by se přehrávači sypaly na vstup MP3ky v ASCII formátu (jak to tak vypadá), tak ti asi není pomoci, je mi líto.

[ʚĭɞ 🍉]

Možná ti jenom nejde angličtina, to nevadí.

Z čeho to vyvozuješ?

Citace výše je jedním se shrnutí nejdůležitějších myšlenek celé jedné dlouhé kapitoly.

To jsem asi nepoznal, ne?

Programy by měly dělat jednu věc a měly ji dělat pořádně.

Záleží, co si pod tím představíš. Měl by program pořádně umožňovat správu a přehrávání hudby, nebo by měl pořádně umožňovat pouze přehrávání hudby s tím, že její organizaci si nějak vyřeší uživatel, k editaci ID3 tagů bude sloužit další program, ke komunikaci s last.fm bude určen další program, pak bude ještě program sloužící ke stahování textů,...?

Takže jde o to, co si představíš pod "pracovat s proudem textu". Pokud to, že by se přehrávači sypaly na vstup MP3ky v ASCII formátu (jak to tak vypadá)...

Jak jinak?

[Martin]

Z ničeho, dělám si z tebe srandu, protože vím, že tě to nasere.

[ʚĭɞ 🍉]

Tohle není věc, která by mě nasrala. To by se muselo zabrousit do politiky/filosofie.

[Martin]

Mám na tebe sérii krátkých a jednoduchých otázek:

Proč reaguješ zrovna na něco, o čem jsem nemluvil?

Prohlížeč ti nezobrazuje tučný text?

Kdo je to to "vy"?

Proč myslíš, že "nás" nenapadlo to udělat líp? (Ovšemže napadlo. Že něco považuji za dobré neznamená, že se to nedá opravit. I když zrovna v tebou citovaném tvrzení chybu nevidím.)

Ale ať je taky nějaká legrace: navrhni řešení, které bude stejně funkční a elegantní, ale ne tak zhovadilé.

[Ladicek]

Protože to cituješ a pravděpodobně k tomu máš nějaký důvod. Zobrazuje. Všichni, kdo se ohánějí unixovou filosofií jako nedotknutelným etalonem kvalitní softwarové architektury (haha). Protože je zřejmé, že to lze, ale nikdo o tom nemluví (povinná četba: Unix-Haters Handbook ). Například pro komunikaci mezi programy zasíláním strukturovaných zpráv v přesně daném, triviálně zpracovatelném formátu (Protocol Buffers, anyone?).

Ale omlouvám se, že jsem se nechal tak unést pod dojmem z téhle diskuse a ještě jedné vedle V diskusi o multimediálním jánevímčem je to úplně mimo.

[Martin]

V pohodě, i můj sarkasmus je potřeba brát trochu s rezervou.

Neměl bys o tom posílání zpráv link na nějaké slajdy/paper nebo podobně? Aby to pomopil i imbecil jako já.

Já jsem zastánce minimalismu a jednoduchých řešení. Proto mi přijde komunikace pomocí jednoduchých rozhraní (ať už jakýchkoli) vcelku elegantní. Pokud je textový výstup programu rozumný, nevidím v tom velký problém (ale parsovat to asi není moc velká zábava). Je mi ale jasné, že v dnešním světě už může leckomu přijít komunikace pomocí ASCII streamů jako prehistorie.

[Martin]

s/pomopil/pochopil

Některé "překlepy" mi prostě hlava nebere.

[Ladicek]

Právě že mně textové rozhraní kvůli obtížnému a na chyby náchylnému zpracování i generování příliš jednoduché nepřijde. Zase je velmi univerzální a dá se nepředstavitelným způsobem přiohejbat, to je typicky unixovská výhoda Vzhledem k tomu, že rozhraní člověk/program do značné míry vždycky bude založené na textu, dokážu pochopit zobecnění textu na univerzální rozhraní, ale nemůžu s ním souhlasit.

Žádný článek na tohle téma jsem nečetl, nevím, zase nejsem tak daleko, nelíbí se mi jenom přenosový formát, když to tak řeknu Mimochodem zajímavé využití Protocol Buffers je ve Drizzle, tam to používají pro ukládání databázových schémat, to jsem vyloženě čuměl.

A ASCII skutečně je prehistorie, se 7 bity dneska nevystačí snad ani ti amíci

[Martin]

Já jako největší výhodu beru právě tu univerzálnost. A s tím zpracováním... pokud je ten výstup zasviněný, tak je to problém. Ale není to problém celého principu, je to problém toho programu. I složitý výstup se dá naformátovat přehledně a srozumitelně. Přiznávám, že roura je jednou z mých model, ale je to tak jenom proto, že mi dosud nikdo neukázal lepší přístup. A že na to unix-haters měli dost času, čtyřicet let.

[Martin]

Kdybys totiž použil něco jiného, ne tak univerzálního, tak se dostaneš zase do dalších problémů. Něco by se hodilo sem, něco jiného tam, něco jiného onam... Jestli něco nemám rád, tak jsou to speciální případy. Textové vstupy a výstupy někomu sice možná připadají jako neohrabaný zastaralý kanón. Ale je to *univerzální* kanón, který prostě funguje všude a na všechno. Snad. Protipříklad? Miluju protipříklady!

[thingie]

To je spíš otázka nástrojů. Když má člověk shell, který vypadá tak jak vypadá, připadá mu proud textu docela rozumně a univerzálně. Mohl by mít například nástroj, se kterým by mu připadal univerzální drátový formát dbusu, nebo něco. Ten taky není nijak složitý.

[ʚĭɞ 🍉]

Někde (síťový přenos v kritických uzlech) potřebuješ šetřit datový průtok, proto se hodí (a) binárky nebo (b) komprimace. Spíše to první.

[Martin]

To se obvykle řeší tak, že výstup programu před vstupem do toho úzkého hrdla nějak zpracuju a na druhé straně je zase převedu do původního formátu. To moc s problematikou textových inverfaců mezi programy příliš nesouvisí. Je to tak univerzálnější. Nemusím tak programu nebo jejímu uživateli vnucovat nějaký styl práce. Je to podobně jako se šifrovanou komunikací. Než abych nějakou formu šifrování rval do každé aplikace, můžu ji nechat využívat nějaké "externí šifrovátko", pokud to opravdu potřebuju. Nebudu tímhle způsobem zatěžovat ty, kteří to z různých důvodů nepotřebují.

[ʚĭɞ 🍉]

To je samozřejmě pravda, ale jaká může být režie té konverze v kritickém nasazení? (Chtěl jsi protipříklad, tak jsem napsal první, co mě napadlo.)

[Martin]

Mohl bych argumentovat stejně, akorát z opačné strany: i kdybych tu konverzi začlenil přímo do samotného programu, znamenala by zpoždění. Co kdybych jej potřeboval použít v kritickém prostředí, kde by to zpoždění bylo nepřípustné? Jsme v kruhu.

Prostě si nemyslím, že by tohle byl zrovna dobrý příklad problematiky, kterou tady řešíme. Mluvíme obecně o způsobech a formátech zasílání dat z výstupu jednoho programu na vstup jiného. Ale pokus se cení! Aspoň je to diskuze o něčem. Lepší než o uhniji, komunistech a podobně.

[ʚĭɞ 🍉]

Je samozřejmě nesmysl, aby ls vyhazovalo nějaký binární bastl, ale pokud jde o přenosy dat v rámci sítě (zvláště pokud jde (a) o obrovské vytížení HW nebo (b) pokud mají být klientem mobilní zařízení s pofidérním připojením), cení se každé zrychlení, každý ušetřený bajt. Proto bych tam preferoval binární formát. Jestli bude výhodnější vyhazovat to přímo z daného programu, nebo bude lepší to prohánět ještě nějakým skriptem, to nevím, spočítat to nedovedu. Ale určitě budou situace, kdy má binárka své výhody, k čemu by jinak bylo Pickle v Pythonu?

Ale pokus se cení! Aspoň je to diskuze o něčem. Lepší než o uhniji, komunistech a podobně.

Už to začínalo být stereotypní, je čas na krátkou pauzu.

[Ladicek]

Je samozřejmě nesmysl, aby ls vyhazovalo nějaký binární bastl

Ale ls -l už by mohlo. To myslím vážně.

[Ladicek]

Tak na rouře samotné nevidím žádný problém, ono posílání zpráv, sdílená paměť nebo roura jsou (na dostatečně vysoké úrovni abstrakce ) to samé. Ale text… no a ten nestačí přinejmenším na věci, které nejde textově vyjádřit, nebo je to zoufale neefektivní. Kromě třeba zvuku mne teď napadá jedna zajímavější věc: překladače.

Kdesi jsem četl o překladači, který měl asi 50 fází (ne průchodů, fází!) překladu. Výstup každé z nich by samozřejmě šlo serializovat do textu a na vstupu ten text zase analyzovat. Ale to pak každá fáze překladače kromě svojí vlastní činnosti obsahuje další malý překladač (a to předpokládám jenom několik málo podob mezikódu), což je sice úchvatně možné, ale naprosto uhozené A to nemluvím o tom, jaké chybové hlášky by takový překladač asi produkoval, kdyby se přišlo na chybu v nějaké pozdější fázi, kde už není k disposici informace o původní podobě zdrojáku (leda ji pořád tahat s sebou). Proto mají obvyklé překladače fází poměrně málo (okolo pěti), a často jsou všechny součástí jednoho programu.

[Ladicek]

Jo a ještě si vzpomínám: ukládat zdrojovou podobu programu jako text je taky špatný řešení. Zdroják by měl být AST uložený v nějaké databázi I to myslím (částečně) vážně, třeba kluci od JetBrains to tak v MPS dělají, mají tam i podporu verzování, ale to jsem ještě neviděl v akci.

[Martin Böhm]

Uff, takze je lepsi pouzit pristup, kdy ma kazda aplikace konfiguraci (komunikaci) v nijak nedokumentovane binarni databazi (protokolu) (jako Miranda)? Ne, diky. Textova rozhrani maji tu vyhodu, ze pokud jsou udelana dobre, jsou z vetsi casti sebedokumentujici.

[ʚĭɞ 🍉]

XML!!!

[Ladicek]

Dostatečně sebedokumentující mi přijde možná tak jednoduchý INI soubor , cokoliv složitějšího dokumentaci nutně potřebuje (konfigurák Apache? Konfigurák logrotate? Poslední dva formáty, se kterými jsem se pral, na procmail radši ani nevzpomínám), občas i co do struktury. Beru text jako formát pro komunikaci člověk/program, to je tak všechno.

[Sešívaný]

Tak to je "super" novina. Banshee používám, přijde mi jako nejpoužitelnější GTK přehrávač, ale už s tou podporou videa mě nepotěšili a jestli tam přidají ještě podporu fotek, která bude stejně příšerná jako F-spot, tak se zase budu muset podívat po něčem jiném.