Mac OS X pod kapotou - resources - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Jaký fotograf/ka získal/a cenu za nejpopulárnější příspěvek v Nikon Photo Contest?

V dnešní soutěži hrajeme o:

Seriály

Více seriálů



Software

Mac OS X pod kapotou - resources

MacOSX_class

8. října 2001, 00.00 | Pokud se vyznáte v Mac OS, určitě jste někdy používali ResEdit pro úpravy v aplikacích nebo v systému. V Mac OS X je všechno opět jinak, a my si ukážeme jak na to.

Když se zkušenějšího uživatele Maca zeptáte, jak se podle něj liší aplikace pro MacOS a pro Widnows, pravděpodobně odpoví, že "na Macovi jsou přece ty resources". Co však resources jsou, na co jsou dobré a jaká je jejich role v novém operačním systému Mac OS X není zase tak úplně zřejmé.
Pro tentokrát to zkusíme vzít od konce. Resource je malá databáze, která má své jméno (Resource type) a strukturu. Jednotlivé položky pak mají své unikátní pořadové číslo (Resource ID), které může, ale nemusí začínat 0 a může být i záporné.
Každý soubor v operačním systému MacOS do verze 9.x je tvořen ze dvou částí. Část, určená pro databáze (resources) se nazývá resource fork a část pro data je data fork.

V těchto databázích se ukládají informace, které mají svou pevně danou a neměnnou strukturu. Víceméně celý resource fork je také databáze, která obsahuje jednotlivé resource.

Pravděpodobně každý z uživatelů Maca zná program ResEdit, případně jeho konkurenci, program Resourcerer. A velmi pravděpodobně spiše znáte vizuální interpretaci jednotlivých typů. Takhle například vypadá položka menu, jak ji interpretuje program Resourcerer:

To, že ji můžeme vidět tímto způsobem je způsobeno tím, že program "zná" strukturu resource typu 'MENU'. Pokud by tomu tak nebylo, uvidíme jen skupinu hexadecimálních čísel. Na obrázku dole je zvýrazněn text menu "About Cyclone...".

K čemu jsou resources dobré?

Na "starých" počítačích typu Quadra a podobně, tedy přesněji těch, které mají procesor řady Motorola 680x0 platilo, že aplikace mají jen resource fork a jejich datová část je prázdná. Dokonce i samotný kód aplikace byl v resource forku ve speciálním typu označeném 'CODE'. Na počítačích s procesory PowerPC je již kód aplikace uložen v data forku a v resourcech je vše ostatní. To znamená všechna okna, tlačítka, menu, nápisy a spousta dalších věcí.
Chceme-li například změnit text na tlačítku, není nic jednoduššího, než spustit ResEdit, otevřít aplikaci, najít správné dialogové okno a je to. Potřebujete-li přidat nebo změnit klávesovou zkratku, najdete resource 'MENU' a prostě si ji přidáte.
Nejčastěji se tato technika používá při lokalizaci aplikace do jiného jazyka. Existují speciální aplikace, určené právě k tomuto úkolu. A pokud je aplikace korektně napsaná, je její lokalizace otázka jednoduchého přeložení textů.

Změny v Mac OS X

Ti z vás, kteří již spouštěli ResEdit dříve a mají přístup k Mac OS X se o to jistě pokusili na novém systému také. Pokud to ale dělali bez znalosti některých změn, zažili jistě trpké zklamání. ResEdit totiž nenajde nic a to ani v souboru pojmenovaném s příponou .rsrc. Vývojáři u Apple se totiž rozhodli, že přesunou celý resource fork do datové části. Pokud se tedy vrátíme k úplně prvnímu obrázku, došlo k úplnému oddělení obou částí souboru na soubory dva, které jsou oba datové, ale jeden z nich má příponu .rsrc a obsahuje resources v datové formě. A v čem je výhoda? Doufám, že je to zřejmé. V naší (všech macistů) domluvě se světem Windows. Teď si již klidně můžete zkopírovat aplikaci na disk s Windows 95/98....

