OSX oroszlános hasznosságok

A rendszerbutítás folytatódott a 10.7 Lion és 10.8 Mountain Lion során is. (A 10.6-nál elvett type/creator code támogatást máig nem emésztettem meg pölö.)

Az új oroszlános rendszerekben* is van pár bosszantó újdonság, amivel régóta jól működő dolgokat rontottak el a butítás iOS-ítés fejlődés jegyében.

Osztottam már meg korábban terminálos osx trükköket nem egyszer, itt van most néhány újabb, 10.7 és utáni rendszerekre.

Az egyik újdonság ami körülményesebbé tette a rendszer mindennapi használatát a (többek között a) párbeszédablakoknál a billentyűzetes navigáció megszüntetése. Például mentésnél, régen lehetett másodperc tört része alatt funkciót (gombot) váltani nyilak vagy tab segítségével, sőr, egyszerre két gomb is ki lehetett jelölve (egy fő-, és alternatív kijelölés), és elsőt return, másikat space használatával lenyomhattad. Nem kellett egérrel kaparászni. Elvenni a kezet a klaviatúráról. Itt a megoldás visszacsinálni:
defaults write NSGlobalDomain AppleKeyboardUIMode -int 3

a felhasználói jegyzékben a Library jegyzék újramegjelenítése a Finderben:
chflags nohidden ~/Library

szövegkijelölés QuickLook ablakban:
defaults write com.apple.finder QLEnableTextSelection -bool true

(Egyébként QuickLook kiválóan hekkelhető is extension-ökkel is.)

Amire még mindig nincs megoldásom, de nagyon kéne: a hide-olt alkalmazások kerüljenek az appswitcher lista (command+tab programváltás, értitek) végére, mint régen! Amit eltűntetek, azt épp nem akarom használni! Azért tűntetem el, mert most épp nincs rá szükségem. Így ha gyorsan almatabolok, nem azt akarom visszahozni, hanem a következő elől lévő (látható) programot.

Ez utóbbi, meg a legelső (megoldott) probléma, hogy is mondjam, vesztett a rendszerhasználat a transzparenciájából, azaz oda kellett figyelni mit csinál (pedig elvileg pont az lenne a cél, hogy észre se vedd, épp gépet kezelsz), és ezen túl ki is zökkenti az embert, ami nem jó.

(Lion-t rövid ideig használtam, tehát lehet keverni fogom a kettőt és csak később jött be valamit amiről beszélek, ezért az oroszlános gyűjtőnév, még ha magyarul nem is így hívjuk a pumát)

Software update az Alma menüből

Az elmúlt nagyobb OSX frissítéseknél az Alma menü felső harmada, ahol a “legfontosabb”, számítógépszintű menüelemek vannak változgatott kicsit. A legújabb, 10.8-as rendszerben így néz ki a dolog, ahogy jobboldalt látható.
Ez önmagában még nem lenne baj, az App Store már korábban kirúgta a System Preferencest (valójában már 10.6.x alatt).

Viszont. Mountain Lionnal (10.8) az önálló Software Update alkalmazást megszüntették. Értem én, kötik az ebet a karóhoz azaz a jobbágyot a röghöz akarom mondani a legtöbb alkalmazást úgyis a bolton keresztül tölti le a nép (erre, kevéssé finoman az új biztonsági őr program, a Gatekeeper is noszogat), így a rendszerfrissítések és alkalmazásfrissítések központilag menedzselhetők. Valójában ezzel sincs problémám.

A problémám az, hogy a fentiek miatt mindkét menüpont ugyanazt a programot nyitja meg (még ha nem is ugyanazt az “ablakát” (egyablakos az App Store app)). Redundáns, felesleges.

Apple kezdetektől nagyon odafigyelt a jó, a felhasználóbarát GUI-ra, komoly HIG (human interface  guideline) köteteket jelentettek meg, nem véletlenül volt követett példa a Mac OS külső. Ezért furcsa egy ennyire fontos helyen egy ekkora bakit elkövetni. Nem volt ez átgondolva (vagy ellenkezőleg, túlgondolták :)

A legelső NeXT bugreport

Steve Jobs halálával sokminden elszaporodott a neten, többek között a nyerészkedő hajlam. Ezen belül elég sok NeXT, korai Apple cuccot toltak ki rövid idő alatt eBay-re, azzal a gyakran nem, vagy alig leplezett szándékkal, hogy meglovagolják a halálhírt és aprópénzre váltsanak valamit, ami esetleg évek óta porosodik.

Viszont éppen ezért néha egészen érdekes, korábban nem látott dolgok jönnek szembe, ha szétnéz az ember.


a bugreport első oldala

Ilyen a bejegyzés címében is említett dolog, ami a cseppet sem hatásvadász (várjunk, nem ez a jó kifejezés…) Steve Jobs Memorabilia: Very First NeXT Bug Report címmel és NeXT Cube Report Matted and Framed Historical Document alcímmel került ki eladásra. A cím hangvételéhez passzoló árcímkével (5200 amerikai dollárról indul a licit, de ha gyors vagy 25000-ért tied lehet azonnal), nem csoda, hogy nem tett senki ajánlatot két nap alatt; amióta kikerült azóta figyelem, csak az eladó vette le-tette vissza a képeket (tegnap meg is ijedtem, hogy nem mentettem le őket, pedig már akkor blogolni akartam).
De ami most a lényeg, a bugreport “kivitelezése”, és a hozzá tartozó sztori.

A NeXT-ről nem ejtenék most sok szót, jobb helyeken a neten meg szétszórva itt nálam a blogarchívumban elég sok olvasható Steve másik számítógépcégéről, miért volt jó, meg mennyivel járt kora előtt stb (ma is kb minden Apple termék NeXT (szoftver-)technológiát használ vagy arra épül, az iTunes Store-tól kezdve az iPhone appokig).

Annyit azért el kell mondanom, hogy az első NeXT gépek egyetemekre meg kormányhivatalokba kerültek (később is a legnagyobb vásárlók ezek voltak, beleértve a titkosszolgálatokat, kiegészítve bankokkal. Itthon a SZTAKI-t meg a Graphisoftot említeném meg, mint jó ellátott helyeket), gyakran tesztelési céllal, a nem teljesen kész operációs rendszerrel rátöltve. Ami gép és os megjelenésekor évekkel, évtizedekkel előzte a piacot, részben ebből él ma is az Apple.
Valahonnan innen érkezett a bugreport is. A dátuma 1988 december 18-a, a 312-es sorszámú Cube, amin a 0.8-as verziójú operációs rendszer fut a hibát generáló előzetes (preliminary) kiadású Interface Builderrel.


a bugreport második oldala

Két dolog érdekes ebben az egészben.
Az első, hogy milyen szép részletesen írnak, és milyen lelkesedéssel a gépről. Hiszen ilyen rendszer még korábban nem létezett, és utána még évekig más sem.
Péntek délután kapták meg a hardvert, és ahelyett, hogy például hazamentek volna hétvégére, azonnal nekiestek, és elkezdték próbálgatni, rögtön az alkalmazásfejlesztést. És a végülis működő, (és ahogy kiveszem, “normál üzemben” rendesen visszatérő) programban egy bizonyos objektum kiválasztása mégis hibát okoz (ne feledjük, első teljesen objektum-orientált rendszerről beszélünk). Az info panel mai nevén egyébként az Application menüben az About <programnév> alól nyitható meg.
Kedves és egyben ijesztő a “van még ezernyi megjegyzésünk, kérjük ezt csak bevezető üzenetként kezeljék” mondat. De talán a legjobb a végén, az utolsó, egymondatos bekezdés, ami rávilágít, az új és zseniális rendszer:
“Thanks to all at NeXT for making this a reality.”
Ne feledjük, a dokumentum egy hibajelentés, nem köszönőlevél, mégis…

A másik érdekesség, hogy a NeXT-nél annyira megörültek ennek a legleső bugreportnak (mert mérföldkőt jelentett a cég történetében, több év fejlesztés után végre kikerültek a “vadonba” az első gépeik, és használják emberek őket), hogy kinyomtatták, bekeretezték, és kifüggesztették az irodában a falra. Az eBay-es eladó leírása alapján végig ott is lehetett, mert ő akkor vette meg, mikor megszűnt önálló cégként üzemelni a NeXT és kiárusították az ilyen dolgait.
Nem tudom más cég csinált-e, csinálna-e ilyen dolgot, de a NeXT kultúrája nem az a hagyományos élrevasalt cégkultúra volt.

