Pokud poklikáte na dokument ve Finder, jak systém rozhodne kterou aplikací jej má otevřít? Vazba mezi dokumentem a jeho aplikací je nazývaná "preferred application binding" (volně přeloženo preferovaná vazba na aplikaci). Od prvního dne uvedení Mac OS X zde byl nepříjemný rozdíl mezi DOSovskou vazbou k dokumentům a původní Macovskou cestou, zděděnou od prvních dob Mac OS. Nyní ve Snow Leopardovi si uživatelé a vývojáři stěžují, že DOSovský způsob je upřednostňován před Macovským.
Základem Macovské vazby dokumentu k aplikaci je kód tvůrce - čtyřznaková hodnota, unikátní pro každou aplikaci připojená jako metadata k dokumentu. Jednou z výhod tohoto přístupu je povolit aplikaci sdílet dokumenty příbuzného typu (samostatně reprezentované jako čtyřznaková hodnota, typ kódu). Například, pokud se podívám k sobě na plochu, vidím dva textové soubory (kód typu "TEXT"); Jeden patří SimpleTextu (kód tvůrce "ttxt") a druhý BBEditu (kód tvůrce "R*ch").
Kódy typu a tvůrce jsou pro uživatele neviditelné; což je dobře, protože uživatelům tak nepřekáží, ale pokročilí uživatelé potřebují nástroje třetích stran, aby s nimi mohli pracovat. Tidbits kdysi připravila fascinující rozhovor s Brucem Hornem, který tento mechanismus vymyslel. Viz odkaz na konci článku.
DOSový přístup (nebo to co můžeme nazvat DOSovým přístupem pro zjednodušení, pochází původní z platforem DEC a DOS) je používání přípon souborů, což je tečka následovaná zkratkou na konci jména souboru.
Nemalé části uživatelů Macovské implementace přípon souborů - jsou ošklivé, nepochopitelné, občas je vidíte občas ne, můžete je změnit, ale obtížně. Adam C.Engst kritizoval tento přístup už u Mac OS X 10.1 (viz odkaz níže). Stále však má tento přístup jednu výhodu - je to pouze text, takže jej můžete vidět a měnit.
(Začátkem roku 2005 Apple uvedl jiný způsob specifikace typu souboru: uniform type identifier - UTI. Jedná se o neviditelná metadata, podobně jako typ kódu, ale delší, obsahující více informací a může mít hiearchickou strukturu. Například textový soubor může být typicky "public.plain-text", který je podtřídou "public.text". Souborové přípony jsou však stále s námi.)
V DOSovském způsobu se používají přípony, které prostě označují typ souboru, vlastník těchto typů je již úplně jiná otázka. Aplikační balíček obsahuje důležitý soubor, který se jmenuj Info.plist, který dovoluje ohlásit vlastnictví určitého typu souboru. Služba Launch udržuje databázi těchto ohlášení a používá ji pro určení jakou aplikací se má soubor otevřít ve Finderu.
Uživatel má možnost nastavit preferovanou aplikaci, ve Finderu stačí nechat zobrazit informaci o souboru (Get Info) a tam přiřadit soubor nebo typ souboru příslušné aplikaci.
Abychom to shrnuli, dokument může mít minimálně tři způsoby, jak být připojen k aplikaci:
- Uživatel může použít Finder pro připojení dokumentu k aplikaci
- Název souboru může obsahovat příponu a/nebo UTI, ke které se aplikace přihlásila
- Dokument může být označen pomocí kódu tvůrce souboru
Je jasné, že algoritmus Launch služeb musí mít interní pravidla, které řeší případné konflikty mezi těmito alternativami. Pravidla jsou velmi nepřesně dokumentovány a v historii Mac OS X se také několikrát měnily. Je jasné, že úprava uživatelem pomocí Finderu by měla mít nejvyšší prioritu, což je jen správně. Co však v případě, že je v konfliktu přípona a kód tvůrce souboru? A co když - a to je nyní nejvážnější problém - je přípona souboru zpracovatelná více aplikacemi a soubor má tvůrce souboru?
Dokumentace Apple říká:
Jestliže byla nalezena více než jedna aplikace jako výsledek kroků 2-3, aplikuj následující pravidla pro výběr:
(a) Jestliže dokument obsahuje čtyřznakový podpis tvůrce (nebo jestli byl specifikován jako parametr), dej přednost té aplikaci hlásící se k dokumentu s podpisem (typicky aplikací, které podpis v dokumentu patří)
Podle tohoto pravidla, jestliže dva textové soubory mají stejnou příponu (jako .txt) ale jeden z nich má tvůrce "R*ch", pak soubor patří BBEditu. To je dobře, protože to znamená že BBEdit může upravovat jakýkoliv textový soubor bez změny vazby na aplikaci a vytvářet textové soubory které označí jako soubory patřící jemu.
(jestli máte problémy si představit práci s texty, popřemýšlejte o obrázcích. Soubor .jpg vytvořený Photoshopem nebo GraphicConvertorem, mohou stále patři buď Photoshopu nebo GraphicConvertoru)
Toto pravidlo bylo dodržováno v Tygrovi i Leopardovi a uživatelé a vývojáři si na něj zvykli. Nicméně pravidlo má také velmi elastickou klauzuli: "Poznámka: Apple si vyhrazuje právo změnit výběrová kritéria v dalších verzích systému."
Ve Snow Leopardu Apple tuto klauzuli využil. Bez upozornění a změny v dokumentaci Apple pravidla upravil, takže pravidlo a) není upřednostňováno. To by nebyl velký problém, máme tu UTI (viz níže v textu), bohužel Apple to opomněl vývojářům zdůraznit a vývojáři stále používaly zažité způsoby označování souboru. To se pak vymstilo jak jim, tak v konečném důsledku Apple.
V praxi to znamená že aplikace (která nepoužívá UTI) ve Snow Leopardovi nemůže k sobě svázat dokument. To znamená, že pokud ve Snow Leopardovi vytvoříte textový dokument v BBEditu, BBEdit jej podepíše svým "R*ch" kódem, ale dokument přesto patří standardnímu TextEditu. Má ikonu TextEditu a po poklepání je otevřen TextEditem - i když jej vytvořil BBEdit. TextEdit tak ukradl BBEditu dokument. Podobně Preview krade dokumenty Photoshopu nebo GraphicConvertoru.
Problém není možné odstranit jednoduše smazání přípony souboru (takže systém bude přinucen využít informaci o tvůrci). Ale ačkoliv toto fungovalo v prvních vývojářských verzích Snow Leoparda, ve finální verzí to tímto způsobem obejít nelze. Soubor možná neobsahuje .txt, ale uvnitř je stále označen jako "public.plain-text", což je prakticky totéž. Služby Launch tak přiřadí soubor TextEditu.
Vaší jedinou možností, pokud chcete soubor vždy otevírat v BBEditu je explicitně jej označit: vybrat soubor ve Finderu, otevřít okno Get Info (Jablíčko-I) a změnit nastavení Open with .... (Otevřít pomocí .... ). Toto je však dobré pro jeden soubor, ale co když takto chcete pracovat s více soubory? Naštěstí zůstala jedna možnost.
Ve Finderu si vyberte File -> Find. Změnte Kind pop-up menu na Raw Query (z dialogu Other..., jestli jej nevidíte) Do textu pak napište frázi:
(kMDItemContentType == "public.plain-text") &&
(kMDItemFSCreatorCode == "R*ch")
Tento výraz najde všechny .txt soubory vytvořené BBEditem, nyní je můžete všechny označit, vybrat Get Info a změnit Open With nastavení. Podobně můžete upravovat .jpg soubory atd. To je hodně komplikované cvičení, což je ovšem přesně to, co je na tomto přístupu špatně.
Článek v tidbits uváděl, poměrně nepřesnou informaci. Vývojáři mají způsob jak chování odstranit. Řešením je UTI. Jednoduše vývojáři budou muset opustit bývalý systému tvůrce souborů a začít více využívat UTI. Pomocí UTI si pak zadefinovat typ souboru:
kMDItemContentTypeTree = (
"cz.firstnet.aktuality.document",
"public.plain-text",
"public.text",
"public.data",
"public.item",
"public.content"
)
V případě že neexistuje aplikace, která by typ cz.firstnet.aktuality.dokument zpracovala, Lauch služby by našly první aplikaci, která je schopna otevřít typ public.plain-text.
Internetová komunita na to zareagovala a objevilo se spousta článků na toto téma s větami: "Apple udělal velkou a hloupou chybu." a "Snow Leopard vzal jednu z nejelegantnějších Macovských funkcí - spouštění správné aplikace pro soubor - a zahodil ji.".
A proč na tom záleží? Jestli pracujete pouze a jen s jednou aplikací která pracuje např s textovými soubory, tak si problému ani nevšimnete. Ale co když některé věci otevíráte v TextEditu a některé ve Wordu nebo Pages? Budete pak muset lehce upravit svůj způsob práce, bohužel k horšímu, alespoň do doby, než vývojáři aktualizují svůj kód.
Komplexnější informace o změnách práce s typy souborů najdete na stránkách arstechnica.com ještě z dob uvolnění Tygra.
Odkazy z novinek:
