Nápad: tagy na desktopu (diskuse)

[Jirka Keresteš]

Tagovat hudbu umi urcite Amarok, u fotek to umi tusim DigiKam. S tagovanim souboru obecne zkus kouknout na Nepomuk, mozna uz je to i funkcni

[ground]

mne tento napad pripomina GNOME Zeitgeist

[Michal Kašpar]

No o tagování a spol. se v Gnome stará spíš Tracker. Ostatně stačí v nějaké novější verzi dát v Nautilu vlastnosti a poslední záložka je právě Tags.

[Vlastimil Ott]

Vítej ve světě KDE SC, sémantického desktopu a Nepomuku.

[Martin]

Vítej v pekle.

[tsLnox]

+1

[RapMan]

:)

[Lukáš Zapletal]

Ne, já nechci žádný sémantický web, ani Nepomuk, Tracker ani nic jinýho.

Já hledám aplikaci, ve které můžu soubory otagovat a poté si vytvořit strukturu adresářů (symbolických odkazů).

Nepomuk a spol je mi k ničemu, když jej aplikace nepodporuje. Jak pak budu vybírat soubory třeba v programu na přehrávání muziky, který nepodporuje sémantický web?

[Senior Database Programmer]

otagovane subory vyberies cez Dolphin, ktory tagovanie podporuje.

[Let_Me_Be]

Tohle je pekne schizofrenicky zapisek.

[xkucf03]

Ty symbolické odkazy jsou dobrý nápad (univerzální, funguje v jakékoli aplikaci), akorát je trochu potíž s jejich změnami – co když soubor smažeš? Zbude ti spousta mrtvých odkazů. Co když si budeš chtít zobrazit další štítky, které jsou k danému souboru přiřazené? Nejsou to neřešitelné problémy, ale vždycky je potřeba projít celý strom.

Aby to fungovalo efektivně, je potřeba mít něco na způsob databázových indexů – např. mít štítky uložené jako rozšířené atributy (funkce souborového systému) a pak z nich generovat strom symbolických odkazů. Nebo mít ty symbolické odkazy jako primární úložiště a z nich generovat ty atributy – abys věděl, v jakých kategoriích soubor je a jaké odkazy je např. potřeba upravit při přesunu souboru. Nakonec to asi nejde jinak, než mít tu informaci na dvou místech, jinak by to bylo moc pomalé.

Taky můžeš použít ten sémantický desktop a generovat si ty symbolické odkazy z něj – to by nemělo být těžké – a jednu půlku aplikace už za tebe někdo napsal

[VSi]

Tohle je docela dobrý nápad, a pokud by to fungovalo, možná bych kvůli tomu začal na desktopu používat Linux Naznačený způsob je o několik řádů jednodušší než nějaké Nepomuky. Představa:

- Tagy budou uložené primárně v rozsířených atributech souborů. Na to není třeba nic speciálního, ext3 to umí. Na editaci stačí triviální grafická aplikace, nebo lépe integrace do správce souborů (nějaký panel po straně, nebo aspoň karta ve vlastnostech souboru).

- Tvořit "fyzicky" symlinky pro všechny kombinace tagů je pro větší počet souborl nesmysl. Takže:

- Démon, který přes inotify bude sledovat nové / upravené / smazané soubory v nastavených adresářích. Jejich umístění a seznam tagů si bude ukládat do databáze (stačila by pravděpodobně sqlite).

- FUSE virtuální filesystem, který na základě té databáze bude tagy prezentovat jako adresáře a přiřazené soubory jako symlinky na skutečné soubory.

Nakonec pro grafické aplikace by asi nebyly potřeba ty symlinky, stačila by integrace do file dialogu - políčko pro zadání tagů oddělených mezerami. Nebo se na Linux desktopu používá hodně různých file dialogů? Na Windows 99% aplikací používá ten systémový. Chápu, že tohle je součástí Nepomuku etc. ale evidentně to zatím není moc použitelné. Kdyby tak takovou minimální funkcionalitu rozumně zprovoznili, a neřešili furt nějaké ontologie.

