WordPress 2.3:ブログエディタからのタグの指定

WordPress 2.3 が リリース されましたね。

バージョン 2.3 の目玉機能といえば タグのサポート ですが、これをブログエディタからどうやって指定するかというと、MarsEdit の Daniel Jalkut 氏が 書いて いるように、「キーワード」フィールド に、カンマ区切り で入力するだけ。僕もベータ版の xmlrpc.php を逐一チェックしていたので、確認済みでした。

「 タグ = キーワード 」ではないので(結構近いけど)、ちょっと妙な気もしますが、新たな API を作ってブログエディタの対応を待つよりも、もともと WordPress では(デフォルトでは?)使えなかったフィールドを利用する、という現実的な選択。

「キーワード編集フィールドを、比較的ゆるい条件で表示しているブログエディタ」なら、すぐにタグを使えるはずです。( ecto 3 …! プラグインだからすぐ対応できるはず。たぶん。)

WordPress 2.3 のタグ機能、このサイトでも速攻で使ってみたいんですが、過去の記事をタグで分類したらどのような作用が起きるのか、まだよくわからないので、実験してみなくては。

Notes: NSTextView へのドロップ

この 記事 では、いろんなところでドラッグ&ドロップ操作ができるようにした、ということを書いていますが、いちばん対応に苦労したのが、NSTextView へのドロップ でした。

NSTextView のサブクラスで、独自形式の項目のドロップを受け付ける、あるいは、ドロップされた項目の処理を、独自に実装するには

障害になるのは、ドラッグ&ドロップを実装すること自体がちょっとややこしいことと、NSTextView が、標準でテキストやファイルのドロップに対応しているため、独自形式の項目をドロップできるようにするには、標準の実装を殺さないように、うまく立ち回らなくてはならないことです。

これにはみんな苦労しているようで、cocoa-dev ML には、やたらとこのテーマの質問が投稿されていますが、その中で本当に役に立った記事を紹介しておきます:

この記事では、必要な registerForDraggedTypes: をしていないこと、 (標準で対応している項目の処理方法を変えるのが目的のコードだからか。) ドロップされた項目を、標準の実装に任せるのか、自分で処理するのか判定する部分の効率が悪いこと、-performDragOperation: の部分で、呼び出すスーパークラスのメソッドが間違っている、など注意しなければならない点がありますが、基本的には、これに習えばちゃんと動くはずです。(まあ、その前にちゃんと動かなかったのは、書き方が適当すぎたからですが 汗)

カーソルの位置を、マウスポインタの位置に追従させるには

テキストエディタで文字列をドラッグしてみると分かりますが、標準では、NSTextView 内のカーソルの位置が、マウスポインタの位置に追従します。しかし、ドラッグされている項目の処理を自分で受け取ると、これが動作しないようです。

この場合、自分でカーソルの位置を再計算する必要がありますが、以下の記事に、そのためのコードが掲載されています:

あとは -draggingUpdated: の中などで、自分(NSTextView)に setSelectedRange: してやれば OK です。ただし、別のウィンドウなどからドラッグしてきた項目の場合は、まだカーソルの位置が見えないので、-draggingEntered: の中などで、自分を firstResponder にしてもらえばいいでしょう。

あなたの Mac アプリをシェイプアップしよう — Vacuous Virtuoso

更新頻度は高くないものの、かなりためになる 記事をアップしてくれる、Ankur Kothari 氏によるブログ Vacuous Virtuoso ですが、また面白い記事がアップされていました。

Mac developer? Clean up your appVacuous Virtuoso

Too many apps are shipped with debug symbols, uncompressed images, redundant files or generally useless rubbish that not only wastes users’ disk space, it ultimately ends up increasing the developer’s own bandwidth costs.

多くのサードパーティ製(…とこの記事では書いてあるけど、Apple 製のものは完璧なんだろうか)Mac アプリでは、そのパッケージングに問題があり、非圧縮の画像リソースや必要のないファイルで、ユーザーのディスクスペースを無駄にしていることが少なくないそうです。

それがどんなものかというと、記事で紹介されているものを挙げると、Finder 代替のファイルブラウザ Path Finder が、もとの 60MB から、簡単な処理で 30MB まで減らせる、といった具合。

“あなたの Mac アプリをシェイプアップしよう — Vacuous Virtuoso” の続きを読む

Dock の UTI 対応の罠

Kaku の画像挿入機能ですが、Kaku のアイコンに画像ファイルをドラッグ&ドロップすることでも、画像を登録できるようにしたいと考えています。でも、ちょっと詰まりました。

