Snow Leopard visszafejlődés: nem ismeri a creator code-okat

Ezt a problémát a switcherek lehet nem veszik észre, de régi macesek nagy része és az úgynevezett power userek fogják a fejüket és káromkodnak. Neten ahogy szétnéztem, fejlesztők munkáját, felhasználók aprólékosan felépített workflow-ját teszi tönkre ez az új “fejlesztés”.

Miről is van szó?

Köznapiul: egyszerűsödött (értsd: butább és rugalmatlan lett) a file-ok típus szerinti megkülönböztetése és megszűnt az automatikusan programhoz való kötésük (application binding).
Ez így eléggé semmitmondó, de hogy ez mit jelent, és miért olyan jelentős dolog, hogy én is, de rajtam kívül sokan még jobban felhúzták magukat rajta, az alábbiakban magyarázom meg. Akiket nem érdekel a technikai háttere a dolognak, és csak a lényegre kíváncsi, ugorjon pár bekezdést (de akkor nem biztos, hogy érteni fogja, miről van szó).
Tudom, kicsit hosszúra nyúlt, de fontos és érdekes dologról van szó, és ha érdekel a Macintosh működése a történeti és technikai rész is érdekes lesz, annyira nem hardcore szöveg (például a Core Foundation-ről szóló részeket töröltem és máshol sem mentem bele nagyon a rendszer bugyraiba :D) és jól széttagoltam ha át akarja valaki lépni az adott részt.

Fork-ok és file-metaadatok

Nagyon röviden megpróbálom összefoglalni az egyik sajátosságát (és előnyét) a hagyományos Macintosh filerendszernek (nem az MFS-re gondolok, annyira ne menjünk vissza az időben :), a forkos rendszert:
A file-ok itt két részből állnak, két, úgynevezett forkból. Az egyik a resource fork, a másik a data fork. A data fork értelemszerűen magának a filenak a bitjeit tartalmazza, azaz az “adatot”, más rendszereken ez jelenti “a” file-t. A resource forkban pedig a file-hoz tartozó különbféle információkat, (meta)adatokat találunk, a felhasználó számára transzparens módon tárolva, ami jó dolog. Resource elég sokféle lehet, akár a nyelvi lokalizáció is, tehát nagyon gazdag reprezentációja az adott állomány tulajdonságainak (máshol van a kiterjesztés, és kész), de én most csak arra a részre szorítkozok, ami a bejegyzés témáját érinti. (Megjegyzés: a resource fork nem összekeverendő a hagyományos UNIX-os i-böggel (i-node)!) Ezen forkos rendszer miatt teljesen mindegy, mi a file kiterjesztése, vagy egyáltalán van-e neki, ki nem szarja le? Csak egy kevés további szöveg a filenév végén. Kiemelem tehát: a filekiterjesztésnek alapvetően semmi köze (nem volt régen) a file tipusához, tulajdonságaihoz. Ami többek között azért jó, mert (a rendszer- vagy fejlesztői oldalról nézve) a kiterjesztéssel azonosítani egy állományt nehézkes, nem megbízható stb. Az egész rendszer merev. Ráadásul ki lehet kapcsolni, hogy meg legyenek-e jelenítve a kiterjesztések vagy nem, ami meg a felhasználói oldalon zavart, de emellett kárt is okozhat. Például sok Windowsos kártevő így települ vagy terjed: kiterjesztéssel azonosítják a filetipust, de a kiterjesztést (ami azonosítja a filetipust) ha elrejted, akkor, ha jön a spamben a jocsaj.jpg.exe, az egyszeri felhasználó csak azt látja, itt a jocsaj.jpg, ami ugye kép, és mikor meg akarja nyitni valójában elindítja a .exe alkalmazást, ami aztán gonosz dolgokat művel a gépén… “It’s kind of… a bummer“, ahogy Ellen Feiss mondaná.