Pokud chcete trochu prozkoumat nový operační systém, budete k tomu potřebovat vývojářské nástroje. Můžete je získat dvěma způsoby - buď se zaregistrujte na adrese http://www.apple.com/developer do ADC (Apple Developer Connection) jako "on-line" člen. Je to zdarma a můžete si stáhnout kompletní vývojářské nástroje (asi 180MB) pro Mac OS X. Druhá varianta je, zajít k některému z dealerů Apple a ti by vám je měly vypálit, pravděpodobně za cenu CD. Po instalaci si uděláme pár pomůcek a jdeme na to.

Resources v Mac OS X v praxi

Na disku se vám objevil nový adresář nazvaný "Developer". V něm je vše, co potřebujeme a ještě asi tisíckrát tolik. Spusťte si Terminál a napište:

% sudo -s

a zadejte heslo. Tím jste na 5 minut získali absolutní práva na svém počítači.
Nyní si uděláme dva symbolické linky (takové aliasy) na dva nástroje, které budeme nejvíce používat, abychom nemuseli neustále psát celou cestu.

# ln -s /Developer/Tools/Rez /usr/bin/Rez
# ln -s /Developer/Tools/DeRez /usr/bin/DeRez
#rehash

Poslední příkaz znamená, že se znova vytvoří seznam programů v přednastavených cestách a počítač "bude vědět", že v /usr/bin má dva nové programy.

A teď do práce. Pokusíme se trochu vylepšit vzhled OSX. Jen nezapomeňte, že si hrajete s Pandořinou skříňkou a můžete si systém zcela zničit!

# DeRez -useDF /System/Library/Frameworks/Carbon.framework/ Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc > ~/temp/Extras.r

Také milujete příkazovou řádku? Příkaz znamená:
DeRez - program na konverzi resource forku
-useDF - resources jsou v data forku
pak následuje cesta na soubor
> výstup z programu ulož do
cesta na výstupní soubor (adresář musí existovat)

Nyní máte ve svém domovském adresáři v podsložce temp soubor, veliký asi 17MB, který se jmenuje Extras.r Nyní se v Terminálu vraťte do své domovské složky a pak do podadresáře temp, kde je uložený soubor, který jsme právě vytvořili. Teď můžete napsat:

# Rez -a Extras.r -o Extras

Tím jsme ze souboru Extras.r vytvořili "standardní" resource file, který lze editovat ResEditem. Pokud ho otevřete, uvidíte několik neznámých typů a dva známé - 'clut' a 'ppat'. Typ 'clut' jsou barevné paletky a 'ppat' jsou systémové vzory. Zde je to známé pruhování všech oken. Pokud uděláte nějakou změnu, uložte soubor (možná budete muset předtím změnit pomocí příkazu chown majitele). Cesta zpátky je poměrně jednoduchá:

# DeRez Extras > Extras.r
# Rez -useDF Extras.r -o /System/Library/Frameworks/Carbon.framework/ Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc

Nyní se stačí odhlásit a znovu přihlásit a uvidíte změny, které jste udělali. Největší problém v OSX je, že struktura systémového adresáře je úplně jiná než v předchozích systémech. Ty nejzákladnější systémové části a jejich resources jsou v HIToolbox.framework. Pokud jste používali mou lokalizaci předchozích verzí OS X, tak víte, že klávesnice jsou uloženy v Localized.rsrc. Je tam toho ještě mnohem více. Pokud tedy chcete v úpravách systému pokračovat, je to skvělé místo, kde začít.

Pokud jste dočetli až sem, mám pro vás odměnu - aplikaci pro Mac OS X, která se vám bude určitě hodit. Jmenuje se NameDayLite a na najdete ji na http://homepage.mac.com/robertcerny

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Software  

Diskuse k článku

 

Vložit nový příspěvek   Sbalit příspěvky

 

Prenos na PC

Autor: Lukas Kalista Muž

Založeno: 08.10.2001, 09:03
Odpovědí: 0

Abych pravdu rekl, puvodni usporadani mi vyhovovalo vice. Alespon co se tyka prenosu souboru na ZIPce. Pod OS 9 se na medium formatovane pro DOS nahraly krome souboru i tzv. FRKy - slozky, ve kterych byly prave informace, ktere na takto formatovana media jinak nahrat nesla. Coz jsou prave resource. Jenze OS X nahraje na tyto media kazdy soubor 2x - jednou datovou cast a jednou resource. Je v tom pak na PC pekny bordel...