Az OS X, az Apple és a switcherek

os x dobozok

Kezdjük ott, hogy a Tiger (Mac OS X 10.4) volt a legjobb osx változat. Már a Panther (10.3) is kiforrott rendszernek volt tekinthető, de a Tiger hozta azt a stabilitást, sebességet, amit azóta sem láttunk (félreértések elkerülése végett: újabb rendszerek valóban mind gyorsabbak mint az előzőek… de csak ha erőgépen futtatod. Tiger öreg G3-okon is tudta ezt.)
Valahogy ezt kellett volna továbbvinnie az Apple-nek.

De nem ez történt (és ebben bizonyára szerepe van az intelre váltásnak is, de ez most nem az a poszt). A Leopard és Snow Leopard esetében (10.5, 10.6) már látszott, hogy az Apple az új változatokat nem a régi felhasználóinak készíti, hanem a Windowsról váltott, vagy onnan átcsalogatni kívánt embereknek (“Windows switchers”). Ez a filozófia és folyamat a sok új, valóban hasznos fícsör és egyéb parasztvakítás ellenére a power userek számára a rendszer sajnálatos butulásával (és windowsosodásával, itt ezek most szinonim fogalmak, nem trollcsali) járt együtt.
Szívtuk a fogunkat, de nem volt mit tenni.

A Lion (10.7) esetében az Apple még tovább ment. Felfedezte, hogy, míg az intelre váltás után Windowsról érkezett sok új felhasználó, a platformváltás utáni évben bemutatott iPhone és a többi iOS eszköz nyomán az utóbbi években onnan érkezik a legtöbb új Mac felhasználó.
Így számukra készítették el a legújabb rendszert, azaz az iOS-ről Mac OS X-re váltóknak (iOS switchers).
Ami a sok új látványos fícsör ellenére kurvára nem tesz jót a rendszernek. Power user szemmel (na, már megint, de jobb szó egyelőre nem jut eszembe) meg pláne, van pár dolog ami ki van kapcsolva, vagy úgy kell előcsalogatni (elrejtett Library??), és pár dolog amit pedig azonnal jó kikapcsolni.

Első OS X-eket még úgy rakták össze, hogy próbáltak egy új, rendes rendszert létrehozni (apránként, de sikerült). Nem úgy, hogy OS 8-9 switchereknek, azaz a teljes akkori felhasználói bázisuknak, akik életben tartják a céget ismerős, megszokott legyen az új operációs rendszer. Tudták, hogy ők hamar képesek lesznek azt megtanulni, használni.
Azóta, úgy tűnik, sokat változott a világ.

Verdikt: már az sem volt jó ötlet, hogy Windowsosítani akarták a rendszert, bár azok még bátortalanabb lépések voltak. Az iOS-szel keresztezni pedig egyenesen rossz döntés innen nézve, pedig a folyamat valószínűleg nem fog leállni. Ezt jelzi az a szimbolikus apróság is, hogy kikerült a rendszer nevéből a ‘Mac’. A Mac OS XI valószínűleg ennek a folyamatnak a végállomása, avagy egy újabb korszak első állomása lesz.

Megjegyzés: posztíró egyelőre nem frissített Lion-ra, de előbb-utóbb természetesen megteszi. A Golden Master verzió és mások leírásai alapján rögzítette benyomásait. Néhol meg szándékosan fogalmaztam kicsit sarkosan, néha nekem is szabad rinyálni a saját blogomon, nem? A vélemény ettől függetlenül áll, és azt hiszem, sokan egyetértenek velem mind a folyamatot, mind a következtetést illetően. Aki nem, az győzzön meg.

Magyar QWERTY billentyűzetkiosztás Macintoshra

Hungarian QWERTY