A resource forkban ellenben (mások mellett) ott van, milyen file-ról beszélünk, ezt az úgynevezett type code azonosítja. De ez még nem mondja meg, hogy melyik programé az adott állomány (persze a programok tudják, hogy ők milyen type code-ú alkalmazást képesek kezelni). Itt lép be a képbe a creator code. Az adott állományt létrehozó program ezzel megmondhatja, hogy az általa készített állománynak ő a “gazdája” (megint nem összekeverendő a UNIX i-node-ban tárolt tulajdonosi/jogosultsági adatokkal!). Mac OS 9 és korábbi rendszereknél egyszerűen senki nem foglalkozott a filekiterjesztésekkel (vagy legalábbis nem nagyon), egy opcionális érdekesség volt csupán. A type és creator code-os azonosítás sokkal kifinomultabb rendszer, mint mereven a filenévben az utolsó pont utáni sztringre hagyatkozni.

Itt egy példa, bár lehet nem a legjobb: sokan játszanak különbféle játékokkal, sok játék .sav kiterjesztéssel menti el az adott állást, tehát többféle program, mind más struktúrában és logika alapján ment ugyanolyan kiterjesztésű file-t. A creator code alapján viszont mindnek megvan a gazdája.

Ez elmentette, ugyanez fogja megnyitni.

Újabb, ezúttal jobb és életszagúbb példa a testvéremtől: Photoshopban mentett PSD-t a Photoshop nyitotta meg, és nem a Preview, ami szinte minden esetben a kívánatos viselkedés volt. Snow Leopard esetén Photoshopban mentett PSD-t is a Preview nyitja, aminek nem örül. Most vagy minden psd-t átállít, vagy egyenként ami kell neki, aminek nem örül. Bővebben erről később.


A fenti képernyőfotón egy, parancssorból létrehozott txt file Info panelje látható, ahol az “Open with:” beállításnál kiválasztható, mi nyissa meg. Alapból txt-t a TextEdit, mint itt is, hisz itt nincs elérhető creator code (mivel egy unix stdout átirányítás hozta létre a filet), de én jobb szeretném ha az okosabb TextWrangler nyitná meg bizonyos okokból. A kijelölésen és a megváltozott file ikonon látszik is az új beállítás – ezentúl ő a gazdája a file-nak.

Application binding és UTI-k

OSX alatt elkezdett bonyolódni a helyzet a file-ok programhoz kötésével (binding). Persze, valahogy össze kellett hozni a HFS+ -t
a UNIX-os tulajdonságokkal (erről annak idején egy érdekes és bonyolult cikket olvastam, hogy mit szívtak és mit hogy oldották meg, valahol még megvan), és ott már a file-ok nagy részének volt kiterjesztése is. Ami kicsit zavaros máig is, mert vannak file-ok amiknél a Finder rendszerszinten alapból elrejti a kiterjesztést (megjelenítésnél), van aminél alapból megjeleníti, van összevissza jeleníti, és persze egyénileg, minden file-nál külön be lehet állítani bármikor, látszódjon-e vagy sem a kiterjesztés. Vagy még mindig él az is, hogy elhagyhatjuk.

A Panther (10.3) idején tovább bonyolította az application binding dolgot egy újabb metaadat-típus, a uniform type identifier (UTI) megjelenése. Ez “fontosság szerint” a type code filetípus-azonosítás fölött áll, nem is rossz dolog, hierarchikus tipusazonosítók stb, de bővebben ebből a szempontból most nem foglalkozok vele, mert nem erről szól a bejegyzés. Sőt, mint ahogy creator code-ot, UTI-t is létre lehet hozni magunknak is.

Szóval, van egy adott kiterjesztésű/típusú file, amire több alkalmazás is bejelenti “az igényét”, hogy az az övé (értsd: adott filetípust több program is képes legalábbis megnyitni, de van amelyik írni is), mi dönti el, ki nyissa meg alapértelmezve? Eddig (Panther óta) az UTI-ban tárolt információ, vagy ha ott nem dől el, akkor a creator code volt, ami eldöntötte. Persze más is megnyithatta, (ha képes volt rá) szerkeszthette, elmenthette, de tulajdonosává nem vált. De ha ő hozta létre, akkor az övé volt! Ez elmentette, ugyanez fogja megnyitni. Ez a látszólag apróság annyira szignifikáns része volt az operációs rendszer működésének, hogy a felhasználók és fejlesztők építettek rá (ld első bekezdés és ld lejjebb).