Konzistence databáze se může pro jistotu kontrolovat jednou za čas proskenováním všech souborů.

[Let_Me_Be]

A co ti v Dolphinu nefunguje?

[Lukáš Zapletal]

Jeden tvůj příspěvek do diskuse lepší než druhý. Opravdu.

[Let_Me_Be]

Tohle byla reakce na: "Chápu, že tohle je součástí Nepomuku etc. ale evidentně to zatím není moc použitelné. Kdyby tak takovou minimální funkcionalitu rozumně zprovoznili, a neřešili furt nějaké ontologie."

Mne totiz uvedene veci v Dolphinu funguji uz od prvnich verzi coz je celkem logicke, protoze jde o prerekvizitu vuci ontologiim a dalsim pokrocilym funkcim.

Ten druhy prispevek je reakce na to ze radsi nez pouzivat system ktery podporuji alespon KDE aplikace chce pouzivat "protoze to podporuji pouze KDE aplikace" system ktery nebude podporovat zadna aplikace.

[petr_p]

Mimochodem, jak se *notify chová při připojení/odpojení souborového systému? Jak by na to měl démon reagovat?

Například když se odpojí souborový systém, uživatel položí dotaz „vrať všechny soubory, co mají značku“, tak co teď? Má orákulum vrátit všechny nakešované výsledky, takže si uživatel vybere soubor, který už ve VFS není? Nebo má orákulum na každý soubor před vrácením znovu dělat stat()?

Ani jedno není dobré. Bude třeba do keše přidat informaci o souborovém systému, ve kterém se soubor nachází.

A co když se připojí gigantický souborový systém, který už jednou „zaindexován“ byl (třeba v jiném počítači). Bude se vše znovu přepočítávat? Neefektivní.

Bude třeba nakešované údaje před odpojením uložit do daného souborového systému.

Ale co víceuživatelské systémy? Uživatelé si nesmí vidět do cizích metadat. Takže index nemůže být přístupný pro všechny, ale musí tam být hlídač. Takže orákulum musí běžet pod privilegovaným uživatelem.

Nebo bude každý uživatel mít vlastní index? Bude se vše počítat pro každého uživatele znovu (v případě dat, kam mají přístup všichni)? Hloupost. Orákulum musí skutečně být jediný privilegovaný proces.

No a brzo z toho máme databázový/objektový souborový systém, který nikdo nepoužívá, protože je pomalý, neexistuje jednotný formát a je pouze předmět vášnivých akademických debat :)

[Lukáš Zapletal]

Zajímavý, díky za tipy i rady.

Asi se do toho pustím. Nebude to ale přes hlídač, ale uživatelské programy + FUSE + lokální databáze SQLITE3.

[fraxinus]

Vidim tu jeden zasadny problem. Vacsina suborovych formatov tagovanie nepodporuje vobec (napr. txt, gif) niektore to nepriamo podporuju (metadata v png, 30 znakov na genre v mp3 id3 tagu) a snad niektore formaty to podporuju priamo ze obsahuju polozku "tags" kde sa priamo zapisuju tagy (ziaden priklad ma teraz nenapada ale urcite nejaky je).

Jediny sposob je ukladat tagy do nejakej oddelenej databazy alebo do nazvu suboru. Ak to bude oddelena databaza, je nutne ju zlozito spravovat, a jedneho dna sa pozabudnes, spustis si terminal a v MC skopirujes nejaky subor na USB kluc a metadata su v prdeli. Rovnako tak email, ftp, ...

Podla mna externa databaza na metadata je totalna blbost, nikdy to nebude poriadne fungovat. Kde sa da, treba prejst na tagovatelne formaty, kde nie, tagovat do nazvu suboru alebo vedla neho vytvorit subor s tagmi (DSC00024.jpg + DSC00025.tag) a modlit sa aby som ten .tag subor niekde cestou nestratil.

