たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
XUL/Migemo更新した。0.3.9での変更点は以下の通り。
ご指摘くださったHさん、ありがとうございます。
XUL/Migemo更新した。0.3.8での変更点は以下の通り。
要するにバグフィックス。
searchcache改造版を更新。
Download and Install searchcache 2005.06.15.20060426012006042602
変更点は以下の通り。
突然検索できなくなる問題については、相変わらず原因不明で対処不能にて絶賛放置中。
好きなWebページに好きなように付箋を貼り付けられる拡張機能でMyStickiesというものがあります。同名のWebサービスと連携して動作するもので、アカウントを作成すれば誰でもすぐに使えます。
で、試してみたんですが致命的な問題がひとつ。日本語が通らねえ!! いや保存した付箋が再読み込みされた段階で、日本語の文字がことごとくエスケープされて表示されてしまうんですね。これじゃ使い物になりません。
でもこれ、非ASCII文字がエスケープされてしまってるということだけが問題なので、ならばアンエスケープしてしまえばいいじゃまいか!と、ごにょごにょいじって作ってみました国際化対応版。
まあ、unescape関数を適当なところに2〜3個書いただけなんですが……
GmailのHTMLメール編集モードなどで使われているリッチテキストエリアは、HTMLのフォーム部品を使わず、JavaScriptでキーイベントを捕捉して諸々の処理を行うことで実現されている。
実はFirefoxでtextareaなどのフォーム部品でも内部的には同じ事をやっているのだけれども、XULアプリケーションの開発程度までのレベルでは、このあたりの処理はほぼ完全に隠蔽されているので、ユーザも開発者もこの実装の事を意識する必要はない。
でもGmailのような普通のWebページでこれをやられてしまうと、困ったことになる。入力がリッチテキストエリアの中で行われた物なのか、それとも他の部分で行われた物なのか、判別ができないのだ。しかも、サイトによってリッチテキストエリアの実装方法が違うので、それいっこ書いておけばどんなサイトでもきちんとリッチテキストエリアを検出できる!というようなコードを書くことは非常に難しいと考えられる。
Rewind/Fastforward ButtonsのようにXPath式をサイトごとに登録しておけるようにするとか、いくつか方法は考えられるけど、どれも面倒だなあ……
追記。この件、修正できました。
XUL/Migemo勝手改造版更新。変更点は以下の通り。
Shift-F3とか検索ツールバー上のボタンで前方検索しようとしてうまくいかんかったからというのが、上記の問題に気付いた理由。
XUL/Migemo勝手改造版更新。変更点は以下の通り。
ぶっちゃけMigemizeExplorerのパクリです。残り時間が分かるとちょっとイイかなーと思って、軽い気持ちで。
XUL/Migemo勝手改造版を更新した。検索ツールバーで普通に検索したあと再検索できなくなってた件とか、Trunkでまともに動かなくなってた件についての対応も含んでる。
ちなみに、Trunkで本家の旧バージョンが動いてフォーク版が動かないという現象が起こっていたのは、検索ツールバーとの連携を僕がフォーク版で勝手に組み込んで、その部分がTrunkでの仕様変更の影響をモロに受けてたせい。つまり僕がエンバグしてました(ぉぃ)。
searchcache改造版のGUIDを変えた。元々のsearchcacheとは明確に別のものという扱いにしておいた方が良さそうだったので。
searchcache改造版を更新した。
Download and Install searchcache 2005.06.15.2005112301
変更点は以下の通り。
突然検索できなくなる問題については、原因不明で対処不能。誰か直して。