Snow Leopard alatt mindezt szépen csendben (a dokumentációba például nem került bele a változtatás) eltörölték. A creator code maradt, csak a rendszer szarik bele.

Az “igényeket” a Launch Services adatbázisa kezeli, amiben minden filetípushoz ott van az alapértelmezett program is, ami megnyitja (ld a képet feljebb), meg a többi is, ami képes megnyitni (ezeket az információkat a programok az application bundle-ben az Info.plist-ben tárolják, a Launch Services onnan olvassa ki dokumentumtípus (pl szöveges) és kiterjesztés (.txt, .html, .m – ezek ugye mind szöveges állományok) alapján. Viszont ezek az információk csak a file típusával foglalkoznak, a létrehozóval (a gazdájával) nem, így minden azzal nyílik meg, ami a Launch Services-ben az alapértelmezett program (kivéve ha explicit megváltoztatja az egyes állománynál a felhasználó).

Miért hatalmas probléma és óriási visszalépés ez?

Ahogy egy fejlesztő írta, akinek a programjának komoly gondokat okozott a creator code rendszer általi figyelmen kívül hagyása:

Snow Leopard takes one of the Mac’s most elegant features—launching the correct application for a file—and desecrates it.
Kb magyarul: A Hópárduc fogja a Mac egyik legelegánsabb sajátosságát – a file-nak megfelelő program indításának képességét – és jól megszentségteleníti.

Lássuk például a szöveges állományokat. A rendszer nagy része amivel az ember matat sima szöveges ( ¬ bináris) állomány, a beállítási file-ok (.plist) és bármely egyéb xml dolgok, man pages, logok, scriptek, header-ök, forráskódok mind szöveges állományok. Mint ahogy ugye az összes webes cucc (html, css, php, js stb) is. Type code ezt tudja, creator code tudja, mivel nyissuk meg, az UTI-ban benne van, hogy például ez egy szoveges állomány, de log, ezért mondjuk a console nyissa meg stb. De ezeket kiterjesztés is azonosítja, de mi a helyzet például a simán .txt szöveges állományokkal? A “text” szöveges állományokkal?

Én magam zömmel szöveges állományokat használok számtalan okból a napi rutinomhoz. Persze nem mind txt kiterjesztésű (sőt, a többségnek nincs is kiterjesztése, de a rendszer tudja miről van szó, mert ott a type code, és tudja mivel kell nyitni, mert ott a creator code), és bizony nem mindet (többséget nem) a sima szövegfile-okhoz alapértelmezetten rendelt TextEdittel készítettem, és zömüket nem is azzal nyitom meg. Van például SubEthaEdit vagy TextWrangler-ös .txt-m amit szeretek azokkal nyitni és kezelni.

Webes cuccokat SubEthaEdittel írok, de elmenteni .html, .css, .php kiterjesztéssel szoktam, ami webes cucc, tehát a böngésző nyitná, de nem, mert a creator code-ban ott van, hogy SubEthaEdit, és ez nekem így jó, mert ha ezeket meg akarom nyitni Finderből, akkor azért teszem, mert beléjük akarok nyúlni. Tehát ne Camino nyissa meg, ami rendszerszinten alapértelmezett a html állományokra, Caminoval megnyitom, ha úgy akarom, de ha Finderből nyitom, igenis SubEthaEditet indítson (mint ahogy most, egyelőre, teszi)! Böngészővel ráérek még. (Részletkérdés, hogy SubEthaEditből közvetlenül tudok html oldalakat – stíluslapokkal együtt– előnézni és a php scripteket is le tudom futtatni és debugolni, tehát böngészőre tényleg a legvégén van szükség ha úgy vesszük.)

Nincs olyan ember, aki elsőre tökéletesen elvégez egy hosszú, komplex feladatot!

Főleg, mind weblap esetén, a munka sohasem áll le. Ezért a félkészen, menet közben elmentett állományt aki dolgozik, azzal a programmal akarja megnyitni, amellyel létrehozta, nem pedig egy teljesen másikkal!


Toasttal létrehozott és elmentett iso image – nyíljon meg Toasttal, ahogy alapértelmezve itt is! (bármely, “sima” iso-hoz a DiskImageMounter van hozzárendelve – tehát felcsatolja az image-ben lévő filerendszert, ahogy Snow Leopard alatt mindennel teszi, ezzel is, akár azt akartuk ezzel az isoval, akár csak Toasttal kiírni később)

Fenti példák alapján, elkezd valaki dolgozni egy képen, elmenti menet közben a psd-t, kilép a fotosopból, utána, mikor legközelebb rábök a file-ra, NEM meg akarja tekinteni képnézőben, hanem folytatni akarja a munkát a képszerkesztőben! Ha valamit igazítani akar valaki egy weboldal stíluslapjain, akkor nem a Dashcode vagy a böngésző kell neki, hanem az a szövegszerkesztő, amivel a munkát kezdte! Vagy, a fentebb idétett fejlesztő példájával: ha készít egy rtf-et táblázatokkal, oszlopokkal, akkor utána nem TextEdittel akarja megnyitni. De azt nem írta le, miért: a TextEdit csomó, bonyolultabb rtf-es tulajdonságot nem (vagy nem rendesen) támogat, ilyen például a lábjegyzet, tehát ha újra meg akarja nyitni a file-ját, a TextEdit nem fogja tudni rendesen megjeleníteni a munkáját.

És ezek mind komoly problémák!

Egyelőre Leopard (10.5) felhasználó vagyok, tehát ezek még élnek nálam, de ha frissítek 10.6-ra, akkor valamennyi szopásnak nézek elébe, mert a TextEdit lesz minden txt-nek a gazdája (más típusú file-jaimról nem is beszélve). Sokan pedig orbitális szopást kaptak az arcukba, szóval nem magam akarom sajnáltatni. Én sajnálom a felhasználókat, fejlesztőket, és a butuló operációs rendszert…

Mivel az Apple szerint 10.6 alatt ez a rendszer helyes működése, ezért (legalábbis egyelőre) nincs rendes megoldás a problémára, és persze hivatalosat ne is várjunk. Persze, ha kézzel átállítjuk, akkor még mindig (de ki tudja, meddig?) az az érvényes beállítás, hiszen the customer is always right (kivéve, mikor az Apple-nek ez nem tetszik), de ez természetesen nem megoldás, főleg nagyobb file-mennyiségnél.
No meg használhatunk “alternatív” megnyitási módokat, például a futó alkalmazás dokkbéli ikonjára rádobva megnyitni a file-t, vagy control-klikk ➞ Open with…, amik körülményesek, vagy egyszerűen minden adott típúsú file gazdáját megváltoztatni, hogy azzal nyíljon (command+i, a panelen “open with” alatt kiválasztani a programot és a “change all” gombra bökni) de akkor megint ugyanott vagyunk, ahonnan elindultunk, csak más a program neve.

A file kiterjesztésének törlése sem megoldás, hisz ott az UTI, mint fentebb említettem, előbb azt nézi meg, nem a creator code-ot.

Fejlesszük vissza!

Ezzel a Apple megint közelítette a Windows (sőt, a DOS!) felé a rendszert, ami sajnos egy hatalmas visszalépést is jelent ebben az esetben. Remélem, azért a kizárólagosan kiterjesztés-alapú filemeghatározásig nem jutunk el.

Tehát, ahogy kezdtem a bejegyzést, ez a problémát a switcherek lehet nem veszik észre, de régi macesek nagy része és az úgynevezett power userek fogják a fejüket és káromkodnak. Neten ahogy szétnéztem, fejlesztők munkáját, felhasználók aprólékosan felépített workflow-ját teszi tönkre ez az új “fejlesztés”.

Minek elrontani, ami jól működött évtizedekig? Miért okoznak szándékosan kellemetlenséget a felhasználóiknak és fejlesztőiknek?

Az az esetleges kifogás pedig, hogy “a többi rendszereknél mindig ugyanaz a program nyitja meg ugyanazt a kiterjesztésű file-t” meg nem állja meg a helyét, hiszen épp ezért jobb az OS X a többi rendszereknél, hogy sok mindenben más (és több mindenben jobb, mint rosszabb ez a másság), de már egyre kevésbé más, és itt nem előnyére változott.
Think different, hová lettél?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.