‘OS X’ címkével ellátott bejegyzések

Susan Kare munkái

2011. december 9. péntek

Susan Kare a ‘80-as évek elején csatlakozott az Apple-höz és a Macintosh felhasználói felületének több elemét is ő készítette el – így például jónéhány ismertebb ikont is. De nem csak az Apple-nek, hanem a világ vezető szoftvercégeinek is tervezett ikonokat, ezért az ügyfelei között olyan nevek is szerepelnek, mint az AT&T, Cisco, Facebook, IBM, Intel, Microsoft, Motorola, Nokia, Oracle, vagy pl. a Xerox. Az általa készített munkákból szemezgetnék most párat, melyek talán ismertebbek és amelyek nekem is jobban tetszenek.

Látszólag nem nagy dolog ilyen ikonokat összehozni, viszont aki már egyszer megpróbálkozott vele, az tudja, hogy mégsem olyan egyszerű ez, mint amilyennek látszik… :)

Susan nevéhez fűződik többek között a Chicago, a Geneva és a Monaco nevű font is.

Akit esetleg jobban, vagy bővebben is érdekelne a dolog: a fenti ikonok Susan Kare által kiadott különböző nyomtatott, limitált és dedikált formában megrendelhetők a kareprints.com oldalon.

Folyamatosan leálló, majd újra felpörgő merevlemez

2011. november 6. vasárnap

A hétvégén – még a nagy merevlemez-drágulás előtt pár nappal – beszereztem egy nagyobb winchestert (2,5″-os, Western Digital Scorpio Blue). Feltettem rá az OS X-et, majd meglepődve vettem észre, hogy bizonyos időközönként (elég gyakran, percenként több alkalommal) leáll a merevlemez, ill. amikor éppen szeretne írni/olvasni róla adatot a gép, akkor újra felpörög. Utánanéztem a dolognak és szerencsére találtam rá megoldást, melyet most meg is osztanék.

Kis keresgélés után viszonylag gyorsan rájöttem, hogy a fenti probléma nem egyedi eset. Az ilyen leállás-újraindulás az APM (Advanced Power Management) miatt van, mely arra hivatott, hogy a merevlemez – amikor éppen nincs használatban, akkor – a leállással energiát spóroljon. Őszintén szólva nem sok értelmét látom, hogy percenként több alkalommal leáll és újból felpörög, mert egyrészt általában az indításkor több áramot vesz fel minden eszköz, másrészt pedig így az élettartama is csökken… A mérnökök jobban tudják, biztosan tesztelték, kipróbálták, utánanéztek és úgy találták, hogy ez a jobb megoldás, de ennek ellenére (akármilyen mechanizmussal látták is el ezeket a HDD-ket) iszonyatosan zavaró a folyamatos leállást és újraindulást hallani.

Rábukkantam erre az oldalra, ahonnan letölthető egy hdapm-installer.dmg nevű fájl, ami gondoskodik arról, hogy merevlemezünk ne álljon le folyton. A dmg fájlt megnyitva, majd a benne található hdapm.pgk állományt telepítve egyből, újraindítás nélkül megszűnik az idegesítő felpörgés és egy szépen, folyamatosan járó merevlemezt kapunk. Szerencsére a rendszer újraindítása után sem kell újból futtatni semmit, mert a fenti probléma tünetmentesen elmúlik.

Ez egyébként egy évek óta fennálló jelenség, azért írok csak most róla, mert én eddig nem találkoztam még ezzel és egészen biztosan lesz olyan, aki majd még csak ezután fut bele először.

Boxer

2011. október 19. szerda

Azt hiszem, hogy ezt a szoftvert már rengeteg Mac-es ismeri évek óta, én viszont csak nem rég tudtam meg Vilmostól, hogy létezik egy Boxer nevű, ingyenes, nyílt forráskódú, DOS emulátor OS X alá, mely a DOSBox-ra épül. Ettől függetlenül írok róla pár sort, hátha olvassák olyanok a blogot, akinek ez még szintén újdonság.