[Lukáš Zapletal]

Díky za komentář. No - můj nápad je takový, že otagovaný adresář se soubory by obsahoval speciální skrytý adresář (.tags), kde by byly informace uloženy. Ten by cestoval spolu s adresářem a daty.

Vycházím z toho, je tagovat má smysl větší množství souborů. Tedy nějaký adresář plný souborů (nebo celou adresářovou strukturu).

Podobně funguje třeba .git nebo .bzr.

[grim]

Co takhle podpora ze strany os/file-systemu, např "alternate streams" v NTFS. Tím by (doufám, že neplácám blbosti) bylo zajištěno, že uživatelem dodané atributy/tagy by "vždy" šly společně se souborem (kopírování/přesun/přejmenování/..), i když jenom v rámci (jednoho?) filesystemu. Problém je, že aplikací, které by alternate streams podporovaly moc není. Vzpomínám si akorát akorát na viry.

Neřešil by tohle i kdysi slibovaný filesystem od MS, který měl být řešený jako DB? (neznám podrobnosti).

[fraxinus]

Neriesi to FTP, email, USB kluce, zalohovanie, atd...

[Václav HFechs Švirga]

Jsem o tom taky takhle přemýšlel a kdyby to bylo ve tvaru soubor.přípona.meta.přípona, tak třeba windows by imho ten zbytek skryl, zbytek commanderu zobrazuje stejně nějakou omezenou délku, takže by ukázal soubor.přípona.me... Určitě bych tam nacpal mime typ, u text/plain kódování a pak třeba ty tagy:

soubor.txt.text_plain-utf8:povidka:fantasy:tvorba.txt

(snažil jsem se použít znaky, které nevadí widlím, i když u té : si nejsem jistý)

Ale práce s tím jako přejmenovávání a podobně by byl asi hrozný opruz . Navíc by se tomu musely přizpůsobit aplikace. Ale zase ať by se to zkopírovalo kamkoliv, tak by ty tagy měly vydržet (teda až na filesystemy s omezenou delkou jako některé pro CD a fat16 ).

[Václav HFechs Švirga]

Ještě druhá možnost je v systému držet tagy nějakým standardním způsobem a ve chvíli kdyby soubor šel jinam (ftp, kopírování na flashku, upload po http), tak by aplikace soubor převedla do takového tvaru a naopak, kdyby se do systému nakopírovala tato podivnost, systém by si zase tagy poznamenal lépe a soubor přejmenoval. Ale chce to zase podporu systému a aplikací.

[grim]

třetí možnost je vkládat soubory do kontejneru, podobně jako to dělají dnešní audio/video formáty (mkv,..). S podporou ze strany OS, by pak (snad) nebyl problém se zpětnou kompatibilitou.

[Václav HFechs Švirga]

Njo, ale zas bez podpory si to člověk neotevře, zatímco soubor se zabordeleným názvem jo. Určitě by ale šlo na tu flashku přihrát nějaký "přehrávač", který by si s tím kontejnerem poradil - takže řešitelné to je.

Je jedno jakým způsobem, ale potřebuje to nějaký standard, který začnou ostatní implementovat. Zatím to je tak, že každý si dělá na svém písečku, takže se asi nic nezmění.

[petr_p]

Opět pravím: POSIX Extended Attributes. Existujete to, umí to kdejaký souborový systém, coreutils, tar a podobné nástroje je podporují. Jen ještě zbývá vysvětlit deskotopovým prostředím, že toto je správná cesta.

[xkucf03]

+1

[Nicky726]

Pokud používáš KDE, je tu Nepomuk, což je slovo, které vyvolává vášně, ale místo hádání, jestli to je k něčemu nebo k ničemu, bude asi nejlepší osobně vyzkoušet aktuální verzi. Pro Gnome se taky něco podobného vyvíjí, ale nevím v jakém je to stavu.

