nämlich a) ein Lebenszeichen
und b)
Stopwatchicon
völlig unnütze Software. Als ich gestern nacht schauen wollte, wie ich mit meinem Referat zur Helvetischen Revolution in Bern (jaja, ein Historiker-Thema ich weiss. Besser als der Landadel am Lac de Paladru) so mit der Zeit drin war, merkte ich plötzlich, dass ich gar keine Stopuhr habe, mit der ich die Sprechzeite a) stoppen und b) jederzeit im Überblick haben kann. Und ein kurzes Googeln brachte mich da auch nicht weiter, fand nur ein Widget, und das ist eben nicht jederzeit sichtbar.
Was also tun: Schnell so eine Stoppuhr Programmieren, herausgekommen ist das extremst simple und hässliche aber seinen Zweck völlig erfüllende StopWatch (Universal Binary).
Stopwatchscreenshot
Entwicklungszeit < 1 Stunde, von dem her hat es mich nicht mal so gross aus der Referatsvorbereitung geworfen, dass ich wieder mal die Nacht durcharbeiten muss, hatte ich schon vorher begriffen.
Wie immer ist auch der Quellcode vorhanden, bitte einfach nachsicht haben: Bin in Cocoa immer noch ein Rookie und das ganze war wirklich nur schnell ein Build-For-Use. Denn heute morgen kaufte ich mir im Sportgeschäft (uhhhh, Mullzk im Sportgeschäft….) eine echte geile alte Digitale Stoppuhr, während dem referieren kann ich ja nicht dauernd den Compi offen haben. So eine echte Stoppuhr wie wir sie als Kinder hatten, mit hunderstel-Anzeige und blabla. Item, wer mal eine Stoppuhr auf dem Mac braucht, kann sich bedienen.

Jetzt mach ich es doch noch – ich poste was zu MacHeists Week of Independent Mac Developer.

Für jene, die noch nichts davon mitbekommen haben: In der Blog-Szene der unabhängigen (=kleinen) Software-Entwicklern für Mac OS X ist die Athmosphäre seit einigen Tagen nicht mehr gaaaanz so gut wie auch schon.
Angefangen haben die Scharmützel eigentlich schon Anfang November: Rund um den Hype der neuen Brenn-Software Disco gab es einige kritische Stimmen von älteren, klassischeren Mac-Emtwicklern – insbesondere kam der Vorwurf, dass Disco, der My Dream App Contest und ähnliche Sachen nur noch Marketing-Gags seien und damit dem guten Ruf der Mac-Software-Szene schaden würden. (Erwähnenswert in diesem Zusammenhang ist vor allem der Artikel zur Delicious Generation von Audio Hijack Pro-Entwickler Paul Kafasis).

Und dann starteten die „My Dream App“-Leute MacHeist – eine Aktion wo man 10 Mac-Produkte – u.a. die absolut grossartigen Delicious Library, Textmate oder Rapid Weaver – für den Spott-Preis von 49$ erhält, wovon erst noch 25% in die Charity gehen. Das ganze unter dem Titel „Week of Independent Mac Developer“ – als Dankeschön und Ehrerweisung an die unabhängige Entwicklerszene.

Und dann kam der Aufschrei – erst einmal Gus Mueller (VoodoPad, nicht im Bundle), der vorrechnete, dass bei diesem Bundle-Preis weniger als ein Dollar pro verkauftes Bundle an den einzelnen Entwickler geht, und dass dies ja wohl nicht der Weg sei, um sich bei den Entwicklern zu bedanken. Danach kam John Gruber, der zwar festhielt, dass die beteiligten Entwickler durchaus freiwillig dabei seien und sich daher wohl etwas von der Aktion versprechen, dass aber der Anteil, den MacHeist dabei macht, schlicht eine Frechheit sei. Dann war es am Zug von einigen der beteiligten Entwicklern (unter anderem Delicious Library-Entwickler Wil Shipley) darauf hinzuweisen, dass ihnen mit MacHeist kaum Erträge entgehen und dass der Profit der MacHeist-Leute für sie in Ordnung gehe, solange für ihre Programme derart viel Publicity herausspringt wie dies der Fall ist etc etc. Der Ton wurde härter, die Stimmung giftiger.

Das erste halbwegs konstruktive Statement kam dann von MacZealot-Mitgründer Justin Williams: „Rather than support gimmicks such as MacHeist that hurt the independent Mac software platform why not directly support shareware developers so they earn the full amount of money for all their hard work?“. Sein Vorschlag: Im Rahmen der „Real week of Independent Mac Developers“ solle doch jeder endlich die Mac-Shareware kaufen, die er schon lange Zeit ohne registriert zu haben einsetzt:

