b]dusanx wrote:[/b]
Upravo to pricam: Na OSX-u prakticno nema pajpova niti zvanja izvrsnih fajlova sa parametrima.
Kako bre nema, a NSTask? Kako misliš da radi gomila programa, koji su samo UI za CLI programe koji se vrte u pozadini? A da se ne spuštamo niže na POSIX nivo (system() i exec() familija funkcija). I šta podrazumevaš pod ‘pajpovi’?
Apple Script je de facto jedini standard za komunikaciju izmedju programa.
??? Počev od UNIX nivoa, gde se mogu koristiti pipes, sockets i ostale stvari iz UNIX-ovog IPC-a, preko Carbon AEvents, pa sve do Cocoa nivoa, sa NSDistantObject, NSConnection, NSPort, odnosno ceo tzv. Cocoa DIstributed Objects deo, postoji gomila načna za komunikaciju među programima.
Nastavljamo da pričamo o istoj stvari na drugačji načn. AppleScript je napravljen sa namenom da se njima skriptuju programi (od strane korisnika) i za tu svrhu koristi AEvents. E sada se neko setio da u Cocoa ubaci klasu NSAppleScript, njome prikrije sav prljavi AEvents mambo-džambo i pojednostavi stvari. Ni to se nije desilo samom pojavom Cocoa frejmvorka, ta klasa se pojavila tek u Jaguaru. Pre toga, ako si hteo da iz svog programa komuniciraš sa drugim programom koji podržava AS, lepo u Carbon pa udri po AEvents API-ju (koji je užasno komplikovan). Dakle, to što možeš iz svog programa preko AS-a da komuniciraš sa drugim je samo posledica implementacije, nije namena jezika. Pitaj bilo koga, čji program podržava AS, da li su uopšte imali u vidu takvu namenu, kada su pravili podršku za AS? Mislim, da se razumemo, dobro dođe ako i to može (iz drugog programa); ali nije to svrha. Sve to, uz čnjenicu da je (za sada) ograničeno na MAS, stavlja izjavu ‘AppleScript je zvanično mrtav’ u red bombastičnih izjava u medijima, kako bi se privukla pažnja auditorijuma. Ovde se uopšte ne radi o AS-u.
Sa druge strane bilo kakva 3rd party app <-> 3rd party app komunikacija nije dozvoljena.
Nije tačno. Evo šta kaže ‘App Sandbox Design Guide’:
The following app behaviors are incompatible with App Sandbox:
bla, bla, bla,...
………………
Sending Apple events to arbitrary appsWith App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps.
………………
bla, bla, bla,...
Dakle, nema komunikacije između programa korišćenjem AEvents-a. Nigde ništa ne kaže za Cocoa Distributed Objects API, koristeći njega možeš da komuniciraš među programima do mile volje. Naravno, da bi to bilo moguće, programi to moraju da podržavaju. Ako ne podržavaju, pa ništa onda, ne podržavaju svi programi ni AS skriptovanje, ni sa njima ne može da se komunicira. Da kažem prostim rečma: programer je napravio program i pritom odlučo da pruži korisnicima mogućnost da program skriptuju i nateraju ga nešto da radi. U tu svrhu programer definiše nešto kao rečnik, kojim korisniku kaže šta sve može od programa da zatraži, tako da ovaj može da napiše sledeći skript:
[code:1]tell application ‘SuperLoto’
daj bre dobitnu kombinaciju za sedmicu
end tell[/code:1]
Dakle, programer definiše rečnik jezika, kojim korisnik komunicira sa programom. Kao što rekoh, zgodno je došla ta NSAppleScript klasa, pa se isto može uraditi i iz drugog programa. Ako je programeru bilo bitno samo da omogući da korisnici skriptuju program, baš ga briga oko sandboxinga u MAS-u. Ako je programeru baš stalo da i ostale kolege mogu iz njihovih programa (koji su sandboxovani i u MAS-u) da komuniciraju sa njegovim, onda će lepo za kolege da obezbedi API, koji će oni da koriste u tu svrhu. API implementacija će koristiti distribuirane objekte, a ako je programer lepo vaspitan, oko cele implementacije će se sam pomučti, a kolegama ponuditi API sa jasnim i jednostavnim metodama (sintaksom poruka, koje mogu da pošalju njegovom remek delu i kakve odgovore na te poruke mogu da očekuju). Naravno, sve ovo pada u vodu, ako se sandbox restrikcije odnose i na distribuirane objekte i na bilo kakvu interproces komunikaciju, ali ja to nisam uspeo da pronađem ni u dokumentaciji, ni na webu, a i lista sandbox entitlement-a ne ukazuje na to.
Sad banalan je primer da bilo koji App Store program ubuduce nece moci da koristi growl ali lepo ilustruje kakva ogranicenja su u toku.
Zar Growl ne omogućava i jedno i drugo? Nemam pojma, nisam ni koristio, ni gledao dokumentaciju niti bilo šta, ali koliko sam upoznat, možeš da skriptuješ neki GrowlHelper.app (ili tako nešto); koji radi u pozadini, sa ispišeš neko Growl obaveštenje, ali možeš i da koristiš neki Cocoa API, koji je koliko sam informisan baziran baš na Cocoa distribuiranim objektima, da GrowHelper-u pošalješ poruku. Ako programeri koriste ovo drugo (pod uslovom da sam u pravu); ne bi trebalo da bude zime za MAS programe koji komuniciraju sa Growl-om.
… ja sam ohrabren da pisem iTunes helper ali ne i Radium helper. Koristim samo kao primer kojim sam se bavio, ima paralela i za iCal prema ostalim kalendar programima i slicno.
Javi autorima Radiuma da urade ono što sam gore naveo. Ako neće znač da: (i) ih baš briga da neki drugi program komunicira sa njihovim, (ii) baš briga za MAS. Što se tiče iCal-a i ostalih Epl programa, verovatan ishod je (i).
Najmanje mi je u celoj prici bitan CoverToaster, niti sam se namucio niti je nesto silno zaradio. Prosto vidim Apple Script (ako uopste prezivi) kao power user tool koji niko u stvari ne koristi i gomilu iOS like aplikacija koje su ostrva za sebe. Sto je isto kao prakticno mrtav, ziv je na papiru ali se ne koristi za sta se velikom vecinom koristio godinama.
Ja ću u to da poverujem (za šta se AS uglavnom koristi) kada izneseš neke relevante brojke (a to neće biti moguće). Sajtova sa AS primerima i živim diskusijama ima dosta (valjda ne postoje samo postojanja radi); a programi koji komuniciraju sa drugim programima preko AS-a (dakle baš AS-a, a ne direktno AEnevt-a) predstavljaju verovatno manje od 1% svih OSX programa.