Az egész ötlet onnan jött, hogy még régen, mikor sokszor írtam kódot megszoktam az amerikai angol kiosztást, mivel ott könnyen elérhetőek a nem alfanumerikus karakterek, amik szükségesek kódíráshoz. Évekig használtam minden alkalomra így az angol kiosztást, de mostanában egyre gyakrabban van, hogy kénytelen vagyok magyarra váltani az ékezetek miatt (vagy úgy döntöttem, hogy magyarra váltok, mint pl. most), mert nagy szövegmennyiségnél már kényelmetlen az ⌥+e + <betű> és tsai. Továbbá, amikor csak simán szöveget írtam, már korábban is zavart a németmajmolásból még az írógépkorszakban elkövetett, és a számítógépek világába is átvett y-z csere. Ez azóta csak fokozódott.
Először tehát csak ezt javítottam ki a saját kiosztásomnál, de hamar elkezdtem más apróságokat is implementálni vagy javítani, főleg a rendszerspecifikus, a gyári magyar kiosztásból hiányzó, de általam gyakran használt kombinációkat. Közben menő ikont is kapott, hogy nézzen ki valahogy (csinálj jobb ikont 16×16 pixelen, amin látszik, hogy magyar, hogy qwerty, és olvasható is!). Szóval ez nem az első verzió, és valószínű, hogy nem az utolsó, mert esélyes, hogy matatok még vele (tervek vannak).

Most pedig nyilvánossá teszem a cuccot

Tehát, qwerty a kiosztás, de magyar ékezetes betűkkel. Teszteltem Mac OS X 10.4-től 10.7-ig (zárt intervallum, utóbbiból származik a fenti keyboard viewer screenshot is), megy mindenütt. Működnek vele olyan shortcutok amik a gyárival nem, és van pár egyéb apróság is.
Bővebben ezekről a billentyűzetkiosztás honlapján lehet olvasni.

Macintoshról van szó, tehát a telepítés egyszerű: másold be a Library-ben található Keyboard Layouts jegyzékbe. Jelentkezz ki-be.
Részletes leírást a telepítésről a billentyűzetkiosztás honlapján lehet olvasni.

Letöltés: HunQWERTY (2011.07.03)

Twitter for Mac “Super Secret” tulajdonságok kikódolása

Egy hete, mikor írtam a Tweetie filterezéséről még nem tudtam, hogy hamarosan, azaz csütörtökön megjelenik, azaz most már megjelent a következő verzió. Ami már a Twitter for Mac nevet viseli (ezt speciel tudtam :)

A programnak van pár szép fícsöre, halom dolog nem jó benne, meg van aminek működnie kéne de nálam mégsem teszi, mindegy, most nem kritika jön.
Kiderült ugyanis, hogy van pár “super secret” fícsör benne, amit a legutóbbi MacHeist nanobundle vásárlói érhetnek el. Nekik anno megígérték, hogy megkapják a vásárlásukhoz a majdan megjelenő Tweetie2-t, de az időközben baszott megjelenni, majd most Twitter néven ingyen jött. Ezzel kompenzálják őket, ugye.
Screenshot készült a titkos panelról.
Én meg úgy voltam vele, ha be lehet kapcsolni, akkor az bizony ott van, akkor miért ne keresném meg? Ma délelőtt nekiültem, és sikerült bekapcsolni őket:

Túlzottan nem hiányoztak, inkább a “szakmai érdeklődés” (hehe) csináltatta velem. Először a második meg harmadikat intéztem, mert azok mégis remek kényelmi megoldásnak tűntek. A hide in background annak jöhet jól, akinek nagyon zsúfolt a timeline és a folyamatos update miatt könnyen elterelné a figyelmét a munkáról vagy bármi másról.

Most csak a Terminal-parancsokat adom meg, hogy lehet ezeket bekapcsolni (ugyanabban a sorrendben, mint a képen) mert éhes vagyok:
defaults write com.twitter.twitter-mac UserTimelineDerepeater -bool TRUE
defaults write com.twitter.twitter-mac ScrollingMakesKeyAndOrdersFront -bool TRUE
defaults write com.twitter.twitter-mac TypeAnywhereToTweet -bool TRUE
defaults write com.twitter.twitter-mac HideInBackground -bool TRUE
defaults write com.twitter.twitter-mac ESCClosesComposeWindow -bool TRUE