[default]

Od toho jsou rozšířené atributy souborového systému. Jediný systém, se kterým jsem se setkal, který tyto atributy používá, je zde tolik nenáviděný OS X. Atributy se přenášejí automaticky i přes souborové systémy, které je nepodporují; například FAT. Nebo přes e-mail, když použiješ Apple Mail.

Pro každý soubor si můžeš dopsat poznámku podle které Spotlight vyhledává.

Zahoď nedodělky, přejdi na OS X a zbavíš se všech problémů.

[cezz]

Smutne (ako pre koho) je, ze mas pravdu..

[SPM]

... zahoď počítač a zbavíš se všech problémů...

[Ondrej 'SanTiago' Zajicek]

A samozrejme o takto resene tagy prijdes pokud soubor nechas kolovat v heterogennim prostredi (mimo MacOS X).

[Algi]

Osobně vyzkoušeno?

[cezz]

A samozrejme o takto resene tagy prijdes pokud soubor nechas kolovat v heterogennim prostredi (mimo MacOS X).

Co je urcite chyba MacOS

[default]

No, chyba OS X to určitě není. OS X je jen první operační systém, který tuto funkcionalitu nabízí a nabízí ji přes rožšířené atributy soborového/operačního systému.

Teď je jen na ostatních, aby zneužili třebas HTTP protokol (ten je dost oblíbený) a řekli, že jejich řešení — mimojiné přes prdel — je jediné správné a OS X to dělá špatně.

Schválně! Kdo bude první? Microsoft nebo GNU/Linux? Já tipuju Microsoft, který přijde se svým "super skvělým řešením"™.

Proč né GNU/Linux? Protože GNU/Linux kopíruje Microsoft.

[Ondrej 'SanTiago' Zajicek]

No, chyba OS X to určitě není.

No, je to dusledek rozhodnuti vyvojaru Mac OS X. Takovou vec jako tagovani souboru je mozne implementovat nekolika zpusoby a je na vyvojarich, zda vyberou zpusob vicemene kompatibilni s celym svetem (napr. pomoci skryteho souboru s tagy pro soubor nebo pro adresar) nebo zpusob nekompatibilni s vicemene celym svetem (pomoci rozsirenych atributu).

Ja tedy presne nevim, jak to v Mac OS X maji implementovane, mozna tam maji nejake triky pro zajisteni kompatibility (napr. ze by nepouzival ciste reseni postavene na rozsirenych atributech, ale michal by ho s pouzitim skryteho souboru).

[default]

Celé je to dané historicky. Apple původně používal tzv. Resource Forks. Ty byly uložené u souborů podobně, jako se dnes ukládají rozšířené atributy. Aplikace si takto spolu nesly ikonky, layouty dialogů a tak podobně. To bylo na Mac OS do verze 9.

S příchodem OS X se spousta věcí změnila. Resources se přesunuly do adresářů a souborů. Resource Forks jako takový snad už ani podporovaný nejsou. Místo toho jsou rozšířené atributy. A OS X si do nich ukládá primárně blbosti spojený s umístěním ikonek v adresáři (ve smyslu zobrazení ve Finderu), asociace s aplikacemi (ano, můžeš mít v adresáři dva PDF soubory a jeden se by default otevírá v Preview a druhý třeba v Acrobatu), barvičky a tak podobně.

Pak přišli se Spotlightem a tu informaci prostě ukládají také tam. A proč ne. Mechanizmus funguje spolehlivě.

A teď o tom, jak OS X neztrácí atributy. Problematický je přenos přes média, která nepodporují rozšířené atributy. V tom případě OS X automaticky zakládá vedle vlastního souboru soubor druhý s prefixem ._ nebo tak nějak a do něj dumpne ty atributy. Dost silně provařený je soubor .DS_Store, který dost často lidem vadí. Stačí připojit například foťák s FATkou a už ho tam máš.