A használata végtelenül egyszerű, „fogd és vidd” módszerrel tudjuk elindítani a futtatható állományokat, de szükség esetén egy DOS ablakot is nyithatunk, ahol megjelenik a régi időkből jól ismert DOS prompt. Érdemes szétnézni a program beállítási lehetőségei között – pl. Emulation menüpont – mert a mai számítógépeken nem minden esetben úgy futnak a szoftverek, ahogy annak idején.

Megemlíteném még a Boxer kapcsán, hogy az interneten rengeteg régi, DOS-os játékot találhatunk meg és férhetünk hozzá ezekhez sokszor teljesen ingyenesen és egyben legálisan is.

Bár magam is sok éve, rendszeresen végzek társadalmi munkát, de ettől függetlenül sokszor elcsodálkozom az ilyen szoftverek készítőin, akik miután rengeteg órát fordítottak egy-egy program megírására és tesztelésére, azt forráskóddal együtt a köz rendelkezésére bocsájtják – teljesen ingyenesen.

Firefox 7

2011. október 1. szombat

Szeretem, amikor egy szoftverbe nem csak újdonságokat pakolnak, hanem időnként optimalizálják is és próbálják elérni, hogy gyorsabban fusson, ugyanakkor viszont beérje kevesebb memóriával is. Le a kalappal a Mozilla fejlesztői előtt, a hetes Firefox egy nagyon kellemes meglepetés lett OS X alatt.

A memóriahasználatot nem nagyon szoktam figyelni (állítólag ez már jóval kevesebbel is beéri mint az elődje), inkább azt figyelem, hogy egy új ablak vagy tab mennyi idő alatt nyílik meg és sok-sok aktív tabbal mennyire lassul be. Bár az új ablak nyitását még azért lomhának érzem, de összességében az egész szoftver jóval gyorsabb lett, élvezet használni. Talán ez az eddigi leggyorsabb Firefox, amivel találkoztam.

A Mac OS X ereje

2011. augusztus 14. vasárnap

Több, mint 73 nappal, 6 órával és 31 perccel ezelőtt kapcsoltam be a Mac-et. Most viszont eljött az ideje az újraindításnak, mert már jó ideje ott figyeltek az újraindítást is igénylő frissítések a Software Update ablakban. Ha jól rémlik, akkor Debian alatt valamivel több, mint 250 nap volt az eddigi uptime rekord (parancssoros környezet, web- ill. FTP szerver), Windows alatt pedig valami 2 hét körüli időre emlékszem.

A Mac-et ha nem használom, akkor csak sleep módba teszem, ahogy talán a legtöbb Mac felhasználó. Nagyjából 2 másodperccel az Apple menü Sleep menüpontjára való kattintás után már alszik is és kb. ugyanennyi időre van szüksége, hogy az óránként néhány wattot fogyasztó alvó állapotból felébredjen és az összes ablakot a tartalmával együtt a sleep előtti állapotban lássam viszont. Ez főleg akkor hasznos, ha előre láthatólag valamiért hosszabb ideig nem vagyok gépközelben (ez nálam azt jelenti, hogy kb. 20-30 percnél tovább).

Többen kritizálták már a sleep módban történő árampazarlást, de azt sokan nem tudják, hogy ez a fogyasztás ilyenkor minimális (tényleg csak néhány watt). Ha valakinél otthon egy órára véletlenül bekapcsolva marad a TV, akkor az gyakorlatilag több áramot elhasználhat, mint naponta egy Mac alvó állapotban…

Ahhoz pedig, hogy ennyi legyen az uptime, nem kell más, mint vagy egy kis szerencse (hogy hónapokig ne legyen áramszünet), vagy pedig egy szünetmentes tápegység – ahogy erről korábban már írtam is. Mondjuk a Security Update-eket sem a legjobb kihagyni, ezek viszont sajnos ilyen újraindítást igénylő dolgok.

Egyébként még mindig a Leopardot nyúzom és nem hiszem, hogy mostanában válatni fogok Snow Leopardra (pedig a polcon pihen egy az XMS-ből vásárolt páldány), Lionra meg főleg nem. Hiába számít réginek, vagy elavultnak a Leopard, egyelőre a stabilabb működést sokkal többre értékelem, mint a technikai újításokat. Természetesen, ha lenne egy valamilyen második Mac is a házban, akkor biztosan kipróbálnám a Liont, de így inkább egyelőre nem kockáztatom meg.

