ウィジェットプログラミングの本“Programming Dashboard” 63
ストーリー by Acanthopanax
この一冊から 部門より
この一冊から 部門より
Dashboardプログラミングを解説した「Happy Macintosh Developing Time Programming Dashboard 始めてみようウィジェットプログラミング」が発売された。著者は、HAPPY Macintosh Developing TIME!の木下誠氏。ウィジェットの基本構造の解説から始まり、JavaScript、コントロール、キャンバスから、ネットワーク、Objective-Cによるプラグインまで、ウィジェット作成が一通り学べるようになっている。HTMLやCSS、JavaScriptの基本的な知識を前提としているが、これらの知識があれば内容を理解するのは容易だろう。発行元はビー・エヌ・エヌ新社。オールカラー280ページ。ISBN4861003075。
目次
chapter00 はじめに
chapter01 Dashboardとウィジェット
chapter02 はじめてのウィジェット
chapter03 JavaScriptによる操作
chapter04 コントロール
chapter05 環境設定
chapter06 ローカライズ
chapter07 キャンバス
chapter08 ネットワーク
chapter09 機能の拡張とプラグイン
タイトルが… (スコア:2, 参考になる)
タイトルだとどのウィジェットを指しているのか
さっぱりわかりません。
「Dashboardプログラミングの本」として欲しいです。
…でこのトピックは、誰かのタレ込みでもないようだし、
Acanthopanaxの関係者の本の宣伝ですか？
#表現がキツかったらすみませんが、本当に疑問です。
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:タイトルが… (スコア:1)
なるほど。しかしこの本、題名を全部書くと長いので、一部のみタイトルに入れました。
木下さんとは別に面識ないです。氏のウェブサイト [mac.com]はいつも読んでますが。
で、なんで関係者だと思われたのか、そっちの方が疑問だったり。書き下ろし記事は特に最近のマックセクションでは珍しくないと思いますが。商売が関係しているから? Dashboardプログラミングの本はたぶん初めてなので(英語でもまだなんじゃないかな)紹介する価値はあると思うのですが。
Re:タイトルが… (スコア:1)
この記事はDashboard Programmingの本が出版される
という以外の内容がなく、言ってしまえば書籍紹介です。
今までの記事ですと、この本はコレコレこういう特徴が
あって、逸話として何かあって…と、どうして記事に
なったのかという部分があったように思います。
ですので、どうしてDashboardの本が出版されることが
記事になったのか考えてしまい、腑に落ちる結論として
関係者では？と勘ぐってしまいました。
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:タイトルが… (スコア:0)
Re:タイトルが… (スコア:1)
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
貴重な日本語リソースかも?? (スコア:2, 参考になる)
Developing Dashboard Widgets [apple.com]
Introduction to Dashboard Programming Guide [apple.com]
などなど。
日本語訳はないので、この本は貴重な(?)日本語リソースと言えるかもしれません。また、本の場合は「その気がない人でもふらっと手に取る」可能性があるので、プログラミングの裾野を広げることになりそうです。
とはいえ、スラドを見るような人なら上記の英語ドキュメントで十分かも:-)
Re:貴重な日本語リソースかも?? (スコア:1, 参考になる)
DashboardにおけるWidgetの開発 [aquasky.jp]というアップルのページを翻訳したところもあります。
Re:貴重な日本語リソースかも?? (スコア:0)
無茶を言わないでください。
スラド見るからといって日本語以外を理解できるなんて思わないでください。（涙）
・・・・・・ orz
Re:貴重な日本語リソースかも?? (スコア:1, すばらしい洞察)
Re:貴重な日本語リソースかも?? (スコア:0)
だったらカタカナで書くなよ。
# 本家にはカタカナなんて見あたらない！（涙）
Re:貴重な日本語リソースかも?? (スコア:1)
＞ スラド見るからといって日本語以外を理解できるなんて思わないでください。（涙）
ごめんなさい。スラドの読者なら、英語ドキュメントを見る機会の多い開発者が多いだろうと思っていました。開発者などではなくても、Apple の件のドキュメントは比較的平易な文章なので、中学卒業程度の英語力があれば、ある程度読めるのではと思います。
# とにかく、一度目を通してみてくださいな。
Re:貴重な日本語リソースかも?? (スコア:1)
Konfabulatorのパクリっすか (スコア:1)
「新Mac OS X のDashboardはパクリ」：Konfabulator開発者が激怒 - CNET Japan [cnet.com]
だそうですね。
「こんなことなら、Appleのプラットフォーム上で動くソフトウェアをどうして開発したいなどと思うだろうか」
という言葉と関係あるかどうかはさておき、どうやらWindows版も存在するようですんで、
非Macな人(俺もだ)も、Konfabulatorさえあれば、"幸せになれる"わけですね。
＃相変わらずMacを欲しいと思う動機が生まれないのでG7
＃QuartzComposerも、FREEかつCrossPlatformなPureDataで代替できるだろうし。 [srad.jp]
Konfabulator はXMLでGUIを定義してJavaScriptでアクションを表現する、ってなわけで、
なるほどソックリなんでしょうね。
これで作ったGUI小物ソフトを「ウィジェット」と呼ぶのも、Dashboardと同じ…
ってことは、その点もパクリってことですね。
(Unix畑の人とかは、アプリじゃなくGUI部品をウィジェットと呼ぶ習慣しかないわけで、ちょっと別文化圏なわけですね。)
なんだかなあ。
----
なおKonfabulatorについてのスラドの過去記事はこちら。 [srad.jp]
あと、Konfabulatorも最近、日本語の書籍が出てますね。 Konfabulator Happy Programing Book [cbook24.com]
＃あれ？スラドでは言及されてないみたいだな＞検索してもHIT無し
＃そういや本屋で上記書籍を見かけたのが、俺のKonfabulatorとの"出会い"だったんだっけ。OnLineじゃないんだったなあ。
パクリかどうかは微妙 (スコア:1)
Dashboard は、出したり引っこめたりして使うようになっているので、OS 9 時代のデスクアクセサリを目指したものと言えます。Konfabulator は常にウィジットが鎮座するので、メニューバーやDockに入らない情報を表示させるツールという感じでしょう。
また、Konfabulator は CPU 負荷がけっこう高かったようです。だから、Apple は 車輪の再発明をしたのだと思います。Konfabulator を買い取って改善する方向もあったでしょうが、Apple は改善するより一から作った方が早いと思ったのかも。
とはいえ、Tiger の発売によって Konfabulator に登録料を払う人は激減するのは確実でしょう。これを、Apple による Konfabulator つぶしと見るか、Konfabulator が単にふがいなだけと見るか。
Re:パクリかどうかは微妙 (スコア:0, 荒らし)
え？DAって大昔から有りましたよね？
＃6か7くらいまでしか知らないのでG7
「OS 9 までの時代」ってことですかね。
ただ、なんにせよマルチタスクの御時世にDAでもないだろう、という面はあります。
というか土台、Mac式のGUI(WinもXも同じ)の根本構造って
マルチタスクを想定してなくて、それなりに破綻してるわけですが。
＃とりあえずModalという概念が思いきり破綻してますね。
＃vi打ってる途中に別アプリのPopupDialogが唐突に出て来て、何度ブ
Re:パクリかどうかは微妙 (スコア:0)
>＃vi打ってる途中に別アプリのPopupDialogが唐突に出て来て、何度ブッ殺そうと思ったか知れないので、G7
Docのアイコンが跳ねるだけとかいう設定はなかったのかな。
>つまり(Winでいうところの)Alt-Tabで済んでしまう事ではないかと。
Re:パクリかどうかは微妙 (スコア:0, 荒らし)
同様というのは「(やりかたはさておきとにかく)だましだまし使う」ことですよね？
「GUIの落しどころ」のことですよね？
＃AltTabやそれに類することなんて、出来て当り前だし、出来ないと純粋に不便ですね。
＃誰が作ったOS/GUIであろうと。
で。
…出来るんなら、それでいいじゃないですか。
そして、「それ以外の小難しいやりかた
Re:パクリかどうかは微妙 (スコア:1)
>もともとのDialogというアイデアのまずさ(少くともマルチタスクとの相性の悪さ)自体は
>かわらないわけで。
本当にOSXを使ってみての感想ですか?
だいたい、Appleはその辺を早くから認識していてSystem7投入時、
つまりMultiFinderなる疑似マルチタスク環境を正式採用した時に
NortificationManagerという仕組みを入れていますよ。
ドックでアイコンが跳ねるのはその延長線上の仕組みのはずです。
こいつらはダイアログが出てもフォーカスを奪うようなことをしません。
ひょっとしてGUIってWindowsしかご存じないのに、
そこから外挿して批判なさってるんじゃありませんか?
ただ、NortificationManagerは非常に地味な機能で、
アプリケーションが何かを伝えたい時(ダイアログを出したとき)に
メニューバーにアイコンを点滅させるだけでしたのであんまり知られてないとは思います。
後付けじゃあありませんよ。マルチタスクの導入時に既に考慮に入っていました。
で、ダイアログというのとマルチタスクとの相性の悪さを言うのであれば、
この辺をちゃんと評価しないとまずくないですか?
Re:パクリかどうかは微妙 (スコア:2, 参考になる)
s/NortificationManager/Notification Manager/g
です。それからこいつの導入はSystem6からでした。
MultiFinderの試験的導入時に既にあった模様です。
気になって探してみたら資料がありました [apple.com]。
Re:パクリかどうかは微妙 (スコア:1)
いや、ほんともなにも、使ってないって上で言ってますよね？
＃なんか嘘つきみたいに言われてもなあ…
>後付けじゃあありませんよ。マルチタスクの導入時に既に考慮に入っていました。
そっちの話じゃなく、
今風の(Mac系)GUIに対してマルチタスク自体が後付け、ですよね。
そこが気になってるんです。
Notification Managerは、聞いた限りでは良さそうではありますが、
あくまで小手先の修正ですね…
それでも足りてる、と(或るユーザが)言うなら、それはそれで(その人は)いいんでしょうけど。
＃そういやWinもTaskBarでTaskがチカチカするんじゃなかったっけ？
＃＃でもあれも納得いかなかったけど。
Re:パクリかどうかは微妙 (スコア:1)
あ。ごめんなさい。見落としてました。でも使いもしないで
批判はちょとどうかなあ、と思います。
> 今風の(Mac系)GUIに対してマルチタスク自体が後付け、ですよね。
そうは思いません。Macには最初からDAという仕組みがありましたし。
DAだけはプリエンプティブに動くマルチタスクでしたよ :)
>Notification Managerは、聞いた限りでは良さそうではありますが、
>あくまで小手先の修正ですね…
ではどのような修正がいいのでしょう? とききたいところなんですが、
そもそもG7さんはダイアログの存在自体がマルチタスク環境に
そぐわないとおっしゃってるんで、答はないですよね、多分。
では質問を変えて、マルチタスク環境においてプログラムが人間に何か
を伝えたいときにはどうすればいいですか?
私はNotification Managerはかなりいい線をいってる解だと思うんですよ。
とにかく誰かが何かを伝えたがってるということだけを伝えて作業の邪魔はしない。
切れのいいときに作業を中断して、「どうした?」って聞きに行けばいいんですよ。
それにそのようなダイアログを出す機会自体あんまりないですよね。
業界には3秒ルールってのがあるらしいですし :)
大抵はalert…。あ。alertが出たときは場合によってはすぐに
対処しなければならないこともあります。
ひょっとしてそのことを言ってるのでしょうか。
>＃そういやWinもTaskBarでTaskがチカチカするんじゃなかったっけ？
そうなんですけど、これは光るタイミングがよくわかんないんですよね。
別に何かを伝えたいわけでもないようなのに点滅してたりします。
Re:パクリかどうかは微妙 (スコア:0)
そもそもMac OS Xを使ってみたことはありますか？ (スコア:0)
Mac OS Xの話ですか？
Mac OS 9以前の話ですか？
Windowsの話ですか？
少なくとも最近のMac OS Xを使っているかぎりでは別アプリのダイアログが全面に出てきて邪魔された
覚えなんてまるでないんですけど。
# 初期のバージョンはどうだったか知りません。
他の人も書かれていますが、標準の仕様を守らないよっぽどできの悪いアプリでない限り、Dockで
アイコンが跳ねて知らせるのがすべてのアプリの仕様（というかOSそのものの仕様）だと思いますが。
このスレ
Re:そもそもMac OS Xを使ってみたことはありますか？ (スコア:1)
>本当にMac OS Xを使ってみたことはありますか？
だから、「印象」でもなければ「本当に」でもなく、
「ない」って明示してますでしょ？
かつ、それは必ずしも悪いことではナイと思います。
>それとも「GUIなんてどれも似たようなもの」というスタンスで、XとかWindowsでの経験を
>そのままGUI全般に演繹して議論しようということでしょうか？
もちろん小異はあるでしょうけど、大同ですね。
小異を作る努力を否定する気はありませんが、
どうせならそれよりも大異を作る大鉈を振るって欲しかったです。
それこそAppleのUIのセンス自体は良いと思いますから、
正しい方向(^^;に頑張ってたら、今頃さぞかし素晴らしい次世代UIを
作っていたでしょうに…。
＃それとも現状におけるオリジナリティに「こだわる」あまり、
＃次世代への移行を渋ってしまってるんでしょうか？？
>実際に使ってみたことがないから「DAみたいなもの」というたとえの意味を
メタファははまる、という定番の話でしょうか？(^^;
使ってみたことのない人には通じない(ローカルな)例えだったわけですね…
＃つまり、お互いさま、と。
Re:そもそもMac OS Xを使ってみたことはありますか？ (スコア:0)
ちなみに、WWDCにいったときに、Appleの中の人は「dashboardに関して言えば、ちょっと勉強すれば誰でもプログラムが作れるでしょ?僕らは無論Devを増やすのも仕事だけど、一般のユーザーにプログラムの楽しさを知ってもらいたいとも思ってるんだ」とか言ってました。
話半分と聞いたとしても、確かにパクリもととD
Re:そもそもMac OS Xを使ってみたことはありますか？ (スコア:1)
>Devを増やすのも仕事だけど、一般のユーザーにプログラムの楽しさを知ってもらいたいとも思ってるんだ」とか言ってました。
>話半分と聞いたとしても、確かにパクリもととDashboardを比べると、敷居を低さは断然dashboardに軍配が上がるでしょう。
ええと、すると貴方は結局、Dashboardについて
"本当に触ってみた"あとでコメントなさっているんでしょうか？(^^;
＃「でしょう」で締め括られてるところを見ると、なんか違うっぽい…
それこそDashboardは俺も触ったことないですが、
敷居が低いってのは、なぜ(言えるん)です？
JSのコードとXMLなUI定義がまとめて1つのTextfileだ(＞K)、っていうだけで
かなーり敷居低いよなーと思ってしまう昨今。
「一般のユーザ」がどこまでを指すかは未知なままなのでさておくけど、
Kもそれなりにイケてるような…
＃てゆーか、「違う！」というなら、それこそ皆さん、なんで
＃簡潔に(^^;違いを説明しないんだろ？
＃「違う！」と言っただけで、そこで言葉が止まってしまってる人が数名…
Re:受け手がシングルタスクなのに？ (スコア:1)
それは人間のデフォです(^^;
＃反応が激しいか否かの差は個人差として有りますが。
あと、電話だと実際に受話器とるまでのタイムラグはユーザが選択可能だけど、
DialogBoxがフォーカス奪うのは、まさに一瞬でだから。
Re:パクリかどうかは微妙 (スコア:1)
MYCOM PC WEBの記事にもありますが、これは"devmode"ということで、あくまで開発者用デバッグモードということになっています。"Programing Dashboard"ですと、77ページに記述があります。
Re:Konfabulatorのパクリっすか (スコア:1)
当時に書いたものをこのへん [hatena.ne.jp]以降ににおいてます。
基本的には「どっからどこまでがパクリで、どっからオリジナルか」という議論自体が、このケースではナンセンスだと思いますね。
ただ、何でまたこの手の意見が消えないのかというと、Dashboard発表後にWindows版が出て、まさに「よく事情を知らない」新規ユーザが増えて、CNETのネタを真に受けて増幅してるからなんですけどね。Win版にはSamurizeとか競合するものも多いんですが、シェアウェアにも関わらずそれなりにKonfabユーザは増えました。
もともとWindows版の構想自体は、Dashboard発表以前からあったんですが、どうもDashboard対抗でWin版を出したと思ってる人も多い（多分「開発を急いだ」なら当たってると思うけど）。ただ、Win版が出たくらいから新しく斬新なウィジェットというのは却って見かけなくなったというか…。個人的にも開発をペンディングしてますが、win/macで完全コンパチにはならず（シェルとかに依存してるので仕方ないんだけど）、開発が面倒になったのが原因だったりします。
ちなみにKonafabulatorはつい先日メジャーアップデートしてVer. 2 (通称 K:2)が出たところです。ここに来て、マルチウィンドウやマルチタイマーなど、これまで不満に上げられてたポイントがかなり改良されてますので、簡単な小物の開発環境としてはなかなか使いやすいと思いますよ。単に構造だけ見たら、XML+CSSよりオブジェクトが判りやすいですから。
Re:Konfabulatorのパクリっすか (スコア:1)
俺も、自分の意見としては、そう思います。
ただ、俺じゃなくAppleが話の中心になるならば、
「ナンセンス」の一言で済ますのは、
今までの振る舞いからして、ちょっとどうよ？と思うわけで。
>Win版にはSamurizeとか競合するものも多いんですが
Javaとかにも色々あるらしいですね。
Thinletってのを最近知りました。
＃ただJavaは起動が遅いんで「こういうツール」では困るんですけどね。
＃JVMをデーモン(やサービス)として常時アゲっぱなしといて、
＃そこから各アプリを迅速に起動すりゃ、良かろうものを。
＃＃…という技術は(名前忘れたけど)CommingSoonだそうですね。期待。
＃＃てゆーか、最初からそう作れよ＞Sun
＃＃鯖でMultiThreadで荒稼ぎしたんなら、ClientもMultiThreadベースにしろ。
Re:Konfabulatorのパクリっすか (スコア:0)
Mac使いはこういうのに慣れてないですからね。
怒っていいのか悲しんでいいのか、困惑してるんでしょう。
私なんかでも、これがWindowsでの話なら、元ネタを動かしてみて
「おお、似てる似てる」
とか
「そうかぁ？」
とか言ってるんだけど、
今回はどうもAppleも堕
Re:Konfabulatorのパクリっすか (スコア:0)
まだこんなボケたことを言う人もいるんですね。Konfabulatorの作者が
何を真似ているか知らないからなんでしょうが...。Appleは昔のMacに
あった機能をどんどん現代的なもの
Re:Konfabulatorのパクリっすか (スコア:1)
「逆じゃん」という話が”あるならば”あるで、それはそれで良いんです。
ただ、じゃあ何でAppleお得意の
(トーゼンのケンリのシュチョーとしての)訴訟を
おっ始めないのかなー？と(^^;
そうしない理由が有るのかな、と。
で、それを前提としまして(藁)…↓
パクリ自体は俺も好きです。
パクリあえばいいんです。
そういう意味ではべつにシェアヱアが潰れようがどうしようが
たいして気になりません。
それが本当に有用なら、似たようなもんを我々で作ればいいんだから(藁
ただ、相手があのAppleだからねえ。
パクリ(だと思えなくもないもの)に対してあれだけ厳しい態度で臨む会社が
自分の番になったら、どういう態度を示すのかなー、と…。
> Appleは昔のMacにあった機能をどんどん現代的なものに新しく作り替えてMac OS Xに追加しているだけですよ。
別口でも書きましたが、
いまさらカビの生えたDAという概念(マルチタスクって何でしょうね？)
を引合に出すのって、ちょっとどうかと思います。
WinのStartメニューなんかは、ある意味でDAみたいな考え方の縮小再生産なわけですが、
あれは縮小して良かったんだろうと思っています。
つまりDAとアプリの差なんて忘れて、単にアプリを起動する口を用意するという
機能統合をしたほうが、むしろスッキリしたので。
＃それ以前に個人的にはStartメニューやDA自体どうでもいいと思っていますけどね。
＃UNIXみたいなフラットさや、アイコンとフォルダだけで全部やっちゃうフラットな考え方のほうが
＃かえって良かったというか。
＃＃そういう意味では「メニュー」も要らないなあ。あの概念は実はフォルダに統合できるので。
というか、「Macらしい」を連呼するのも、ちょっとどうかと。
閑話休題。
そういう古いものを引合に出して「ほらオリジナルはこっちだ」と主張するのは
なんだかなあ、と思います。
どこまで先祖返りすりゃいいのか、きりが無くなっちゃいますから。
>事情を知らないなら書かなければ良い
そういう考え方は結局建設的ではない [srad.jp]だろうなあ、と思います。
Re:Konfabulatorのパクリっすか (スコア:1)
>いまさらカビの生えたDAという概念(マルチタスクって何でしょうね？)
>を引合に出すのって、ちょっとどうかと思います
DAとマルチタスクは全然関係ないような。
GUIを使いやすくするのがDAだという認識は間違っているのでしょうか？
>＃＃そういう意味では「メニュー」も要らないなあ。あの概念は実はフォルダに統合できるので。
フォルダに統合出来るのはわかります(WindowsのInternet Explorerのお気に入りとかがそういう構造になってたような)が、階層が深いとフォルダだと困りませんか？
目的の階層を開くまで一回づつクリックしていくのは苦痛だと思うのですが。
Re:Konfabulatorのパクリっすか (スコア:2, 参考になる)
少くとも俺はそうは思ったことが無いです。
マルチタスクが無かった時代の苦肉の策、としか感じませんでした。
だって、アプリにわざわざメインとサブという位置付け(の格差)をつけることに
(ユーザビリティにとって)何の意味が有るでしょう？
「全部同等に扱えればいいのに！」と何度思ったことか。
>目的の階層を開くまで一回づつクリックしていくのは苦痛だと思うのですが。
そんな使いかたをしなけりゃいいんだと思います。
というのは、深い階層で苦痛なメニューが有ったら、そこへのショートカット(とかエイリアスとかsymlink)を
どっか好きなフォルダ(つまりメニュー)に張ればいいんですもの。
要らないのは、項目が固定されてる(伝統的な)メニューです。
そんなわけで俺WinのStartメニューの「トップレベル」には、
自分の好み(つまり最も頻繁に使うアプリやデータなどへのショートカット)のアイコンが並んでます。
vimやjavadocやrubyリファレンスなんかが並んでます。＃スラドへのリンクは置いてないですが…
Startメニューに好みのもの(のショートカット)を並べていると、
なんだかAppleメニューに好みのDAが並んでたあの感じですね…。
実際には、呼べるものの種類が多い(DAとアプリの区別は無いから何でも呼べるし、データも置けるし)ので、自由度はStartメニューが上ですが。
余談ですがWinの[*]フォルダ内のアイコン(普通はファイルやフォルダ)は、
名前に対してインクリメンタルサーチが効きます
(ついでにMigemizeExplorerっていう拡張を入れると日本語名でもローマ字でインクリメンタルできます)
から、項目の選択(をキーボードで行うの)は相当楽です。
[*]今のはよく知りませんが、Macでもそれくらい(or同等かそれ以上に便利なこと)出来ますよねきっと…
ふざけたことにWinのメニューのほうは項目をインクリメンタルサーチできない
(頭文字だけのHITは出来るんですが) んで、使いにくいなあと何時もぼやいていたりします。
まあ頭文字だけでも出来るだけマシなんで、
結構深いメニューも瞬時に呼べます(そういやクリックなんて滅多にしないです)。
Re:Konfabulatorのパクリっすか (スコア:1)
>
>少くとも俺はそうは思ったことが無いです。
>マルチタスクが無かった時代の苦肉の策、としか感じませんでした。
そもそも、「言いたい事は何か」が食い違っているから、すれ違ってるんじゃないでしょうか。
元のtargzさんの言いたい事は、「Dashboardは必要な時に表示される、Konfabulatorは常時デスクトップ上に表示されるという違いがある、この『必要な時に表示される』というオペレーションがDAに近い、と言っただけであって、内部の動作について言ってるのではないですよね。
確かに昔の（マルチタスクでなかった頃にあった）DAは、あたかもマルチタスク（あるアプリケーションを終了させることなく独立した違う機能を使うという意味で）のように振る舞うという事では、確かに苦肉の策だったと思います。内部的にはそのとおりだと思います。しかし、中でどう動いていようとユーザーにはあまり関係ないわけで、結果としてGUIを使いやすくしたという事は事実なんじゃないでしょうかね。
その後、マルチタスクになって、DAとアプリとの差はほとんど無くなりました。それはそれで例えば事前にDAを登録するような作業も必要も無くなって便利になりました。いわばメインのアプリと同等に使えるようになったわけですよ。でも、「よく使う小さなアプリを、（メインのアプリよりも）迅速に呼び出せれば便利」という事実は事実であって、その「より迅速」を目指したものがDashboardであって、これがtargzさんが表現するところの「デスクアクセサリを目指したもの」という事なののではないでしょうか。そして、「迅速に呼び出す」を通り越して「いつでも動いている」がKonfabulatorでしょうか。
Re:Konfabulatorのパクリっすか (スコア:1)
ああ。なるほど。その観点は俺には無かったです。
なぜなら、「必要なときに表示される」ことの嬉しさを
感じたことが無いから、かな。
>中でどう動いていようとユーザーにはあまり関係ないわけで
いやー関係あるでしょう。
というか多分話は逆で、
DAの対極(?)である普通のアプリのほうが
(DAのように)「必要なとき(それがイツつかは自分で決める)に表示させられる」
という性質を持って「いなかった」のが、イライラの原因でした。
あの時代の語彙(かな？)で言えば、「みーんなDAになりゃいいのに」という感じ。
もっと言えば「DAってものが可能なら、なんで全部DAになってくれないんだ？」です。
＃逆にいえばいっそDAなんか無ければ(狭い世界なりに)満足してられたんでしょうね。ただしそれは小さい満足だけど。
よく存じませんが、両者の違いには何か「技術的な」理由があったのでしょう。
だって、「そうする(ユーザから見て嬉しいような何らかの)理由が無い」んですもん。
それって技術的限界くらいしか無いんじゃないでしょうか？
＃政治や経済まで言い出すとキリがないですが…
つまり、中でどう動いているか？が、
DAとそれ以外との技術的な差として、露出してしまっていたわけです。
>その後、マルチタスクになって、DAとアプリとの差はほとんど無くなりました。
>それはそれで例えば事前にDAを登録するような作業も必要も無くなって便利になりました。
ん。ここらへんは既に俺の知らない時代です。
なるほど、そういう感じだったんですか。
＃と、説明してくれた人が、やっと一名様(T_T)
>でも、「よく使う小さなアプリを、（メインのアプリよりも）迅速に呼び出せれば便利」という事実
え？その時代になってもDAのほうが「迅速」なのですか？
なぜ？
それこそ知らないので(^^;予想になりますが、
起動速度が違うか、呼出し手順のUIの違いか、
それくらいしか違いを思いつかないです。
で、(前者はそれこそOS設計者が解決してくれる問題なので、置いとくとして)
後者だとすると(やっぱりAppleメニューでしょうか？)、
それはUIの設計を「さらにフラットにする」ことで解決しそうな気がする
んですが、どうなんでしょう？
Winなんか(^^;のStartメニューを引き合いに出して恐縮ですが、
ああいう風に、「なんでも放り込めれば(==これをフラット化と呼ぶことにします)」、
それで済むわけで。
＃WinKey＋Nで「メモ帳」が立ち上がるのでG7。つまりnotepad.exeですね。
>その「より迅速」を目指したものがDashboardであって
というわけで、もし本当にそういうものなのだとしたら、
俺としてはDashboardにあまり魅力感じないかもです。
というか、
そういう感じじゃナイのでは？
http://www.apple.com/jp/macosx/features/dashboard/
の上のほうのGIFアニメ(dashboardanim.gif)(QT動画は今見れないんで)
みたいに動くんですか？
「半透明のレイヤー」と書いてますね。
もしそうなら、
「マルチディスプレイ(デスクトップ)」を「混ぜる(オーバーレイする)」
とでもいうような振る舞いをする、ってことかと思うんですが。
「呼び出す」という言い方が多分曖昧なのだと思います。
「起動する」という意味と、「既に起動されてる奴を再びShowする」という意味の
どっちにも取れますから。
そういう言い方でいうと、DAの「呼び出す」は前者でした…よね？
Re:Konfabulatorのパクリっすか (スコア:1)
え？そう「だった」の？
＃すると、Font/DA Moverって一体？
＃…何度も言うようですが古い話で恐縮です。
>何百
そこでインクリメンタルサーチ(と普通の検索)です。
俺はブラウザのメニュー(IEだと"お気に入り"とか？)じゃなく
一般的なファイル用フォルダに
URLショートカットを放り込んで管理(?)してるんですが、
完全フラットで数千個、ただ入れてあるだけです。
でも検索でなに不自由なく暮らしてます。
頻繁に使う奴は「インクリメンタルサーチしやすいように」リネームしてあります。
つまり名前の頭に余計な(しかし自分にとって意味のある)数文字を追加するんです。
＃ついでにbashでもインクリメンタルサーチしてます。
＃URLショートカットは、ちょいとフィルタかましてw3mの引数に食わせます。
＃そうやってどのブラウザでも同じURL集(?)を共有してます。
＃＃同様にsambaでDebian側のw3mとも共有。
>"項目が固定されてる(伝統的な)メニュー"ってあったのですか？
う。(環境によっては)知りません。
＃まあいいや。ResEditでいじっちゃえ。
Re:Konfabulatorのパクリっすか (スコア:1)
え？
いや、そうじゃなく、「マルチタスクならDAという概念自体いらんよね」という話のつもりなのですが？
Re:Konfabulatorのパクリっすか (スコア:0)
無理にDAなんて話にするから、ややこしくなってるだけなんでは？
なかったときと比べて使いやすくなったのは事実です。
そりゃあなくていいって人もいるんでしょうが。あるにこしたこたーないんでは。
「あのAppleが」って連呼してるのは、デザイン面であちこちのソフトをつぶして歩いた
イメージがあるからなのかな？
konfaburatorがwindows版でたことがあったみたいに、dashboardのウィジェットを
そのまま別のプラットフォームで動かす人は、そろそろ出てないのかな？
X-windowで動くようになったときにこりゃー便利だ、とかいいだしたら、ちょ
Re:Konfabulatorのパクリっすか (スコア:1)
うん。そうなんだろうと思います。誰だDAの話を"最初に"出したのは？(^^;
>そりゃあなくていいって人もいるんでしょうが。あるにこしたこたーないんでは。
いや、当初は「ないと使いものにならなかった」と思います。
だってそれしか
(ある使い方をしたいとき(具体的にはもちろん「複数のソフトを使いたいとき」)の)
手段が無かったわけだから。要らんってわけではないと思います。
>「あのAppleが」って連呼してるのは、デザイン面であちこちのソフトをつぶして歩いた
>イメージがあるからなのかな？
え？あれってイメージだったんですか？
てっきり実話だと思ってたんですが、違っていたのなら失礼。
＃それとも、「他社も同じようなもんじゃん」ということですか？
>スマートリスト（とかspotlight）は、そういうのを補完するわけだし。
それこそ知らないんで(藁)、spotlightについてはググって、
http://www.apple.com/jp/macosx/features/spotlight/ とか読みました。
うーん。つまりメタデータとIndexing(検索ネタのキャッシュつー意味での)でしょうか。
(だとすれば)もちろんそれはそれで便利だけど、
俺が気にしてる問題(?)とはまた別の便利さというか…。
＃メタデータとかによる「分類」に限界感じて
＃すっかり超整理法もどきベースになっちゃってるので、G7
あとローカル検索ツールは(特に最近)ほうぼうから一杯沸いて出てるし…
あ。フォルダって言い方が悪かったのかな。
別にFileだけを置くものを意図したかったわけじゃなく、
Objectならなんでも置ける場所として、フォルダって単語を使ってしまいました。
だから、たとえば、ボタンとかも置ける。
Processに属するフォルダ(名前は恐らく「File」や「Edit」です)に
「Save」とか「Cut」とかいう名前のボタンが格納されてる、という感じ。
＃あ。これもMacには既にあるんでしたらすみません。
Re:Konfabulatorのパクリっすか (スコア:0)
Macのマネ関係の多さを考えれば、ごく一部でしょう。
Macのマネが多いのはある意味あたりまえ。
自分で自分を真似する奴はあまりいないですから。
Re:Konfabulatorのパクリっすか (スコア:0)
CNetに踊らされているだけの人がいかに多いか実感できますよ。
Dashboardが標準化へ (スコア:0)
完全にオリジナルなものってほとんどないですよ。
Dashboardが標準化へ [mycom.co.jp]というのもあるし、いいものは広まってくれればうれしいです。
Re:Dashboardが標準化へ (スコア:1)
ええ。そのとおりです！
だから俺としてはKonfabulatorが潰れても気にしませんし、
逆にいえばAppleがGUIやiPodをパクられて潰れても(藁)気にしません。
問題は「あのAppleが」だというところです。
>Dashboardが標準化へ [mycom.co.jp]というのもあるし、いいものは広まってくれればうれしいです。
おお。すばらしい。
というか、Dashboardかどうかはどうでもよくて、
Scriptingな言語と設定言語を使ってライトウェイトにGUI小物を作るってのは
とても未来が有る考え方だし「一般的に広まって欲しい」考えかただと思います。
てゆーかMSのhtaも、ある意味で似たようなもんだしね。
とはいえ、HTML(やKonfabulatorのようにXML)を使うのは、
個人的にはあまり好きではないです。
KonfabulatorでのXMLの位置付けを、
HTMLやXMLなんかみたいなヘビーウェイトで書きにくい言語でやるよりは、
JSONやYAMLに取り換えたほうが良いのんちゃうか？と思いますし、
もっといえばClosure使えばわざわざ別言語で設定しなくても良かろう
(つまり設定用の別言語なんか要らない)し、と。
Re:Dashboardが標準化へ (スコア:0)
AppleScriptもHTMLでGUI作れるようになったら素晴らしいのに。
HTMLも巻き込んでコンパイル（っぽいこと）ができれば、さらに素晴らしいんだけどな。
WindowsXPのSP2から、HTAがアイコンなしからアプリケーションアイコンになったのが嬉しい。
ささやかだけど使いやすくなったよ。
Re:Dashboardが標準化へ (スコア:1)
>JSON, YAMLなどは、(私も含め)一般の人は聞いたことも無いですし。
うーん。メジャーさと敷居の低さはイコールじゃないと思いたいです。
＃そうでないとそれこそMacの立場が(^^;;;
"JSON JavaScript"でGoogleすると(国内リソースも)既に一杯あるようですが、
本家は http://www.crockford.com/JSON/index.html です。
要するに(人間の目にも機械にも)ちょー簡単な構造データ保存フォーマット。
どれくらい簡単かは同ページに色々書いてある
(英語読まなくても見た目だけで判るかもー) し、
一部の言語(Rubyとか)だとプログラム1行で読み込めるそうな。
同じような位置づけですが、YAMLは
http://www-6.ibm.com/jp/developerworks/xml/030124/j_x-matters23.html
なんかをどうぞ。
ライバル(?)のXMLとかと比較してますです。
どっちもXMLより随分と「簡単」だと思います。
この簡単さが敷居を下げてくれるんじゃないかと。かなり。
もちろんビジュアルなGUIビルダが有れば
複雑なXMLでも構わないわけですが、
それならユーザ(プログラマ)から隠蔽されるわけですから、
そもそもXMLであることを売りにする理由もない。
てゆーか「XML」って単語を聞いて、実際、「ラクそうだなあ」と思ったりします？
俺はしません。全く逆に「小難しそうだなあ」と思っちゃいます。
なんせ今時の小難しいソフトでは大抵XMLを使ってますからねえ(^^;
＃余談ですが、iEPGのファイルは簡単な独自(？)フォーマットのテキストでした。
実際に買ってみた (スコア:1, 参考になる)
Realbasicで書いたあるソフトの機能をDashboard widgetで実現してみたいのだが
どこからとっかかればいいのかいまひとつ分からない。
ということでこの本をAmazonで予約して買ってみました。到着は10日。
で、感想ですが、ページ数に比べて「軽い」本です。
電車の中で1時間でほとんど読み終わりました。これは別に悪いことではなく、
「これを読むと、なんだか自分でもできそうだ、という気に十分なれる」ということです。
実際にはまともなWidgetを作ろうとすればCSSやJavascriptのそれなりの知識が
必要になるので、この本一冊ですごいwigdgetがあなたにも!とはなりませんが、
それでも基本的なwidgetのルールを押さえたwidgetをものにする参考書の役目は
十分果たしてくれると思います。
＃全くの初心者もこれでプログラムができる! Macユーザが増える! と
なるほどのものでもありません。念のため。
なお、この本にはCD-ROM等は付属していませんが、文中にサンプルコードの
ダウンロードサイトのページが書いてあり、そこから全てのコード・widget用画像等をダウンロードできます。
＃で、ここからはオフトピですが・・・
こういったプログラミングの本ですが、「書籍を買ったらPDF版もダウンロードできる」ようになってくれるとうれしいです。
いまや、分厚い本を片手に、よりも、PDFで必要なページをさっと読む、と言ったスタイルのほうが気楽なもので。
前出のRealbasicも、不満はいろいろ(多数)あるんだけど
「日本語ドキュメントがPDFで提供されている」というのはとても助かります。
（電車の中でもマニュアルを読みながらプログラミングできる!)
Macのintel化。実はRealbasicの対応が一番心配なACより。
Re:実際に買ってみた (スコア:2, 参考になる)
基本的な章立ては、Apple の Programming Guide と似ていますね。当然ですが、Apple の方が網羅的に見えます。その代わり、この本は丁寧に書かれているような感じ？ある技術に関する最初の本としてはオーソドックスなものだと思います。
英語が読め、プログラミングの知識があるかたは、Programming Guide と Reference [apple.com] で十分だと思います。
ところで、上のほうで Konfabulator がらみの荒れ気味の（ｗ）スレがありますが、Amnesty [mesadynamics.com]
を使うと、Dashboard を Konfabulator のように常駐させられるようですね (defaults write でもできるようですが)。
Re:実際に買ってみた (スコア:1)
Developers speak out on the big switch (part I) [macosxrumors.com]
自動翻訳：「「クロスプラットフォームアーキテクチャを考えて、1999年以来REALbasicはx86をサポートしています。」 したがって、インテルでMac OSがXであるとサポートするのは、私たちのための全く大きい挑戦ではありません。 それは私たちの顧客のために大したことにならないでしょう; 私たちの顧客はソースコードへの変化なしで彼らのアプリケーションを単に再コンパイルするでしょう。 私たちがこの能力を提供するつもりである時に関して、私たちの顧客要求は、私たちの開発スケジュールを追い立てるのを助けます。 「私たちは、私たちの顧客が彼らの互換性のアプリケーションを検査して、アップルが乗船する前にそれらを出荷する何時間もこの技術があらゆるインテルベースのMacsであるとサポートするのを確実にするつもりです。」」