What a deal. I just got five great applications that cost $104 for $104. It’s a steal because these tools have either made my life sos much easier and happier. These applications are worth well more than the developers are charging: why should they take less just to get a good day of sales?

Die Idee fand ich gut – sowohl aus Prinzip wie auch als Antwort auf die ganze MacHeist-Debatte. Aber: Für mich nicht praktikabel, weil ich als flotter aufrechter Mensch prinzipell jede Shareware registriere, die ich länger als zwei Tage einsetze. Heute nun noch der zweite Vorschlag, diesmal von einem mir unbekannten Autor auf fairyuseless.com: Nicht Shareware kaufen (resp. das sowieso), sondern jenen Entwicklern, die ihre Software verschenken, ein Weihnachts-Geschenk machen: Bei Donationware endlich mal auf den Donate-Button klicken.

Tja, und genau das habe ich nun gemacht, und rufe dazu auf, dasselbe zu tun: Auch bei Software, die von den Entwicklern gratis herausgegeben wird, steckt eine gewaltige Arbeit dahinter – Arbeit die verdient hat, entschädigt zu werden, und sei es auch nur mit kleinen symbolischen Beiträgen. Einfach als Danke schön für den Programmierer: Danke für tolle Software, und erst recht Danke, dass Du Deine Arbeit verschenkst. Spendet, Leute, spendet.

Und weil es halt einfach dazu gehört – die Jungs die von mir was erhalten haben:
10base-T: Für Drop Copy – dem mit Abstand besten Tool um schnell Dateien von einem Mac zum anderem zu schieben.
Growl: Unbeschreiblich grandios. Unvergleichbar. Und nur für Mac. Sowohl als Klein-Stil-Programmierer wie auch als Endanwender bin ich einfach nur hin und weg von Growl.
Handbrake: Der einzig vernünftige weg, um Filme von einer DVD auf den Mac zu bringen.
Cocoa Dev Central: Für einige der besten Tutorials für Mac-Entwickler.
Disk Inventory X: Für die Übersicht, wo all die Bytes, die beim Kauf noch frei auf der Festplatte waren, verschwunden sind. Sehr praktische Funktion, super Darstellung

Ah ja – zum Schluss noch: In der ganzen MacHeist-Debatte schliesse ich mich voll und ganz der Meinung von Michele Balistreri auf Briksoftware an. Vernünftiger Ton, klare Aussage.
Ah ja 2: Im ersten Entwurf dieses Posts stand bei fast jedem der zitierten Blogger, was sie für absolut grandiose Jungs sind mit dem Extrem-Voll-Hacker-Durchblick. Im Text wirkte das irgendwie lächerlich: aber es sollte doch vermerkt sein: Wil Shipley ist ein Drei-Fünftel-Gott, Gus Mueller ein Halb-Gott, und mehr oder weniger alle anderen unabhängigen Entwickler sind mindestens Viertel-Götter.

wird neben mir wohl mal wieder kein Schwein interessieren, aber für mich übertrifft es sogar Zubis Patzer:
XCode kriegt Refactoring-Möglichkeiten !!!

Endlich. Ich habe mich immer gefragt, weshalb Apple da derart hinten drein ist.

1. Zwischenbemerkung für die Nichtprogrammierer: XCode ist das Programm, in welchem OS X-Programme programmiert werden – eine sogenannte Entwicklungsumgebung oder IDE. Man kann auch ohne IDE programmieren, einfach mit einem simplen Texteditor, aber IDEs helfen einem dabei, den Überblick zu bewahren, alles ein bisschen näher zu haben und bestimmte Dinge per Knopfdruck zu automatisieren. Um die richtige IDE mit den richtigen Einstellungen gibt es zuweilen blutige Glaubenskriege – beim programmieren von OS X-Programmen ist aber XCode haushoch Marktleader, nicht nur weil es gratis ist (IDEs können brutal teuer sein), sondern weil es halt einfach die einzige IDE ist, die speziell auf die Charakteristika und Mechanismen von OS X ausgelegt ist.