Gyorsan utána számoltam, hogy ha netán ismét uptime rekordot szeretnék dönteni, akkor mostantól kezdve nagyjából október végéig kellene mennie kikapcsolás és újraindítás nélkül. Ha pedig a következő 17 napban nem kell újraindítani, akkor elmondhatom magamról, hogy idén nyáron összesen csak két alkalommal kapcsoltam be a gépet… :)

A MySQL és a Mac OS X

2011. július 18. hétfő

Egy bejegyzés arról, hogy hogyan tudod használni Mac OS X alatt a MySQL-t (MAMP nélkül), ha a „gyári” telepítővel nem sikerült volna összehoznod a dolgot.

Régebben már próbáltam feltenni Leopard alá a MySQL-t, de mivel nem jött össze egyből és nem is volt rá túl sok időm, ezért akkor nem foglalkoztam tovább a dologgal. Szerencsére mindig volt és van a közelben néhány Linux alapú webszerver feltelepített MySQL-lel amit elérek, így nem volt annyira égető a kérdés. Aztán decemberben vásároltam egy Snow Leopard DVD-t, megpróbálkoztam a telepítéssel (nagyon negatív tapasztalat), de a szóban forgó adatbázis-kezelő az alatt sem jött össze. Bár nem a MySQL miatt, de pár órán belül visszatettem a Leopardot és folytattam mindent ott, ahol azelőtt (így gyakorlatilag lett egy teljesen újonnan telepített rendszer, ami alatt a MySQL még mindig nem akart működni).

Akik ismerik a Mac-et, azok tudják, hogy a világon talán Mac-re legegyszerűbb telepíteni bármit is. Az esetek 90%-ban megnyitjuk a .dmg fájlt, feljön egy ablak, ahol közlik velünk, hogy azt az egyetlen egy fájlt húzzuk az Applications könyvtárba és néhány másodpercen belül már indíthatjuk is a frissen telepített szoftvert. Bár néha azért előfordul, hogy parancssorban kell valamit kutyulni, de ezt egyrészt megszoktam Linux alatt, másrészt pedig nem szokott gondot okozni a parancssoros használat.

Néhány napja gondoltam egy merészet (hajnali három után néhány perccel) és kitaláltam, hogy most felteszem a MySQL-t, akármi is lesz a vége, vagy akármeddig is fog tartani. Olyan nincs, hogy nem működik rendesen. Hát tévedtem. Egy rosszul megírt alkalmazáson nem nagyon segít az, ha egy óra helyett ötöt töltünk el a telepítéssel és beállításokkal…

Mac-re – legjobb tudomásom szerint – kétféle képpen lehet feltenni a MySQL-t. Egyszer hagyományos módon fel kell telepíteni a mysql.com-ról letölthető „gyári” .dmg fájlt (csúnya kifejezés, de jelenleg nem tudok jobbat), majd a szükséges dolgokat be kell állítani. Ennek mérete (5.5.8-as MySQL) pedig kb. 82 MB-os. A másik módszer az, hogy feltesszük a MAMP-ot, ami szintén egy .dmg-ben tölthető le. Itt nem kell vesződni a beállításokkal és a MySQL mellé kapunk még jópár dolgot, viszont ez több, mint 160 MB-nyi helyet foglal (kicsomagolva több, mint 350 MB). Bár annak idején kipróbáltam a MAMP-ot, de úgy döntöttem, hogy mégegyszer nem teszek fel a gépre egy ilyen sok száz megás szörnyeteget, ne foglalja a helyet és az erőforrásokat.

Visszatérve a mysql.com-ról letölthető MySQL szerverre: a telepítéssel nincs gond, viszont a beállításnál már jobban oda kel figyelni, ugyanis az OS X alatt található Apache beállításaihoz képest a telepítő a socket fájlt teljesen máshova rakja, így eleve nem is nagyon működhet normálisan a rendszer. Aztán ha erre a logfájlok és/vagy az internet segítségével sikerült rájönnünk, akkor jön az, hogy a MySQL .dmg fájljában található MySQL.prefPane csak leállítani képes a mysqld-t, elindítani már nem (legalábbis nekem többszöri nekifutás után is ez volt a probléma). A MySQLStartupItem.pkg sem váltotta be a hozzáfűzött reményeket, így azt nem is tettem fel mégegyszer.

