Stattoo

February 14, 2006

Stattoo è una piccola utility fatta da Panic. Uno dei più celebri prodotti di Panic è Transmit, a detta di molti il miglior client FTP per Mac (io personalmente sono affezionato a Fetch, che come studente posso avere in licenza gratuita e che ho usato fin dalla versione 1.x nei primi anni ’90, ma i meriti di Transmit sono indubbi).

Un’altra applicazione di Panic è Unison, ottimo newsreader per gruppi binari (per i le discussioni francamente lo trovo abbastanza povero, ma si stanno attrezzando). Ad ogni modo, ora è il turno di “Stattoo”. Il prezzo è 12.9 $. L’applicativo stampa sul desktop alcune informazioni con una bella veste grafica.

Stattoo Example

Per ora sono disponibili:

  1. Ora
  2. Data
  3. Appuntamenti di iCal
  4. Ultime Mail di Mail o di un qualunque account pop/imap anche non specificato in Mail
  5. Lo stato di iTunes
  6. Lista degli ultimi software arrivati su VersionTracker
  7. Spazio occupato sui vari dischi
  8. Temperatura locale
  9. Stato della batteria

La maggior parte di queste features sono ottenibili in altro modo. Spesso con dei widget o dei programmi. Tuttavia Stattoo è molto più veloce di Dashboard e cerco di tenerci quanta più roba possibile.

Varrebbe la pena di comprarlo anche solo per i punti 3 e 4. E anche la batteria è comodissima. Inoltre si può “sollevare” Statoo in trasparenza sopra le altre finestre schiacciando un tasto.

stattoo2.jpg

La cosa che però mi ha fatto decidere definitivamente per l’acquisto è stata la professionalità. Ho inviato una email facendo presente che per la mia città (Parma) non era disponibile un codice areoportuale ICAO (per le città non-USA viene usato questo per identificarle) e quindi non potevo usare il modulo “Weather”.

In effetti non è che la mia città non avesse un codice ICAO, solo il sito da Panic consigliato per scoprire tali codici presentava solo il codice IATA (un’altra sigla, poco importa cosa siano effettivamente). Ho mandato una email per chiedere consigli, dicevo.

Un gentilissimo dipendente (o forse proprietario o programmatore) mi ha risposto dicendomi il codice ICAO della mia città. Ovviamente funziona tutto. Immagino che in caso di problemi (all’epoca non ero ancora registrato) siano altrettanto celeri. E questo deve essere il valore aggiunto delle piccole case software: idee, ben realizzate e rapporto “umano” con il cliente.

Advertisements

Window Shade X

February 12, 2006

