Gus Mueller has announced JSTalk, an alternative to AppleScript that uses JavaScript and the JSCocoa bridge, and an Objective-J-like language alternative to hide the ugly_methods_when_needed.
Here is Gus:
JSTalk's goal can described like this: JSTalk is to AppleScript, what Cocoa is to Carbon.
I know, I know. It's a lofty, crazy goal. But someone has do try and it doesn't look like the solution is coming from Apple anytime soon. So I'm keeping it very simple, and very easy.
JSTalk isn't anything new. You write your scripts in JavaScript, and application communication is handled via Cocoa's distributed objects. Like PyObjc and RubyCocoa, JSTalk uses a bridge to talk to Cocoa (JSCocoa + WebKit's JavaScriptCore), so you get all the power and speed that comes with it. JSTalk comes with a little editor, a command line tool, and an automator action. If an application you want to script isn't exposed via JSTalk, you can still tell it what to do via the Cocoa Script Bridge (which is new to 10.5). Here's an example which sets your iChat status using this technique:
On Friday, the SVG and CSS working groups of the W3C published the first working drafts of Apple's proposed graphics and styling extensions:
The CSS and SVG Working Groups delivered today
five new specifications for public review, aimed at enabling more compelling content creation with open Web technologies. The five drafts are: SVG Transforms 1.0, Part 2: Language, CSS 2D Transforms Module Level 3, CSS 3D Transforms Module Level 3, CSS Animations Module Level 3, and CSS Transitions Module Level 3.
SVG Transforms allows two-dimensional objects to be transformed using three-dimensional transformations.
CSS 2D Transforms allows elements rendered by CSS to be transformed in two-dimensional space. CSS 3D Transforms extends CSS Transforms to allow elements rendered by CSS to be transformed in three-dimensional space. CSS Animations allow an author to modify CSS property values over time. CSS Transitions allows property changes in CSS values to occur smoothly over a specified duration.
The groups are working closely together to make implementing and authoring these features easy and consistent across Web languages.
Learn more about the Style Activity and Graphics Activity.
Thanks to Harry Underwood for pointing this out to us!
Great news for Web developers and users, Safari 4 has a public beta, and it comes with some nice features such as: tabs on top and top sites (a la Chrome), full page zoom, history view, and ARIA Support.
The Twitter thumbnail is interesting
But, what about the engine? Here are some of the features as Apple see's them:
Speculative Loading
Safari loads the documents, scripts, and style information required to view a web page ahead of time, so they’re ready when you need them. CSS Effects
Pioneered by Safari, CSS effects help developers add polish to websites by stylizing images and photos with eye-catching gradients, precise masks, and stunning reflections that require only a few lines of code.
CSS Canvas
Using CSS Canvas, web designers can position canvas elements anywhere an image can be placed using CSS. Safari is the first web browser to support CSS Canvas.
Acid 3 Compliance
Safari is the first — and only — web browser to pass Acid 3. Acid 3 tests a browser’s ability to fully render pages using the web standards used to build dynamic, next-generation websites, including CSS, JavaScript, XML, and SVG.
Nitro JavaScript Engine
Safari 4 introduces the Nitro JavaScript engine, an advanced bytecode JavaScript engine that makes web browsing even faster. In fact, Safari 4 executes JavaScript up to 6 times faster than Internet Explorer 8 and up to 4 times faster than Firefox 3.1.
HTML 5 Offline Support
Web developers can now create applications that you can use even when you don’t have access to the Internet. Thanks to HTML 5 offline support, designers can build web applications that store themselves on your computer, where you have immediate access to them. Along with the application, web developers can also choose to store the application’s data on your system, so you always have the information you need. Applications and data can be stored in a traditional SQL-like database serving as an application cache or as a “super cookie,” which stores data in the familiar cookie format.
There are some new articles up on how to use the tech, such as:
I had an Automator script that would go out and grab WebKit nightlies for me. NightShift does the deed for you on the Mac. But, no more.
WebKit joins Firefox, Chrome, and other browsers in auto updating channels of development.
Great stuff. Now we can live on the edge, and report bugs as they occur.
I am utterly astounded at how stable the nightly builds are for the browsers out there. Minefield is running like a charm for me, and WebKit nightly is nice and snappy. Rarely a crash on nightly code. Thanks to the browser developers for making this the case.
As soon as I heard about the new iWork.com site launched yesterday, I knew I wanted to know more about how it was made. iWork.com is a web-based way to share and collaborate over your iWork documents. I searched around the blogosphere seeing if anyone knew any technical details, but didn't find anything, so I had to crack open Firebug and see what was under the covers. I really wanted to know whether the apps were built with Flash or Ajax or something else.
I downloaded a trial version of iWork 2009 and published a Keynote presentation. The new Sharing function unfortunately requires you to configure and use the Apple Mail program, which I did before I could test out to see how the iWork.com shared documents work.
Looking at the JavaScript files, I see SproutCore and Prototype being pulled in, so everything is built with Ajax and web technologies. It's also using WebDAV to pull in the metadata about the document, which is interesting (though it's piping the WebDAV over some kind of proxy):
Notice how some of the metadata payload is JSON as well.
The web-based iWork apps are themselves built above SproutCore, using that framework to organize and do things. For example, there appears to be something named CoreHeckler that has to do with the commenting system, all built using SproutCore.
Using the Firebug Inspector, I see that the slides are a combination of an image file, the Canvas tag, and transparent DIVs that overlay; if there are hyperlinks on the page they are overlaid on a separate DIV that lies over the canvas. Comments also float on top of the Canvas using another DIV. The Canvas appears to be used for comments somehow, but I'm not sure how. I see CoreHeckler.Graphics being bound to the Canvas element; I'm not super familiar with SproutCore however.
Looking through the CSS I see they are using a few -webkit- specific CSS style rules, mostly around rounded border corners and shadows. They are also using the Webkit CSS Gradients and Clipping.
I wanted to see how things were handled in Internet Explorer. When I look at a published iWork.com document in Internet Explorer a very interesting dialog box first appears:
It was indeed slow; it took about 17 seconds to load the document in IE. Clicking on individual slides took about 4 to 5 seconds to show.
I used the Internet Explorer Developer Toolbar to get into the DOM and see how things run on IE. The first thing I see is that the Canvas tag is in the DOM:
However, notice a glitch that it has the <CANVAS> and </CANVAS> tags as separate elements, which can sometimes happen when IE is dealing with unknown tags. They are also definently using VML (Vector Markup Language) on IE, since I see them pulling in the VML behavior for IE on the main page. I wonder why they didn't just use the Google-ExCanvas library that emulates Canvas for Internet Explorer (Disclosure: I work for a team at Google that promotes open web technologies like this).
One other thing I noticed is that if you are on the iPhone you get redirected to an iPhone version of the app. This just replaces the URL /document/ section with /iphone/. When you navigate to this you get a PDF version of the page -- that must be the iPhone version, a PDF file!
I wanted to see how the Pages application does things as well, so I published a document there. The published text is selectable in the browser! The document itself appears to be an image file. To do selection, whenever I run over some text it appears that a Canvas element is created and a 'highlighted' type graphic is drawn over the correct characters. Internet Explorer also supports similar highlighting, though on there it appears to be using VML to do the highlighting.
All in all this is a very interesting web-based application built with Ajax and JavaScript!
Robert Tomsick has been playing with Sandboxed Safari, a project that aims to let you use the Leopard sandbox feature with the browser, via a little launcher:
When Leopard was released, one of its big selling points was its "sandbox" feature. This garnered a fair bit of attention, as sandboxing is a fairly new feature for consumer operating systems.
A lot of people (myself included) assumed that Leopard's sandbox system would be used for Safari, seeing as how web browser exploits are a tremendously popular attack vector. Unfortunately, Leopard's version of Safari is not sandboxed. In fact, very little of the OS actually is. I don't know the real reason behind this, but I suspect it had to do with the release date pressures. Although Leopard ships with a number of sandbox profiles for things like syslog and ntpd, they are not used in the default config. Pretty much the only things that are sandboxed are mDNSResponder and some xgrid daemons. A quick look at the comments in the existing policies indicate that Leopard's sandbox system (named "seatbelt") is rather... buggy. As it turns out, the comments don't lie -- seatbelt *is* quite buggy, at least as of 10.5.6. Still, it's an extraordinarily powerful (not to mention cool) feature, and it's got a lot of potential to increase the security of Mac OS X.
But enough rambling about seatbelt. I'll make a few pages documenting what I've learned about it -- but until I get around to doing that, let's talk about Safari. Basically, I found that Leopard's sandbox system, buggy though it may be, is sufficiently mature as to allow the development of a seatbelt policy for Safari, albeit with some caveats. SandboxedSafari is my attempt at developing such a policy.
He continues to discuss the flaws: No plugin support, overly-permissive process-exec rules, no network filtering, no address book integration, no keychain, focus issues.
It will be interesting to see if Safari 4 + Snow Leopard gets us this out of the box.
New language addition to Objective-J: The @accessors keyword to eliminate the boiler plate code of writing setters and getters. Read more about it here.
Support for more classes like CPTimer.
Performance improvements all around, but especially in Objective-J thanks to a major rewrite of the parser.
Improved debugging tools and a new debugging “mode”.
Tom Robinson has created an interesting new tool called nib2cib that could lead to you being able to use Interface Builder to create Ajax frontends.
nib2cib is a command line tool designed for converting Cocoa’s nibs and xibs to Cappuccino’s cibs. It is still very much a work in progress, but is a good foundation for starting to fully support nib-style development on Cappuccino.
nib2cib converts nibs and xib that you supply to it on the command line to cibs. Given the new nature of this program, a good place to try it out is with NibApp:
$ cd /path/to/Cappuccino/Tools/NibApp
Copy or symlink the Cappuccino Frameworks to this directory
$ nib2cib HelloWorld.xib
Open /path/to/Cappuccino/Tools/NibApp/index.html in your favorite browser.
The basic task behind nib2cib is to convert NS-classes to CP-classes. When you give it a nib or xib file, nib2cib open the file, unarchives the actual NS-objects, converts them, and then archives the CP-equivalents.
I noticed the new iPod Engraving Gallery that is a nice use of Coherent to show a slick UI with engraving suggestions.
I was also talking to a friend that has leopard beta bits and he was playing with an updated Dashcode. It appears that the Coherent library is now used for the widgets too. Yay data binding!
We've talked a bit about Apple's extensions to HTML and CSS; <canvas> has of course gone on to much fame and fortune. Charles Ying pointed us to his CSS-VFX project which aims to be
a collection of components and code examples that illustrate the power of CSS Visual Effects. So far, only 1 gem that illustrates a popular RIA user interface demo, "Cover Flow" is currently available. If you'd like to see more, please don't hesitate to suggest something you'd like to see.
Charles has a blog entry with a video showing off a mobile Safari demo of using Apple's CSS Visual Effects to create a Cover Flow interface:
The demo makes use of a variety of these extensions:
* zflow starts by loading each image from the images array. When each image is loaded, we scale the image to fit in a square region, and apply 3D CSS transforms to scale it in place.
* Reflections - zflow then takes the scaled image and creates a Canvas element that contains a gradient alpha mask of the image’s reflection (using a “reflect” function to do this) and positions the canvas element in place.
* Touch Controller - zflow creates a TouchController object, who’s job is to field touch events from Mobile Safari and calculate an appropriate offset.
* Clicking - zflow detects when no move events have been made, and zooms + rotates the focused image forward by setting a “CSS Transition”ed 3D transform on the focused image. Clicking again transitions the image back.
* Inertia - zflow achieves inertia by setting the “transition timing function” of the “tray” to an “ease-out” function, which slows things down. On the touch end event, we calculate the projected velocity and set the tray’s target position to that location. CSS Transitions handles the decay in velocity as the transition timing function executes — slowing the tray down gradually.
It makes you wonder how many folks are going to need to learn the SDK in the future...
Wouldn't it be nice if we actually had a decent component model? Instead of making JavaScript frameworks have to mess around and try to create one on top of the crud they have to deal with?
This is what XBL 2.0 is all about. I talked about XBL in one of my Web Archeology posts, and how Jonas Sicking of Mozilla was back working on the implementation for Firefox.
This means that fairly shortly we will have Firefox and WebKit/Safari running with XBL 2 support. That in turn means that we will have an interesting component model for the first time, and who knows where that could lead us!
, JavaScript