Odpovědět na příspěvek

Bordel to je kazdopadne

Autor: Nobody Muž

Založeno: 08.10.2001, 13:21

Mam pocit, ze nekdo na zacatku slapnul do "cehosi" a vsichni po nem uz v tom "jenom" tancujou. Ja vam reknu co chce uzivatel: CHCE ZKOPIROVAT JEDEN SOUBOR a NECHCE RESIT BORDEL S DATOVOU A RESOURCE casti na cizich discich. Zmena na OS X byla xakru uz dost velkou zmenou, aby se nemuselo ohlizet zpet, ne?

Odpovědět na příspěvek

RE: Bordel to je kazdopadne

Autor: Lukas Kalista Muž

Založeno: 08.10.2001, 13:37

Aby bylo jasno - ja jsem strasne rad, ze resorce existuji. Je to prehledne, je to jasne dane a ne takovy bordel, jako v PC programech. Ovsem mohlo se to vyresit alespon trosku lepe, nez soucasny stav (v OS 9 to bylo lepsi - nemotalo se to). Bohuzel Windows jsou tak kompatibilni, ze neumeji cist nic jenho, nez ten svuj format :-(((

Odpovědět na příspěvek

Bordel to je kazdopadne !!!

Autor: Jirka Muž

Založeno: 08.10.2001, 17:10

Presne jak psal kolega - tanec v hovnech. A aby bylo jasno, jsem Macista uz 10 let.
Nevim proc nemohou byt vsechna data vzdy v jednom souboru. At jsou strukturovana jakkoli. To ze souvisejici data rozdelim do dvou souboru je blbost na n-tou. I kdyby se data_fork a resource_fork mely dat jen jednoduse za sebe do jednoho souboru, bylo by to reseni. Nevim proc by se v takto ulozenych datech melo hur orientovat - je to opravdu hrozna blbost.

Odpovědět na příspěvek

RE: Bordel to je kazdopadne !!!

Autor: Robert Černý Muž

Založeno: 08.10.2001, 18:37

Tedy,
ne, že bych chtěl rušit vaši plamennou diskusi o tom, zda resource ano nebo ne, ale domnívám se, že ani jeden z nás není pan Jobs, který jedinný má možnost situaci změnit. Já osobně mám resource rád. Jsem schopen s nimi žít a nevadí mi. Navíc si myslím, že v OS X je to vyřešené lépe. Zapomínáte totiž na jednu věc: pokud někomu zkopírujete datový soubor (text ve wordu, zlom v QXP nebo obrázek v PSD) tak u něj je resource většinou prázdný, nebo obsahuje informace, které se mohou klidně ztratit. Jediné, u čeho mají resources nějaký zásadní význam jsou aplikace a podpůrné knihovny a tam zase nevím, proč by je proboha někdo chtěl kopírovat na windows? Řešení v OSX je dobré z tohoto pohledu. Mám-li aplikaci pro OSX s novým typem resources (v dataforku) a nakopíruju ji na PC disk, aplikace to přežije bez úhony. A to jde, ne?

Odpovědět na příspěvek

RE: RE: Bordel to je kazdopadne !!!

Autor: Nobody Muž

Založeno: 08.10.2001, 22:25

JO, to je bez diskuze, ze resources se svou strukturou jsou fajn. Kde jinde bych si mohl jako laik dovolit vrtat v aplikacich, menit ikonky, klacesove zkratky, vyzobavat obrazky , jednou se mi podarilo cracknout nejakej plugin uplne s minimalnimi znalostmi(!), pouze selskym rozumem! ... :o) Ale myslim si, ze by to mohlo byt i o kapanek chytrejsi, nebo blbovzdornejsi... Od UNIXoveho jadra v OS X cekam vetsi kompatibilitu logiky se svetem, ale taky dusledne trvani na jednoduse resenych vecech PRO UZIVATELE, nikoliv pro PROGRAMATORY.

Odpovědět na příspěvek

RE: RE: RE: Bordel to je kazdopadne !!!

Autor: Robert Černý Muž

Založeno: 09.10.2001, 08:51

Doporučoval bych (a nejen vám) podívat se na několik starších článků zde na serveru. Od UNIXového jádra nemůžete očekávat vůbec nic, protože MACOS X na UNIXu postaven není. Je to jen jedna z jeho částí. Stačí si o tom myslet něco jako:"jo, a OSX umí taky UNIX". Na stránkách Apple je poměrně jednoduchý diagram, který ukazuje, z čeho všeho je OS X složený. Kdyby Apple postavil OSX jen na UNIXu, tak by to byl ten největší průser, co by mohli udělat - nulová zpětná kompatibilita. Jak jsem již jednou napsal, kompatibilita je větší než v OS 9.

Odpovědět na příspěvek

RE: RE: RE: RE: Bordel to je kazdopadne !!!

Autor: Lukas Kalista Muž

Založeno: 09.10.2001, 09:43

Aby bylo jasno, myslim, ze jsme se vsichni shodli, ze resource je vyborna vec. Jde ale o to apple implementovane reseni. Nekdy jsme nuceni nahravat soubory na PC media, nebot Wokenice zkratka jsou kompatibilni s okolnim svetem, az to hezke neni. No a kam s nasimi resource? Drive se to hodilo do slozek s FRKy a byl klid - PCckari na ne sice obcas nadavali, co tam delaji, ale vesmes neobtezovaly. Ovsem ted je tak kazdy soubor dvakrat (ja vim, trosku se lisi jmeno) a na prvni pohled je na disku neskutecny bordel :-((

Odpovědět na příspěvek

RE: RE: RE: Bordel to je kazdopadne !!!

Autor: OC Muž

Založeno: 16.10.2001, 01:32

"...resources se svou strukturou jsou fajn. Kde jinde bych si mohl jako laik dovolit vrtat v aplikacich, menit ikonky..."

Omyl. Resources se svou strukturou jsou zbytecne slozite, komplikovane, zastarale, a vseobecne nanicdobre :))))