Tehát a lényeg, hogy socket fájlnak adjuk meg a rendes, valódi helyét az /etc/php.ini fájlban – ez a várakozásokkal ellentétben a /tmp/mysql.sock helyen található. Ezt írjuk is be a php.ini-be a következő helyre és a következő formában:

mysql.default_socket = /tmp/mysql.sock

Most adjuk ki parancssorban a

sudo apachectl restart

parancsot az Apache újraindításához, ezután pedig indítsuk el a MySQL kiszolgálót a

sudo /usr/local/mysql/bin/mysqld_safe

parancs beírásával. Most elvileg fut a mysqld. De hogy ne legyen minden ilyen egyszerű, ezért a leállítása sem olyan hétköznapi, mint Linux alatt:

sudo /usr/local/mysql/bin/mysqladmin –user=root -p shutdown

Nekem csakis a fenti módon hajlandó futni, a visszadobott hibaüzenetek számát pedig sikerült egyre redukálnom, a telepítés és beállítás több, mint 5, azaz öt órája alatt. Őszintén szólva el is ment a kedvem az OS X alatti MySQL telepítgetésektől egy jó időre…

Azért azt leírnám, hogy van olyan 2002-ben(!) írt fórumbejegyzés a neten, ahol kb. ugyanezekkel a dolgokkal küzdöttek. Magyarul kilenc év kevés volt a MySQL fejlesztőcsapatának ahhoz, hogy megváltoztassák a socket fájl default helyét és megoldják, hogy telepítés után egyből használni lehessen a MySQL-t ugyanúgy, mint sok ezer másik programot. Ezek után mindenki gondoljon ezzel kapcsolatban azt, amit akar…

Bonyolítsuk még picit, hogy később egyszerűbb legyen

Ha a telepítéssel és a beállításokkal megvagyunk és netán még a mysqld-t is sikerül elindítani / megállítani, akkor szánjunk még egy kis időt a további beállításokra, hogy később a kiszolgálót sokkal könnyebben tudjuk elindítani és leállítani.

Írjuk be a következő (valójában két sornyi) szöveget a felhasználói könyvtárunkban található .bash_profile nevű fájlba (erről bővebben az előző bejegyzésben olvashatunk).

alias mysql-start=”sudo /usr/local/mysql/bin/mysqld_safe”
alias mysql-stop=”sudo /usr/local/mysql/bin/mysqladmin –user=root -p shutdown”

Ezzel gyakorlatilag azt érjük el, hogy ha el akarjuk indítani a MySQL kiszolgálót, akkor elég lesz azt beírni a parancssorba, hogy mysql-start, a leállításához meg az, hogy mysql-stop.

A bejegyzésben említett telepítés Mac OS X Leopard (10.5.8) alatt történt, de gyaníthatóan 10.6 alatt is valami hasonló lesz a MySQL problémájára a megoldás. Minden esetre örülnék annak, hogy aki e bejegyzés alapján megpróbálja, az esetleg visszajelez egy komment vagy egy e-mail erejéig, hogy mire jutott.

Ha pedig valakinek ezek alapján sikerült életre keltenie a MySQL kiszolgálót OS X alatt, akkor egyet kattinthatna a tetszik gombra itt alul, mert nagy valószínűséggel épp most mentettem meg több órai szenvedéstől és felesleges próbálkozástól. :)

A .bash_profile fájl létrehozása Mac OS X alatt

2011. július 14. csütörtök

Szeretem a Mac-ben azt, hogy UNIX alapú. Mivel a GNU/Linux-nak is UNIX-os gyökerei vannak, ezért (pl. parancssorban, ill. működést tekintve) eléggé látványos a Linux és a Mac OS X közötti rokonság. Azoknak pedig, akik amúgy is sokat koptatják a billentyűzetet valamilyen Linux rendszer alatti parancssorban is, ez a rokoni kapcsolat kifejezetten jól jön, többek között az alább leírtak is nagyjából ugyanígy működnek a különböző Linux-disztribúciók alatt (bár néhány apró eltérés lehetséges).

