[13h45] Mac OS X Tiger -- Auf der WWDC wurde auch die systeminterne Suchtechnologie „
Spotlight“ vorgestellt. Unbeantwortet blieben die Fragen nach der Umsetzung, ob zum Beispiel ein neues Dateisystem Einzug hält.
Was man sich u.a. durch Blogs zusammenreimen konnte: ein kleiner „daemon“ hängt im Hintergrund und indiziert alle Dateien während des laufenden Betriebs. Dabei verwendet er eine offene Plug-In-Architektur um verschiedene Dateiformate auswerten zu können (PDF, Word-doc etc,,,).
Im Kleingedruckten ist noch mehr zu lesen. So soll die in „Tiger“ integrierte SQLLite-Datenbank
lt. eWeek dazu benützt werden um Daten und MetaDaten abzuspeichern („
including Core Data, which will offer a built-in SQL database and metadata store“).
[12h33] Apple_WebDev -- In Bezugnahme auf meinen Eintrag von gestern bzgl. der Implementierung eines
neuen Types für das input
-Element für Suchfelder in Apples Safari, meldete sich bei mir Gerrit. Ich zitiere aus seiner eMail:
Das „aufjazzen“ der Formularelemente ist eine Implementation des
Web Forms 2.0-Standards von
whatwg.org, einer Standardisierungsinitiative von Mozilla, Opera & Apple, von der du bestimmt schon gehört hast. Schau mal auf den zweiten
Screenshot. Siehst du den Slider-Control dort? <input type="range"> (
whatwg.org/specs/web-forms/current-work/#range). Die speichelerzeugende Neuigkeit wurde folglich schon von Steve Jobs auf der WWDC-Keynote gezeigt... Hat nur niemand gemerkt. Das Safari-RSS-Interface ist also kein „natives GUI“ sondern eine Anwendung von XML, CSS & JS, inkl. Web Forms 2.0.
Ich unterstreiche noch einmal Kernaussage: „
Das Safari-RSS-Interface ist eine Anwendung von XML, CSS & JS, inkl. Web Forms 2.0.“. Dies verdeutlicht den Quantensprung den Web-Applikationen mit anstehenden Standards annehmen können und paßt wie Faust aufs Auge in die Debatte um „
Windows API vs. Web Applications“
Dabei muss aber unterstrichen werden, dass
WebForms 2.0 noch kein abgesegneter Standard ist, sondern vor kurzem erst die Phase des „Calls for Comments“ erreicht hat. Einer der Initiatoren ist der Opera-Mitarbeiter
Ian Hixie, der eine vor einigen Tagen auch einen langen und lesenswerten Artikel zum Thema Windows API und Web Applications geschrieben hat: „
State of the WHAT“ (und dessen Erwähnung von Safari ich beim ersten Lesen übersehen habe, oder der Artikel wurde zwischenzeitlich aktualisiert)
Noch ein Punkt muss unterstrichen werden: was da „aufgejazzt“ wird ist nicht Apples Safari-Browser, sondern das im Betriebssystem verankerte „
WebKit“ auf das Safari, aber auch Nicht-Apple-Anwendungen zugreifen.
Die eigentlich Ahnung wie groß sich da Änderungen andeuten, bekommt man erst, wenn man das ganze im Zusammenhang mit „Dashboard“ setzt. Von mir anfangs kleingeistig als „Konfabulator“-Killer eingeschätzt, ist es nichts anderes als eine Oberfläche für Browser-Anwendungen ohne Browser, plus der Möglichkeit auf einige Systemfunktionen mehr zuzugreifen.
Dashboard-Anwendungen sind nichts anderes als
lokale Webseiten. Der Beweis wird
bei Erik Veland angetreten, der die Dashboard-Applikationen von der Tiger-Preview-CD runtergekratzt und ins Web gestellt hat. Weil natürlich die aktuellen Browser in der Unterstützung der neuen Standards noch nicht so weit sind, bzw. die Anbindung an das Tiger-Betriebssystem fehlt, „funktioniert“ nur ein Teil der Anwendung. Das Adressbuch kann zum Beispiel noch keine Daten aus dem OS X-Adressbuch abfragen. Aber
Taschenrechner und
Kachel-Spiel funktionieren bereits in Safari (wo das Problem bei Mozilla konkret ist, weiß ich nicht).
A Dashboard widget is a bundle that contains a principal HTML file and any supporting code that the widget requires (be it CSS, JS, images, or native code). A widget can add an optional interface to native code, written in Objective-C, that can be bound into JavaScript and made accessible from the HTML document's JS window object [...]
The „native code as a service accessible from JS“ model should be familiar to anyone who has used XPCOM with XUL. It's essentially the same idea. Extensions to the Firefox browser that contain native code can expose that native code to script as an XPCOM service, and then that object can be obtained from JS and have methods/properties invoked [...]
As for many of the animations, fades, slides, etc in the widgets themselves, they simply look so damn cool because of Safari's rich support for CSS3 used in conjunction with DHTML. Do you know what I talked about at WWDC? Image replacement. Sliding doors. Using opacity to create fade effects. CSS3 text truncation. Web standards. All of which are being used to full effect in Dashboard widgets. Our standards support has grown so rich and our engine has become so smooth at effects that people are constantly mistaking pure JS/DHTML/CSS stuff that people are doing for something fancier. I've heard „That's HTML?!“ several times in the past week.
[...] the new WebCore supports all of WinIE's drag events, and that's how drag and drop is done in the Dashboard.
Auch hier wiederhole ich noch einmal die Kernaussage: Animation und Aussehen der Widgets basieren auf CSS3, DHTML et al...!
Es gibt aber aus Sicherheitgründen einige wichtige Einschränkungen:
(1) The native plugin code must be owned by root. This means that in order for a Dashboard widget that contains one of these special types of plugins to execute that code, you have to enter a root account password (to chown the plugin code). This plugin code cannot execute, therefore, without the widget being „blessed“ just as an application that you might install on your system must be.
(2) This plugin will not be present in Safari or other WebKit applications, and is only accessible from Dashboard.
(3) The dashboard object is also exposed on the JS window object of the HTML document and has methods for „meta-functions“ that the Dashboard can execute.
Erst langsam ahne ich den vollen Umfang dessen, was Joel Spolsky
da geschrieben hat.