Racte se prosim podivat na NIBy a InterfaceBuilder.

OC

Odpovědět na příspěvek

treba se opravdu pletu

Autor: Nobody Muž

Založeno: 16.10.2001, 12:50

Tyto produkty neznam, pokud jsou opravdu chytreji vymyslene, tak fajn! Klidne zmenim nazor. Kdosi na webu tvrdi, ze pro Cocoa je programovani asi 10x snazsi, nez pro cokoliv jineho.

Vztahoval jsem to vzhledem k realizovane praxi s knihovnami, mnozstvim souboru jenz maji divotvorne koncovky, systemovymi registry atd... To je prostor k chybam, konfliktum, chaosu... vsichni vime, co komentuji...:o)

Ja se stejne jako uzivatel vrtat ve strevech nechci, od toho jsou jini lidi. Ja chci pracovat na sve praci se svymi nastroji. V pocitaci, kteremu chci rozumnet jako uzivatel, nikoliv jako servisman-programator. Chci, aby moje lopata umela vsechno mozne, ale nemusi byt k tomu pruhledna, mit na sobe 350 tlacitek, napovedu a 24-hodinovou podporu (ktera stejne lopatu neopravi), kdyz znicehonic prestane fungovat. :o)))

Odpovědět na příspěvek

RE: RE: Bordel to je kazdopadne !!!

Autor: Peter Strazan Muž

Založeno: 30.06.2003, 20:51

...ale uz to neskopirujem naspat (PC->MAC) v 'povodnom zneni'. A to je (v dobe internetu) katastrofa.

Odpovědět na příspěvek

chtelo by to optimalizovat!!!!!

Autor: Nonejm Muž

Založeno: 14.10.2001, 11:06
Odpovědí: 0

dyz uz jsou resourceFRKy tak chytra vec, porad nechapu, proc ma MacOS X takovejch stomilionu souboru, kdyz ho nainstalujes, a proc pritom zabira takovejch giga! VSADIM se, ze kdyby nekdo chtel, tak by velikost mohla byt polovicni, ne-li mensi a vnitrni stuktura systemu by mela par souboru, ktere by mely ve svych FRKach vsechny ty miliardy parkilovejch mikrosouboru, jak to vidim dneska. Funkcnost a pristup k nim by se snad nezhorsil, ne? Je to jen lenost programatoru a uzivatel pak doplaci na to, ze vidi chaos.