Minden felhasználói könyvtárban van (ill. ha nincs, akkor mindjárt létrehozzuk) egy .bash_profile nevű fájl, amivel adott esetben egyszerűbbé és kényelmesebbé tehetjük életünket.

Lássunk is neki. Először is nézzük meg, hogy létezik-e a .bash_profile nevű állomány. De ne a Finder segítségével keressük, mert azzal picit bonyolult lesz megtalálni, hanem a parancssorba (Terminal, vagy tetszés szerinti hasonló alkalmazás) írjuk be a következőt:

ls -a ~/

Az ls parancs a fájlok listázására szolgál, a -a kapcsolóval pedig megadjuk neki hogy minden (all) fájlt listázzunk ki. A ~/ pedig azt jelenti, hogy ezeket a dolgokat a saját felhasználói könyvtárunkban csinálja. Ha minden igaz, akkor ott lesz a listában a .bash_profile. Ha esetleg nincs ott, akkor se essünk kétségbe, hanem bátran hozzuk létre a következő parancs beírásával:

sudo touch ~/.bash_profile

Ha a fentieket pontosan másoltuk vagy illesztettük be és nem kaptunk semmilyen hibaüzenetet, akkor most már biztosak lehetünk abban, hogy ott a fájl (a fent leírt módon tudjuk ellenőrizni a meglétét). Ha ez megvan, akkor nyissuk meg szerkesztésre, a következő paranccsal:

sudo open -e ~/.bash_profile

Most a TextEdittel megnyitottuk a fájlt, ami valószínűleg – ha az imént hoztuk létre, akkor biztosan – üres.

Most szemléltetés képpen kezdjünk is vele valamit. Például használjuk arra, hogy egy rövid parancs segítségével elindítunk egy programot parancssorból. Az egyszerűség kedvéért legyen ez a program a számológép, vagyis a Calculator.app. A fájlba írjuk be a következőt – ügyelve arra, hogy minden ilyen parancs új sorba kerüljön:

alias calc=”open /Applications/Calculator.app”

Ezzel a következőt érjük el: a parancssorba pusztán a calc szót beírva elindítjuk a Calculator.app alkalmazást – csendben megjegyezném, hogy a Windows ezt már ősidők óta alapból tudja, de ugye ez a bejegyzés most nem arról szól…

Most ahhoz, hogy ez a fenti dolog működjön is, mentsük el TextEditben a fájlt (cmd+s) és adjuk ki a következő parancsot (az eleje egy ponttal és egy szóközzel kezdődik, erre ügyeljünk):

. ~/.bash_profile

Ennyi az egész, most a calc szót a parancssorba írva elindul az alkalmazás. Láthatjuk, hogy mennyivel kevesebb gépeléssel, elérési utak megadása nélkül érhetünk el dolgokat így Mac-en. Természetesen ne ragadjunk le a számológépes példánál, ilyen módon szinte bármelyik, gyakrabban használt fájlt vagy programot is el tudjuk érni pár karakter begépelésével, parancssorból.

Bár a BASH-t még sok hasznos dologra tudjuk használni, de most csak azért írtam erről, mert a következő blogbejegyzésben szüksége lehet az olvasóknak az itt megszerzett ismeretekre…

Amikor a gyorsítótár lassít…

2011. június 27. hétfő

Talán a legegyszerűbb módszer arra, hogy felgyorsítsuk a böngészőnket az az, ha időnként manuálisan töröljük a gyorsítótárat (cache), vagy kisebbre állítjuk a böngészőben megadott értékeket. Nem gondoltam, hogy egy napon pont erről fogok blogbejegyzést írni, de úgy veszem észre, hogy rengeteg ember nem is tud a gyorsítótárnak még csak a létezéséről sem.