Credo di non avere mai decantato pubblicamente questo piccolo software. Lo registrai per la modica cifra di 10 $ (molto moderate. Quando un programma è buono e mi piace, lo compro, anche se è commerciale [ posto che me lo possa permettere ]. Questo è ancora più valido se si tratta di software di piccole case o singoli sviluppatori che mettono passione nel loro lavoro.
È il caso di TextMate di Allan Odgaard e di BBEdit (questa per esempio è una media software house che si dedica da anni a sviluppare ottimo software per Mac). È il caso di Yojimbo, sempre di BareBones (questo lo sto ancora valutando nei 30 giorni di prova). È il caso di GraphicConverter, che ho usato a sorti alterne credo fin dalla versione 1 sui miei vecchissimi Mac (e adesso uso in quanto la licenza viene pagata da Apple se acquisto un Mac di fascia “pro”). È il caso di MacSOUP (anche se ultimamente mi sto stancando di quanto poco sia “aquoso“, d’altra parte è uno di quei programmi che la licenza la paghi una volta e poi lo usi sempre).

Beh… fra questi ottimi software ci sono anche un paio di utility di Unsanity. Mi riferisco in particolar modo a FruitMenu e a WindowShade X. Dei due quello che uso più di frequente è senza dubbio il secondo. Altre utility interessanti di Unsanity sono ShapeShifter per cambiare il tema al MacOS e MenuMaster che sto valutando.

Window Shade X

Una delle cose che meno tollero di MacOS X è il dock. Lo trovo una brillante idea terribilmente sprecata. Al di la di ovvi problemi di coerenza di interfaccia (ad esempio al di la del separatore ci stanno finestre minimizzate, documenti, cartelle e cestino, mentre a mio avviso almeno le finestre dovrebbero essere da un’altra parte). Dicevo, le finestre da un’altra parte anche per ragioni di spazio.
Se si minimizzano molte finestre il dock si allunga e diviene quasi ingestibile. Questo problema viene risolto brillantemente da WindowShade X. Infatti permette di “minimizzare le finestre sul desktop: cosa intendo? Guardate l’immagine.

windowshade1.png

In questo modo posso facilmente minimizzare le finestre (posso anche spostarle sul desktop come fossero icone). Per esempio posso “rebindare” il pulsantino giallo per fare questo e continuare a minimizzare sul dock con Mela-M.
Per chi se lo stesse chiedendo… si, la minimizzazione sul desktop è simile a quello che fanno alcuni window manger sotto X11, per esempio twm [ ovviamente in modo oltremodo più raffinato, come si può vedere dall’immagine ] oppure il mio amatissimo WindowMaker. Triste che oggi ci si sia tutti o quasi omologati su sistemi molto più pesanti anche su GNU/Linux (senza nulla togliere a GNOME e KDE, solo meno  “originali”, per come la vedo io).
Un’altra funzione davvero comoda (la maggior parte delle volte uso questa) è minimizzare una finestra alla sua barra del titolo facendo doppioclick sulla stessa. Questo c’era in MacOS 9 e Apple lo ha (stupidamente?) tolto in MacOS X. È qualcosa presente anche su molti wmanager per X11, metacity per citarne uno.
Il tutto coopera perfettamente con Exposè e rende lavorare con molte finestre davvero comodo.

Altre funzioni sono quelle di fare diventare trasparente una finestra oppure di renderla “floating” sopra tutto il resto (per esempio una chat, un player audio minimizzato, boh). Insomma… davvero geniale WindowShade X.


About learning Cocoa

February 12, 2006

I first learnt about ObjectiveC and Open/GNUStep when I was basically a Linux user. That was quite a lot of time ago. I was a WindowMaker fan, and that was the way I learnt about GNUStep. However, I did not learn ObjectiveC nor GNUStep programming. In fact there was plenty of “wonderful” languages out there and I felt no need for another one. The few GUI applications I did were made with GTK1 and C (yes, GTK 2 did not exist yet and wx was not really widespread; the first time I installed Audacity on Slackware 8.1 I had to google for them) or Qt with C++.
I was quite skeptical with interpreted languages too: I knew a bit of Lisp (more for academic reasons than for “real programming” — that is to say I would not be able to write a piece of useful software; well, this isn’t changed, anyway) and quite a lot of Perl (still I did not use to do what I considered “serious work”: a few cgi and some system scripting). But I’m going off topic.

One day one of my friends showed me the Powerbook G4 and MacOS X (it was Jaguar, for those who care). After some time I bought my first Mac with MacOS X. Before being a Linux user I was a big fan of MacOS Classic (and the first machine I installed GNU/Linux on was an iMac), so I was really happy with the “new deal” of Apple. Still I planned to “install GNU/Linux as soon as possible”. In fact this never happened (but one of this days when I have time and airport support is stable enough…).
The first thing I did was to learn Objective C. I took a look at Carbon, but I wasn’t amazed. I read Apple’s guides about the language. They were clear and well done. Still to code GUI applications I needed a more detailed book (I’m kind of a perfectionist) since the Tutorial, although well done, is designed for absolute beginners. Anyway the Apple guide for the language ObjectiveC is here.

I still have no idea why I chose to learn it. In fact I was a “cross-platform gui”. I still thought I would use both systems, so having my own applications on both of them was probably quite desirable. Moreover the QT MacOS port was young (it was released a couple of months after I bought the Mac, IIRC).
In the same period I was learning Python too, and almost everything else (system tools, web sites, cross platform gui applications with awful Tk) was made with it. I found some similarities between the two languages (in fact I think they were more similarities between Python and Smalltalk, and only indirectly between Python and ObjectiveC). Still one thing was different. Python is a very high level language, but does not force you in anyway into some kind of framework.

In fact you can perfectly “translate” command line from C using the same POSIX APIs or, for example, “convert” a Qt + C++ program. The language Objective C in fact has the same properties. In fact I wrote a few command line utilities and found that the Foundation kit was a well designed environment that abstracted some POSIX interfaces. I quite liked it. And quite liked ObjectiveC.

The only thing I truly missed were namespaces (or analogue things). I spend a couple of days understanding the memory model and that was everything. I bought two books, “Cocoa in a Nutshell” (today I would not buy this) and “Cocoa Programming” by Anguish Buck and Yacktman. They were both good books. I do not use the Nutshell because Apple documentation is more recent today, not because it’s not well done.
Cocoa Programming” is a “big” book. There are lots of infos. Some of them are advanced topics (for example there are Chapters about optimizations — you know, optimization hinders evolutions, but we want to run our software on something more portable than a mainframe).

The book focuses on how Cocoa was thought with Design Patterns (expecially those from the famous book), even if they change their name (and Anguish/Buck/Yacktman show which Cocoa pattern corresponds to a GOF pattern). I was already acquainted with DP, I read the “Design Patterns: EORSD” some time ago (and recently I bought the book and I’m reading it again). In fact Cocoa developing needs understanding of design patterns, but you can have a less theoretical approach to Cocoa.

I recently read Hillegass’s “Cocoa Programming for MacOS X” and that is what I mean. It’s more like a tutorial, but not as elementar as Apple one. It shows you some “real life” small applications that use key tecnologies. It shows Cocoa structure, main “patterns” (for example how to deal with a NSTableView — and introduces the concept of delegation).
While “Cocoa Programming” shows how much Cocoa can be powerful, Hillegass shows how much Cocoa is easy. There are many things that are not explained in the latter (even if it covers some topics I didn’t find in the other book).

You may need (you probably need) a book like Anguish/Buck/Yacktman’s “Cocoa Programming“, but I strongly advise to start with “Cocoa Programming for MacOS X“. It’s not recent, but it’s well done and complete. You can build a whole lot of applications reading it, and for example explains the Document Based Applications in a very simple yet complete way (for example in “Cocoa Programming” the authors implement classes that act quite like the NSDocument and friends to show you in details how it works, still I was not really able to understand how easy it is programming Doc-based apps with Cocoa; in fact I thought it was hard, since many explanation about how the “true” class works are embedded in the explanation of how to rewrite a subset of it.
Another reason for reading “Cocoa Programming for MacOS X” is its length. Much shorter than the other one, you can read it in less than a week, and dive into programming with more skills. Some useful subjects in “Cocoa Programming” are not at the beginning and you must already know you have to skip chapters and go and read them.
In fact I find the two books complement each other well. I’ve got a third book (well a fourth), but I’m not gonna speak about it this time.

  1. Cocoa Programming” – Anguish/Buck/Yacktman
  2. Cocoa Programming” for MacOS X” – Hillegass

Apple PyObjC tutorial (Cocoa programming with Python)

February 12, 2006

This is Apple’s tutorial about programming Cocoa with Python. It’s an easy one, but read it if you want to start programming Cocoa with Python. It is quite well done.

Here PyObjC website.


MacOS X Intel & Rosetta: application compatibility

February 10, 2006

This site keeps an updated list of software that works with Rosetta and how they work. For example some applications do work, but with serious performance issues. If you have to use them professionaly (or often) you should consider not to go with Intel Macs and stay with old Macs.

With some other applications however Intel performances are quite impressive.


Opera 9 (preview)

February 7, 2006

La prima cosa che salta all’occhio è la nuova interfaccia. Più browser e meno “pacchetto integrato”. Di default ci viene mostrato solo il minimo indispensabile come si vede nello screen

Toolbar Opera

Le classiche toolbar sono comunque tutte accessibili attraverso il solito Menu.

La prima cosa che faremo sarà caricare una pagina. Qui rimarremo sorpresi. La velocità è impressionante (sicuramente la velocità percepita). Anche il resto del programma rimane decisamente reattivo.

Alcuni binding sono cambiati (per esempio adesso per aprire un nuovo tab possiamo usare Mela-T/Ctrl-T come su Firefox e Safari, mentre prima, se la memoria non mi inganna, era Mela-Option-N, con eventualmente sostituito Mela da Ctrl se sotto X11 o Windows).

I bookmark sono stati importati in un batter d’occhio. Bene. Per posta e altro non mi esprimo, non sono funzioni che uso, preferendo di gran lunga programmi apposta, come Apple Mail e NetNewswire — newsfeed –).

Il problema più grosso temo sia *esportare* i bookmark. Passare da un altro browser ad Opera è facile, non altrettanto facile il contrario, purtroppo. L’ultima volta lo feci attraverso un servizio web esterno (questo) . Tale sito fra le varie cose offre un convertitore di file di bookmarks da e per moltissimi programmi diversi.

AJAX pare funzionare bene (a parte un problemuccio su WordPress, qui, sulle immagini, ma cose “complesse” come per esempio l’editor di post WYSIWYG in javascript avanzato funziona decisamente bene).

Ribadisco… veloce, interessante. Vediamo Google cosa inventerà, perchè per adesso Opera 9 sembra una versione riveduta e corretta di Opera 8, ma non offre davvero quanto Firefox, ne è integrato come Safari.
Comunque da tenere sott’occhio senza dubbio.


Abiword on MacOS X

February 7, 2006

Funny… this are a couple of screenshots I got running Abiword straight from the .dmg, without installing it.
I was just to file a bugl (that is to say 1- check if someone filed the same bug 2- if not, file), when I tried to run it from the desktop (or Application directory). In this case, no troubles of any sort.

The screenshots below do refer only to Abiword run from the dmg. Even if we can call this a bug, it’s harmless and you have to know it is there to find it.

You probably expected some more comments… maybe another time. What can I say is that at first sight it looks really good, a fast one.

abiword_funny2
abiword_funny1