Odpovědět na příspěvek

RE: chtelo by to optimalizovat!!!!!

Autor: Robert Černý Muž

Založeno: 15.10.2001, 09:39

Dobrý den,
nechci se pouštět do vášnivých diskusí, ale obávám se, že v tomto případě mícháte hrušky s jablkama. O co vám vlastně jde? Zkusme se trochu přesněji podívat, co nám to vlastně v OS X běhá: Cocoa, Java, Classic, Carbon, Apache, php, perl, několik UNIXových shellů atd. Pomineme-li v tomto případě, že každý pes jiná ves, má rozdrobení na spoustu souborů tři významy:
1. jednoduchá možnost upgrade
2. jednoduchá lokalizace
3. malé knihovny pro programátory

Dovedete si představit, že bych ke každé i té nejmenší aplikaci, musel přilinkovat 20mb knihovnu?? A to úplně pomíjím to, že OS X se standardně instaluje v 8 (asi) lokalizacích...

Odpovědět na příspěvek

Vysvetlim svuj nazor

Autor: Nonejm Muž

Založeno: 15.10.2001, 13:52

O, ne, pane Cerny... Ja si Vas opravdu vazim a nepochybuji o tom, ze tomu co pisete opravdu rozumite vic, nez ja... Ja na to koukam jako uzivatel, ktery je jen trochu poucen, jak to chodi a pouziva logiku selskeho rozumu...(si myslim) NECHCI michat hrusky s jabkama, protoze vim, ze to je blbost... a chapu, ze OS X je soubor mnoha bloku, ktere jste zminil a tyto casti ze maji sve komponenty. Ale fajn... proc by treba kazda z tech vrstev nemohla byt v nejake elegantni "package" nebo slozkach s radove do 3 urovni, kazda do 10 polozek? Tedy z hromady jablek, hromady hrusek a hromady svestek udelat jedno jabko, jednu hrusku a jednu svestku. Co se tyce vasich argumentu, 1) 2) 3).... nepopiram... ale to by snad bylo mozno i kdyz by byly tyto veci ve FRKach, ne? Vnitrne by se to preci nemenilo ... Stejne jsou k dispozici source kody, takze vyvojari mohou pristupovat k datum dobre, ne?...

Rozhodne nechci ke kazde kravine linkovat 20MB soubor, jen proto, ze se zmenila jedna mikro-komponenta,nebo byl opraven bug.. to udela jen proramatorsky lamer. Ale myslel jsem, ze uz jsme v roce 2001 a ze existuji nejake updaty po internetu, ktere stahuji/instaluji jen co je potreba a co je noveho... Pri updatech SW se taky preci kontroluji FRKy a meni se jejich obsah, ne? Proc lokalizaci zakladnich veci v OS neresit jednou instalacni polozkou s nazvem "Czech 1.0", nebo German 1.2", ackoliv by uvnitr bylo vsechno nakouskovany na knihovny? Neargumentujte mi, ze neco nejde v SW udelat, to bych se fakt rozesmal! Jde preci o to vymyslet, jak tu stavebnici skladat...
Rozhodne uz znam (pro mne smutny) pripad z minulych Mac OS, kde se postupne zacaly mnozit nutne soucasti OS, ktere sice patrily k sobe, delaly dohromady jednu vec (napr. QuickTime) ale kdyz neco z nich chybelo, tak se to muselo preinstalovat stejne vsechno, nebo zacly prusery, nebo nestabilita... Uzivatele a nekdy ani servismani nevedeli, co je dulezity a co ne, co s cim koliduje, kdyz se v tom vrtali, tak to vetsinou pojebali.Cim vic souboru, a moznosti vrtat se, tim jsou vetsi sance neco dodatecne pojebat.

Jde mi o to ZJEDNODUSIT a optimalizovat velikost tech 1,5 GB (coz si myslim, ze jde) a vratit MacOS jeho pruhlednost, protoze i kdyz je uvnit slozity, nikoho ze servismanu nezajimaji miliardy knihoven, ktere si vyrobi programatori, aby nakonec udelali jeden obecny tiskovy modul. Oni to stejne musi preinstalovat komplet. Proste pral bych si udelat misto puzzle, ktere ma 1.000.000 dilku pouze 1.000 dilku a vysledek pritom byl stejny. To je tezke?