Vannak napok, amikor bizony 24 óra alatt az általam meglátogatott weboldalak száma eléri a több ezret és sajnos – a nevével ellentétben – ilyenkor a böngésző gyorsítótára inkább csak hátrány, mint előny. Csak csendben megjegyzem, hogy eddig sajnos egyik böngésző sem tudott hosszabb távon (mondjuk 48 órán keresztül) megbirkózni az általam megtekintett oldalak mennyiségével (twitter linkek, RSS feedek, webfejlesztés, szakmai anyagok stb), érezhető belassulás nélkül.

A fenti okok miatt naponta, manuálisan (általában akkor, amikor a nap folyamán először a gép elé ülök) törlöm a gyorsítótárat és az előzményeket a Safariból (Chrome-ból, Firefox-ból, vagy ami épp a kezem ügyébe akad), azonban ezt a múlt héten valami oknál fogva sikerült kétszer is elfelejtenem egymás után. Az eredménye az lett, hogy a Safari elég érezhetően belassult és nehézkes volt már a böngészés.

Persze beállíthatnék egy kisebb értéket is az oldalak gyorsítótárazásánál, de mivel webre fejlesztek, ezért a fix szélességű betűtípuson és annak méretén kívül nem módosítom az alapértelmezett beállításokat. Pontosabban dehogynem, a Safarinak nem engedem meg, hogy használja a címjegyzéket, ill. az „Open ‘Safe’ files after downloading sincs kipipálva…

Mire való a cache?

A cache (más nevén gyorsítótár) tulajdonképpen arra való, hogy ha meglátogatunk egy webhelyet, akkor a már egyszer letöltött képek, ill. a webhely részét képező fájlok a merevlemezünkön eltárolásra kerülnek. Amikor pedig a következő alkalommal járunk ugyanazon a weboldalon, a böngészőnek nem kell újból letölteni az oldalt alkotó elemeket, hanem egyszerűen (az internetkapcsolatnál sokkal-sokkal gyorsabb) merevlemezről tölti be azokat, megspórolva ezzel akár több másodpercet, ill. akár több MB hálózati forgalmat is. Jól járunk mi (gyorsabban töltődik be az oldal), jól jár az internetszolgáltató (kisebb hálózati forgalom), ill. jól járnak a szerver üzemeltetői is (kisebb terhelés). Természetesen most itt ne egy olyan oldalra gondoljunk, ami mindennel együtt kitesz 2-3 MB-ot és van naponta 10 látogatója, hanem egy olyanra, ahol van napi százezer oldalletöltés (ez már ugye naponta több száz gigabájtnyi adatforgalmat is eredményezhet).

Ha viszont megnézünk néhány ezer oldalt és az ezekről eltárolt információkat később már nem használjuk fel, akkor azok csak feleslegesen foglalják a helyet a lemezen és feleslegesen lassítják a rendszert.

Tehát összegezve: azokat az oldalakat érdemes gyorsítótárban tárolni, amiket napi rendszerességgel (esetleg naponta többször is) meglátogatunk. Ilyenkor van leginkább értelme a gyorsítótár használatának. Az „ipari méretekben” történő böngészésnél / oldalletöltéseknél inkább hátrány, mint előny.

Egyébként én a magam részéről azt tartanám ideálisnak, ha beállíthatnám, hogy melyik oldalakat tárolja gyorsítótárban a böngésző (az összes többit ne). Sajnos ilyen böngészőt nem ismerek (tessék, itt egy jó ötlet a fejlesztőknek egy újabb funkció beépítéséhez, ami ma még nincs elterjedve). Az Opera beállításai mondjuk elég részletesek, de még az sem az igazi.

A teljesség igénye nélkül összeírtam, hogy az ismertebb böngészőkben hol kell a gyorsítótárat törölni, hátha többeknek hasznos lesz. Ez böngészőnként, operációs rendszerenként és nyelvenként eltérhet, de egy pici körültekintéssel bárki megtalálhatja akkor is, ha egy másik menüpontba lenne eldugva (az alábbi lista Mac OS X-re vonatkozik):

  • Safari
    Safari / Reset Safari…
  • Chrome
    Chrome / Böngészés adatainak törlése…
  • Firefox
    Eszközök / Előzmények törlése…
  • Opera
    Tools / Delete Private Data…

Google Chrome ikon lecserélése Mac-en

2011. április 30. szombat