Takže když na druhym Macu tu FATku připojíš, OS X si hodnoty těch původních atributů vytáhne z těch skrytejch souborů. Podobně fungují i přílohy v Apple Mail. Prostě ten klient přiloží soubory dva namísto jednoho.

Celej ten management je plně automatizovaný. I standardní konzolové nástroje jako cp, mv, tar, zip s atributy transparentně zacházejí. Když potřebuješ něco víc, ditto je tvůj kamarád.

Tak. Teď musíš uznat, že ukládání Spotlight Comments do rozšířených atributů je logické, protože rozšířené atributy se v OS X (a vpodstatě i v MacOS) používají od nepaměti a jejich management je vyřešený. Tak proč zas vymejšlet něco novýho jen kvůli hloupýmu komentáři.

[kotyz]

jo, s .DS_Store sem se uz parkrat setkal a to sem mac nikdy nemel

[Ondrej 'SanTiago' Zajicek]

Diky za info.

A teď o tom, jak OS X neztrácí atributy. Problematický je přenos přes média, která nepodporují rozšířené atributy.

Nejde jen o media (resp. filesystemy), ktere nepodporuji rozsirene atributy. I kdyz soubor nahraju na fs, ktery rozsirene atributy podporuje, tak pak medium muzu zapojit do OS, kde znacna cast programu rozsirene atributy ignoruje, a pokud se neporevede stejny workaround, tak se pri praci s tim souborem nejspis rozsirene atributy co nevidet ztrati.

Nebo treba multiplatformni programy, prelozene pro Mac OS X - bud se pro ne budou emulovat ty vlastni soubory s dumpnutymi atributy i na primarnim FS, nebo je v nekterych pripadech budou ztracet.

Nebo treba presun pres FTP a spoustu dalsich sitovych protokolu.

Proste bez ohledu na to, jak jsou extended atributy implementovane na urovni FS, bylo by rozumne mit nejake jejich standardni vnoreni do bezneho prostoru souboru, aby se nemusely predelavat vsechny stavajici souborove protokoly a programy.

[default]

Multiplatformní programy jsou blbost největší. Abys uživatelům nabídnul stejný komfort jako zbytek systému, budeš muset naimplementovat platformě závislé věci. Tudíž i rozšířené atributy a zacházení s nimi.

FTP protokol, sdílené disky Windows a tak podobně se na OS X chovají naprosto stejně jako FAT. Jediný, co rozšířené atributy zahazuje je odesílání souborů přes HTTP(S) protokol. A to jen proto, že se zatím nikdo neobtěžoval definovat způsob, jak tyto atributy předat. A jestli definoval, serverové aplikace na to stejně kašlou. Download je v pohodě. Je na to workaround ve formě stahování zipů, tarů či DMG souborů, které po stažení automaticky rozbalí.

Co se předělávání protokolů a programů týče, tak předělávat se bude. Tak jako tak. Je jen důležité zvolit správnou cestu a né workaround. A není to zase tak složité. Stačí obyčejné API, které ten management okolo zařídí. Aplikace pak budou používat toto API a nebudou muset se o nic starat.

Inspirovat se můžete třeba zrovna u Applu nebo u Javy.

Ale ono je to stejně takové liché. Teď mám namysli ty tagy. Gnome si udělá svoje API, KDE si udělá svoje API a aplikace aby podporovaly všechno. To samozřejmě nikdo implementovat nebude. Takže zpátky na stromy a hurá na symlinky.

[Ondrej 'SanTiago' Zajicek]

FTP protokol, sdílené disky Windows a tak podobně se na OS X chovají naprosto stejně jako FAT.

Ja se na to koukam z hlediska programatora, nikoliv z hlediska uzivatele. U zapisu na FS tohle reseni muze zajistit OS, ale u sitovych protokolu to musi zajistit ten, kdo ten sitovy protokol implementuje, tedy obvykle primo aplikace. Oproti tomu pokud se rozsirene atributy budou tvarit jako soubory, vse bude fungovat pro aplikace transparentne (akorat pri operacich nad samotnymi soubory budou muset kopirovat i prislusne atributove soubory, coz je ale trivialita proti rozsireni sitovych protokolu o nove operace cteni a zapisu rozsirenych atributu).