...jsem asi naivni, ale proc maji nektere komercni aplikace (narocne na vypocty, zobrazeni, vstupy, vystupy) par MB a jine podobne aplikace par stovek MB? To jako ze ty druhe toho umi 100x vic? to asi ne, ze...spis treba jen 2x vic ale jsou jenom malo kompaktne zkompilovane. Rozumnou velikost pro tak velky OS jako je MacOS X bych bral tak 500-800 MB. (OS je samozrejme od toho, aby urcil dobra "pravidla" a "hriste" a vse ostatni maji resit nadstavby a aplikace) Jakmile se v OS zacnou objevovat sluzby na kompresi MP3, paleni CD, atd... tak to uz chapu jako "aplikaci" (prekl. pouziti) nove sluzby, nikoliv zakladni stavebni jednotku OS. Tim se OS jen zasira.

BTW ....kdyz si tak vzpomenu, pro mne zajimavou myslenkou byl OpenDoc. Dovedu si predstavit, ze kdyby se myslenkove dotahl do konce, tak by to byla revoluce vetsi nez OS X. Opendoc jsem chapal jako nove pojeti struktury pocitacovych dat a noveho prirozenejsiho postupu jejich zpracovani. (Kdyz varim polivku, taky pouzivam ruzne nadobi na JEDNU polivku, micham ruznymi vareckami a ne ze po kazdem pridani jednoho druhu zeleniny strcim hrnec do mrazaku, zmrazim pak zas rozmrazim, naleju do jineho kastrolu a pridam dalsi mrkev...) Jenze to asi ztroskotalo na tom, ze si chce kazda firma (resp.aplikace) placat babovky (resp. data) na svem pisecku, nikoliv na spolecnem pisecku OpenDocu. Slo jim (vyrobcum SW) o prachy, ten kdo OpenDoc vymyslel jim je nemohl v kratke dobe slibit.

Odpovědět na příspěvek

RE: Vysvetlim svuj nazor

Autor: Robert Černý Muž

Založeno: 15.10.2001, 15:53

Dobrý den,
rozhodně bych se rád vyhnul diskusi, čemu rozumím. Není to tak slavné...:)
Abych řekl pravdu, svým názorem jdete dost proti proudu. Samozřejmě, váš příklad s aplikaceni na výpočty a třeba MS Wordem je jasný. Je zde ale malý rozdíl v tom, jak programátoři k tomuto problému přistupují. V případě, že napíšu nějakou pěknou funkci nebo lépe sadu funkcí, bude pro men lepší zkompilovat je do samostatné knihovny. A to z několika důvodů:
1. logické oddělení od aplikace
2. možnost sdílení jednoho kódu mezi aplikacemi
3. snazší obsluha v případě bugů

Jestliže například napíšu několik sad funkcí a jedna bude manipulovat s obrázky, druhá s čísly a třetí bude debuger, bude asi logičtější, oddělit je do tří knihoven a atd.
Nejsem si jistý, jak veliký je váš OSX systém, ale můj má 700MB, což je asi tak to, co chcete. Myslím si, že váš nápad s UNIX.package není špatný, ale bohužel nefunguje. Chci-li tvrdit, že můj systém je 100% komptibilní s nějakou verzí UNIXu, musí takový být včetně cest a adresářů, protože v UNIXu to tak chodí.
Osobně si myslím, že celý systém balíčků (package) je docela chytrý a posouvá nás od Windowz zase kousek dopředu -> Vezmu-li například takovou Office.X pro Maca a Office.XP pro Windows, jistě pochopíte, o čem mluvím. Není totiž problém vzít Word a zkopírovat ho na jiný disk, což je u woken docela problém :))

Odpovědět na příspěvek

ehhh.. rozumim....

Autor: Nonejm Muž

Založeno: 16.10.2001, 12:01