Kikapcsolni értelemszerűen a FALSE-szal. Vagy törölni.

Azt hiszem, most reggelizek egyet, és még kutakodok, mert találtam egyéb érdekes dolgokat is, amikkel jó lenne rájönni, hogy tudnék kezdeni valamit. Ja, filterezésre gui itt sincs, de a korábbi trükk sem működik.

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?

“Eszem-faszom megáll”, mondaná Ford Fairlane – WWDC 2009

Na, ma hajnaltól egész nap nem voltam itthon, magyar idő szerint este sikerült hazesnem úgy, hogy elkapjam az Apple WWDC keynote végét. És behozni az elejét. Ahogy a címben említettem: egyem-faszom megáll! Pedig én mindig az Apple szétszedésével szoktam beszámolni a keynote-okról, egyelőre még keresem ezeket a dolgokat.
Addig is betolok egy kis Little Axe-t és leírom, hogy mi a lófasz van, hogy egy korábbi konzulensem idézzem (az idézet pontosan így szólt, a szövegkörnyezet az volt, hogy a komplex tervezési feladatot hogy kell leadminisztrálni, meg ilyesmi, X tanár úr a jegyzője ennek és régi ismerőse a volt konzulensemnek: (…) menj már fel akkor a tanszékedre X tanár úrhoz, és mondd meg neki, hogy B tanár úr tiszteletteljesen kérdezteti, hogy mi a lófaszt csináljunk?! Igen, van egy stílusa a faszinak, de arany szíve van és a profanitásokat sem gondolja komolyan).

Szóval, frissült a 17-es kivételével a teljes Macbook vonal. Olyannyira, hogy a MacBook (a legacy fehéret nem nézve) megszűnt, azaz átlényegült 13″-os MacBook Pro-vá. Már majdnem a 12″-os PowerBook utódának tekinthető! Tehát mivel MBP lett, így a lowend modell (1200 dolláros alapár, a mostani alap alu ha jól emlékszem 1300 volt) is háttérvilágító billentyűzet meg hasonló gezemicéket kapott, meg, mint a 15″-os, SD kártyahelyet, de, ami a lényeg: FireWire! Firewire 800 van minden alubody MacBookban! (és a nép örvendezik vala). Emellett minden alubody MBP megkapta a 17″-osnál bevezetett új csodaakksit, amiről egyelőre csak annyit tudunk, hogy nem lehet cserélni, azt, hogy tényleg annyi órát és annyi éven át fog bírni, hogy cserére nem lesz szükség, majd hiszem ha látom. Nem telt el még annyi idő, hogy bárki lássa. Tehát majd meglátjuk. Szóval most ott tartok, hogy nagyon kéne egy 13″-os MBP :))
Ja, frissítették a MacBook Air-t is, meg durván leárazták, de még így is egy túlárazott baromság, de legalább már kevésbé túlárazott.

Lesz Hópárduc (Snow Leopard) is, ma új fejlesztői változat van, a boltokba véglegesen szeptemberbe kerül, olcsón. És tele lesz pakolva mocskosul jó cuccokkal, meg ráadásul végre teljesen átírták a Finder kódját. A finomságok között ilyen mókás dolgok is lesznek, mint kézírásfelismerés támogatása a trackpadről. Továbbá halom apróság, amik viszont jelentősen javítják majd a felhasználói élményt. Nem beszélve a több processzormag és a 64 bites architektúra egyre jobb kihasználásáról. Azt hiszem, ha a héten megnyerem a lottóötöst, megvárom szeptembert a MBP vásárlással (ezt úgy mondom, mintha lottóznék…). A PPC támogatásról természetesen nincs hír (hivatalos doksi lehet hogy van, de én nem láttam, ami azt írja, hogy nem támogatja PPC-t), most is elmésen kerülték a témát. Azaz egész pontosan azt mondták a Hópárducról: It will be available for all Intel Macs, past and present. Amivel, ha az ember értelmezi (intencionális szintje az információnak) azt mondta Schiller, hogy PPC-re nem lesz elérhető.