ある種類のファイルを、アプリケーションアイコンへのドラッグ&ドロップで開けるようにするには、(僕が知る限り)Xcode の、「プロジェクト」→「アクティブターゲット‘…’を編集」→「プロパティ」タブ→「書類のタイプ:」 に、開きたいファイルの種類を指定します。

開きたいファイルの種類を指定する方法は、昔からある 拡張子、MIME タイプ、タイプ/クリエータ のほかに、Tiger からは「 UTI 」というものが加わりました。

UTI についての詳しい説明は、Wikipedia の記事 やリンク先に譲るとして、要は、先ほど挙げた、拡張子をはじめとした レガシーなファイルタイプ指定方法をラップ し、さらに、クラス継承のような 継承関係 を持たせる、という仕組みです。

“Dock の UTI 対応の罠” の続きを読む

親切なスパム

何とはなしに、久しぶりにチェックしてみたのですが、

「 CAPTCHA 使ってれば、こんなこと、されないのにね!」とか言いたいのでしょうが、その前に Akismet にしょっぴかれちゃってる、というオチ。

Core Data で画像を扱う

前回の記事 で、「 Core Data によって、プログラムの骨格を作るのはかなり楽になるけれど、それだけでちゃんとしたプログラムができるわけではないし、もしそれができなければ、いま作っている Kaku の画像挿入機能は搭載しない」 ということを書いたと思います。

昨日はまさに、そういう「これじゃあ公開できない」という事態に直面していました。前回の記事を書く前に、うすうす気付いてはいたのですが、やはり大量の画像を登録したとき、画像挿入機能のパフォーマンスがかなり悪くなる のです。

結局原因は、Core Data に頼りすぎた、とかではなく、設計そのものがおかしかったというか、単純に、もっと勉強してから臨むべきだった、ということでしたが…(汗)

…というわけで今日は、その問題を解決していった過程を書いていきたいと思います。タイトルは「Core Data で画像を扱う」となっていますが、それについての 正しい答えが書いてあるわけではありません ので、悪しからず(僕が今のところどういった方法でやることにしたかは、書いてあります)。

何しろ、プログラム開発の専門教育を受けたこともないし、もろ文系なので、あまり笑わずに(?)読んでください。何かもっといいアドバイスがありましたら、ありがたく頂戴いたします。

“Core Data で画像を扱う” の続きを読む

Core Data は素敵 / AppleScript Studio プロジェクトと Core Data

最近、MarsEdit 2 を使って、それについての 記事 を書いてみたり、ecto 3 Alpha を使って 記事 を書いてみたりしていたわけですが、自分は?というと、Kaku の画像挿入機能を試しに作ってみていました。

なぜいま画像挿入機能を作っているのかというと、他に作ってみたい機能や、他に作ってみたいソフトもあるのですが、現実問題、いまとりあえず足りないのは、Kaku の画像・リンク挿入機能あたりだろう、と。また、すでに書いたように、Mac 向けの二大ブログエディタを実戦で使ってみた結果、「やっぱり画像やリンクの扱いをなんとかしないと、記事を書くのがなかなかスムースにならない」ということを痛感したからでもあります。

こういった機能を作るには、画像の扱いやら、外部ファイルの扱いやら、ドラッグ&ドロップの扱いやら、自分がこれまで学んできたことがほとんど役に立たなそうな領域(=避けてきた領域)に挑むことになるので、かなりビビっていますが(下にも弱気発言)、今日からしばらくは、その中で気付いたことを記事にしていきます(たぶん)。

“Core Data は素敵 / AppleScript Studio プロジェクトと Core Data” の続きを読む

Markdown Extra for MarsEdit

ひとつ前の 記事 では、MarsEdit 2 の新機能を試すために、久々に HTML で書こうと思ったけど、一瞬で Markdown に戻してしまった」というようなことを書きましたが、Markdown といっても、僕の場合はは本来の Markdown ではなく、(PHP)Markdown Extra でなくてはなりません。

記事を Markdown Extra で書くのに特別な設定はいりませんが、Markdown Extra で書いた記事をプレビューする機能は、MarsEdit には用意されていません。

そこで、MarsEdit で、Markdown Extra で書いた記事のプレビューを可能にするパッケージ を作成してみました。そんなに難しくないので、間違いなく他にも誰かがやっていると思いますが、「marsedit markdown extra」とかでググっても、結構ポピュラーなキーワードなので探しにくいし、運良く(?)当サイトをご覧になっている方のために…

ダウンロード:Markdown_Extra_for_MarsEdit.zip(36KB)

使い方等は以下。

“Markdown Extra for MarsEdit” の続きを読む