Már vártam – pontosabban szólva reménykedtem, hogy minél később következik be a dolog – hogy a Google Chrome lecseréli a saját ikonját, de tegnap megtörtént. Természetesen az első dolgom az volt, hogy előkerestem a régi ikonokat és egyből visszacseréltem őket a régiekre.

Ebben a bejegyzésben ezt a folyamatot szeretném bemutatni, lépésről lépésre.

Először is szükségünk lesz a régi ikonokra, amik Mac OS X alatt .icn kiterjesztésű fájlok és az alkalmazáson belül találhatóak meg). A Google Chrome.app valójában két ilyen fájt is tartalmaz: az egyik magának az alkalmazásnak az ikonja, a másik pedig azoknak a dokumentumoknak az ikonja lesz, melyek a Chrome-hoz vannak hozzárendelve.

Első lépésként töltsük le a régi Chrome ikonokat tartalmazó tömörített fájlt innen.

Ha ezzel megvagyunk, akkor nyissuk meg a Findert, majd navigáljunk el az Applications könyvtárba, ott pedig keressük meg az előbb említett Google Chrome.app fájlt. Klikkeljünk rá jobb egérgombbal, majd válasszuk a menüben a Show Package Contents lehetőséget:

Ekkor megnyílik egy új ablakban a Google Chrome.app fájl tartalma. Egyetlen könyvtár van benne Contents néven, amit szintén nyissunk meg, majd utána lépjünk be az abban található Resources könyvtárba.

Itt látni fogjuk a két fájlt, ami az új ikonokat tartalmazza: app.icns és a document.icns. Ezt a két fájlt fogjuk felülírni az imént letöltött fájlokkal.

Ha eddig nem tettük volna meg, akkor most tömörítsük ki az imént letöltött old-google-chrome-icons.zip-et és a benne lévő két ikonfájlt húzzuk be ebbe a könyvtárba.

Valószínű, hogy ezt nem fogja szó nélkül hagyni az OS X, ezért a felugró ablakban válasszuk a Replace, a következő felugró ablakban pedig az Authenticate lehetőséget, majd adjuk meg jelszavunkat.

Ha ezzel is megvagyunk, akkor lecseréltük az új Chrome ikont a régire, az viszont elképzelhető, hogy pl. a Dockra húzott Applications könyvtár még a régi ikont mutatja. Ezt a problémát az alábbi módon lehet a legegyszerűbben megoldani: nyissuk meg a Terminalt és írjuk be parancssorba a következő parancsot:

killall Dock

Mostantól ismét a régi ikon ül a Dockon a Google Chrome neve alatt és ezt látjuk az Applications könyvtárban is. A fenti módszerrel természetesen szinte bármilyen más alkalmazás ikonja tetszőlegesen lecserélhető.

Frissítés: mivel a fent említett ikonok a Google Chrome.app-ban vannak tárolva, ezért amikor a Chrome frissíti magát, az ikonokat is visszacseréli az újakra. Ilyenkor újból végig kell csinálni a fenti műveleteket (másodszorra már sokkal gyorsabban fog menni). :)

10 éves a Mac OS X

2011. március 24. csütörtök

Napra pontosan tíz évvel ezelőtt, 2001. március 24-én indult útjára az az operációs rendszer, melyet hozzá adnak minden Apple által forgalmazott számítógéphez, vagyis a Mac OS X. A 10.0-s verzió a Cheetah volt, majd jött a Puma (10.1), a Jaguar (10.2), a Panther (10.3), a Tiger (10.4), a Leopard (10.5), a jelenlegi aktuális verzió pedig a Snow Leopard (10.6). A következő változat a nyáron érkező Lion lesz, ami értelemszerűen 10.7-es verziószámot kapja.

Jómagam a 10.5-ös változat – vagyis a Leopard – megjelenése előtt néhány héttel ismerkedtem meg a Macintosh és az Apple világával, de ez már egy másik történet. Fogok mesélni erről is egyszer itt a blogon.

A beszeljukMac.hu egyébként egy részletesebb cikkel emlékezik meg az évfordulóról, érdemes elolvasni.

Boldog születésnapot, Mac OS X!

Ez pedig kereken a századik blogbejegyzésem. :)