[default]

Z hlediska programátora je to velice jednoduché. Při manipulaci se soubory bude používat API stejně jako ho používá dnes. Prostě přibydou funkce copyFile() a tak podobně, které zařídí vše potřebné.

Proč by měla každá aplikace řešit něco, co má zajistit operační systém (nebo desktopové prostředí, kernelu je po tom putna)?

Když to dotáhnu do extrému, nevidím jediný problém používat třebas API konqueroru v případě KDE aplikací. Chci kopírovat soubor? Řeknu konqueroru, ať to za mě udělá. Okýnka si taky nekreslíš sám po pixelech. Pakety taky nelepíš v nějakym ByteArray; smažíš data do Streamu a zbytek tě nezajímá.

Já to prostě vnímám jako službu, funkcionalitu, další API. A jestli to API to bude realizovat přes rozšířené atributy nebo přes Web 2.0 je mi vzásadě jedno.

A ještě taková malá poznámka k těm atributům. Mně se na nich líbí, že nejsou vidět. Na vyžádání si je zobrazit umím, ale když brousim file systém, tak mě neobtěžují. To je třeba případ těch .DS_Store, Desktop.ini, Thumbs.db a podobných. Najednou máš v adresáři dvakrát tolik souborů a blbě se v tom orientuje.

[petr_p]

Přitom rozšíření pro ukládání rozšířených atributů do FAT už zadefinoval OS/2.

[Lukáš Zapletal]

Snad si nemyslíš, že díky takové prkotině jako nějaké tagy bych přecházel na MacOS

Ne, já chci v podstatě vytvářet adresáře symbolických linků tak, jako jsou tag cloudy na sociálních serverech. Nechci žádná bombastická řešení v podobě fs-metadat nebo sémantických věcí. Já jsem konzervativec.

Můj dotaz tedy je - existuje (mimo výše uvedené) nějaké takové řešení? Neměl někdo potřebu mít na disku soubory kategorizovány pomocí symbolických odkazů podobným způsobem, jako fungují tagy?

[petr_p]

Konzervativní řešení:

dd if=/dev/urandom of=~/soubor count=42
ln -s ~/soubor ~/kategorie/bordel

Spokojen?

Ne? Tak si kategorii strč do rozšířeného atributu, a přes fa_notify(2) probuď démona, který ten symlink za tebe udělá. A pokud si necheš zaneřádit systém odkazy, tak nech démona dělat symlinky přes FUSE, který si můžeš namountovat, kam je libo.

[Bystroushaak]

Já jí měl, ale linky dělám ručně.

[Máček333]

Jejda, já tajně doufal, že už to linux umí

Jediná cesta je právě přes rozšířené atributy a podpora desktopu podle Finderu v Apple.

Jde totiž nejen o hudbu a filmy, ale i o dokumenty všeho druhu. Zkuste si někdy pojmenovat dokument tak, aby vyjadřoval několik TAGS (např.: Práce 2010 Dům Koupelna Rozpočet) V současné době to řešíme tak, že máme folder 2010/Dům/Koupelna/Rozpočet.odt jenže tím každou chvíli používám search, když chci vidět všechny rozpočty... Takhle by stačilo nechat zobrazit dokumenty s tagem Rozpočet a hotovo... Prostě jako je seskupit dle kategorií v outlooku

Problém je prostě více Views podle různých kritérií napříč všemi dialogy otevření souboru, tedy ne řešit to na aplikaci (Amarok apod) ale přímo v OS

Nejsem programátor ale jen user, a ještě k tomu jsem na chvíli čichl k OSX :-p

Už aby to bylo, je nakažlivé používat google na webu...