2. Zwischenbemerkung für Nichtprogrammierer: Refactoring bedeutet das ändern des Codes, ohne die eigentliche Funktion zu ändern. Beispielsweise hatte ich bei meinem MacAlarm ein Objekt namens iTunesAlarm erstellt, als eine Abstraktion über das losgehen eines Radioweckers, in welchem festgelegt wird, um welche Uhrzeit welche Playlist in welcher Lautstärke abgespielt werden soll. Dann merkte ich aber, dass ich noch einen zweiten Wecker in MacAlarm integrieren will, der blöde nervige Weckertöne vor sich gibt, der aber gewisse Charakteristiken mit dem iTunesAlarm teilt, zB dass er eine Einstellung für die Zeit und eine für die Lautstärke hat. Ich will also das Objekt iTunesAlarm aufteilen: ein Teil der die generellen Charakteristika eines Weckers besitzt, und ein zweiter Teil, der nur für einen iTunesWecker gilt und auf Mechanismen des generellen Weckers zurückgreift (in der Programmierersprache: iTunesAlarm ist eine Subklasse des abstrakten Objekts Alarm und erbt dessen Merkmale (Attribute) und Fähigkeiten (Methoden). Refactoring ist nun die reine Handarbeit dieses aufteilens – beispielsweise, dass überall, wo bisher auf iTunesAlarm verwiesen wurde (und das sind viele Orte in MacAlarm) nun nicht mehr iTunesAlarm im Code steht sondern Alarm. Kleine Sachen, die aber in grosser Menge und absolut zuverlässig gemacht werden müssen, denn programmieren erlaubt keine Schreib- und Flüchtigkeitsfehler, und mit Copy und Paste verliert man auch fast immer. Die Funkionalität wird nicht geändert, aber Struktur und Darstellung des Codes.

Wo war ich? ah ja: Ich habe mich immer gefragt, weshalb Apple da derart hinten drein ist.
XCode ist meines Erachtens die stärkste aller IDEs wenn es um das erstellen eines neuen Programmes geht. Nirgendwo kriegt man in derart kurzer Zeit derart viele Funktionalitäten und erst noch eine brauchbare Oberfläche hin. Aber: Programmieren ist nicht einfach neues erschaffen. Man verbringt deutlich mehr Zeit am abändern von Code (sei es um Bugs auszumerzen oder die Möglichkeit zu haben, neue Features einzuklinken. Und am meisten Zeit braucht man, um den alten Code zu verstehen, den man letzte Woche oder gar letztes Jahr geschrieben hat, noch schlimmer, wenn es nicht mal der eigene Code ist, den man bearbeiten möchte. Peter Hallam’s Artikel ist zu diesem Thema glaube ich immer noch das beste was ja geschrieben wurde – er spricht darin von folgenden Verhältnissen:
New Code: 5%
Modifying Existing Code: 25%
Understanding Code: 70%
Wohlbemerkt: Hier geht es um Zeit-Verhältisse, aber die Hirnschmalz-Verteilung dürfte ähnlich sein.

Refactoring ist der absolut zentrale Schlüssel zu den Punkten zwei und drei: Um Code zu ändern, muss man ihn fast immer neu strukturieren. Und chaotisch durcheinander gewürfelter Code ist fast unmöglich zu verstehen. XCode aber kannte bis dato kaum oder nur winzige Refactoring-Mechanismen. Sogar wenn ich nur den Namen einer Klasse verändern wollte, musste ich a) im Editor ein Search/Replace über alle Files machen (und dann nicht etwa automatisch „Alle ersetzen“, sondern einzeln durch alle Dateien durchgehen, denn vielleicht gab es neben dem zu ändernden iTunesAlarm auch mal ein iTunesAlarmDelegate oder was auch immer, das von der Änderung nicht betroffen sein sollte. Und wenn dann alles ersetzt war, wurde es erst schmerzhaft: Die Bindings in Interface Builder (dem Tool, mit dem man die graphische Oberfläche eines Programms erstellt) reagiert nicht auf solches Search/Replace. Da musste man alle Elemente einzeln durchgehen und manuell abändern, und wehe man vergass es irgendwo – denn dann gibts beim compilieren auch keine Fehlermeldung – sondern einfach einen simplen Absturz im fertiggestellten Programm. Very very nice.

Vor XCode arbeitete ich meist mit Eclipse, einer IDE die umfangreiche Refactoring- Funktionen anbietet. Der Schock, als ich mit XCode anfing war gross: Ich konnte mir kaum vorstellen, dass man heutzutage noch so arbeiten kann und suchte tagelang nach entsprechenden Funktionen. Nix da. XCode 2.0 ist sackstark, wenn es um das erstellen geht, um den ersten Entwurf eines Programm. Die ersten 5%. Der Rest der Arbeit, das verfeinern, abändern, umdenken, die restlichen 95%, die waren bei XCode immer die Hölle.

Und nun gibts mit XCode 3 in OS X Leopard nicht nur Garbage Collection und Block Folding, jetzt hat Apple auch noch Refactoring-Tools:

To allow you to work more rapidly and effectively, Xcode 3.0 offers support for re-factoring your Cocoa applications. This means you can now make structural changes to your source code without accidentally changing its behavior. Instead of performing multiple search and replace operations, you can rename an instance variable and update all of the methods that work with that variable, including indirect access through KVC style methods. This re-factoring support extends beyond your source code and will even update bindings set in your nib files

Läck, freue ich mich auf XCode 3. Und weil mein iBook mit Leopard kaum noch klarkommen wird, freu ich mich auch schon jetzt auf die neue Hardware im 2007. Das wird ein langes warten…

So, jetzt bin ich endlich so weit: MacAlarm steht als Beta-Version. Die Veröffentlichung auf Macupdate und Versiontracker kommt spätestens dieses Wochenende – ebenso wie die Bekanntmachung auf Apfeltalk. Mal schauen wie weit man damit kommt.
Der wichtigste Promotion-Kanal heutzutage ist aber natürlich Google. Und damit ich da auch irgendwo auftauche, hier mal die Feature-List:

  • iTunes zu beliebiger Zeit mit beliebiger Playlist starten
  • Wer zu Musik weiterdöst statt aufstehen: Wie wärs mit einem nervigen Klingelton – ob nun von einem digitalen oder analogen Wecker ?
  • Immer noch zu wenig nervtötend, um weiter zu schlafen? MacAlarm lässt natürlich auch eine wahre Kaskade von nacheinanderfolgenden und gleichzeitigen Weckern zu. Und jedesmal wird die Lautstärke wieder voll aufgedreht, für all jene, die die Lautstärke auch im Vollschlaf runterschrauben können.
  • Sleep Timer, um iTunes noch ein Weilchen zum einschlafen mitträllern zu lassen. Ebenso eine rudimentäre Integration des Ruhezustandes und um-eine-bestimmte-Zeit-Aufwachen von OS X.
  • Falls erwünscht: Automatisches Update.
  • Falls erwünscht: Automatisches Bug-Reporting.
  • Falls erwünscht: Integration mit Growl.

Weitere Informationen gibts auf der MacAlarm-Seite.
Hier gehts zum direkten Download: MacAlarm (3.1 Megabytes. OS X Tiger samt iTunes ist einzige Voraussetzung).

Achtung: Beta-Phase bedeutet, dass das Teil erst auf meinen Systemen getestet wurde. Ich habe noch keine Ahnung, wie es sich auf anderen Systemen verhält, auch wenn ich überheblicherweise keine Probleme vermute. Wenn etwas schief läuft und dein Mac danach nicht mehr so funktioniert wie er sollte, biete ich natürlich meine Hilfe an, aber übernehme keine Verantwortung. Für gar nichts.
Und als kleiner Tip: Zumindest beim ersten Ernsteinsatz würde ich noch einen zweiten Wecker stellen oder den Telefon-Weckdienst einschalten. Nicht dass da ein Software-Versagen zu Komplikationen mit dem Arbeitgeber führt….

Und eine kleine Bitte: Ich würde es extrem schätzen, wenn ein paar der Handvoll Lesern meines Blogs das Ding mal ausprobieren würden, auch wenn man es nicht braucht. Einfach um zu sehen ob es funktionieren würde oder ob es subito abstürzt. Ich bin für jegliches Feedback dankbar.

So, mein erstes Projekt ist fürs erste gemacht, allerdings wirklich nur fürs erste: MacAlarm ist per sofort als erste Beta-Version runterladbar. User-Erfahrungen werden sehr gerne entgegengenommen. Die grosse Vorstellung folgt später, nur schnell eine kurze Aufstellung:
Features:
– Es kann eine beliebige Anzahl von Weckdiensten eingerichtet werden.
– Neben iTunes-Playlists können auch nervige Weckertöne abgespielt werden.
– Mit dem Schlafmodus komme ich noch nicht ganz zu recht – aber immerhin geht das einschlafen schon ganz gut und fürs wieder Aufwachen öffnet sich immerhin das entsprechende Fenster der Systemeinstellung.
– Ich bin zumindest nicht ganz unzufrieden mit Design und Widget-Verhalten. Klar verbesserungsfähig, aber wenn man das mal mit Konkurrenz-Produkten vergleicht bin ich glaub ich immer noch sehr gut im Rennen.
Ansonsten: Einfach mal ausprobieren. Es ist nicht die grosse Software, aber ich glaube sie tut ihren Dienst.

Benutzte APIs und Frameworks:
Cocoa Bindings
Core Data
Quicktime
Applescript
Sparkle
Growl
sowie zusätzlich meine erste Version für ein Crashreporter-Framework ohne Input Manager. Aber noch zu stark verbesserungswürdig, um es als Framework zu veröffentlichen.

MacAlarm ist gratis resp. OpenSource. Weil ich aber das eine oder andere noch schöner machen will, schmeisse ich die Quellen momentan aber noch nicht aufs Netz. Falls irgend jemand aus irgendeinem Grund diese aber mal sehen möchte, genügt ein Mail.
So und jetzt leg ich mich mal hin. Irgendwie glaube ich müsste ich mir keinen Wecker sondern einen Einschlafer programmieren, der mich zu einer bestimmten Zeit ausser Betrieb nimmt. Wäre wohl sinnvoller….

Ah, das wurde ja auch Zeit. Uni vorbei, Pendenzen abgebaut und die WM nimmt auch nicht mehr soviel Zeit in Anspruch wie auch schon. Als Warmup für Cocoa zwei kleinere Projekte:
Mein guter alter iTunes-Wecker Alarm Clock S.E. verweigert seit einiger Zeit den Dienst; Ersatz ist nötig, und gratis soll er auch noch werden. Erhoffte Lerneffekte:

  • Applescript von Cocoa aus steuern.
  • Umgang mit Schlafmodus
  • Core Data und Bindings

Und dann noch ein kleines Ausgaben-/Einnahmen-Überwachungstool, welches ich parallel von iBook und G5 aus benutzen kann. Erhoffte Lerneffekte:

  • Core Data und Bindings
  • Rendezvous
  • .mac SDK
  • Vorbereitung für ein saubere Buchhaltungs-Programm für OS X.

Ein erstes ist mal schon erledigt: Abfragen von iTunes aus einer Cocoa-Klasse hinaus. Applescript ist noch nicht so wirklich in der Zeit von Objective-C angekommen, zuviel läuft noch über das C aus dem alten Zeiten. Ich habe nun mal eine Helferklasse erstellt, die simple Befehle und Abfrage in zwei Zeilen ermöglicht. Mehr dazu im Post zu APApplescriptHandler.

Wenn es mit dieser Geschwindigkeit weiter geht, werden das ganz geile Ferien….

Veröffentlicht in Cocoa

So, I wanted to query iTunes from within a Cocoa-App for all of its playlists. Sounds simple, doesn’t it? And telling iTunes to start playing must be even simpler, or not?

Of course, you could do this quit simple:
– Get the path of the iTunes Library
– Parse the iTunes Library.xml for playlist entries
– use osascript(1) to tell iTunes to start playing the playlist.
Simple as that. But heck – somehow this does not really look satisfying. Parsing another app’s Property List and Library? Going to shell to execute Applescript? Pleeeease…

Next Step: Let’s check the API for Apple Events
e Events. Hummm. Stranded in Carbon? Yup: No classes, no easy-understood-easy-used methods – plain obfuscated C. Nonononono.

OK, another way: Using Foundation’s NSAppleScript, a nice wrapper for the API. But wait: Why is it necessary to write 10 or more lines for a simple query? And why do we find ourselves in pure ugly C-Code after Line 5? Nope, not what I was looking for.

What I really want is a handle, which I can connect to an app, and then just posting a Message and retrieve the result. As far as I can see, there is nothing which would provide some simple of use within an OO construct. Sounds like a job for a Student on holiday… Enter APApplescriptHandler

APApplescriptHandler * iTunes = [[APApplescriptHandler alloc] initWithApplicationName:@“iTunes“];
[iTunes performMessage:@“playpause“];
NSString * string = [iTunes getStringForMessage:@“name of current track“];
NSArray * array = [iTunes getArrayOfStringsForMessage:@“

ApplescripHandler; Interface; Implementation
This is one of my first things done in Objective-C – so the Code most probably stinks for any experienced Programmer. I sure hope it will stink for me too in some months. But experienced Coders most propably won’t have any use for this class, and for newbies it will work and look just fine. Just be sure to catch the NSException if you use getArrayOfStringsForMessage: with a Message, which does not return a list. Every other Error I could think of is treated internally and results in a returning nil.
Any feedback is very welcome.

Veröffentlicht in Cocoa

Good news everyone: As all-time-hero John Siracusa points out, we will eventually have Garbage Collection in Objective-C, at least when a) Mac OS X.5 Leopard comes out and b) everything goes as planned. Looks like the corresponding pointer in the gcc was available since first release of Tiger, but nobody really looked at gcc’s manpage, or those who did simply told it no-one.

-fobjc-gc
Enable garbage collection (GC) for Objective-C objects. The resulting binary can only be used on Mac OS X 10.5 (Leopard) and later systems, due to additional functionality needed in the (NeXT) Objective-C runtime.

For the non-programmers: In C-Type languages like Objective-C, you have to manage to memory of every variable yourself, by counting every reference made to the variable and releasing the memory, when no-one references to it anymore. If you release to early, your application will crash, if you release to late or never at all, you have a memory-leak and your application will get slower and slower and slower and finally start to do funny things like crashing. Managing memory is quite painful, especially for beginners or people like me, coming from a language where you don’t need to.

Garbage Collection is a feature of Classic Languages like Smalltalk and some newer languages like Java, Ruby, Python and C#, and simply said, GC does it all for you – you just don’t have to worry about memory anymore.

Objective-C is THE progamming language for Mac OS X, almost all never applications are written in it. Bringing Garbage Collection to Objective-C means lower hurdes for new Mac Programmers, probably leading to more Mac Programmers and more cool software.

Just great news. Hope they will succeed in making a real good Garbage Collection and not having to withdraw this.

Sore Points in Developping for Mac : -1
Remaining only my wish for good refactoring tools in XCode, and then I will be happy after all.

Last Post today: Three good reads!
1) Peter Hallam from Microsoft, pointing out the important thing of a good IDE. He starts with the experience that developers spend 2-5% of their time in writing new Code, 20-25% in modifying existing Code and the rest of the time in reading and understanding old Code, and therefore concludes:

If we spent a ton of work, making intellisense, designers and wizards so good that writing new code took no time at all. Zero time. The ESP coding interface. That would still have less developer impact than a 10% reduction in the amount of time developers spend understanding the code base they are working in.

Looking at Xcode: Apple is near to zero time for producing new Code. The Sceleton of a simple app can be made on a rainy afternoon (how great is Core Data combined with Bindings? Whoooha).
But then? Modifying Code is horrible. No refactoring at all. If you have ever used eclipse oder intelliJ, you know what would be possible, and you will miss it. I mean, XCode doesn’t even let you change a Class name without giving you a headache. And how easy would it be to automaticaly prepare an Interface-File?
But reading Code is even worse. No block-folding. No Class-Inspectors. No Jump-to-Class-Definition-Shortcut. No visual Flow-Representation.
I really do like coding in XCode. I really do like fast results. But if I am honest to myself: It’s an IDE from the old days, where Marketing Features were everything and real use didn’t count. I really hope that Apple goes into a direction, towards which even Microsoft is headed for some years now…

2) Eric Lippert, taking on Hallams post. Why Programming looks like Rocket Science, but really is more like brain surgery, and why software engineering should transform it to Rocket Science again.

3) Paul Thurrott ranting about Windows Vista. Thurrott, the guy dissing OS X for not running Minesweeper, the one who accused Apple of stealing Spotlight, Aqua, Filevault, the Dock and even Expose from Microsoft, this Paul Thurrott blames Microsoft failing with Vista. I always knew that Microsoft will fall someday. Sometimes I even thought, that it could be within the next 30 years. Sometimes I even hoped, that Linux will be the Destroyer, and very rarely I dreamed of Apple winning the next round. But know, with a Microsoft-Fan like Thurrott ranting about Windows Vista and blaming Redmond to fail miserably, not being able to make a big OS-transition anymore, there’s only one thing left to say: „Welcome back to the fight. This time, I know our side will win!“

A big booo to Apples Documentation once again. In a very boring Human-Computer-Interaction-Lecture I finally went along with my Hattrick-Viewer-Project, which slept for some months. Todays task look quite simple: Add the possibility to drag a Link onto the Application, so that the URL of the Link gets evaluated and the match behind the Link gets added to the HT-Live-List.

Dropping the Link to the Applications Main-Window is easy and well documented. But I wanted to enable dropping links to the Dock-Icon too, and this was sorta trickier than I expected…

Weiterlesen

Veröffentlicht in Cocoa