iPhone OS 3.0 és új iPhone 3G[s]. Megint láthattunk demot az új iPhone OS-ből és az új iPhone-nal. Na, ez a durva. Felsorolni is hosszú lenne, csak néhány cucc címszavakban: felszabadult bluetooth és kamera, maps api, bárhonnan lekérhetjük a telefon helyzetét, státusát (hasznos ha elhagytuk vagy ellopták), távolról formázhatjuk is (detto), gps is szabadon hozzáférhető lett fejlesztőknek (és programjaiknak, ugye), digitális iránytű, miegymás. A kamera új, menő satöbbi lett, viszont amit lehet vele csinálni, az tényleg az. Természetesen videóra is jó, felveszel mozgóképet aminél előzetesen adatokat adhatsz meg, azt helyben vághatod/szerkesztheted, majd megoszthatod. Az autofókusz képes lesz úgy is fókuszálni, hogy te mondod meg, a keresőmezőben melyik tárgy legyen a fókuszpont. Meg ilyenek. Lesz benne sok performanszjavítás, halom új fícsör, köztük viccesek is, például hanggal is lehet utasítást adni neki és úgy vezérelni (pl megkérdezni, hogy milyen dal szól most, játsz hasonló dalokat, hívd fel a pápát vagy térdelj le és szeress (utóbbi egyelőre nem, de dolgoznak a megfelelő hardveres kiegészítőn, ha valaki még közelebbi, intimebb kapcsolatba akar kerülni az iPhone-jával)), ami utasításszöveget át is úsztat a képernyőn, meg tud ő is beszélni, satöbbi.
Szerintem az iPhone-ból lesz a Skynet hamarosan, elnézve miket fog tudni az új készülék az új firmware-rel és ez mit vetít előre. Kezdjünk felkészülni az iTélet napjára (bocsi :)
A Gold Master mától elérhető.

Az új szifon 16 gigás és 32 gigás lesz, előbbi potom 200 dollárért (tavaly februárban én 400-ért vettem a touchom), utóbbi 300-ért, de a mostani iPhone 3G 8 gigásat is árulják majd potom 100-asért. A konkurrencia ha nem lép azonnal valami nagyot hardver && szoftver && ár terén akkor nem csak a gatyáját, hanem saját magát is felkötheti (pedig azért kis verseny nem ártana az Apple-nek, mert megint el fognak szállni nagyon maguktól).
Az új készülékek (és akkor az új firmware is, remélem az első generációs touch-omon minél több fontos eleme elérhető lesz, mert ha pénzem lenne rá sem akarom lecserélni a készüléket) jövő péntektől a boltokban (egyelőre ámerika), azaz június 19-e.

Az viszont biztos, hogy az APPL ma jókorát fog emelkedni, pedig még Steve sem jelent meg meglepetésként a színpadon (miért tette volna mondjuk). Viszont ahogy látom, ahogy kezdtem belejönni a bejegyzésírásba mégiscsak sikerült kicsit beszólogatnom az Apple-nek. :)

10.5.crash

Vannak olyan újdonságok a Leopárdban, amiket meglehetősen kedvelek.
Aztán vannak olyan újdonságok a Leopárdban, amiket meglehetősen nem kedvelek.
Aztán vannak olyan újdonságok a Leopárdban, amik nem fícsörök, hanem bugok.

Eme rövid áttekintő bevezetés után megosztom tegnapi élményemet. Olyat fagyott és omlott össze a gép, amilyet még nem láttam. Persze, a 10.5 még mindig egy rohadtul béta rendszer, bármit mondjon az Apple, de akkor is. Új rendszer, sok újítás, újfajta hibák.
Tegnap este szinte Zen pillanatot éltem át. Először megjelelent a dokkban mozilla Talkback funkciója, ami már akkor szól, hogy lefagyott a termékük, mikor neked még sejtelmed sincs róla. Egyszer azt veszem észre, hogy csendben pattog a dokkom tövében.

Idő lelassul, szélfuvallat sincs, madarak is elhallgatnak várakozásteljesen. Rossz hírek hozója, Talkback még mindig pattog a dokkban, nem indul. Camino (egyetlen Mozilla-termék a gépen) még üzemben. De aztán jött a kernel mélyéről egy Oni (démonnem daemon!) és elkezdte fogyasztani a gépem erőforrásait. A rendszer szép lassan elkezdett összeomlani. Lelőttem a Talkback-et. Erre programok, szép lassan, egymás után lekapcsolták magukat. Egyik a másik után. Olyan volt az egész, mint Sakuravirágzás idején figyelni a hulló cseresznyevirágszirmot, és elmerengeni minden dolgok múlandóságán. Nincs jelen senki más, csak a lassan hulló szirom (saku) és te, a külvilág nem ér el a pillanatba. Camino érdekes módon sokadiknak hullott el. Nemsokára követte a Finder. Néhány percbe tellt az egész. Mondom, mint egy lassan lehulló cseresznyevirág valahol Japánban, egy szent hegyen, egy templom kertjében, vagy külvárosi éjben. Egy teljes világ pusztulása (jelesül a számítógépemé) egyetlen apró eseménybe sűrítve, lassított felvételen. Aztán a pillanat végetért, a külvilág újra betolakodott a meghitt elmúlás szemlélésébe. A háttérben taiko dobolást hallottam, mintha matsuri (fesztivál) készült volna, lehet, az Onik távoltartására.

Azóta rájöttem, hogy valószínűleg mégis egy Hóasszony (Yuki-onna) támadott meg, és fagyasztotta be a rendszert, ami ennek hatására összekuporodott önmagába és csendben kilehelte lelkét. Végül eltűnt a desktop, vele a dokk és menübár és én egyedül maradtam a sötéten és hidegen világitó monitorral, miközben éreztem a Hóasszony hideg leheletét.
Kézzel (hardveresen) lekapcsoltam a rendszert, mi mást tehettem volna?

ph34r t3h l30p4rd

10.5 regi gepen Kaptam kölcsön egy barátomtól egy dobozos Leopárdot (Max OS X 10.5), elég faszán néz ki a hologramos csomagolás meg minden, hogy csináljak neki biztonsági másolatot. Uagynis ő szereti magánál hurcolni a rendszert, de ezt nincs szíve, mert olyan állapotba is kerülne (pl a gépéhez adott tiger dvd tokja is hogy néz ki… elég leharcolt). Nekem ugyan nincs leopárdképes gépem (Minimálkonfig: G4-es proci legalább 867-es órajellel, meg 512 ram. Az én gépeim vagy nem G4-esek, vagy régebbiek.), de van dual layeres íróm. De rendes srác, természetesen megengedte, hogy csináljak magamnak is egy biztonsági másolatot. És ha már, akkor belenyúltam a telepítőbe. Kicsit buheráltam a gépellenőrzéssel foglalkozó programsorokon. Van itt nekem (még egy napig, anyagi okokból megválok tőle, de majd az árából +egyéb pénzből elérhető lesz egy ámerikás iPod touch, ha lesz ámerikás kontakt) egy 466 Mhz-es PowerMac G4 Digital Audio-m, 256Mb rammal. Gondoltam, kiprobálom a Leót. Ezért nyúltam bele a telepítőbe. Levittem a minimális memóriakövetelményt 256-ra (alacsonyabbra nem hiszem, hogy megérné), a minimális órajelet 300 Mhz-re (szintén) és megváltoztattam a G3-as procit ellenőrző függvényt is – elvileg el kell indulnia G3-on is, de nem próbáltam, és állítólag ha nem is ellenőrzi sem képes már a Leopard G3-on működni.
És ímhol, a haxolt 10.5 megy a régi masinán! :) Kicsit soká tartott telepíteni, meg semmi csilivili nem megy rajta (azokhoz már Quartz Extreme meg Core Image kéne), viszont így szebb is, mint amúgy, kevesebb a csillogás, és nem átlátszó a menüsor alapból sem. Amúgy első blikkre azt kell, hogy mondjam, hogy sokat változott a rendszer. Nem a felszínt értem itt, hanem a mélyműködést. Hosszabb tesztre sajnos nem fogom tudni fogni a 10.5-öt, mert holnap, ha minden igaz a masina megy az új tulajdonosához. Majd ő játszik vele.