Takze celkem pripoustite, ze finalni produkt (aplikace) je vytvoren tak, jak je to snazsi pro programatora, nez pro uzivatele... Mno, to je mi pekne... ! Potvrzuje to muj dojem, ze vyvoj je vice ovlivnovan schopnostmi tvurcu nez potrebami uzivatelu. :o) Ostatne, ja nepopiram dulezitost strukturovani knihoven, ale vsechno ma sve... Ukazte mi nejakou komercni aplikaci, ktera ma svoje knihovny, jenz vyuzivaji uplne jine komercni aplikace... Ja takovou neznam. Jo, pokud je to knihovna samotneho OS, nebo ovladace HW, pak by to mohly vyuzivat vsechny App, a to je preci samozrejmost. Presto nevidim duvod, proc by nemohly byt skupiny knihoven logicteji sdruzovane.

Co si myslim k pristupu programatoru? At si kazdy programuje jak nejlepe umi, ale finalni produkt by mel splnovat urcite naroky a specifikace. Vim ze to tak jiste je, a taky vim ze programovani pro kakao je trosku jine, nez driv... Tim spis se mohl udelat novy lepsi poradek smerujici k jednoduchosti vysledku.


Ad kompatibilita s UNIXem.... Mno, to co jste napsal mne nepresvedcilo. Resp. presvedcilo o tom, ze to je zase ustupek a ohled na cizi produkty. To je mi u Apple v tomto smeru vice nez zarazejici! Apple se nerozpakoval kompletne zmenit vlastni produkt (OS) - svou kompatibilitu zarucil temer emulaci stareho OS a kdyz jde o UNIX, tak se uzkostlive trese, aby byl kompatibilni. MacOS X preci neni UNIX (jak jsem se tu docetl) ale je s nim skvele kompatibilni, to ano.(Jasne, je to i tim, ze koupil NEXT, protoze vymyslet komplet neco noveho by trvalo desitky clovekoroku.) Je tak tezke namapovat na vnitrni strukturu MacOS X nejakou UNIX-kompatibilni hierarchii souboru? Vzdyt by to mohla byt jen jedna mala polozka v resource forku kazdeho souboru, hned vedle polozky ciselne verze nebo verze jazyku a jinych kravin, co jich tam je...

Ad moznost kopirovani: Diky tomuto MacOS miluju. A je to presny priklad toho, jak Windoze (resp. mene kvalitni reseni struktury dat) svym resenim ovlivnuji mysleni lidi. Uzivateli Windowsu casto ani nenapadne, ze by to (presun misto preinstalace) mohlo byt jinak-"normalnejc" protoze "tak to proste nikdy nikdo neudelal a proto to tak nejde" ... :o)

Jinak diky za diskusi, to vite, ja tak nad tim premyslim a jen kroutim hlavou.
Vzdycky mne irituje, ze ti, co maji moznost realizovat vize jsou tak omezeni ve spousta vecech. Jeden priklad mimo: VSICHNI berou jako normalka (fakt, dogma), ze existuji pocitace s nekolika typy pameti (ulozny prostor:HDD, operacni pamet:RAM vyrovnavaci pameri: cache L1,2,3) Vyvoj jde preci dal a uz brzy by mohly byt pocitace s jednim typem pameti (napr. baze flash, nebo bubble) a pak by vnitrek krabic vypadal uplne jinak. Kdo je zvedavy na to, ze se pocitac startuje desitky sekund z disku? Kdo je zvedavy na to, ze se aplikace startuji a zase zaviraji? Ze po restartu mas smulu s rozdelanou praci? Plytvani GB na software se projevi za par let, uvidite... Jsem asi jen rejpavy snilek, ale bez tohohle pristupu se neda prichazet na nove veci, a odpoutat se od dogmatickych konvenci... protoze pak uz zbydou jen account manageri, kteri reknou ze to je drahy a malo se na tom vydela.

Hezky den! :o)

Odpovědět na příspěvek

prosba

Autor: mustang Muž

Založeno: 01.05.2007, 15:40
Odpovědí: 0

Zdravím...mám soubor s příponou .REZ a potřeboval bych do něj...ale čím a jak??? poradte mi prosím...předem DĚKUJI

Odpovědět na příspěvek

 

 

Vložit nový příspěvek

Jméno:

Pohlaví:

,

E-mail:

Předmět:

Příspěvek:

 

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: