1 :
名称未設定 :
02/10/24 00:27 ID:Qd71qucq
2 :
1 :02/10/24 00:27 ID:Qd71qucq
2get。で、Cocoaスレでも書いたんだけど、とりあえず、 どんな感じのメーラーを作るか決めたいので、良かったらご意見ください。 あるていど固まったら、設計に入りたいと思ってます。 今のところ出ているアイデアは、 ・ML専用メーラー ・メニューバーやDockと連動 ・2chメール欄と連動 ・1メール1ファイルじゃないのがいい。 ・OSXならではの機能。 (検索やフィルターにPerlを直接使用したり、MySQLにデータを流せたり) ・メールボックス毎に、異なる保存先
3 :
1 :02/10/24 00:28 ID:Qd71qucq
4 :
名称未設定 :02/10/24 00:30 ID:4WEjukBP
がんばってね...。 できたら呼んで。
5 :
1 :02/10/24 00:37 ID:Qd71qucq
>>4 さみしいな・・・。
なんかこんなメーラー欲しいなあ、とか、
あんなことできたらいいなあ、とかない?
6 :
名称未設定 :02/10/24 00:39 ID:xtBkmmkq
7 :
名称未設定 :02/10/24 00:41 ID:Gk7EtfeF
一秒で起動するメーラが欲しい。(マジレス)
8 :
1 :02/10/24 00:42 ID:Qd71qucq
9 :
1 :02/10/24 00:45 ID:Qd71qucq
一秒か・・・マジレスすると、結構きびしいんだよね。 最初にリソースの読み込みがあるし。
10 :
名称未設定 :02/10/24 00:50 ID:CO8WQ4mA
できるだけ表示の切り替えが速いメーラがほしいな... メールの一覧表示で、ラベル(色分け)できるとうれすぃ... bugfixとかには付き合えるので是非頑張って下さい♪
11 :
名称未設定 :02/10/24 00:52 ID:0gVX+5EB
・HotMail、エキサイトメール、インフォシーク、ライブドアなどの Webメールを使えるメーラー。 ・メーリングリストの読みやすいメーラー。 ・常駐していても軽いメーラー。 ・インターフェイスがキレイなメーラー。 ・検索が使えるメーラー。 ・継続的に開発しているメーラー。 ・サポートを打ち切らないメーラー。 ・フリーならなおよし。 ・匿名メーラー(メルマガなどの登録用)
12 :
名称未設定 :02/10/24 00:53 ID:uVTon9Qv
>>1 がんばってください。
個人的には、os9.2を使うこともたまにあるので、
9.2のアントラージュと同期できるとうれしいです。
13 :
名称未設定 :02/10/24 00:55 ID:tx/Zfu0m
1さん期待してます。 強力な検索機能機能が欲しいです。 そしたらSwitchします。 ウフッ
14 :
1 :02/10/24 00:55 ID:Qd71qucq
>>10 ありがとうございます。
ラベルはいいですね。色でフィルタリングできたり、
検索条件に含められると便利になりそう。
15 :
1 :02/10/24 01:02 ID:Qd71qucq
>>11 たくさんありがとうございます。
ところで、どんな風にすると、メーリングリストが読みやすくなるかな・・・
やっぱスレッド表示をきれいにすること?
16 :
名称未設定 :02/10/24 01:03 ID:2gLymIPg
インターフェースはCyberDogがベースだといいなあ
17 :
1 :02/10/24 01:07 ID:Qd71qucq
>>12 アントラージュと同期ですか。それは俺もできるとうれしいですね。
昔使ってたけど、メールボックス移行せずにそのままになってるから・・・
できれば、他のメールソフトのメールボックスをそのまま
読み書きできるといいな。
18 :
1 :02/10/24 01:12 ID:Qd71qucq
>>13 ありがとう桃子タソ。
強力な検索機能はやっぱり欲しいですね。
正規表現で全文検索できるのが理想です。
19 :
12 :02/10/24 01:12 ID:uVTon9Qv
がんばってください。 スレの保守がんばりましょう。
20 :
1 :02/10/24 01:13 ID:Qd71qucq
>>16 すんません、実はOSXからのユーザなもので、
CyberDogってどんなものなのか知らないんですよね・・・
それは、今のOSXでも(擬似的にでも)適合出来るものなんでしょうか?
21 :
名称未設定 :02/10/24 01:13 ID:HUldEyaj
ARENAみたいにTOPの概念があって、上にツールボタンが並んでるような インターフェースだと個人的には嬉しいなあ。
22 :
1 :02/10/24 01:18 ID:Qd71qucq
>>19 ありがとうございます。
スレもメーラー開発もなんとか長生きさせたいと思ってます。
継続するのが結構難しいですからね。
23 :
名称未設定 :02/10/24 01:25 ID:AO7ZwC0b
希望です。あくまで希望なので・・・。 ・モジュール対応:外観を変えるやつです。出来たら作りまくります。 ・リモートメール:MUSASHIやARENAみたいに、サーバを開いて削除とか出来る機能。 ・メールチェッカー:本体とは別に、メールチェックしてくれる軽いソフトを付けて欲しいです。 アプリならスキンを激しく希望。もしくは新着通知がメニューバーに表示されるといいですね。 ・受信したメールは圧縮ファイルに:メーラーには圧縮ファイルから読み込むようにして欲しいです。 メールが増えて来たらそのままバックアップ取ればいいだけだから便利!! ・自動転送:特定のアドレスからのメールを、携帯等の違うアドレスへ転送。 ・ウインドウは出来れば別々に:3ペインとかだとホイールの動作が怪しかったりするので・・・ ・コンテクストメニューを充実:右クリックで色々出来ると便利だと思います。 ・画像表示:添付画像はメール内で縮小表示して欲しいです。設定で非表示にも出来ればなお最高! ・複数アカウントの柔軟な組み合わせ:ARENAのように、このアカウントの場合はこの受信サーバと この受信サーバをメールチェック、というような組み合わせを決められると便利です。
24 :
1 :02/10/24 01:26 ID:Qd71qucq
>>21 俺も実は今はARENA使ってます。あの上のツールボタンは、
大きくて押しやすくていいですね。デザインもシンプルでいい感じです。
ああいうのは取り入れたいな。
ところで、俺はもともとウィンナだったのでメーラーっていうと
3ペインをすぐ思い浮かべるんですが、Macユーザだと、
ARENAみたいな感じの方がしっくりくるんでしょうか?
25 :
追加 :02/10/24 01:28 ID:AO7ZwC0b
ツールバーはユードラやクラリスメールのように、ウインドウとは別にフロートさせて欲しいです。
26 :
名称未設定 :02/10/24 01:33 ID:0gVX+5EB
↑ やだ。Mail.appの様に一つのウインドウで完結して欲しい。 ということで、ウインドウは3ペインがいい。Mail.appのような。 Arenaのインターフェイスは使いやすかったけど、OS9までのインターフェイスなので、 Xっぽくないので却下。
27 :
追加 :02/10/24 01:35 ID:AO7ZwC0b
では、3ペインかバラバラにするか設定で選べるように・・・
28 :
名称未設定 :02/10/24 01:39 ID:HUldEyaj
>>24 あ、ごめんなさい。ツールボタンをTOPの上に並べるという意味です。
ようするに見た目がOS Xのウインドウみたいな感じになってて、
カラム表示や別ウインドウで開くとかを任意で設定できたり。
29 :
名称未設定 :02/10/24 01:41 ID:fzZm1+VR
ネスケ4.7のメッセンジャーと同等の機能、同じ配置で、マルチユーザーマルチアカウント対応でお願いします。
30 :
1 :02/10/24 01:43 ID:Qd71qucq
>>23 かなり具体的な希望をありがとうございます。
もちろん、今の段階では希望だけどんどん出してもらえればうれしいです。
外観をかえる機能は、俺も是非欲しいと思っていました。
なるべく、カスタマイズを色々できるようなものにしたいです。
コンテクストメニューとかも、自分で好みのメニューを設定できる
ように出来るとまた便利そうですね。
メールチェッカーもいいですね。Dockに通知したりとか。
ところで23さんは、絵ごころのあるかたですか?
今はまだそういう段階じゃないんですけど、
そのうちGUIデザインとか必要になってくるので・・・
暇があればそのうち協力してもらえるとうれしいです。
31 :
名称未設定 :02/10/24 01:45 ID:8g3u5cgA
>>28 ARENAのTOPにツールバーないのは欠点ですよね。
他のメーラーには全部あるのに。
32 :
追加 :02/10/24 01:49 ID:AO7ZwC0b
>>30 絵は大丈夫ですよ。もし今後出来ることがあれば
是非協力させてください。このスレは定期的に見に来ますので。
33 :
1 :02/10/24 01:51 ID:Qd71qucq
>>25 ,26,27
なるほどです。やっぱりこの辺は好みが分かれるんですね。
確か設定でどちらにでも出来るようになった方がいいかも。
34 :
1 :02/10/24 01:55 ID:Qd71qucq
>>28 ,31
すいません、勘違いしてました。
TOPにツールバーは、確かに欲しいですね。
しかし、カラム表示もできるメーラーって面白いな・・・
既存のものでそういうのってないんじゃないかな?
35 :
1 :02/10/24 01:58 ID:Qd71qucq
>>29 ネスケメーラーは、実はWinでかなり長いこと愛用してました。
あれ、何気に名作ですよね。特に検索機能が好きだったな。
Macのも同じかどうか知らないんですけど・・・
36 :
_ :02/10/24 02:00 ID:UBEe0PPy
・ProjectBuilderみたいにペイン分割を設定できるといいかもねー。 ・なんかMail.appもそうだけど、添付ファイルのエンコード選べないメーラー最近多くない? あれ、困るんだよねー。。是非。 ・メールチェッカーはDockよりmenuかな。 ・MagelanやEntourageみたいに、メールボックスとは別にカスタムビューがあると便利。
37 :
名称未設定 :02/10/24 02:00 ID:uAqw9a/u
個人的な機能の要望です。 普段メールをいろいろなフォルダーに振り分けているのですが、 たまに探しているメールをどのフォルダーに入れたか忘れてしまって、 Mail.appだといちいちいろんなフォルダーにたいして 検索をかけないといけないので、 いくつかのフォルダーに対して、 一回で検索出来るようなシステムにして欲しいです。
38 :
1 :02/10/24 02:00 ID:Qd71qucq
>>32 ありがとうございます。ホントに助かります。
自分で作るとかなりダサダサになりそうなので・・・
39 :
37 :02/10/24 02:02 ID:uAqw9a/u
例えばiTunesでbrowseしている時に、 いくつかのジャンルを選択した状態で曲名を検索出来るようなシステムかな。
40 :
1 :02/10/24 02:10 ID:Qd71qucq
>>36 PB使ってるってことはプログラマですね。ぜひプログラミングの方でもご協力を・・・
ペイン分割の設定って、タスクテンプレートみたいなやつ?
あれはかなり柔軟でいいですね。参考になりそうです。
あと、カスタムビューは俺も欲しいですね。
特に、新着したメールだけを表示するビューは個人的に絶対欲しいところ。
41 :
余談ですが :02/10/24 02:12 ID:8WsOnPPZ
ARENAって、メールサーバをマウントした状態でアカウント設定変えると ぶっ壊れますよね。。。あの致命的なバグはなぜ最後まで直らなかったんだろう。。。
42 :
1 :02/10/24 02:17 ID:Qd71qucq
>>37 ,39
うーん、ちょっとわからないのですが、単なる
全メールボックス検索じゃなくって、フィルタリングと検索機能を
組み合わせて使えるようなものってことでしょうか?
例えば、フォルダー内の、ラベルが赤のメールのみを表示させるように
設定して、その中から文字列検索をする・・というような感じ?
そういうのは、面白いですね。
43 :
1 :02/10/24 02:22 ID:Qd71qucq
>>41 それは知らなかったな・・・
でも、そういう操作はなかなか想定できないものだから、怖いですね。
メーラ作ったはいいけど、ユーザのメールボックス壊しちゃったらやばいな・・・
44 :
1 :02/10/24 02:23 ID:Qd71qucq
とりあえず、そろそろ寝ます。 また明日よろしくお願いします。
45 :
名称未設定 :02/10/24 02:26 ID:bNgBpJkE
>>1 CyberDogのメールパートをインターフェースそのままで移植して下さい。
メールファイルをそのまま使えたらなお嬉しいです。
46 :
名称未設定 :02/10/24 02:27 ID:zrWrzwtx
検索画面でメールフォルダの一覧が出て、 検索対象にしたいフォルダにチェックを入れる みたいな感じじゃないでしょうか。
47 :
名称未設定 :02/10/24 02:39 ID:7uS3YyGI
.macとhotmailが見れたらいいなぁ(ボソッ
48 :
37 :02/10/24 03:05 ID:uAqw9a/u
>>42 そんな感じです。
分かりにくくてすいません。
後、結構後回しにされがちだけど、
ほかのメーラーからのメールとアドレスのインポートは、
ユーザーを増やすためにかなり重要だと思います。
特に過去のメールは捨てられても、
アドレスを捨てられる人は少ないと思うので。
Mail.appなんかでもOutlookExpressからのアドレスのインポートが
出来ないみたいだし(一回Entourageに読み込まないといけないらしい).
49 :
名称未設定 :02/10/24 03:27 ID:FSZV/uuY
良スレの予感
50 :
名称未設定 :02/10/24 03:38 ID:/RePN4Ku
1さん頑張ってください
51 :
名称未設定 :02/10/24 03:52 ID:H0P52qci
菊地桃子が使うとフリーズするメーラーキボンヌ!
52 :
名称未設定 :02/10/24 03:53 ID:cz/G2EES
応援してるよー、ガンガレ。
53 :
名称未設定 :02/10/24 03:56 ID:W2kvAgyI
ど う せ 途 中 で ド ロ ン す る ん だ ろ
54 :
名称未設定 :02/10/24 04:04 ID:DTuPq5Qm
Postinoにあったすてきな機能というか仕様 うざいHTMLメールは添付ファイルにしちゃってください わざわざレンダリングしてくれなくていいです… あとアドレス機能もいらない、標準のアドレスブックに丸投げ してしまえば。 あと画像とかムービーのインライン表示もいらんなあ とにかく、軽くうごくメーラーきぼん
55 :
21 :02/10/24 04:12 ID:HUldEyaj
56 :
21 :02/10/24 04:18 ID:HUldEyaj
あ、スクロールアロー入れるの忘れてた。スマソ
>>1 希望だけ……。
- スレッド表示可能 (スレッド編集機能があるとなお良しかなぁ)
- アドレスブックとの連携
- 引用レベル色分け + 引用符変更 (> とか | とか)
- 軽い動作
お手伝いはマニュアルの校正とかしかできん……。
58 :
名称未設定 :02/10/24 05:47 ID:7te+1mRJ
windows使ってたのならBeckyやAl-mailのように ・本体はシンプルに、そしてプラグインで機能追加 出来るようにしてほしい。人によって必要とする機能は 違うわけだし、本体が不必要にでかくなるのはイヤン。
59 :
名称未設定 :02/10/24 06:17 ID:hypFCDx0
ついでにファイル交換機能も付けちゃえ。 WinMXにも接続出来ちゃうみたいな。
60 :
名称未設定 :02/10/24 06:49 ID:U01+Ufqv
一番希望するのは、本体とは別のメニューバー常駐の定期チェック機能ですね。 いろいろあるので箇条書き ・主な機能は定期チェックと受信。 ・メニューバーに表示するステータスは、新着あり/なしの2種。 ・新着ありステータスはメニューバーアイコンクリックか、本体起動でクリア。 ・簡単なログ表示。 ・アカウントごとに、チェックする/しない、受信もする/しないを設定できる。 ・ユーザには別アプリと意識させない(本体アプリケーションパッケージ内に隠蔽)。 ・ログイン時に起動するかどうかの選択。 ・本体が起動しているときはプロセス間通信で通知、即座に本体に反映。 ・すべての設定は本体の環境設定から(も)できる。 こんな感じでどうでしょう?
61 :
名称未設定 :02/10/24 07:10 ID:AF7/y8Cw
62 :
名称未設定 :02/10/24 08:29 ID:ZTbFbDYh
ぐはぁ。スレ立ってたのか。 出遅れた。
63 :
名称未設定 :02/10/24 08:58 ID:ZWZCCMKr
そろそろ名前考えろ! ダサくていいなら、CocoaMail。
64 :
名称未設定 :02/10/24 09:29 ID:hbCTjdOK
返信メールに At Tue, 22 Oct 2002 18:33:20 ,nanashi>wrote これが入るようにしてほしいな.
65 :
名称未設定 :02/10/24 09:34 ID:0gVX+5EB
っていうか、GyazMailを完全日本語化してくれたらそれで満足。
66 :
名称未設定 :02/10/24 09:53 ID:ruADKJ5T
他メーラーからの完全取込み・他メーラーへの完全書き出し は絶対必要。
67 :
_ :02/10/24 14:26 ID:UBEe0PPy
GyazMailって添付ファイルのエンコードかえられんからつかえん。 それに既存のメーラーの枠内でしか開発する気ないみたいだしね。 あんま期待できんなー。
68 :
名称未設定 :02/10/24 14:29 ID:VBDCszoH
販売がact2なメーラー。
69 :
名称未設定 :02/10/24 14:32 ID:ruADKJ5T
Void氏が関与するメーラー
70 :
名称未設定 :02/10/24 15:46 ID:AO7ZwC0b
既存のメーラーの枠内でも、それぞれの長所拾ってくれば かなり良いものが出来ると思いますけどね。 まったく不満というより、何か欠けてる、惜しい、って思う事が ほとんどなので、そこら辺をカバーした物があれば充分嬉しいですよ。
71 :
名称未設定 :02/10/24 15:57 ID:zrWrzwtx
あまり多機能にすると今度はLemonみたいにわけわからなくなるから、 やはりプラグインで強化出来るようなのが理想だね。
72 :
名称未設定 :02/10/24 15:57 ID:BFp6dCdH
楽しそうですね…。期待してます。
>>37 ,39
検索案良いですね〜賛成です。
>>54 標準アドレスブックに丸投げ案、賛成です。
3ペインか否か?ってやり始めると絶対まとまらないと思います。
モードの切り替え、ツールバーの切り離しができると皆満足かな。
21,55氏のカラムもおもろいかも。別窓は必須でしょうね。
60氏のチェック機能は、Dockからもできると良いな。
73 :
名称未設定 :02/10/24 19:28 ID:znD7m9Hg
まとめるとかじゃなくて、言いたい放題言っておいて、 あとは1始め制作する側にお任せする感じで良いのでは。 なんにせよ選択肢が増えるのは嬉しい事だから なんとか公開まではこぎつけて欲しいよ。
74 :
名称未設定 :02/10/24 19:31 ID:RX2GZaf+
Postinoのメールデータをほぼ完全に一発取り込み出来るメーラができたら、 シェアウェアになってもレジります。 ARENAプロジェクトも投げ出した形式なので、贅沢は言いません…⊃ Д `)。
75 :
名称未設定 :02/10/24 20:30 ID:1ZBNrLkj
アイディアを2chでタダで手に入れるんだったらソースコードも公開するんだよな?
76 :
名称未設定 :02/10/24 21:05 ID:uJp4dlo4
効果音のカスタマイズもできるとうれしい。
77 :
1 :02/10/24 21:14 ID:Qd71qucq
こんにちは。レスがいっぱいついててウレシイです。
>>45 CyberDogずいぶん人気ありますね。気になったんでちょっとGoogleで調べたんですけど、
壮大な計画のもとに作られたソフトだったんですね・・・
別ソフトの移植っていうのはあんまり考えてないんですけど、
メーラー作りに生かせるかも知れないので、CyberDogのどんなところが
いいのか教えてもらえるとうれしいです。
>>47 .macはPOPにも対応しているので、普通に作れば使えそうですね。
hotmailは使ったことがないので知らないんですけど、
POPやIMAPじゃ無理なのかな?
78 :
1 :02/10/24 21:15 ID:Qd71qucq
>>46 ,48
なるほどです。検索機能は俺も特に重視したいと思っているので、
後でもっと細かくインターフェースや仕様を詰めたいと思っています。
あと、メーラーの移行はホントに面倒だから、なにか工夫したいですね。
>>49 ,50,52
ありがとう!がんばってみるよ。
>>51 桃子に「ホント使えない」って言われるのはイヤだな・・・。
>>53 まあ、その危険性はないとは言えないけど、
とりあえずがんばってみるから応援してくれよ。
79 :
1 :02/10/24 21:16 ID:Qd71qucq
>>54 そうですね。HTMLメールは添付にして、必要に応じてブラウザで
見られるようにしておくのが俺もいいような気がします。
アドレスブックはやっぱりアドレス帳でやりたいですね。
せっかくOSXならではの機能なのだから。
>>55 ありがとうございました!
サブジェクト面白すぎ。「友人」なのがちょっと泣ける。
やっぱり画面があると想像しやすいですね。
みててふと思ったんだけど、カラム表示ってラベルや日付を使った
フィルタリングに使うと効果的かも知れないですね。
例えば、一番左の列が、ラベルの色で「赤」とか「青」とかになってて、
赤 -> 友人 ->山田一郎って選んでいくと、山田一郎のラベル赤のメールだけが
表示されているって感じ。
同じように、一番左の列が「今日」「最近一週間」「それ以前」とか。
フィルタ条件はユーザが自分で指定できるようにして。
どうでしょう?
80 :
1 :02/10/24 21:22 ID:Qd71qucq
>>57 スレッド編集機能っていうのが気になるんですけど、これって
MLのスレッドを、あとから自分でなおしたりできるってことでしょうか?
あればかなり便利そうですね〜。
既存のメーラーでそういうことが出来るのがあるのでしょうか?
>>58 これはいいですね。プログラマ的にはこういう発想、かなりそそられます。
プラグインの仕様をどうするか?とか、考えるだけで楽しそう。
設計するのはかなり難しそうですけど。
81 :
名称未設定 :02/10/24 21:24 ID:f6OMSXcG
>>1 にはできるだけ初期にソースコードの公開をキボンヌ
あまり大規模になった後では、読むの面倒で参加しづらいので・・。
82 :
名称未設定 :02/10/24 21:26 ID:3xwq9fXF
えっと〜 なんか興味ある話ですね。陰ながら応援しています。がんがってください
83 :
1 :02/10/24 21:31 ID:Qd71qucq
>>59 それはかなり面白そうですね・・・いや、メーラー部分いらないのでは・・・。
>>60 すごく具体的なアイデアありがとうございます。
そのまま仕様として使えそうです。
これはホントに是非ともほしい機能だな。
簡単なログっていうのは、「〜通受信しました」みたいなやつでしょうか。
>>80 Winだと、EdMaxやBecky!、Datulaなんかができるみたい。
Macでもできるメーラーがあった気がする (SweetMailかな?)。
……やっぱりWinはメーラー強いな。
会社でも仕事はMacだけど、メーラーだけはWinでEdMax。
それを乗り換えさせるだけの威力をもったメーラーキボンヌ (
>>1 )
85 :
1 :02/10/24 21:51 ID:Qd71qucq
先に最近のレスから・・・
>>81 はい、基本的に最初からずっとオープンにしてやっていこうと思ってます。
ちょっと恥ずかしいっすけどね。ソースコード見られるの。
どこにオープンするのかはちょっと考え中なんですけど。
何か良いやり方があれば教えてもらえるとうれしいです。
>>82 ありがとうございます。暇があったら色々意見ください。
>>84 そうでしたか。ちょっと今度試してみます。
Datulaってそういえば昔つかってたなー。
EdMaxって最近のでしょうか?知らないです。
俺は会社では鶴亀メールだったりして。
86 :
名称未設定 :02/10/24 21:57 ID:UVKU298z
87 :
名称未設定 :02/10/24 22:04 ID:VBDCszoH
88 :
1 :02/10/24 22:06 ID:Qd71qucq
>>86 ありがとうございます。
いまちょっとざっくり見たんですけど、これはかなり参考になるかも・・・
もしかすると、部分部分ソースをそのまま拝借できるかな。
オープンソースのコードって拝借しても大丈夫なんでしたっけ?
89 :
名称未設定 :02/10/24 22:08 ID:GM616mXh
Subjectの特定のワードを表示しない機能が欲しいでつ。 たとえば、たいていのMLって[xxxxx:12345]みたいに、 []で文字をくくってますよね。 この部分を任意で表示できないようにすると、 MLで題名からスレッドを追いやすいんですよ。 この機能のあるMac用のメーラーって、 寡聞にして知らないので、 とりあえずキボンヌしてみます。
90 :
1 :02/10/24 22:13 ID:Qd71qucq
>>87 えーと、すいません、ライセンスってソースコードのですか?
それは全然考えてませんです。知識も全くなし。
少し教えてもらえるとありがたいのですが。
91 :
1 :02/10/24 22:21 ID:Qd71qucq
>>89 それはすごくいいですね。スレッドを追いやすいのもあるし、
メール一覧のSubjectが[xxxxx:12345]の部分でほとんど占められて
しまうようなMLもあるので。
特に、OSXってフォントを大きくしがちだから、かなり便利だと思います。
92 :
名称未設定 :02/10/24 22:26 ID:bwzOxRVo
93 :
名称未設定 :02/10/24 22:35 ID:UVKU298z
94 :
1 :02/10/24 22:37 ID:Qd71qucq
>>92 サンクスです。ここ有名ですよね。
有名なソフトの開発ばっかりだから、ちょっと緊張しますね。
95 :
名称未設定 :02/10/24 22:39 ID:AO7ZwC0b
96 :
1 :02/10/24 23:02 ID:Qd71qucq
>>93 ありがとうございます。リンクざっと見ました。
基本的にはGPLの方向で考えていきたいと思います。
ただ、GPLにすることで、何か守らなければいけなくなることも
あると思うので、ちゃんと条文読んで理解してから決めたいと思います。
97 :
名称未設定 :02/10/24 23:02 ID:Qb8/rgko
リリースまでのスケジュールを教えてクラハイ。 以下、かってに考えた妄想です。 今月:この調子で要件定義 来月:製造 さ来月:β版リリース 以降:フィールドテスト ??:バージョン1リリース
98 :
名称未設定 :02/10/24 23:06 ID:tD2fHRjY
勝手な要望ですが、 ・メールチェック ・新規メール作成 ・メールボックスの表示(未読数なんかも) ・サーバの切り替え なんかをDockから出来たら常駐させたいです。
99 :
1 :02/10/24 23:08 ID:Qd71qucq
>>95 これは面白い機能ですね〜。
多分、できないことはないんじゃないかと思います。
(スキンはCocoaだとやりにくいかもしれないけど・・・)
>>97 >リリースまでのスケジュールを教えてクラハイ。
胴衣。ベータ版公開まででいいので。
101 :
1 :02/10/24 23:24 ID:Qd71qucq
>>97 ,100
うーん、会社員なものでこのスケジュールは正直キビシイです。
協力してくれる人がどれくらいいるかにもよりけりなんですが。
あと、最初に超基本的な機能だけ備えたものを作ってみて、
それから順次機能追加していくような形にしていきたいと思っています。
というわけで、俺の脳内スケジュールです。
10月:要件定義
11月:画面設計 + 技術検証プロト
12月〜1月:超基本機能製造
2月〜3月:その他の機能製造
4月以降:βリリース&ひたすら機能追加
102 :
1 :02/10/24 23:28 ID:Qd71qucq
>>98 常駐機能はやっぱり需要多いですね。
メニューバー派とDock派は、どっちの方が多いのかな?
103 :
1 :02/10/24 23:39 ID:Qd71qucq
すいません、全レスしようかと思ってたんですが、 スレに張り付きすぎでだんだん気分が悪くなってきました・・・ 今日はもう寝ます。レス出来なかったみなさんごめんなさい。 明日くらいからは、ぼちぼち具体的な仕様の話をしたいですね。 もちろん、今まで通り要望もどんどん出して欲しいです。 では、おやすみなさい。
>>101 たぶん、言葉のあやだろうけど、ひたすら機能追加より、
バグ取りの方がよいかも。
むやみな機能追加はさらなるバグを呼ぶ……。
105 :
60 :02/10/24 23:59 ID:U01+Ufqv
>>83 そうです、「hogeアカウント12件受信」とか。メニューバーのメニュー項目から
ログウィンドウ開く感じですね。けど
>>95 みたいに、メニュー自体に表示
されるような方向でもいいかも。
本体とは別のメニューバー項目が欲しい理由にメール受信と閲覧を区別したい
っていうのがあります、要はモジュール化ですね。
で、モジュール化の極端な例として Mac OSメール環境(
http://mac-ome.jp )
がありますね。使ったことないんですが、これはメールソフトとしての
一体感が感じられないしMac的でないと思うので敬遠してしまいます。
一応参考までに。
ところで、アカウントの考え方はどんなもんです?
Mail.appみたいにINBOXだけ別なのか、
アカウントの中にINBOXやその他フォルダがあるのか。
自分としては、アカウントが違うものは完全に別管理なので
後者の方がいいんですが、、、
あと、保存形式は?
>>92 sf.netだけでアクセスできるsourceforge.netのほうがいいなぁ。
107 :
21 :02/10/25 02:33 ID:oF5N1/q5
私が考えたOS X のウインドウと同じ挙動をするTOPなんですが、 ボタンひとつでツールバーだけになりフロート化できるというのはどうでしょうか? そうすれば25さんと26さんの希望を両立させることができそうなんですが。
108 :
_ :02/10/25 02:51 ID:nyXVTvB5
フロートちょっと。。。じゃまです。僕はmenu派 >95 はOSXのMailTickerみたいなやつですね。 あれも使いやすいけど、まだまだ機能すくないかなぁ。
109 :
21 :02/10/25 03:07 ID:oF5N1/q5
>>108 私もフロート派ではないんですが、フロート化「も」できればいいかなあと。
初期設定で選ぶよりこの方が直感的だし。
ホシュホシュ
111 :
名称未設定 :02/10/25 11:29 ID:pJbnt5fP
マクロメディアみたいにつかんでドラッグで各ツールバーやウインドウ 切り離したりくっつけたり出来れば楽しいカモ。使いやすそうだし。
112 :
名称未設定 :02/10/25 11:42 ID:Kmh9mta0
たいていのメーラーって、ルールとかフィルタとかって付いてますよね。 でも、あれって高機能になればなるほど設定が複雑でめんどくさくなったり、何故か期待した動作をしてくれなかったりしますよね。 頭悪いのでどうしてくれなんて思い付かないけど、D&Dとかで簡単に設定できる様にしてほしいです。
フィルタ機能については、 フォルダの「情報を見る」みたいものを開いて、 フィルタするメールの条件を指定できたら便利だと思う。 つまり、 「このメール」を「あのフォルダ」に仕分けするってのじゃなくて、 「あのフォルダ」に「このメール」を仕分けするって管理方法のほうが、 あとあとの管理作業が楽になると思う。 フィルタ条件を50くらい設定してると、 あとで再設定するのが面倒じゃない?
114 :
名称未設定 :02/10/25 12:15 ID:x1buv4PX
1よ、あまり真面目に全レスするな。 いちいちマメに返事していたら、楽しいけど疲れてしまって続かなくなるぞ。 意見を言う側も、1のレスを必ずしも期待するな。 1は、自分が興味をもった内容について上手にレスした方がいい。 ある程度マイペースでな。1さん。 俺も同じような状況に陥ったことがあるんだ。 楽しいけど、日常をあまり犠牲にするなよ。1さん。 続けるには、急ぎすぎないこと。これ。
115 :
名称未設定 :02/10/25 13:45 ID:4eEFMZ5Y
>>113 優先順位はどうするよ?
foo folderにはFromにfooが含まれるものを
hoge folderにはReply-Toにhogeが含まれるものを
(Fromがfooのこともあるがこっちが優先)
MLなんかをReply-toで設定するけど、当然そのMLには
Fromでフィルタリングされるような知人も参加していると。
>>113 のインターフェースでそれ出来るかなぁ?
>>115 優先順位は、ルール付けの問題だから、
インターフェイスの問題じゃないのでは?
わかりにくかったかもしれませんが、
Mail.appを例にして出すと、
「環境設定」→「ルール」でフィルタのルールを決めますよね。
そうじゃなくなくて、
Mail.appの任意のフォルダから、
ルールを呼び出したほうが楽じゃないかってことです。
具体例として、WinならBecky!がそういう仕組みになってます。
フィルタの設定画面も呼び出せるし、
フォルダからもルールを設定できるようになっています。
117 :
名称未設定 :02/10/25 15:13 ID:OWDxcYJh
メールチェッカーの段階でフィルタが欲しいな。 本文まで読み込んでたら時間かかるだろうから ヘッダからしか振り分けできないだろうけど、 スパムやDMを受信通知せずにサーバから削除させたい。
118 :
1 :02/10/25 21:03 ID:HYPOMlgv
ども、こんにちは。
>>114 さん、ありがとうございます。とりあえず、これからはのんびり
やりたいと思います。
で、だいぶみなさんに意見を出していただけたので、そろそろそれを元に
これから作るメーラーの目指す方向性というか、コンセプトみたいなものを決めたいと思っています。
今後は、それを機能の取捨選択を行う時の判断基準にできたらいいかなと。
以下のような感じで考えているんですけど、どうでしょうか?
よかったらご意見ください。
119 :
1 :02/10/25 21:04 ID:HYPOMlgv
1.軽快な動作。 ストレスなく、さくさく動く。スクロールのたびに虹色カーソルがまわるようなのはだめ。 これを満たせなくなるような機能追加は、基本的に行わない。 2.無駄な機能は極力省く。そのかわり、独自にプラグインを作れるような仕組みを導入。 3.メニューバーのメールチェッカーに力を入れる。 みなさんの意見で、だいぶ需要が多いことが分かったので、この機能の利便性には こだわりたいと思っています。Dockかメニューかという話が出ていたと思いますが、 個人的に画面の上の方で操作したいので、メニューの方にしたいと思ってます。
120 :
1 :02/10/25 21:04 ID:HYPOMlgv
4.検索機能に力を入れる。 正規表現や、複数メールボックスの一括検索を可能にする。ユーザー独自のビューを作れる。 ついでに極力高速化をはかる。 5.様々な種類のメール保存方式を、混在可能にする。 フォルダ毎に、メールの保存方式を指定できるようにする。 他のメーラー形式の読み書きや、iDisk、MySQLへの保存も可能。 6.画面構成は、TOP+ツールバーで。 基本的に、21さんの考えたような、TOP+ツールバーな構成で、ボタン一発で見せ方を 代えられるようなものにしたいです。もちろん標準的な3ペインにも対応できるってことで。
121 :
名称未設定 :02/10/25 21:06 ID:QqpdUXiq
1さんに期待あげ できればオープンソースにしてもらいたい!
122 :
ユカリ :02/10/25 21:07 ID:3RbbyN3m
124 :
1 :02/10/25 21:31 ID:HYPOMlgv
>>105 MacOSメール環境は、なかなか面白いですよね。
多分、自分で色々作れるプログラマにとっては、
ああいう考え方のメーラーって一番合っているんじゃないでしょうか。
でも、こっちはできればあんまりマニアックな方向にはしたくないと
思っています。初心者にはわかりやすく、でも使い込んでいくと奥深い・・・
みたいなメーラーを作れたらいいな。
アカウントの考え方は、あんまり考えてなかったんですが、
個人的な趣味だと、一つのInBoxに別々のアカウントのメールが
混在するような形の方が好きです。
60さんとは反対ってことになってしまいますね。
できればみなさんの意見も聞いてみたいのですが、どうでしょう?
保存形式は、上にも書いたとおり、色々混在できるものにしたいのですが、
デフォルトをどうするかは考え中です。
これもご意見もらえるとうれしいです。
125 :
1 :02/10/25 21:58 ID:HYPOMlgv
>>113 そのやり方、とても便利そうです。
フォルダのコンテクストメニューから設定画面を呼べると
いいですよね。
あと、実際にフィルタリングする前に、テストできる機能があると、
数が増えたときにわかりやすくなるかもしれないですね。
例えば、あるメールのコンテクストメニューで「振り分けテスト」
みたいなメニューを選ぶと、「このメールは、〜フォルダに移動します」
という感じに教えてもらえる、みたいな。
これで振り分け条件が正しく設定できているかどうかを
事前に判定できて、ちょっと楽になるかもしれないです。
またまた60で好き勝手の希望だけ言いますが、 フィルタリングをツリー構造にしてはどうでしょう? 丁度Mail.appのフィルタリングにツリー構造を取り入れたイメージなんですが、 それだと > 一つのInBoxに別々のアカウントのメールが > 混在するような形 でも、フィルタリングルールのルートに、アカウントによる振り分けをを置くことで、 その後のフィルタリングを独立させることが出来るので運用上問題なしになるし、 フィルタ管理もシンプルなりそうな気がします。
メニューバーのメールチェッカー楽しみでつ。
128 :
1 :02/10/25 22:28 ID:HYPOMlgv
>>126 それはすごく斬新なアイデアですね〜。
視覚的に、とてもわかりやすくなりそうだし、売りの一つになるかもです。
ただ、問題点は、例えばアカウントAとアカウントBの両方のメールで
共通して適用したいルールがあった場合に、同じルールを2つ
書く必要があることでしょうか。
これをクリアできるとさらにいいんですが・・・うーん。
129 :
名称未設定 :02/10/25 22:32 ID:T2a9K6Su
GyazMail 0.9.1 でたね。
130 :
名称未設定 :02/10/25 22:36 ID:7DTmT58/
Apple Mail互換ですよね?
131 :
1 :02/10/25 22:37 ID:HYPOMlgv
>>128 を、書いた後におもったんですけど、そもそも
別アカウントで同じルールを適用したいことなんて
ほとんどないような気がしてきました。
大丈夫ですね。60さん、すみません。
そーだすな。同じくCocoaで書かれたメーラーであるGyazMailと どう差別化を図っていくか?ってのも課題だすな。 別に意識しなくていいのかな?
133 :
名称未設定 :02/10/25 22:53 ID:7a1/DWz2
>>1 さん
GyazMail についてどう思われます。
134 :
126ではありませんが :02/10/25 22:55 ID:T35tTrIF
>1 各ルール毎に”適用するアカウント”を設定できるようにすればどうか… それじゃあツリー構造の意味ないのか…?
>>132 Cocoaで書かれたメーラーなんて、
これから増えてくからあえて意識しなくてもいいんでないかな。
136 :
1 :02/10/25 23:05 ID:HYPOMlgv
>>132 ,133
GyazMail、落として軽く触ってみたんですけど、
シンプルな感じでいいですね。
差別化って言う意味なら、
・フリーのオープンソース
・日本人が作る(予定)
って感じでしょうか。
まあ、既に形になっているGyazMailと、
まだ何一つ作っていないこちらで比べてしまうのはハズカシイんですが。
137 :
1 :02/10/25 23:09 ID:HYPOMlgv
あれ、GyazMailの作者さんってひょっとして日本人?
そうみたいですね。
139 :
1 :02/10/25 23:15 ID:HYPOMlgv
超恥ずかしいです。死のうかな。
作り上げるまでは死なせない!!
GyazMailはツールバーのアイコンはけっこういいのに、 リスト部分が妙にヘボいのはなぜでしょう? アイコンだけ誰かに作ってもらったのかな。。。 製品並にかっこよくしたいですね。
クラシックみたいに、とか言うとまたあれだけど リストの背景は無地よりも行ごとに薄く線が入ってた方が カコイイと思います。
143 :
1 :02/10/25 23:38 ID:HYPOMlgv
>>134 ああ、その手もありますね。。。
でも、60さんの言っているツリー構造って、多分
アカウントだけに限った話ではないと思うので、
それはそれでいいんじゃないでしょうか。
144 :
1 :02/10/25 23:51 ID:HYPOMlgv
>>140 微妙な引き留め方、ありがとう。
>>141 ,142
GyazMailのリストは、多分Cocoaで用意されているテーブルを
そのまま使っているんじゃないでしょうか。
こちらで作っても多分、あんな感じになると思います。
もちろん、テーブルを1から作れば、もっとかっこいいのもできると
思うのですが、時間とのかねあいですね。
145 :
1 :02/10/26 00:42 ID:tOcD2sRO
SourceForgeについて、ちょっと調べて来たのですが、
かなり便利そうですね。
Webページも持てるし、CVSも使えて、
しかもOSXでコンパイルができるみたい。
メーリングリストや掲示板も持てて、しかも無料とは・・・
開発はここでやることに決めたいと思います。
ところで、
>>106 さんが本家の方を薦めてくださったのですが、
ちょっと英語が苦手なもので、jpの方にさせてもらっていいでしょうか?
すみませんです。
146 :
1 :02/10/26 00:55 ID:tOcD2sRO
で、プロジェクトを新たに起こすためには、まず申請が必要らしいです。
それから数日間で承認されるかどうか判断される模様。
承認されないこともあるというのがやや気がかりですが。
この時に、プロジェクト名と、簡単な説明を書く必要が有るみたいです。
プロジェクト名は、できればアプリの名前にしておきたいので、
そろそろ名前を決めましょう。
今のところは、
>>63 さんがCocoaMailというのを上げてくれてますが、
他にも何かよさげな名前があれば、意見を出してもらえないでしょうか。
俺は、こういう点での自分のセンスには全く自信がないので、
みなさんの意見に勝手に期待しちゃってます。
ちなみに、思いついたのは「マカメール」・・・だめかなぁ
147 :
名称未設定 :02/10/26 01:02 ID:QeXlCU+R
新メーラーのコードネームは「ウフッ?。」に決定しました。
148 :
名称未設定 :02/10/26 01:08 ID:oM8PMrvq
149 :
1 :02/10/26 01:14 ID:tOcD2sRO
>>147 そろそろそのネタはいいです。
>>148 そんな夢でもみれたらいいな。そろそろ寝ます。おやすみなさい。
Cocoaだけに拘らず、必要ならCarbonやCoreFoundationも使うってことで、CMailはどう? アイコンにしぃを使えば2ちゃんっぽさも出るし。 問題は似た発音でshemaleって単語があることかなぁ。 と思ったら、sourceforge.jpには同じ名前のが既に登録されてた。
151 :
コードネーム :02/10/26 01:42 ID:WWEIvGWg
今はやりの 菊地桃子→Peach もしくは ココア≒ミロ→MILO
1. 軽さ命 2. Cocoaらしく美しくシンプルなインタフェース 3. 凍らない、落ちない(これが一番大変なんですけどね) ヘビーユーザーじゃないので 個人的にはこういうのが好みです 1さん期待してます ファイト!
メジャーな要望でないことは自覚してるんだけどひとつ。 Mail.appでのパスワードの管理は全部キーチェインでされてる。 だから、Macにログオンしたまま放置してても、キーチェインを ロックしておけばほかの人がMacを触ることによるサーバーの 不正使用が防げるよね。 ところがこの場合、これから新しいメールをサーバーから読むに はマスターパスワードが要求されるのに、Mail.appとかの普通 のメーラでは、既に取り込んであるメールはフリーパスで読めて しまう。ちょっとキーチェインの意味が減少するなぁ、という感じ。 要するに、パスワードを入れないとアプリ自体が立ち上がらな いんだけど、普段はキーチェインからパスワードをとってきて くれるので意識せずに使える、という機能があるといいな、って。 そんなわけで、できたらメールボックスは常に暗号化されてる 状態にできるとなおいいです。 うーん、特殊すぎる要望か。 しかも「軽さ命」には真っ向から反してる気がするw
あ、俺も「Peach」がいいなー。
↑1さんが「そろそろそのネタはいいです。」と言ってるじゃんYO
idea(イデア)。みんなのアイデアを集めて作るから。 とか言っておけば審査は通りやすくなりませんか?
「mail warrior」が鎧武者らしいので、 1000取り合戦の大将をアイコンにしていかがでしょう。 2chのスレッド風に届いたメールを羅列するモードを装備して、 メールが通算1000通になるとイースターエッグ起動、とか。
2ch臭のしないメーラーにしてほすぃ・・・
>>156 ideaちょっとカコイイかも。
参考までにメーラー名一覧
・ARENA
・Eudora
・Postino
・GyazMail
・Numera
・Mail
・Entourage
・Outlook Express
・Becky!
・AL-Mail
・Winbiff
・鶴亀メール
・EdMax
・Datula
・Mew
# 意外にシンプルな名前多いな。
>>151 "MILO"いいねえ。
昔そういう名前のファックスもあったし。
> ココア≒ミロ→MILO この発想には賛成しかねますが、語感は好いですな。 「mail」に近いスペルだったり、la Venus de Miloとか。 賛成しておきます。 MILO Milo milo 全部小文字の方が好いかな。
163 :
1 :02/10/26 11:39 ID:tOcD2sRO
おはようございます。 色々名前を出してもらってうれしいです。 俺もMILOはかなりイイと思うです。 短くて覚えやすいし、画面のデザインにもイメージを反映しやすそう。 あ、あと「そろそろいいです」といっておきながら、 Peachも何気に結構好きだったり(w 「桃子に気に入ってもらえる堅牢なメーラを作りました!」 といって宣伝できそう。 できたころには旬が過ぎているという諸刃の剣ですが。
164 :
1 :02/10/26 11:44 ID:tOcD2sRO
165 :
1 :02/10/26 12:06 ID:tOcD2sRO
>>150 ちょっと違うところに反応してしまいますが。
メニューバーでのチェック機能みたいな、やや特殊な機能は
Carbonの方がいいのかなあ。
Carbonのことはほとんど知らないんですが、
Cocoaは作るのが簡単なかわりに、特殊なことをやろうとすると融通が
効かないっていうイメージがあるので。
166 :
1 :02/10/26 12:12 ID:tOcD2sRO
>>153 個人的には、ぜひ、158さんのアイデアの方向で行きたいな。
暗号をかけておきたいフォルダと、それ以外を分けられた方が
便利なような気がします。
メニューバーといっても、Dockアイコンとメインメニューが 無いだけのただのアプリなんだから、特にCarbonに使う必要は無いんでは? 殆どはUIの絡まないロジックだけの部分だし、 通信をPantomimeに任せるならなおさらかと。
169 :
_ :02/10/26 18:18 ID:V7dd1Q8o
>>166 それって、前にあったフォルダごとの設定で、UI的にも
スリムにいきそう。
170 :
1 :02/10/26 19:43 ID:tOcD2sRO
>>167 すいません、なんとなく
>>95 さんの画像のイメージが
頭に残っていて、ああいうスキンみたいなものもCarbonなら
出来るのかな、と思って発言したのですが・・・
でも、よく考えたらメニューバーでのチェック機能で
スキンを変えるわけではないですよね。
あれは、単体のメールチェックアプリの話で。
すいません、ただの勘違いです。
171 :
1 :02/10/26 19:53 ID:tOcD2sRO
>>168 あ、ほんとですね。JavaMailなら比較的簡単に資料も手にはいるし、
やりやすくなりそうです。
>>169 フォルダ毎のフィルタ設定のあたりの話ですよね。
「情報を見る」で、フィルタの設定もメールボックスの種類も
設定できるようにする、と。
かなりOSXらしいメーラーになりそうですね。
172 :
名称未設定 :02/10/26 19:58 ID:vAHDX4Pt
>>159 同意。
つうか、メールを出すと、自分がどのメーラー使ってるのかって相手に分かっちゃうじゃん。
このメーラー=2ちゃんねらー御用達 ってイメージだと日常に使えないし。
そういえば、メーラー名の偽装機能とかって付けられるの?
例えばiCabだとブラウザ名(& OS)を偽装できるけど。
>>172 ホントに良いメーラーが出来れば、=2ちゃんねらーには
ならないと思う。
ただ、自由にヘッダをカスタマイズできると面白いかも。
フィルタリングとかに役に立ちそう。
174 :
1 :02/10/26 20:10 ID:tOcD2sRO
>>172 メーラー名の偽装は、ヘッダに情報埋め込めるようにすれば
いいだけなので、多分簡単に出来ると思います。
つけるかどうかは別として・・・
ただ、ここでアイデアを募集している以上、
どんな名前だろうとやっぱり「2ちゃん発メーラー」の
イメージはつきますよね。(もちろん完成すれば、の話ですが)
自分的にはそれほど2ちゃんにマイナスイメージもってないんですけど、
世間的には敬遠されるのかなあ。
送信フィルタも付けてほしいな。 自分にBcc送るはめんどくさいし無駄。
>>174 いや、単にモナーメールとか2げっとメールとかそういう名前が
いやだっていってるだけだと思うよ。
普通に使えるメーラーなら2chの枠を越えて使われるようになると踏んでます。 なんといっても無償だし。問題ないと思いますよ。 ただ、2chライクなメーラーにしてしまうとその可能性がなくなるかな・・・。 仕事場でも使いにくいし・・・。X-Mailer: のカスタマイズは面白いですねー!
178 :
1 :02/10/26 20:38 ID:tOcD2sRO
なるほどです。 たしかに、アイコンが2chのAAだとか、2chを全面に押し出した メーラーだと、職場ではちょっと恥ずかしいかもね。 ま、まずはいいメーラーを作るのが先ってことで。 ヘッダのカスタマイズは結構需要がおおいのかな。 自分的にはあまり考えたことがなかったので、 どういう使い方ができるのか教えてもらえるとうれしいです。
僕は単純にお遊び目的ですが・・・>ヘッダ
メーラーの名前は自分自身で決められると みんな満足すると思う。 つまり、配布時のファイル名は例えばbuildした 日付とかにしておいてダウンロードしたら自分で リネームするの。version管理もラクチン。 そんで、環境設定でX-mailerを設定できるように すればいいんじゃない? けっこう、メーラーの名前って愛着がわくから いいアイディアだと思うんですけど。
それは面白いですね。 後々プラグインやモジュールでカスタマイズ出来るなら 名前も決めずに個々でカスタマイズするってのもアリですね。 でも、とりあえず何と呼んだら良いのでしょう。 カスタムメール?
182 :
名称未設定 :02/10/26 21:12 ID:hn9xApxw
カスタムメールだとそれがメインの名前って感じ。 ただのメーラーでいいんじゃない? 配布するときはmailer030625.dmgとか。 名前決めない案は妙にコンセプチュアルで面白い。
183 :
1 :02/10/26 21:16 ID:tOcD2sRO
>>180 ,181
面白いですね〜。さらに
名前、アイコン、画面のビュー、その他のプラグインなんかを
一セットにして自由に入れ替えできるような仕組みが導入できれば面白そう。
もちろん、個々の組み合わせもできるようにして。
ただ、俺としてはやっぱりデフォルトの名前は決めといた方が
いいんじゃないかと思うんですよね。
初心者にもわかりやすく、っていう視点も欲しいので。
184 :
名称未設定 :02/10/26 21:22 ID:lSJApUO9
しかし、最初は骨組みだけみたいなもんで、 自分で機能追加してアピアランスも変えて名前も決めるとなると 相当に愛着の湧くメーラーになりそうだ。 プログラミング出来ない俺みたいな奴らにも 自分で作った気持ちにさせる事が出来れば、 それこそ最大の特長になりそう。 どれくらい難しいのか分からないから勝手な事言ってるけど 正直すごく楽しみだ。
186 :
1 :02/10/26 21:56 ID:tOcD2sRO
>>183 で、デフォルトの名前は決めた方がいいって書いてしまったんですが、
考え直してみると無名のメールっていう
コンセプトにとても魅力を感じます。。。
意図せず2chとリンクしているのもなんか面白い。
初心者向けには、1つのデフォルトをこさえてバンドルして配布すれば
すむ話なので、名前決めない方向で進めてみたいんですけど、
いかがでしょう、みなさん。
SourceForgeのプロジェクト名は「カスタムメールプロジェクト」
みたいな感じにしておいて。
カスタメール なんか変だな、いい名前ヨロ。
188 :
名称未設定 :02/10/26 22:27 ID:WWEIvGWg
Unnamed(無名)にちなんでUnmaildとか メールじゃないっていってるみたい…
189 :
1 :02/10/26 22:28 ID:tOcD2sRO
190 :
名称未設定 :02/10/26 22:30 ID:vAHDX4Pt
191 :
1 :02/10/26 22:31 ID:tOcD2sRO
anonymous mail projectとか? 英語的にいいのかは分からないけど
>>186 賛成です。そうなるとツールアイコンなんかも
なるべく個性の強くない物にした方がいいですね。
Unnamed Mailとか?
194 :
180 :02/10/26 22:52 ID:yJCTuHlv
メーラーの方向性が見えてきましたね。 こうやっていろいろ意見が出てくるのがまさに メーラーのカスタマイズ可能という特性にマッチ していると思います。 非常に有意義なプロジェクトだと思います。 ブレーンストーミングでみんなでどんどんアイ ディアを出していきたいですね。 1さんには是非とも完成させてもらいたいです。 応援しています。 また、いいアイディアがあれば書き込みたいと 思います。
名無しさんのメールか… 「名称未設定」と言うとマックっぽく且つ2ch臭。 実態としては最低限の骨格と、組み合わせ自由なプラグイン集って感じになるのかな?
196 :
1 :02/10/26 23:32 ID:tOcD2sRO
>>194 すばらしいアイデア、ありがとうございました。
「名前に2ch臭を入れたくない」って話から、こういう展開になるとは
全く思ってなかったです。
>>195 多分、そういう感じになるでしょうね。
「骨格」をどこまでととらえるか、技術的にどこまで可能なのかは
今後議論と検証で詰めていきましょう。
197 :
1 :02/10/27 01:00 ID:XwBfzhA8
今後の話ですが、徐々に方向性が定まりつつありますので、
そろそろメーラーの実現に向けて取り組みを始めたいと思ってます。
とりあえず、以前にあげた
>>119-121 に、
今回出た無名のメーラというコンセプトを加えたものを基本路線と
したいと思います。
もし、反対意見があったら遠慮無く書き込んでくださいね。
特に反対がなかったら、明日の夜くらいに
SourceForgeに申請したいと思ってます。
プロジェクト名は、「Unnamed Mail」にしてしまおうかと。
もっといいのがあればご意見ください。
必ずしもプロジェクト名=アプリ名ではないので、
あんまり悩まなくてもいいかな、とは思っていますが。
承認された後は、こっちのスレは一般ユーザの視点での話し合い、
SourceForgeのMLで技術的なことの話し合いという風に
分けて進めようかなと思っていますが、この辺の進め方についても
何かあればご意見ください。
そろそろ寝ます。おやすみなさい。
今は何もでけんが β版出れば、バグ報告くらいは協力したいな ガンガレ!!
また〜りがんばって下さい。
きっとアレだな 山のように要望が出て 開発が滞るとさくーしゃみたいに煽られるんだろうな。かわいそうに。
201 :
名無しさん@Emacs :02/10/27 18:59 ID:fXvfGBou
Winの優良メーラーBeckeyを意識しつつ、Mackeyでどうよ。
Mackeyだとモーホー&くすやることになってタイーホになるのがオチ
ワラ……えない。
204 :
:02/10/27 19:22 ID:hsgncuxg
ミッション・インポッシブルでトムクルーズが使ってたメーラー (あれは確かPB540Cだったかな?)がえらくかっこ良かった。 送信するとバックグラウンドに吸い込まれるような3Dムービーに なってたっけ。 シンプルで云々っていうのもよいが、めちゃめちゃCOOLなメーラー っていうのも欲しい気がする。
Swith考えているWin厨だが、Beckyをよく研究すればUIというか使い勝手がなんたるかっていうのがわかると思う。 アドレス帳は他のアプリケーションと共用できた方がPalm使いにはありがたい。
>>205 とりあえず・・・Beckyがどう良いか知っているユーザーはここにはあんまり居ないかも
207 :
名称未設定 :02/10/27 21:35 ID:gsOV0fPw
どうも、初めまして。 いまはARENAを使用しているものです。 Mailプロジェクト期待しています。 名前のことでちょっと思いついたので、「ゴンベー」なんてのは? おやじかましてすいません。
>>204 PB540cって...
根助けあたりだったりして(ソンナコトナイカ
>>207 ゴンベー・・・・言兵衛ですか?
名前は個人で付けるって話になったんじゃないの?
210 :
名称未設定 :02/10/27 21:47 ID:gsOV0fPw
名無しの・・・です、はい。
マウスだけでもキーボードだけでも十分操作できるようにしてもらいたいね。 特に読むときは。
212 :
1 :02/10/28 01:53 ID:iarfVGsT
213 :
1 :02/10/28 02:00 ID:iarfVGsT
>>201 ,205
俺も会社ではWin使ってますが、Beckeyは一度も使ったことが
ないんですよね。今使っている鶴亀メールで結構満足してしまっているので。
(シェア料金が高いというのもありますが)
でも、参考になりそうなら試用してみようかな。
アドレス帳は、OSX付属のAddressBookを使うつもりです。
palmのことはあんまり知らないんですけど、iSyncとかで同期できるのかな?
214 :
1 :02/10/28 02:08 ID:iarfVGsT
>>211 その気持ちはすごくよく分かります。
俺も、マウスならずーとマウスだけ、
キーボードならずーとキーボードだけって感じで使いたいんですよね。
行ったり来たりするのはとても面倒で。
あ、あと左手キーボードショートカット、右手マウスっていう使い方も
良くするな。Macユーザはむしろこっちの方が多いのかな?
このへんよく考えて操作性を練りたいですね。
ユーザビリティがあがると思う。
215 :
1 :02/10/28 02:18 ID:iarfVGsT
で、今日はSourceForgeにプロジェクト登録しようかと思ってたんですが、 帰りが遅くなってしまって面倒なので、また明日にしたいと思ってます。 プロジェクト名なんですけど、 「ゴンベー」は・・・やめておきましょっか(w
>>214 ARENAみたいにキーボードショートカットがカスタマイズできると
うれしいかも。
217 :
1 :02/10/28 02:35 ID:iarfVGsT
>>216 ARENAのキーカスタマイズは、結構良いですね。
ほとんどすべてのコマンドを設定出来るのではないかな?
キーカスタマイズするときに不便なのは、コマンドが多いと
どのキーが使用済みなのか把握しづらくなることですね。
何かうまい方法はないかなー。
リモートメールは標準で搭載予定ですか?
>>216 キーボードパレット(もどき)と、機能一覧表示して、Interface Builder みたいに、
ドラッグで繋げていくとか。。。そこだけでカナーリ面倒くさくなりそうだけどね。
単純に、キーボードパレット(もどき)を設定ウインドウ内に表示して、
使用済みキーはグレーアウトさせるとかでも、かなりいいかも。
メールのアドレス入力で、ニックネームをつかって入力できるシステムが欲しい。 (mewとかBeckyがわかりやすいかな)
FinderのようにDrag&Dropでフォルダ間の移動やゴミ箱への移動ができたらいいなぁといってみる
222 :
1 :02/10/28 22:53 ID:iarfVGsT
こんにちは。 ついさっき、SourceForgeにプロジェクトの登録をしてきました。 プロジェクト名は、結局「Unnamed Mail」にしておきました。 申請が下りたらまた連絡しますね。
223 :
1 :02/10/28 23:00 ID:iarfVGsT
>>218 リモートメールはなんとなく、メールチェッカーの方に組み込むと
よさげなのではないかと思っているんですけど、どうでしょう。
224 :
1 :02/10/28 23:10 ID:iarfVGsT
>>219 なるほど、グレーアウトするのは非常にわかりやすくていいですね。
KeyCapsみたいなパレットをつけて。
グレーアウトしたキーが、それぞれどのコマンドに
使われているのかすぐ分かるようなインターフェースにするとさらに
よいかも。具体的なイメージはわいてないんですが・・・
225 :
1 :02/10/28 23:24 ID:iarfVGsT
>>220 ニックネームっていうと、メールアドレスの短縮系みたいのを書いて
おいてアドレス欄でTabキーで補完したりするやつって考えていいのかな?
そういう入力支援機能って、アドレスだけに限らず、メール本文の
定型句とかでも使えるように出来るといいかもしれせんね。
226 :
1 :02/10/28 23:27 ID:iarfVGsT
>>221 はい、それはやりたいと思っていました。
Drag&Dropはそこだけじゃなくて、いろんなところでうまく使えるように
したいですね。
227 :
1 :02/10/29 00:20 ID:S0AhttDO
ふとみたら、SourceForgeのプロジェクト、承認されてました・・・ はやすぎ。ほんとに審査してんのかなあ。
228 :
1 :02/10/29 00:41 ID:S0AhttDO
えーと、プロジェクトのページはこちらになります。
https://sourceforge.jp/projects/undmail 開発に参加したい方は、SourceForge.jpにユーザ登録した上で、
上のプロジェクトのページへ移動し、footashida(1のことです)宛に
メールをください。
プロジェクトページの右上の、「プロジェクト管理者」下の名前のリンクを
押せば、Web上からメールを出せます。気軽にご参加ください。
といっても、まだ何にも準備できてないのですが。。。
メールチェッカーの段階でリモートメールは良いと思います。 ただ、本体にリモートがなく、さらに「受信したメールをサーバに残す」 に設定しておいた時ですが、一度受信したメールを捨てて、 再度受信したい時などはどうなるんでしょう? メールチェッカーの段階で受信したいメールを選択し、 それを本体に渡すって感じですか?
>>225 そんなところです。がんばってください。
231 :
1 :02/10/29 01:08 ID:S0AhttDO
>>229 そうですね、メールチェッカーの方でやるなら、そんな感じにならざるを得ないですね・・・
それってやっぱり不便でしょうか?
実は、個人的にリモートメールの機能はあんまり使わないので、
その辺の判断がつきません。ご意見いただけるとうれしいです。
>>1 メールチェッカーから選択受信出来れば、一応問題ないんじゃないでしょうか?
ちなみに、リモートメールの役割って大きく分けて2種あると思います。
1:「不要なメールを受信しない」
不要なメールを削除してから普通に受信する人と、
必要なメールだけ選んで受信する人がいると思います。自分は後者。
重いファイルが添付されているメールなんかを後回しにして、
急ぎのメールだけ先に受信する事などもあります。
2:「バックアップ」
大事なメールを一応残しておくって感じですかね。
HDが逝った時や、間違えて消した時に備えてと言うのが普通だと思いますが、
自分は一度仕事で大揉めしてサーバから消した事を後悔した経験があるので、
仕事のメールは一段落つくまで連絡の証拠としてとっておいてます。
サーバから消えてしまうと、受信済みのメールだけでは
裁判の時などに証拠能力が低くなるので・・・。
cocoaの利点としてローカライズが楽な事があると思うんです。 まあ、このソフトはもちろん日本語なんだけど、 どうせならば英語のリソースも作って、 海外の人たちにも使ってもらえるような物にしたら面白いかなと思います。 この板にも結構英語が出来る人はいるだろうし、 ローカライズスレもあるから作業を委託すれば結構簡単に出来るんじゃないかな。
>>1 とりあえず、インターフェイスのラフでも描いてみたらどうだ?
漏れは
>>1 の思案しているインターフェイスに激しく興味がある。
>>1 >>234 もかなりきになるが
参考までに、今まで提案されてきた機能がそれぞれ
基本的に装備されているのかプラグインで拡張するのか
とどのように考えてくれてるのかしりたいです。
236 :
1 :02/10/29 22:35 ID:S0AhttDO
>>232 詳しい説明ありがとうございました。
なんとなく、リモートメールの用途って削除だけかと思っていたので、
とても参考になります。
ただ、お話を聞いた感じだと、かなり頻繁使う機能のようなので、
メールチェッカーにつけるか、本体につけるかは、
もう少しじっくり考えてみたいと思います。
237 :
1 :02/10/29 22:40 ID:S0AhttDO
>>233 海外の人にも使ってもらえたらうれしいですね〜。
俺は英語全然だめなので、完全におまかせになっちゃうんですが、
アプリが出来てきたら一度お願いしてみましょうか。
238 :
1 :02/10/29 22:46 ID:S0AhttDO
>>234 そうですね。そろそろGUI設計に入ってもいいと思うので、
ざっくりと描いてみます。今後は、それに対して意見をいってもらったり、
付け加えていったりしながら進めるとやりやすいかな?
>>235 ちょっと今、要望のリストをまとめてみてます。量が多いので、
あとでSourceForgeのWebページにでもアップします。
239 :
名称未設定 :02/10/29 23:38 ID:kt6Dxe/i
ドラッグアンドドロップで、 メールアカウント/環境設定/メールBOX内のメールがフォルダ階層を保ったまま、 バックアップ可能だとうれしい。しかも高速に。
240 :
1 :02/10/30 01:06 ID:LhLkcfV3
>>239 それは、Finderにドラッグアンドドロップしてバックアップという
ことでしょうか?
環境設定までそれでバックアップがとれれば、確かにかなり便利ですね。
バックアップを高速にするために、
ファイルの数が少なくなるような保存方式にしておくと
いいかもしれませんね。
是非ともvMessageに対応して欲しいです。 対応メーラーを探したのですが見当たらなくて…
242 :
名称未設定 :02/10/30 02:47 ID:Ze771B5b
>>242 なるほど・・・1つの方がコンパクトでいいと思ってたけどそういう障害もありますね・・・。
244 :
194 :02/10/30 03:59 ID:FzPWjYa4
>>242 ,243
ファイルが更新されるときに毎回バックアップを作れば
よいのではないでしょうか。
例:メールファイルが inbox.mbx でバックアップ inbox.mbx~
これなら壊れても多少被害は少なくなると思います。
オプションでサーバーに日数(3日くらい)で保存しとけばほとんど
被害はないでしょう。
私はメールボックスに対して一つのファイルの方が好きなので・・・
ちなみにEudoraユーザー
無茶を言わせてもらえば、 メールボックスの保存方法も切り替え(あるいはプラグインでの差し替え)を 可能にすれば問題はない。
246 :
1 :02/10/30 21:08 ID:LhLkcfV3
>>241 すみません、vMessageというのを初めて聞きました。
Googleで検索してみて、メールメッセージの形式らしいことは
わかったのですが、どのあたりで使われているものなのでしょうか。
よかったら教えてください。
247 :
1 :02/10/30 21:18 ID:LhLkcfV3
メールの保存形式やバックアップについても、
>>120 で書いた
フォルダ毎の保存形式の変更機能を利用して、別々に指定出来るように
するとよさげですかね。
例えば、重要なメールが入っているようなフォルダは、
安全性の高い1メール1ファイル形式にして、なおかつ別ディスクに
自動ミラーリングできるようにしておいたり、
なくなっても別にいいようなフォルダ(メーリングリストのとか)は、
効率のいい1ファイル形式にしておいたり・・・
といった風に。メールボックスの保存方法も、プラグイン化できるように
しておけば、種類はいくらでも増やせていいかも。
248 :
241 :02/10/31 01:32 ID:S5jf0qUk
こんばんわ。 自分はJ-SH51っていう携帯使ってるんですけど これにはSDカードスロットが付いてて SDカードに送受信メールのバックアップができるんです。 で、それがvMessageになっているんです。 vMessage形式でmac内のメールをでイン/アウトポート出きたら 携帯とmacが同じメールが入ってる事になるんで便利かなと。 ってこんなの俺だけですね。
250 :
248 :02/10/31 19:13 ID:c1e2B02n
Elueonさんありがとうございます 俺仕組みとかは全然分からなくて…
251 :
1 :02/10/31 22:47 ID:zc02lgqx
>>248 ,249
情報ありがとうございます。
vMessage=メールデータのファイルフォーマット
IrMC=上を転送するためのプロトコル
って感じでしょうかね。
vMessageの仕様はまだ読んでませんが、決まったフォーマットの
メールを読み書きするのはそんなに難しくないと思います。
ただ、プロトコルの方はプラグインなり、全く別ソフトで
やってもらうっていう方針の方がいいかなー。
ただ、248さんのケースって、
SDカード(これもよく知らないんですが・・・)をMacにつなげば、
FinderでvMessage形式のファイルが読み書きできるのでしょうか。
もしそうなら、プロトコルの実装は必要ないので楽に対応できそうですね。
あー、言うの忘れてましたが、SourceForge.jpの方に登録したメンバーのElueonです。
どうか、能無しコテうざいとか言わないで下さい。
>>250 漏れもプログラミングできないから、仕組みも詳しくは知らない。
だけど、検索するぐらいならできる。
>>250 自身も何かできることを探そう!
例えば、vMessageファイルをmiなどのテキストエディッタで開いて、タグの形式を考えてみたり。
まぁ今は、vMessageサポートする以前の問題だから、まだ置いといてもいいけどね。
>>all
メーラって何pixel*pixelぐらいの広さで使う?
(実は、GUIのラフを描いていたけれど、縦長過ぎて……)
253 :
1 :02/10/31 23:30 ID:zc02lgqx
>>252 こんにちは。
SourceForgeの方ではお世話になります。
GUIのラフを描いてくれていたんですね。とても助かります。
自分も描くって言っておきながらぜんぜん進んでないので・・・
ちなみに、1はメーラの広さはpixelっていうよりも下の条件で
勝手に決まります。
・メール一覧の、Subject, From,Dateがおおむね隠れず見えること
・メールを見るところで、横スクロールバーがあらわれないこと
・3ペインなら、左のフォルダツリーのフォルダ名が、隠れず見えること。
>>252 自分が使っているメーラーのサイズはどうやって測るの?
簡単にhoge pixel X hoge pixel ってはかれるヤツきぼん
257 :
1 :02/11/02 01:43 ID:4nQ5ftYP
258 :
名称未設定 :02/11/02 01:51 ID:lLwNlznH
ヤフオクのアラートに対応してくれ。 Jaguarのmailじゃ駄目になってもた。
259 :
1 :02/11/02 02:05 ID:4nQ5ftYP
>>256 ありがとうございます。
これはやっぱり押さえとかないといけないんだろうな・・・
ちょっとずつ勉強していきましょうか。
Nameraというメーラ使っているんですが、 15分おき毎に新着メールチェックする設定にしてると ちょうどその時に別の作業が重くなるんですね。 そういうことがないような設計だと嬉しぃっすわ。 あとメールの保存形式は1メール1ファイル? それとも複数メールで1ファイルなん?
261 :
1 :02/11/02 02:12 ID:4nQ5ftYP
>>258 ヤフオクのアラートって普通のメールではないのでしょうか。
Mail.appだとダメになったということは、最近何か仕様の変更があったとか?
よろしければ教えてください。
262 :
1 :02/11/02 02:31 ID:4nQ5ftYP
>>260 なるほどです。メールチェックでリソースを食い過ぎているのかな。
Nameraのプログラムがどうなっているかは知りようがないので、
原因は分からないんですけど、注意します。
どなたかCocoaを使った並行プログラミングで
パフォーマンスに影響が出る要因など、情報があれば、
教えてもらえるとうれしいです。
保存形式は、今のところはどっちも混在できるようにしよう、
という方向で考えています。
パフォーマンスに影響が出るかも知れないので、実現できるかは
分からないのですが。
263 :
名称未設定 :02/11/02 02:44 ID:PqTt/3c2
今だOS 9ユーザーですが、Cocoaメーラー楽しみにしています。
こういうプロジェクト見ていると、ああ、Cocoa勉強しよっかなとか
夢見てしまう私は丸っきりプログラム初心者なので、お手伝いしたくとも
デバッグくらいしかできないのが歯がゆいですが。
気になったことをひとつ。
ttp://undmail.sourceforge.jp/ で、ディレクトリ丸見えです(^^;)
見られて困るものでなくても、index.html置いた方がよいのでは…?
来訪者の安心感も見栄えもUP! と思いますた。
結構、なにかあるかも、と上位ディレクトリって見るんですよね。
(え、私だけ!?)
老婆心ながら……。
265 :
1 :02/11/02 22:05 ID:4nQ5ftYP
>>263 さんのソフトを使って、俺も計ってみました。
ディスプレイは1152×768、
ARENAの2ペインの画面で、700×700くらいでした。
結構占拠してますね。参考になるでしょうか>Elueonさん
ふと思ったんだけど、OSXってGUI部品一つ一つが割と大きめに
作られているから、どうしても画面が狭くなりがちですよね。
メール読みながら、何か他のソフトで作業することを想定して、
小さいスペースの中で、効率よく情報を切り替えられるような画面構成を
考えられるといいのかも。
具体的にどんなのかはイメージ沸かないんですが。
266 :
1 :02/11/02 22:27 ID:4nQ5ftYP
>>264 指摘ありがとうございました。ほんとに丸見えでしたね・・・
というわけで、急遽index.htmlを作りました。
まだ何にも書いてないですが(w
>>263 ,265
なるほど。正方から横長ですね。
ドロワー、意外にスペースとりますね……。
>>263 のトコのMouLocXで僕も計ってみました。
終点でのロックができないのに少し苦笑しつつ、フィードバックしなきゃと思いますた。
で、それはさておき。Mail.appでだいたい縦800*横600ぐらいですね。環境はSXGA。
ドロワー含めてだいたい800*800ぐらいですかね。
理想のマージンとしては、右側に48*48pixelのアイコンと右側ラベルを利用したアイコン列の一列分、
下側には、アイコン32*32pixelのDockと1個のアイコンぐらいは欲しいですね。
ところで、相手に送ったメールがちゃんと読まれたかどうか、ソフト側で確認できればいいんですがね。
昔、8.1時代にそんなソフトがあったような気がしたんですが。(本当は8.5時代の人間ですが。)
素人的な発想では、メールのヘッダに何らかの文字列に加えておいて、
メーラがそのヘッダの文字列を確認、そして送られたメールが既読状態になると、
自動的に返信し(もちろんバックグラウンドで作業。ユーザに意識させない。)、相手に伝える、と。
(本当は、返信せずにSMTPとかの命令でいければいいんですがね。
一応少しSMTPの資料を見ましたが、ちんぷんかんぷんでした。)
##最近、思い付いた(腐った)インターフェイスネタ##
アンダードロワーで添付ファイルを表示。
そのファイルについてのコメント(.txt添付)が書ける。
さらに手書きサイン機能つき!(.jpg添付)
……とりあえず漏れ氏ね(w
まぁ、サイン機能は後々重要になること請け合い(本当かよ?)。
くだらん長文ゴメソ。
>>267 開封確認については、「メール 開封確認」で検索すれば、いろいろ資料がみつかり
ますが、同時にその問題点についてもいっぱい見つかりますね。
仕様としては存在していても、ほとんど使っているひとがいない機能、個人的には
実装はしていてもいいけど、優先度はかなり低いかなと思います。
>>267 メーリングリストなんかに使われたらたまりませんな。<開封確認機能
とりあえずどんなソフト作成するのでもいいのですが必ずRFCには準拠してください。
RFC違反な物は存在自体が邪魔です。
また変な処理を入れないというのも基本です。
たとえばARENAやEudoraはiso-2022-jpで受信した物をわざわざSJISに変換するという
変な事しますがこれはだめです。
とにかく単純に純粋に実装される事が基本だと思いますです。
>>267 なぜ受信確認がRFCなどに規定されないかという事です。規定されない物には
問題があるという場合がほとんどです。
実装はすべきではないです。どうせばかにされます。
UIはかなり大変ですよ、、Mac系にはうるさい人が多いので。
がんばってくださいね。
271 :
_ :02/11/03 06:58 ID:H66LQFBL
アイデアリストに、Perlコマンドやshellコマンドでフィルタをかける ってのが入っていないみたいです。
272 :
_ :02/11/03 06:59 ID:H66LQFBL
IBで組むとき、全部smallがいいなぁ。
273 :
1 :02/11/03 10:28 ID:V1gJkVJx
おはようございます。 開封確認については、皆さんも言われているとおり、 俺もやめておいた方がいいんじゃないかなー、と思います。 昔MLに投げてこっぴどく叩かれている人をみたので・・・ 送信系は、余計なものを送ってしまうと相手に怒られるので、 逆にそういうのをうっかりやってしまうのを防ぐような機能を 盛り込んでいった方がいいですね。 Macでしか読めない文字が入っていたらチェックするとか。
要望ばかりで申し訳ないのですが, 自分でキーバインドを設定できるようにして欲しいです. 本文エリアと受信したメールのリストとか, その辺もマウスなしで行き来できるような感じで. カスタマイズにCtrlキーを使えるとすごく嬉しいです. といいますか,早い話がvimが大好きなので, あんな感じのキーバインドで使いたいんです. ペイン間の移動を^W+h/j/k/lにしたり,^Fで1ページスクロールとか デフォルトにしてくれとは云いませんが,自分で設定できるとありがたいなぁ. unixな人の取り込みという面でも効果あるのではないかと思います.
275 :
1 :02/11/03 10:41 ID:V1gJkVJx
>>271 すみません、もれていました。追加しておきました。
一応、プラグインで対応、っていう方向で考えたいと
思っているんですけど、どうでしょう?
>>272 すみません、「全部small」というのがどういうものなのか知らないので、
教えて頂けないでしょうか。
あ、IBってInterface Builderですよね?
276 :
1 :02/11/03 10:53 ID:V1gJkVJx
>>274 はい、キーバインド設定は
>>216 あたりでも出てますが、
是非とも盛り込みたいですね。
俺も実はvi系の操作は結構好きで、メールの上下移動はJ,Kに割り当ててたりします。
ボタンの大きさって26×22ぐらいあれば充分じゃないですかね。 アイコン32×32&ボタン36×36だと少し大きいかな・・・。 PhotoShopなんかのツールバーのボタンは大体20×20くらいですよね。
278 :
1 :02/11/03 21:59 ID:V1gJkVJx
どもこんにちは。
お待たせしましたが、以前言われていたGUIのラフをアップしてみました。
http://undmail.sourceforge.jp/1_gui.html 皆様の辛口のご意見お待ちしております。
言いたい放題言ってくださった方がうれしいので。
あ、ただこれは、ウィンドウの構成とかボタンの配置とかを決める
目的なので、見た目がダサい、とかは無しで・・・
Elueonさんもいま描いているところだと思いますが、
できたら教えてください。ホームページの方にアップしますので。
いろんな案を出して、いいところを組み合わせて行きたいと思ってます。
他の皆さんも、もしアイデアがあればGUIのラフを
描いてもらえるとウレシイです。
279 :
1 :02/11/03 22:08 ID:V1gJkVJx
>>277 個人的には大きめのボタンの方が押しやすくて好きなのですが、
今計ってみたら32×32はいらないかもしれないですね。
ボタンを小さめにすると、画面上に情報を多く表示することができるかな。
大きさを設定で変えられるようにしてもいいですね。
280 :
:02/11/03 22:13 ID:N31M68JE
匿名にしてな。あとヘッダーをxxxで埋め尽くしたり。
>>1 あの人型のデザインは残してくれ。まぶしい程に素敵だ。
282 :
1 :02/11/03 22:55 ID:V1gJkVJx
>>281 かんべんしてください。はずかしいでつ・・・
GUI第一案に対しての感想と要望 3ペイン構成は一般的で、親しんでる人も多いだろうから 賛成ですが、Mail.appみたいに本文ウインドウを閉じるこ とができて、その場合はメール選択しても開封したことに はならないようにしてほしい。 あ、メール本文はメール ダブルクリックで別ウインドウに開くということです。 人形デザインは僕も好き、あの人形をもう一つ横にずらして重ねた アイコンをアドレスブック呼び出し用ボタンにすれば 一人>個人>自分のアカウント設定、環境設定 二人>人々>他人のメールアカウント>アドレスブック というように連想しやすいし、いいんじゃないでしょうか。
284 :
名称未設定 :02/11/03 23:34 ID:i9p98dox
プレビューウインドウってメール一覧の横に 配置出来た方が良くないでしょうか?
285 :
名称未設定 :02/11/03 23:42 ID:oiL/DfC3
あの人型は、UMLを設計に使ってる人には、なじみがあって良いのでは?
ツールバーはよくある上に一列に並んでるのがいいんじゃないかな。 このイメージだとカスタマイズするときの配置に困るし。
>>285 スティックマン!
しかし1はUML知っていてやってるのかい?
もちろんデザバタも知ってるのだよね、、
288 :
名称未設定 :02/11/03 23:51 ID:HU8NF8RZ
感想です。 六つのアイコンが並ぶツールバーの位置は決定ですか? 上部に横にならぶ形(普通おれたちが見慣れているかたちですが)が なぜ一般的なのかというと、それが1番使いやすいからなのでは? などと思いました。 ユーザーインターフェイスの問題はとても難しくて、どれが1番とは 言えないと思いますが、これがCocoaアプリであり、MacOSで動く メーラーだということを考えると、やはりmail.appに準拠するような ものが望ましいような気がします。 けれど、これもおれ個人の考えなので、みなさんの意見も聞きたいですね。 すげー期待してます! こういう感想を書くことくらいしか出来ませんが(汗)
>>278 GUIのラフにInterfaceBuilder使わないんですか?
UIのガイドラインに沿うのであれば、6個のボタンはNSToolBarにするべきだと思う。
環境設定も標準の別パネルで用意するべきではないかと。
例えばフィルタを設定する時にメールの内容を参考にしたいときとか不便では?
290 :
1 :02/11/03 23:57 ID:V1gJkVJx
>>283 >賛成ですが、Mail.appみたいに本文ウインドウを閉じるこ
>とができて、その場合はメール選択しても開封したことに
>はならないようにしてほしい。 あ、メール本文はメール
それはいいですね。設計のページにそのことも書きたしたいと思います。
そういえば、アドレスブックの呼び出しは漏れてました。
そんな感じで、またちょっと書き足してみます。
>>284 一覧の横にメールですか。そっちの方が見やすいでしょうか。
ちょっと、そういう絵も描いてみます。
291 :
1 :02/11/04 00:04 ID:jVNwHUKD
>>286 ,288,289
やっぱツールバーは上の方が良いですかね・・・
実はそこら辺非常に迷いました。左上に配置したのは、
ツリービューを取り外した時に、ツールバーをそちらに
つけたかったという理由です。
ツールバーをフローティングにしたいっていう要望もたしかあったので。
ちなみに、これは案の一つなので、全然決定事項じゃないです。
へんなところがあれば、びしばし指摘してください。
292 :
1 :02/11/04 00:08 ID:jVNwHUKD
>>285 ,287
実はスティックマンそのものです・・・
あのアイコンはUMLからパクリました。
ラフだから適当でいいかな、と思って・・・
ちなみに、フォルダのアイコンはUMLのパッケージです。
293 :
1 :02/11/04 00:23 ID:jVNwHUKD
>>289 はい、最初はInterfaceBuilderを使ってやろうと思ってたんですが、
パレットにNSToolBarが無かったので、
コードで書かなければならないのがちょっと面倒かな、と。
もちろん、有る程度固まったら実物の画面でもう一度確認してもらいたいと
思っています。
ちなみにあの絵はOmniGraffleで描いてます。
環境設定については、完璧に個人的な趣味でああいう風にしたのですが、
やっぱり標準に準拠しなければ混乱するかな。
ただ、フィルタの設定に関しては、
>>113 のようにすることで
クリアできるのではないかと思ってます。
フォルダビュー(?)の配置はWINのエクスプローラの影響か左側には位置されることが多いが (MACでもiTunesとかマカー用とか多くのソフトがそうだが…) (自分は)右利き&ゴミ箱やファイルの配置が画面の右側なのでフォルダビュー(?)を右側にしてほしいです。 できればスライドバーで左右選べるとか…
296 :
295 :02/11/04 01:04 ID:trHKVzo6
>フォルダビュー(?) ツリービューでした ツリービューじゃなくって2列表示のカラムビューっていうのもいいかも
あの6個のボタンはNSToolbarじゃ作れませんぜ、開発リーダー。
298 :
_ :02/11/04 01:20 ID:/jKGhuen
なんか他のメーラーと代わり映えしないが。 いいのか?まぁプラグインで拡張するから、 いいのか。。
299 :
1 :02/11/04 01:24 ID:jVNwHUKD
>>294 はい、実は画面構成案の、「カスタムビューモード」というのが、
MagellanやアントラージュのViewに相当するような機能のつもりでした。
>>295 なるほど。そういえばMail.appも右ですね。
これは選べるようにした方が良さそうですね。
300 :
1 :02/11/04 01:32 ID:jVNwHUKD
>>296 カラム表示っていう案はかなり最初のころに出して頂いていて、
面白いと思うのですが、画面構成考えていると、
どこら辺で使えば効果的なのか、なかなか思いつかなかったんですよね。。。
カラム表示をうまく使った画面構成案など、ないでしょうか?
>>297 そ、そうなんですか?NSToolbarは最近勉強しはじめたばかりで
あまり知らないので・・・
一列でしか並べられないのかな。
まあ、どのみちあの6個のツールバーは評判悪いので多分やめます。
301 :
1 :02/11/04 01:43 ID:jVNwHUKD
>>298 痛いところをつかれましたね。もうちょっと練り直そうかな。
ただ、あんまり変わったものにすると使いにくくなりそうで・・・
302 :
名称未設定 :02/11/04 02:02 ID:toihPrrb
>>295 賛成。
洩れも右利きなので、フォルダが並ぶデフォルトは右側のほうがいいと思う。
もちろん左利きの人もいるわけなので、選択可能が一番。
>>299 Mail.appはDrawerだから左右どっちにもできる。
受信箱(10/100)とかは未読のみでもいいような。
取得済みが増えると邪魔になりそうだから。
これも選択制か。
304 :
名称未設定 :02/11/04 02:38 ID:6H9NbU7R
>1 こう考えてはどうでしょう。 凄く個性的で、オリジナリティあふれるメーラーなんて、 あまりみんな必要としてないと思うんです。 それよりも、奇をてらわないシンプルで使いやすいものを ほとんどの人は望んでると思います。 個性的で、立ち上げた瞬間に新しい世界にいけるメーラーよりも、 はじめて立ち上げた瞬間、「何これ?Mail.appまんまじゃん。」と 思われた方がむしろいいと思います。 それはCocoaアプリらしさでもあるし、誰でも即使えるということだし。 でも、しばらく使ってみるとMail.appには無いあんなことや こんなこと、こんなレイアウトなどのプラスアルファがカスタマイズ 可能なんだというのがわかってくる、ぐらいの感じが良いと思います。 新奇さを狙うなら、デフォルトのスキンを銀肌にしてやればいいんじゃ ないでしょうか。機能には影響せずに、個性を演出できます。 Mail.appを自分でメタリック化してない人には、見た目で掴めるんじゃないかな。
305 :
名称未設定 :02/11/04 02:43 ID:uFTKq/c2
うんうん。 いろいろ選択出来るってのが売りな気がするね。 使っている人それぞれで見た目もずい分変わってくるわけで、 Unnamed Mailの名前にふさわしいかも。 それだけでも他のメーラーとは随分違うと思うよー!
306 :
254 :02/11/04 03:08 ID:Jqt+YfuJ
307 :
名称未設定 :02/11/04 03:21 ID:sMnf6zev
GyazMail 0.9.3公開。最近小刻みにバージョンアップしてるね。 1.0になってシェアウエア化なのかな。
308 :
名称未設定 :02/11/04 03:23 ID:isHeCXou
AOLメールは使えるようにできないかな? .Macでmac.comをやめてAOLにしたんだけど、 ネスケ以外で使えないから非常に不便。ネスケが 死ぬほど重いから使い物にならん
309 :
名称未設定 :02/11/04 04:04 ID:aNwgY3Fk
将来的にGUIをカスタマイズできるようにするのであれば
デフォルトのGUIは個性のないもの,徹底的にAqua準拠でいいと思います。
>>304 の言うようにMail.appそのまんまでいいのではないでしょうか。
>>308 AOLメールは仕様が公開されてないので無理かも。
というわけで
>>308 は解析して
>>1 にフィードバックするように。
ちなみに Claris Emailer (クラリスメールの元版) はAOLに対応してた。
311 :
名称未設定 :02/11/04 05:14 ID:+PEaPJhB
AOLメールプラグイン。 Hotmailプラグイン。 .Macメールプラグイン。 ...ってか。
がいしゅつだったら無視してください。 スペースキー一発で時間的に一番古い新着メールに飛べて、そのままスペースキーで 次々と新着メールを読み進められたらうれしいです。 あと、個人的にX-Faceに対応してくれたら泣いて喜びます。 一番期待していたNameraの開発が滞っちゃっててGyazMailもそれほど期待していた ほどじゃなさそうだし、もうメーラ難民の漏れとしてはこれに激しく期待してます。
313 :
1 :02/11/04 11:46 ID:jVNwHUKD
おはようございます。
色々ご意見ありがとうございました。
>>304 ,305,309さんのおっしゃる通りだと思います。
ユーザーを無視して特殊なメーラー作っても誰も使わないし、
そもそも、もともとのコンセプトが、「自分好みのメーラーを作れる」なのに
奇抜なインターフェース作ってもしょうがないですよね。
ちょっと難しく考えすぎていたようです。
というわけで、Mail.appライクなシンプルなインターフェースで、
もう一度考え直してみます。
314 :
1 :02/11/04 11:53 ID:jVNwHUKD
>>303 さっきはじめて気がつきましたが、Mail.appって
画面上の位置によってドロワーの開かれる場所が左右変わるんですね。
これは確かにいいかも。
未読/全体の表示も選択できた方が良さそうですね。
315 :
1 :02/11/04 12:00 ID:jVNwHUKD
>>308 ,309
AOLメールはWebメールも使えるので、
HTMLの中身を解析すればHTTPクライアントとして振る舞うことで、
メーラーに取り込めるんじゃないかと妄想したことがあります・・・
308さん、よろしくお願いします(w
316 :
1 :02/11/04 12:03 ID:jVNwHUKD
>>312 新着メールだけ拾って読む機能は便利そうですね。ぜひ盛り込みたいです。
ところでX-Faceってなんでしょうか?
317 :
284 :02/11/04 13:16 ID:3DpJcumx
>>1 Mail.appと殆ど見た目が変わらなくても良いと思います。
そこから使いやすい様にカスタマイズ出来れば尚オッケーですが(^^;)
.Macプラグインは是非とも実装おねがいします。
ガンバです!
>>314 =1
ドロワーってアプリを立ち上げた時に一寸遅く表示されるので
実はあまり好きではないです(^^;;
起動時にスッキリ一発で立ち上がるのが個人的には良いな〜と。
あとソフトの重さとかメモリの量とかに関係あるのかもしれないけど、
ドロワー表示の時にカクカクしてしまうことも・・・。
ペインの配置換えとかで回避できないものでしょうか。
重くなるんなら我慢するしかないけれど。
Mail.appのドロワーは、メールを掴んで左右にドラッグしてみると 好きな方に出せる、ウインドウを画面端によせなくてもO.K.よ〜。
ドロワーに関しては318=314に賛成です。 出し入れする必要性ってあまり無いものね。
321 :
名称未設定 :02/11/04 16:40 ID:ulmS+rAz
何故、Mail.appではダメなのか。Mail.appの何が不満なのか。 それをダメ出ししていけば、理想のメーラーができると思います。 「これさえできれば、Mail.appで満足なんだけど...」 というマニアックな欲望を、いくつか満たしてくれれば、 その人にとっての最高のメーラーになると思う。 僕もドロワーは、最近あまり好きじゃなくなってきました。 理由1 アニメーションのせいで、起動が少し遅く感じられる。 理由2 表示/非表示の時も、やはり一歩出遅れる感じがする。 理由3 表示の幅、大きさを調整できない。3ペインならできる。 よって、あえてドロワーを使わずに3ペイン形式にいく方がシンプルだと 感じます。それだけでもMail.appと差別化できますよね。 Cocoaらしさってことだと、使った方がいいんでしょうが... ドロワーとペイン表示と、両方選べるってのは大変な作業なんでしょうか。
322 :
名称未設定 :02/11/04 16:54 ID:ulmS+rAz
それと、Mail.appのツールバーは、文字だけ表示にすると小さすぎて ボタンとしては使いにくいと思います。通常表示だと、どうも空間を無駄に している気がしてしょうがない。 「ツールバーをカスタマイズ」で、アイコン無し文字表示にするときは、 ある程度の大きさのフォントとボタンであって欲しい。 個人的には、Eudoraのボタン表示や、 マカー用。の板ボタンのようなツールバーがベストだと感じます。 長方形のボタンがすきまなくぎっしり並べられていて、 中にボタン名と小さなアイコンがある形です。 この形の方が、Cocoa標準のツールバーの形よりも、 表示領域を上手に節約していて使いやすいと感じるのです。 どうでしょうか?一度、マカー用。エレメンツを立ち上げて見てください。 僕個人の意見ですので、他の人の意見も聞かなくちゃいけませんが。
323 :
名称未設定 :02/11/04 17:02 ID:1lRvGT0G
俺もドロワーはあんまり好きじゃないな
理由はほとんど
>>321 と同じ
あんまし速いマシン使ってないからなんだけど
あとMail.appは受信したときに索引(検索用?)を作るみたいで
メールボックスに表示するのが一瞬遅れるんだよね
これは受信量が多いときに、ちょっとストレスになる
終了時にまとめて作成とかにしてくれればいいのにと思う
欲しい機能のナンバーワンは、やっぱりカスタムビューだな
ルール作って自動振り分けしてるもんで、
いちいちメールボックスを移動するのが面倒
324 :
名称未設定 :02/11/04 17:14 ID:QhhQ1Dtj
ドロワーの部分はNameraみたいな感じで、ログ表示する部分ってのはどうですかね? 見なくてもいいって人は閉めたままにしておけるし。
気付いたら、かなり進んでるな…。
あー、どうしよう。なんか焦ってきた。
>>1 ラフみますた。アイコンが素敵(w
あぁ、そういう手もアリかな、と関心しました。
ドロワーで、ツリービューボタンを配置することはできそうですね。
Nameraがドロワー内にボタン置いてるんで。
X-Faceって確か、顔写真みたいなのが表示されるやつでしたっけ?
326 :
そういえば :02/11/04 17:27 ID:bsZuWqFR
mail.appってもうアップデートしてないの? おれver.1.1なんだけど...。
>>311 hotmil(http)はあるといいかも。
自分は使ってないけど、周りではhotmailが使えないばかりに
泣く泣くoutlookの人間が結構いるし
出張や海外行く機会が多くて、.Macに入ってない人には
hotmailが一番便利だから手放せないらしい
アイコンは大小選べたほうが良いと思う
このまえ高解像度のモニタにジャガー入れたときに
メニューバーのごつさや128x128のFinderアイコンの意味が分かった
OS 9だとちっこすぎて蟻みたいになってたもんな
おれは、ボタンよりもMail.appのようなツールバーアイコンがいいなぁ。 アイコンのみの表示にしているので、それほど場所とらないしね。 ボタンが良ければ、ボタンアイコンでというのではダメなの? ボタンアイコンに名前も入れておけばどう?で、アイコンのみの表示。 あ、それだと「すきまなくぎっしり」とはいかないのか。 むずかしいねー。 索引を作る間のもたつき Mail.appの1番嫌なところは、これだったりします(笑) あの間ってすごく嫌な感じだよね。 1さん、そのあたりどのように考えてましたか? 文字がじょじょに消えていくようなギミックもいらないですね。
329 :
名称未設定 :02/11/04 18:06 ID:N1CxB1Uh
よくわかんないけど、開発初期としては 「地味で低機能だがとーにーかーく軽い!」とか 「特に軽いとは言えないがカスタマイズ性が高い!」とか 「検索だけは超強力!」とか、 「検索も遅いがコレコレこういう素晴らしい機能がある!」とか、 「Mail.appそっくりで、ココとココが違うだけ!」とか、 なんにせよ親分の独断ではっきり方針を絞った方がいいのでは。 最終的には 「これといって特徴はないがすべてのカユイところに手が届く!」 という線を目指すにしても。
330 :
名称未設定 :02/11/04 18:20 ID:C30uWpp+
「地味で低機能だがとーにーかーく軽い!」 のをベースとして作って、機能の拡張はプラグインで対処ってのが嬉しいけどね。
331 :
名称未設定 :02/11/04 18:26 ID:ulmS+rAz
カスタマイズの自由度をどこまで追求するのかっていうこともありますよね。
>>1 さんが決めて下さい。
僕的にはMail.appをベースに、欲しかったあれとこれとこれを足してくれて、
この部分のUIを変更できるっていう選択肢があるってだけで、
十分画期的だと思うんだけど。
とにかく軽い!ってのを追求するなら、 例えば索引の作成を受信した直後ではなく、しばらくたってからバックグラウンドで ユーザーに気づかれないうちにやってくれるとか。 ユーザーのアクションに対してできるだけ待たせないっていう 気遣いをすればいいんだよね。
333 :
>1さんが決めて下さい。 :02/11/04 18:34 ID:N1CxB1Uh
それだ! 「すべての人を裏切らない」ってのは無理がある。
>>333 むしろ、全ての人が裏切られた!と言うようなメーラーをですな。
じゃあ、POP非対応。
336 :
:02/11/04 20:43 ID:1HhAp2yD
>335ガ━━(゚Д゚;)━━ソ!
337 :
名称未設定 :02/11/04 20:44 ID:n1Se3Jn2
NSToolBarはやはりよくできていますよ。私もメーラーを造るときボタン でやってみようかと思ったのですけど、カスタマイズもしたいな、とか 考えているうちにすなおにNSToolBarを使うこにしました。 カラム表示については悩むところです。フィルタをカラムで表現しようか とも思ったのですけど、よくよく考えていくとNSTableViewを並べたほうが いいのかな、、と思ったりして。 検索機能はどうしますか?索引を自分で造るとなると大変そうだし。。。
338 :
1 :02/11/04 21:40 ID:jVNwHUKD
こんにちは。たくさんご意見ありがとうございます。 まず、開発方針を絞って欲しい、という話ですが、 Unnamed Mailというプロジェクトにした以上、カスタマイズ性を 高くすることを第一目的にします。 多分、ユーザーからみれば軽いものの方が喜ばれるだろうとは思うのですが、 これから作るメーラーの一番の売りなので。 ちなみに、これは開発の都合でもあるんですよね。 というのも、最初からパフォーマンスを上げることを念頭において、 開発すると、コードが汚くなりがちなので、 あとからカスタマイズ性を上げるような構造に変えようと思っても 難しくなってしまう気がするんですよね。 だから、最初にプラグイン可能とか、変更可能なGUIを出来るような 構成を作っておいて、後でパフォーマンスチューニング、っていう やり方のほうが良いのではないかと。
339 :
1 :02/11/04 21:50 ID:jVNwHUKD
それから、ドロワー対3ペインですが、これはできたら カスタマイズ性を上げる、という方針に従って、どっちも選べるような 方向で考えたいですね。 ウィンドウ構成のテンプレートを何種類か用意しておいて、 どのペインに何を表示させるか、ユーザーが選べるようにするとか。 プログラミングできれば、テンプレート自体も開発できるようにするとか。 まあ、そこまでやるのは難しいかもしれないので、その時は 個人的な好みで3ペインがいいかな・・・
340 :
1 :02/11/04 22:03 ID:jVNwHUKD
あと、ツールバー対ボタンについてですが、
これは難しいですね。。。
多分、CocoaのNSToolbarを使わない方が自由度は高いような気が
するのですが、カスタマイズから表示方法まで面倒見てくれる
NSToolbarは捨てがたいです。
>>337 さんのように、素直にNSToolbarを使う方向で行こうかなー。
341 :
1 :02/11/04 22:18 ID:jVNwHUKD
ちなみに、索引とかのことは全く考えてなかったです。 申し訳ないのですが、知識も無いです。 検索もそうなんですが、カスタムビューを使い物にするためには 必須ですよね、多分。詳しい方募集ということで・・・
>>340 ボタンタイプは作るのが面倒なんですよね?
ならば、当座はNSToolbarでしのいで、暇になったら、リファクタリングしつつ、
ボタンでも使えるようなラッパークラスを作ってみては?
それか、初めからNSToolbarをラップするのもアリかも。
開発初期からNSToolbarとラッパークラスの面倒を見ないと逝けないけど、
ラッパーのインターフェイスが良く出来ていれば、
あとは他人に任せっきりに出来るかも。
343 :
312 :02/11/04 22:53 ID:K+lg6kH8
344 :
1 :02/11/04 23:50 ID:jVNwHUKD
>>331 カスタマイズの自由度は個々の仕様になってしまうので、
一言では言いにくいです。
ただ、あまりに自由度が高すぎても誰がこんなものカスタマイズするんだ、
って話になりかねないので、バランスを見ながら必要な範囲だけ
カスタマイズ可能にするのが良いかと。
少なくとも、画面の見た目に関しては、当初は
・アイコンモジュール
・3ペインか、2ペイン+ドロワーか、選べる。
・ツリービューが左右どちらか選べる。
くらいあれば充分ですかね。
もちろん、細かい部分はもっとあるでしょうが。
345 :
1 :02/11/05 00:02 ID:QAYNMki+
>>342 うーん、NSToolbarのラッパークラスですか・・・
ちょっとイメージがうまくわかないです。
教えて頂けないでしょうか?
>>343 なるほど・・・
こういうのはやっぱりプラグインでやるのがいいのかなー。
「一部の数奇者」って書いてあるし。
346 :
1 :02/11/05 00:12 ID:QAYNMki+
>>325 のElueonさん。
いや、焦らないでもぜんぜん大丈夫だと思います・・・
とりあえず、皆さんにもらった意見をもとに、また練り直しましょう。
1さん、お願いがあります。 添付ファイルをメール内に残すか残さないか、 選べるようにしてホスィ……。 この機能がないから、Mail.appが使えないです。
348 :
342 :02/11/05 02:05 ID:l/qbU2Ya
>>345 ごめんなさい、嘘でした。別の物と勘違いしてました。
逝ってきます。激しくゴメソ。
349 :
312 :02/11/05 09:00 ID:l13OJxsG
>>345 = 1
そうそう、プラグインのかたちでいいと思います。
ある程度完成して、安定して、そして余裕があったらつけてもらえればいいです。>X-Face
350 :
289 :02/11/05 16:41 ID:SsNJ3zLD
>> 345 ラッパー書くよりもactionを定義すればいいだけじゃないかな? 例えば新規メッセージボタンならば、newMessage:というactionを定義して NSMenuItemやNSToolbarItem、NSButtonにsetAction:すればいいだけだし。 だから最初はtargetのclass(Controllerクラス)とactionを設計したほうがいいんでは? んでそれも含めてInterfaceBuilderを利用した方がいいんじゃないかと。 あとカスタマイズについても同様で、Drawerでもウィンドウ内のペインでも結局は NSViewを設定すればいいだけだと思うので、そのViewを扱うためのインターフェースを最初に定義するのが良いかと思う。
会社のWinにBeckey!入れてて、まぁ社内は別アプリなんで あんま使ってなかったんだけど。Pluginも入れてないし。 で、今日使ってみた。 返信窓が上下2分割になるのね。で元メールが上に表示される。 これは便利だわい!と思いマスタ。元メールをとりあえずでも 全引用する人はいらんでしょうけど、そうでない人には便利。 Macでは見たことないなと思って。(あったらスンマセン) ガイシュツですが人気のあるだけあって、設定項目も細かくて良いなと。
>>351 > 上下二分割
そのあたりの動作はおそらくEmacs系メイルソフトが最初やとおもわれ。
初期のgnusからそういう動作可能だったはず。
wanderlustの動作とかがシンプルでよい。
あすこまでシンプル化するとすでにすごすぎるが、、
353 :
名称未設定 :02/11/05 22:45 ID:s298HWiQ
>>352 ははぁ。見てきました。
ガイシュツのX-faceってのもあのへんなんですね。
354 :
1 :02/11/05 23:05 ID:QAYNMki+
こんにちは。
>>347 添付ファイルをどこかに保存した後、メールの中の
ファイルを自動的に削除するかどうか環境設定で選べるようにする、
ってことでしょうか?
それとも添付ファイルを手動で削除できるようにするということかな。
>>348 いや、全然気にしないでください・・・
>>349 はい、了解しました。ちょこっと仕様を見た感じだと、そんなに
難しくなさそうですね。
355 :
1 :02/11/05 23:06 ID:QAYNMki+
>>350 ご意見ありがとうございました。進め方については常に不安を抱いているので、
こういうご意見頂けるとすごく助かります。
おっしゃるとおり、InterfaceBuilder使った方がよさそうですね・・・
GUIが割と標準的なものに落ち着きそうなので、そっちの方が100倍くらい
早いような気がしてきました。多少プログラムも交えて、
動く画面つくれば、意見も出やすいと思うし。
ただ、actionの設計に関しては、まだ少し早くはないでしょうか?
IBで画面設計(軽く動くもの)> メニューの仕様決定 > action設計
という流れでやっていくといいかな、と思ったのですが、どうでしょう。
それと並行して、画面のカスタマイズや、NSToolbar、NSButtonのあたりの
技術調査を、軽くプロトなんか作りながら進めていけると良いかなー、
なんて今ちょと思いました。
356 :
1 :02/11/05 23:26 ID:QAYNMki+
>>351 Beckeyは、1も最近会社で試してみてます。
上下2分割の画面は便利ですよね。他にも箱形選択ができたり、
クリップボード履歴がついてたりと、かなり強力でした。
正直、あのレベルまで持ってくのは、エディター1つ作るのと同じくらいの
労力がかかりそうですね・・・
誰か並行してCocoaでオープンソースのエディター作ってくれませんか?
などと半ば本気で言ってみたり(w
>>356 BeckyはDanaっていうかなり高機能なテキストエディタの根幹部分を内包してる。
Danaの原形が最初にあってそののちにBeckyが作成されている。
どうやら完全にコンポーネント化されているように見える。
このあたりはデザインセンスなのかもれいないですが、デザインパターンの完
全なる利用って感じです。
# おそらく作者は最初はデザインパターンしらなかったと思われるが、、
# センスなのかな、、
昨今言われるデザインパターンって、新しいパラダイムでは全然無く、 これまでの既存手法の「まとめ」みたいな物だす。なもんで「デザイン パターンを知っている」必要は無いっすね。 と、あさっての方向につっこんてみるテスト
そうそう、メーラーといえばエディター部分が肝だよねぇ。 すっかり忘れてたな。 ルーラー表示、桁折、禁則……必須機能をあげたらキリがないな。 どこかのテキストエディター作者と協力して作業というのが現実的かなぁ。
/Developer/Examples/Carbon/SimpleText/ に純正品が、まるまるある訳だが、Crabonではだめか
?/Developer/Examples/AppKit/TextEdit
363 :
名称未設定 :02/11/06 11:36 ID:Mguc7P+1
>>1 様
すみません、要望です。
キーチェーンには対応して欲しいです。
IMAP サーバに対応していただけると助かります。
UI は、Mail.app 似の標準インタフェースの他に、カスタマイズ用としてスキン機能などは無理ですか?
まだ先の話かもしれませんが、様々な機能を Plugin 形式でそろえるのでしたら、例えば Photoshop の Plugins フォルダの様に目的別に入れるところを分けていただけると判りやすくて助かります。
364 :
1 :02/11/07 20:37 ID:7MxJgnFp
どうもこんにちは。
エディタについての情報、いろいろとありがとうございました。
俺が会社で使っている鶴亀メールもそうなんですが、
専用のエディタから作ったメーラは、やっぱり強いですよね。
既存のエディタの作者さんと協力してやるっていう手も無くはないんですが、
ちょっとかけあう勇気がないっす。
「メーラー作りたいんでコードください」、ってなんか怒られそう・・・
>>361 のTextEditのソースを参考に独自に作るのがやっぱりいいのかな。
>>362 昔Cocoaスレで読んで試したことがありました。
いろいろ面白いアイデアが盛り込まれていていい感じだな、と思ってました。
ただ、今後拡張の予定はないって書いてあったけど、
今はもう開発は続いてないのかなー。
365 :
1 :02/11/07 20:48 ID:7MxJgnFp
>>363 キーチェーンはできれば対応したいと思っています。
IMAPは
>>164 のPantomimeを使えば割と簡単にできそうな気がするので、
標準で装備しようかな、などと目論んでます。
スキンはちょっと難しいかもしれません。
最初はCocoaで用意されている出来合のウィンドウを使って
作るつもりなので・・・
366 :
1 :02/11/07 20:52 ID:7MxJgnFp
ちなみに、今はInterface Builderを使って画面の叩き台を作っています。 近いうちにアップしますので、 そのときまたご意見ください。
368 :
1 :02/11/07 22:14 ID:7MxJgnFp
情報ありがとうございます。こんなものがあるのですね。 ただ、ページをざっくり見てみたのですが、 バージョン2.0の説明で、「Carbonをサポート」みたいな記述があるので、 Cocoaを使ったアプリから利用できるかどうかは ちょっとわからないです。。。
WASTEなんて捨て捨て。
371 :
1 :02/11/08 08:07 ID:yOeC45LE
>>370 テキスト処理については、ある程度Cocoaフレームワークが
面倒見てくれるようなので、フルスクラッチといっても
それほどたくさんコーディングしなければならない訳ではないと
思っています。
Wasteのページをちょっと読んでみたのですが、備えている機能は
(書式設定、Undo、Drag & Drop、国際化など)
だいたいCocoaに既にあるような気がします。
なんか面白そうなことやってるなー(w
>>371 >テキスト処理については、ある程度Cocoaフレームワークが
>面倒見てくれるようなので、フルスクラッチといっても
>それほどたくさんコーディングしなければならない訳ではないと
>思っています。
どの程度の機能がいる?
ちなみにInterface Builderからドラッグした時点でMail.appと同等
程度の機能がある。
縦書きはたしか、現時点ではサポートされていなかったと思う(いらない
だろうけど)。
373 :
289 :02/11/08 18:31 ID:dsH+kknA
>>364 >ただ、今後拡張の予定はないって書いてあったけど、
>今はもう開発は続いてないのかなー。
続いてないっす。
開発を続行するならフルスクラッチになるなぁ。設計失敗したりしたので。
でもPerlとかでフィルタをかけるとかのアイデアがあがってたので、
NSTaskを利用した部分は参考になるかもしれない。でもそこでNSThreadを使ったのは失敗だった。
TextHandlingSystemでもロックのバグがあったと思う。10.2で結構修正されたんじゃないかな?
Java感覚でThreadを使いまくるとロックとかで大変になると思われます。
それを考えるとMail.appはThread使いまくっても安定してるのでよく出来てる、と感じる。
テキストの処理はCocoa標準のもので十分だと思う。
個人的にはNSTextViewとかNSTextStorageの部分よりundo, redoとかdrag&dropのほうが大変だと思う。
とくにテキスト編集に自動整形とかの特殊な機能をつけるとundoなんか大変。
374 :
1 :02/11/09 06:47 ID:XmjZ6cgh
おはようございます。今日は休みだからがんばります。
>>372 なるほど、デフォルトでも案外いけそうなんですね。
今日びのメーラーが普通に備えているエディタ機能っていうと、
引用形式コピー/貼り付け、引用行色分け、桁折り、自動整形、
機種依存文字チェック・・・
ぐらいあればいいかな。
個人的には、タブ/空白文字の表示なんかも欲しいところ。
うっかり変なところでタブ入れると、送った先で表示がぐちゃぐちゃに
なっていることあり。
そう考えていくと、スクラッチでも結構いけそうな気もしてきました。
375 :
1 :02/11/09 07:25 ID:XmjZ6cgh
あれ、
>>373 =289さんは、ひょっとしてCocoaEditorJの作者さんですか?
非常にこころ強いです。
経験をもとにいろいろご意見いただけるとうれしいです。
ついでに、できたらエディタの方もまた続行してもらえると・・・
並行プログラミングはやっぱり必須ですよね・・・
受信しながらメールの読み書きなんて、普通だもんなー。
Javaはその点ラクチンですよね。
話はずれますが、Perlでフィルタの機能を入れるとすると、
メールボックス形式の混在っていう機能がネックになるような気がしてます。
これをやってしまうと、メールの保存形式が一つに決まらないので、
保存形式毎に異なるフィルタの実装方式が必要になってしまうんじゃ
ないかと思うんですよね。
Perlで〜、に限らず、検索、フィルタ機能をプラグインなんかで
強化できるようにするならば、どうしてもこれが
ネックになってしまうのかな、と。どっちかはあきらめねばならないかも。
376 :
289 :02/11/09 18:26 ID:yR+gwKkh
>>375 引用符とかはNSTextStorageをいじくり、自動整形はNSTextViewのdelegateを実装すれば良いのでは。
タブとか空白文字の表示なんかはNSLayoutManagerで設定すればいいと思うんだけど、いまいちよくわからないんだよなー。
だれか分かる人いませんか?
並列プログラミングに関しては基本的に、
UIの更新とか、イベントハンドリングに関わる部分はNSTimerを使い、
それ以外の内部の処理とかはNSThreadでイケると思う。
”とりあえず別スレッドでreleaseされるからオーナーじゃないけどretainしておこう”とかやるとたぶんハマる。
>話はずれますが、Perlでフィルタの機能を入れるとすると、
>メールボックス形式の混在っていう機能がネックになるような気がしてます。
よくわからんのだけど、クラス図にあったMailクラスを取得してそれをシリアライズして他のプラグインやプロセスに渡せばいいのでは?変換のオーバヘッドを懸念してる?)
377 :
1 :02/11/09 20:28 ID:XmjZ6cgh
>>376 ありがとうございます。参考になります。
そうそう実は、スレッドを使った時のメモリ管理がイマイチまだ
よく分かっていなくて、どういう問題に気を付けなければならないのか、
把握し切れてないんです。
有るオブジェクトをretainしようとした直前で
別スレッドがreleaseしてしまうケースとかは気を付けないと
いけないんだろうな、というのは分かるんですが。
Objective-Cの世界では、並行プログラミングのパターン
みたいなのってあるんでしょうか。Javaだと書籍が結構でてますが。
あと、フィルタ機能についてはおっしゃる通りで、
変換のオーバーヘッドを気にしていました。
脳内設計では、検索やフィルタリングは、MailBoxに
findMailWithSearchCondition:みたいなメソッドを定義しておいて、
個々のMailBoxの実現クラスで保存方式に最適化した検索方法を
実装するのがいいかと思ってました。
あ、ところで今、プロトタイプ作成はSourceForgeの参加者の方に
完全にお任せしているので、あのクラス構成は全然違うものに
なるかもしれないです。
>タブとか空白文字の表示なんかはNSLayoutManagerで設定すればいい メソッドはあるが、いまのとこ効かない。 >並列プログラミング NSNotificationQueueでNSPostWhenIdleという手ももあるよ。
379 :
378 :02/11/09 22:41 ID:eysm8cuS
ごめん
>>378 は
>>376 へのレスね。
>>377 >スレッドを使った時のメモリ管理
他(?)の並行プログラミングと同様、同期をとる必要がある。
NSLockingファミリーを使う。
あとはDistributed Objectでの通信かな。
380 :
289 :02/11/09 23:04 ID:yR+gwKkh
>>377 オーバーヘッドとかそんなに気にしない方がいいのでは。
結局、変換することになると思うけど。エディタに設定したり、テキストファイルで書き出したり。
>>378 > メソッドはあるが、いまのとこ効かない。
やはり。
ありがとうございます。
Disributed Objectはメールチェッカーとかで使えるかな?
並列プログラミングに関しては結構選択肢があるなあ。
381 :
1 :02/11/10 00:10 ID:TKa1uarK
>>379 なるほどです。並行プログラミングについてはJavaのことしか
知らないので、NSLockみたいな明示的なロックで、メモリ管理を
考慮しながら、どういうタイミングでロックをかけるのがいいのか、
あまり想像がつかないんですよね。
何らかのポリシーというか、ルールを決めてやらないと
容易に破綻しそうなことは想像がつくのですが。
この辺は具体的なプログラムでやるときにまた話し合った方が
わかりやすいかもしれないですね。
>>380 うーん、メールの数が数千件になった時のことを考えると、
検索やフィルタについてはそれなにりオーバーヘッドのことも
気にした方が良いのではないでしょうか。
もちろん、試してみないことには分からない部分もありますが・・・
しみじみと良いスレだね。 おいら、OS9ユーザーだけど、ここ見ていると そろそろOS Xに移行しても良いかなって思ってしまうよ。
GUIの話はもう終了してる? 1さんの言うようにプラグインでカスタマイズ可能なら 議論する必要もなさそうだけど、iTunesっぽいUIとかどうよ? プレイリストのところをカスタムビューのリストにして ライブラリのブラウズした時のアーティスト、アルバム、曲を それぞれメールボックスとフォルダのツリービュー、メールのタイトル一覧、本文 とかにしたら使いやすそうじゃない? カスタムビュー機能が便利っぽいから使いやすい位置にあって欲しいし。 んでツールボタン類はやっぱしiTunesっぽく四隅に配置して 上の情報が流れてくるペインには送信日時とかの情報を表示すると。 iTuneって使いやすいし、プラグインにするにしても こんな表示形式の対応を考えてもらえたら嬉しいです。
>>383 iTunesと同様のUIってのはいいかもねぇ。iTunesなら大抵の人が使うはずなので、
違和感をあまり感じないかも。
ただ、iTunesのUIまんまだと視点を上下左右すべてに移動しないと
把握しづらいから疲れるかもね。
人間の視点の移動としては、左→右、上→下が一番楽なので、
下→上 (iTunes右下のオプションボタン→曲名表示エリア、Windowsのスタートメニューなど)
なんかはしんどくなる。
# iTunesのオプションボタンは優先度が低いからあそこにあるのかな、たぶん。
だから、iTunesと同様のUIにするとしても、ツールバーなんかは
上にあった方が多分良いと思われ。
385 :
383 :02/11/10 17:41 ID:FTCD2p+F
>>384 なるほど。
iTunesそのままのUIをなるべくいかしたいけど
用途が全然違うから全く同じってわけにはいかないか。。。
でもやっぱ曲名表示エリアは進行状況表示なんかにして残して欲しいな(w
ってかiTunesってCocoaじゃないよね?
それをCocoaで再現するってのは可能なもんなのでしょうか?
386 :
378 :02/11/10 22:30 ID:lsBxftfE
>>385 >それをCocoaで再現するってのは可能なもんなのでしょうか?
ウィンドウは標準のままでできる(Mac OS X 10.2以上)
他のもつくるのは不可能ではない(がんばれば)
387 :
1 :02/11/11 00:19 ID:RJEhhKF+
iTunesと同じようなUIっていうのは面白そうですね。 カスタムビューって、考え方は iTunesのスマートプレイリストみたいなものだから、割と すんなり受け入れられそうな気がする。 ただ、メーラーとしてはかなり特殊なインターフェースなので、 デフォルトじゃなくて、プラグインとか、オプションみたいな扱いに するのがいいかもしれませんね。 ちなみに、今はGUIの叩き台をInterface Builder で作っている最中で、 それはGyazMailみたいな普通の3ペインな構成になっています。 今のところは、それをデフォルトにしておきたいな、と思っています。
388 :
383 :02/11/11 07:57 ID:m8KI4lP2
>>1 ぜひぜひ実現させて欲しいです!
がんがって下さい!
UI の話が出て来たので、要望を一つお願いします。 このメーラは「名無し」ですよね? ならば、初回起動時などに「名付けの儀式」をお願いします。 「名付けの儀式(実はセットアップアシスタント)」で、名前を付けないと、初回起動出来ないの(それくらい愛情を持って使ってほしい...とか)。 ...って駄目っすか?
>>389 激しくいいアイディアだと思う.
面白いねぇ.あんまりクサいのは嫌だけど、このくらいの遊び心はほしいなぁ.
>>389 セットアップアシスタントってすっごい嫌いなんだけど、
名付けの儀式はおもしろいねぇ。
「遊び心がないMacはMacじゃない」と言い切る人もいるぐらいだし、良いかも。
リストボックスやボタンの配置とかもskinでカスタマイズ可能なら あんまりUIの議論もしなくてもいいような気もするけど。 使う人が、お好みにカスタマイズすれば良いんだし。 命名儀式のウィザードは、面白いね。
393 :
392 :02/11/11 20:02 ID:fwfEFwBD
ついでにもう一つ。 エディタ部分ダケド、テンポラリーファイルを作っておいて既存のエディタソフトに 引き渡すようなプラグインもあるといいかも、とか思いました。 現状でも皆さんJedit4とか色々好みのエディタを、それなりにカスタマイズして使ってると 思うんだけど、多分その人にとっては、それが一番使いやすいと思うんだよね。
394 :
1 :02/11/11 20:18 ID:RJEhhKF+
命名儀式、面白いと思います。 なんだか育てゲーみたいですね。 たぶん、セットアップアシスタントとかを作るのは、 だいぶ先の話になると思いますが、その時は 誰かに面白い文章と絵を考えて欲しいなー。 などとさりげなく期待してみたり。
395 :
1 :02/11/11 20:24 ID:RJEhhKF+
>>392 すみません、ちょっとスキンは対応するのが
厳しいんじゃないかと思ってます。
画面のカスタマイズに関しては、最初にいくつかの
画面構成のひな形を用意しておいて、
それを選択できる、くらいのレベルで考えています。
UIに関しては、画面のレイアウトだけじゃなくって、
メニューや、操作方法の設計も含まれているので、
まだまだ決めなければならないことがたくさんあります。
ある意味Postpetみたいだなw 命名儀式って。 そこまでいかなくとも、軽い遊び心はなんかくすぐられるものがあるよ。
397 :
1 :02/11/11 20:31 ID:RJEhhKF+
>>393 なるほど、それはいいですね。
プラグインじゃなくて、基本機能として備えていても
良さそうな気がします。
命名儀式面白すぎ! でもその場合、X-Mailerもその名前になっちゃうのかな? できればX-MaillerだけはUnnamed Mail(Unnamed Mailer?)って出るように してほしいです。
399 :
1 :02/11/11 21:07 ID:RJEhhKF+
>>398 メーラーの名前は日本語で付けられた方がいいけど、
X-Mailerは日本語だとまずい(ですよね、多分・・・)ので
この2つは別々の方がいいかな、と思います。
400げと
401 :
1 :02/11/12 01:37 ID:veEMpzcC
だいぶ下がったのであげ。
まだ全然途中なのですが、設計中の画面を公開します。
ダウンロードページを作ったので、落として実行してみてください。
(アプリケーション形式になってます)
http://undmail.sourceforge.jp/guiproto.html 一応、ソースコードも以下にあります。
画面を表示するだけなので、読んでもあんまり意味はないですが。
http://sourceforge.jp/cvs/?group_id=297 はじめは一通り完成してから、意見を聞こうかと思っていたのですが、
結構地味な作業なので、一人でやっていたら気が滅入ってきました・・・
できれば、皆さんの意見を聞きながら進めていきたいと思っているので、
よかったらなんでもご意見ください。
今はメインメニューの項目についてご意見もらえると特にうれしいです。
ちなみに、アイコンはGNUMail.appのものを勝手に使ってしまいました。
402 :
1 :02/11/12 01:37 ID:veEMpzcC
401の続き 今のところ作りかけのものは、以下の4つです。 ・メーラーの基本画面 ・メールの作成画面(Command + N) ・検索条件指定画面 (Command + Shift + F) ・メインメニュー 以下は逆に、全く手を付けていないもの。 ・環境設定画面 ・フォルダ毎の設定画面 ・コンテクストメニュー ・その他いろいろ(気がついたら教えてください。)
403 :
1 :02/11/12 01:44 ID:veEMpzcC
書き忘れましたが、ソースコードは、「guiproto」というプロジェクトに 入っています。
404 :
名称未設定 :02/11/12 01:48 ID:25ZG9VMP
イイ! ちょっと気になったのはポストかな。 懐かしきニッポン風でとてもいいんだけど、 あれは「受信」ではなく「送信」というイメージなんだよねー。
ポストは>404に同意かなぁ。 でも、いい感じで(・∀・)イイヨ!
>>1 乙です。
良く見慣れている感じで違和感ないですね。
希望としてはスクロールバーが細くできると嬉しいっす。
あとメニューに「文字コード」に関する記述がなかったので、
どうなるんだろうと思いました。たまにユニコードメールも
来たりするので...
とすると、ログの文字コードは統一するのかどうかも気になったりと。
メール一覧表示のところは未読オプション(?)しかないけど、
他に考えがあったりするのでしょうか。
(ラベルもあるし、無くても一向に構わないですが(^^;;)
メールの作成画面を見る限りではメールヘッダのカスタマイズは
1メール毎には出来ないようですね。アカウントの設定で一括指定に
なるのかな...
まぁ、つらつらと。。。
遅くまでホント乙彼です。
407 :
1 :02/11/12 02:19 ID:veEMpzcC
>>404 ,405
ありがとうございます。
ただ、アイコンは
>>401 にも書きましたが、GNUMail.appという
別のアプリケーションのものを借りただけでして・・・(汗
一通り必要なアイコンの種類が明らかになったら、
募集したいと思っています。
>>1 表示のメニューに各ペインの表示非表示の項目があるけれど、
実際使うかな。iBookとか画面で制限される人向けなのかな。
あと、新規にフォルダーを追加するメニューがないです。
メールの管理に関わるところだと思うんですが、
アカウントAから受信したメールと、アカウントBからのそれが
同じフォルダに共存できるような仕様だと嬉しいですね。
例えばメーリングリストというフォルダを作って、
その下でAとBでのメールの整理も可能という具合に。
409 :
1 :02/11/12 02:37 ID:veEMpzcC
>>406 たくさんご指摘ありがとうございます。
スクロールバーは、細くできるかな・・ちょっと調べてみます。
文字コードは・・・すいません、あんまり詳しくないのですが、
メールって日本語だとiso-2022-jpが標準になってませんでしたっけ?
ちょっと調べてみます。
未読しかないのは、単に考えがなかっただけです。ごめんなさい。
そういえば、添付のマークだとか、印をつけたりとか、優先度だとか、
いろいろありますよね。なおしておきます。
ヘッダーのカスタマイズも、もれていました。
作ってみますね。
410 :
名称未設定 :02/11/12 02:42 ID:UJA18epl
1さん乙カレー。なんかGUIがあるだけでわくわくしてきますね! まあアイコンについてはどうとでもなるとして、メインメニューについて ざっと思い付く点としては、 ・"メール"に"ルールを適用","ルールを作成"があると便利かなあ ・新規メール作成時用の項目が少ないかも("表示"に"ヘッダを追加"など...) のような感じでしょうか。まあこのへんは、無難に他のメーラーを踏襲していくと して、とりあえずはひな形としてこんなかんじで(・∀・)イイ! と思います。 ただ、設計手順としては、 1)メーラーの持つべき機能については、実装項目をピックアップしていく 2)メーラーのルックスについては、InterfaceBuilderで設計していく というふうにきちんと分けたほうが、混乱しなくていいかもしれませんね。 で、命名儀式のような面白い機能については、1と2のどちらにも反映して いくというのがいいんじゃないかと。 勝手な意見ばかりスミマセン。 とにかく体調だけは崩されませんように・・。お疲れさまです!
411 :
1 :02/11/12 02:49 ID:veEMpzcC
>>408 表示・非表示の項目は、
>>283 に本文を閉じて使いたい、
という要望があったので、入れてみました。
でも、左側ペインはあんまり閉じないかなあ。
新規のフォルダ追加は、「メールボックス」->「メールボックスの作成」と
いうのがそれに相当します。
「フォルダ」っていう名前にした方がわかりやすいでしょうか。
アカウントが別でも、フォルダ共存、という話ですが、
実は俺もそっちの方が好きなので、そういう感じに
決めてしまいましょっか。
412 :
308 :02/11/12 02:52 ID:cQdMQXJe
えーっっっっと、
>>308 でAOLメール対応のお願いをした者ですが…
>>1 さん
ごめんなさい!オレは解析なんてできません!なんせ、HTMLってのが、
なんだかもよく分かってないくらいですから。なにもできなくて申し訳
ないですが、応援だけはさせてもらいます。もしAOLメールや、Hotmail
対応で軽くて使いやすいメーラーができたら2万円くらいなら払いたい
位の勢いです。でも、仕様が公開されてないんじゃ難しいですよね。
ダメだったらオレがメルアカ変えます
413 :
1 :02/11/12 02:58 ID:veEMpzcC
>>410 ルールのことは、すっかり忘れてました・・・
肝心なものが抜けてるな・・・
そういえば、ルールの設定画面も作らなきゃいけないですね。
設計手順に関しては、そうやった方がいいのかな・・・
メニューを洗い出していけば、自動的に機能リストが出来るかと
思ってたんですけど、よく考えたら、メニューにすべての
機能が現れるわけじゃないですよね。
どうもありがとうございます。そろそろ寝ます。おやすみなさい。
おお、ちゃんとアプリとして起動する!! 正直、感激しますた。 ただ、スケジュール早すぎませんか? 無理なさらぬよう、くれぐれもお気をつけて。 もっとマターリ開発で、 途中に「早くウプせい!」と煽りが入るぐらいのほうが、 2ちゃんらしい気もするのですが。。。
415 :
1 :02/11/12 03:01 ID:veEMpzcC
>>412 =308
いえいえ、解析してって言ったのは冗談ですので(w
そのうち暇が出来たらやってみます。
>>1 お返事ありがチョー
フォルダではなくメールボックスだったのですね。
ヘタレでスイマセン。
自分勝手な意見しか言えないけど、
サクーシャタンは流されずに、時には意見を切り捨てながら
良いモノを作っていってください。
417 :
1 :02/11/12 03:04 ID:veEMpzcC
>>414 いえいえ、結構マターリやってますので、大丈夫ですよ。
SourceForgeの「活発さ」ランキングだと、
ここしばらくは常に最下位です(w
418 :
1 :02/11/12 03:07 ID:veEMpzcC
>>416 どうもありがとうございます。
いやいや、色々な意見が出て楽しいですよ。
絶対一人じゃ出てこないような発想が出てくるし。
419 :
329 :02/11/12 04:01 ID:f8dpVq8U
そもそもOS Xを使ってないくせに意見など言ってみた者です。 ダウンロードしてみたけど何もわからなくてさみしい............ それでも『地味な作業なので一人でやってると気が滅入る』のは理解できるので、 応援の意志だけは示したいと思い、書き込みます。がんばってください。 時には意見を切り捨てながら良いモノを作ってホスィ、という意見に同感です。 いっそこのスレのためだけにOS X 入れてみようかな。本末転倒ってか? ところで公開に際しては1さんは、『作者名:1』という線でいくつもりですか?
>1さん!! いいよコレ! この時点でもうmail.appよりもこっちのがいいと思った。 やっぱ3ペインはいい。メニューのアイコンの大きさのバランスも 本文を邪魔しない程度の大きさで、iBookで使う分にもちょうどいい。 各ペインを閉じる閉じないは、人によっては使わないかもしんないけど、 閉じれるようにしとく分にはいいんじゃないかな。使わなきゃいいんだし。 新規メッセージの画面もシンプルだし。いいなあ。いいなあ。 あ、でもマターリでね。
つーか、このスレの住人はGyazMailの存在を知っているのだろうか?
不思議なのは、新規メールウインドウはINBOXのウインドウと ちがってウインドウサイズを広げても、テキストフィールドとか適正位置に 調整されませんよね今のとこ、これってInterfaceBuilderで部品を配置しただけじゃ そういう調整は勝手にやってくれないというとこなんでしょうか? いやプログラムには全く門外漢の俺にしてみると、InterfaceBuilderは そのへんも勝手にやってくれるようなイメージがあったもんで。
>>421 少なくとも俺はGyazMailがイマイチ不満なのでこちらを応援してるでつ。
424 :
名称未設定 :02/11/12 13:55 ID:P4DJ9NKO
>>422 パーツ毎にリサイズ時の挙動を設定していく必要があったはずです。
機能追加希望。 1、サービスメニュー。 2、ApleScript対応。 以上。 いや、ほら、 メールチェッカーにアップルイベント投げてやれば、簡単に設定できるなぁと思って考えてたら、 本体にアップルイベント投げるだけでメール送れたら面白いかなと思ったわけです。はい。
>>422 そんなにプログラムは甘くないんです。残念ながら。
あたりまえ、と思う機能も実はちまちま組んで行かないと実現しないのですよ。
というわけで、組んでる方々お疲れ様です。またーりがんばってくださいね。
>>426 リサイズに関しては用意されているから、
難しいことではないと突っ込んでおく。
428 :
1 :02/11/12 21:46 ID:veEMpzcC
>>419 どうもありがとうございます。
もしもOSXを入れることがあったら、試してみてくださいな。
あと、作者名はプロジェクト名にしたいと思ってます。
>>420 どうもです。
ペインの閉じる、閉じないは、とりあえず残しておきますね。
個人的にARENAの2ペインが結構好きなので、
ああいう風な使い方もできたらいいな、と思ってます。
>>421 GyazMailについては、過去に何回か話題が出てきてますので、
だいじょうぶです。
ただ、こちらも標準を3ペインにしたことで、
かなりUIが似てきてしまいますね。
Cocoaを使っている以上、しょうがないのですが。
429 :
1 :02/11/12 21:54 ID:veEMpzcC
>>422 ,426
すみません、リサイズの設定をし忘れてました。
>>427 さんも書いてくれていますが、これに関しては、
InterfaceBuilder使えばプログラムなしで簡単に設定できてしまいます。
ちなみに、今配布している画面も、あんまりプログラムを
書かないでもInterface Builderで出来合の部品を組み合わせれば
だいたい作れてしまうので、ちっとも大変じゃなかったりして・・・
430 :
1 :02/11/12 22:06 ID:veEMpzcC
>>425 こんにちは。
SourceForgeの方ではプロト作成頼りきりですみませんです・・・
ついでに、サービスメニューもAppleScriptも、
全く勉強していないので、また頼ってしまうかも・・・
ちなみに、これらって対応するのは結構たいへんなのでしょうか。
>431 とりあえずお約束だよね。なかなかイイ!んでない?
こいつばかりは好みが別れるよね<チタン おれはダメだなぁ
なんか急に静かになった?
436 :
名称未設定 :02/11/14 12:05 ID:FEZaDPgM
というわけで24時間経ったのでage!
437 :
1 :02/11/14 21:35 ID:uO5ZiK0X
こんにちは。
チタンな画面ありがとうございます。俺は結構好きだなー。
やっぱりどっちでも選べるようにするとよいですね。
>>435 すいません、また週末くらいからぼちぼち動き始めます。
今週はちょと忙しい・・・
438 :
431 :02/11/14 23:10 ID:okAkLZKZ
チタンは少しばかりサイズを調整してあります。 アクアはテキストボックス(?)の左右がぴったりでいいのですが チタンだとマヌケになるので左右にチタンが現れるように調整 しました。 でも、Interface Builderで簡単に弄るからアクアで進行した方が イイと思います。やりたい人はご自由にってことで…
439 :
名称未設定 :02/11/15 22:19 ID:Cvpecnj4
期待していますよage
440 :
名称未設定 :02/11/16 23:16 ID:BuHN7u3K
漏れも期待age
441 :
1 :02/11/18 00:26 ID:jH8AMiNY
こんにちは。 しばらく音沙汰なくしてましたが、一応ちょっとずつ進んでいます。 今は、環境設定パネルの画面を作っているところです。 土日のうちにある程度固めてアップしたかったけど、ちょっと無理でした。 一応ご報告まで。 ところで、全然関係ないのですが、新・Mac板、 最近プロクシ規制で書き込めなくなっちゃいました。 一応ダイアルアップなら書き込めるのですけど、 今後はあんまり頻繁には書き込みできないかも。
442 :
名称未設定 :02/11/18 00:39 ID:OQ9PTMfk
てst
443 :
名称未設定 :02/11/18 00:39 ID:6fAS8boT
サイトつくって報告はそっちに書こうや。1さんとやら
446 :
名称未設定 :02/11/18 22:48 ID:WVGM60uW
447 :
1 :02/11/18 22:50 ID:HB6/jFhs
>>443 ,444
うーん、そうですね。
それじゃ、今後はメーリングリストと、Webサイトの方を
中心に活動していくことにしますか・・・。
メーリングリストはSourceForgeに登録しなくても
参加できますので、良かったら入会してみてください。
>>445 さんのページからたどれます。
あと、一般向けのWebページはこちらです。
http://undmail.sourceforge.jp/ ここのスレはどうしようかな。何か有効利用できればいいんですが。
448 :
1 :02/11/18 22:57 ID:HB6/jFhs
>>446 見てみました。Magellanとかと同じような考え方かな。
フォルダによる分類と併存させるつもりですが、
一応カスタムビューの機能は盛り込む予定です。
ただ、パフォーマンスがちょっと心配。
449 :
名称未設定 :02/11/18 23:12 ID:w1O7qnl5
>>1 さん
おつカレー!
個人的には、別にそんなに深く考えないでもいいと思いますよ。
せっかくここがいい窓口になってるんだから、意見交換などは
今まで通りでいいんじゃないんでしょうか。
450 :
431 :02/11/18 23:34 ID:5/VyMqBW
>>449 同意!
殆どロムってるだけどこのスレが活用されないと
ちと淋しいっス
451 :
1 :02/11/19 22:44 ID:wnzvjQbz
>>449 ,450
それもそうですね。
じゃ、このスレは今まで通りに使っていきましょう。
1の書き込み頻度は減ると思いますが、
要望なり意見なりなんでも書き込んでもらえたらうれしいです。
ついでに、定期的にカキコして、プロジェクトの窓口になってくれる
人が現れないかなー、などとちょっと期待してみたり。
1さんがんばって下さい! 是非最後までつくってみんなに愛用されるメーラーにしてやって下さい。
453 :
名称未設定 :02/11/20 15:14 ID:hGDkJW5i
はじめまして、1さんがんばれage。
454 :
名称未設定 :02/11/21 23:05 ID:9XR7Xg3I
とりあえずage
わくわく
456 :
名称未設定 :02/11/23 03:32 ID:BIzn4G96
457 :
名称未設定 :02/11/23 18:53 ID:ck8YguLD
最近Amazonが古本の個人売買の仲介始めましたよ。 Mac関連のプログラミング本も安くゲットできるチャンスかも。
プロトタイプ2見ました。 気になったところを箇条書き。見てないかもしれないが。 ・検索条件の中に、「未読メール」「ラベルの色で検索」を入れてほしいと思いますた。 (カスタムビューで対応しますか?) ・署名編集はどこからしますか。 実装スケジュールが先ならごめんなさい。
459 :
1 :02/11/24 20:58 ID:KhPCOgWb
どうもこんにちは。
>>456 すいません、ありがとうございました。
一応メーリングリストの方にはアナウンスしたのですが、
反応がなくてさみしかったです(w
やっぱりこっちの方が意見をもらいやすいですね。
ついでに、さっき003もアップしましたので、見てもらえるとうれしいです。
環境設定パネルの方に、いくつかパネルを追加してあります。
>>458 指摘ありがとうございます。
両方とも003の方に追加しておきました。
「未読メール」は「ステータス」で選択するようにしました。
プロトの方では実現できてませんが、
「ステータス」を選ぶと、右のテキストフィールドが、リストに変化して、
「未読のもの」とか、「添付ファイル付きのもの」とかいったステータスを
選択できるようにしようかな、と思ってます。
同様に、「ラベル」を選択しても、テキストフィールドがリストに変化し、
「赤」とか「青」などを選択できるようにしたいと思ってます。
>>459 =1
乙です。
予定にあるのかもしれませんが、外観見ただけで判断しますた。以下希望です。
1.apopコマンドにも対応して欲しいな。
2.新規作成の表示では、枠が無い方がスマートな気がします。
(アピアランスで他メーラとの差別化があるのなら失礼。)
3.「環境設定>表示」で引用文とかヘッダとかの色分けの設定ができると良い。
4.メール作成の時は他のエディタで編集出来るようにする...と以前おっしゃっていた
覚えがあるんですが、デフォルトでも改行文字とか全角空白を表示できると嬉しい。
おいらも2chにもっと情報を流していただけると嬉しいです。
461 :
1 :02/11/24 22:56 ID:kytA+xhb
>>460 ご指摘ありがとうございます。
1,2,3を修正しました。
004がダウンロード出来るようになっていますので、
また確認してもらえるとうれしいです。
4.については、ぜひ本番では対応したいと思っています。
プロトではちょっとやるのが難しいのですが。
(´-`).。oO(Osakeってなんだろう・・・)
>>461 =1
お返事ありがと。
確認しましたが、003と変化ないみたいです。
単にupミスだと思うんですが(^^;;
マターリ頑張って下さい。
464 :
389 :02/11/25 14:15 ID:Xh+0VBlM
>>1 プロト4、ダウンロードしてみました。
「名付けの儀式」を採用頂きありがとうございます。
プログラムの事はさっぱりなのであまりお力にはなれそうにもありませんが、頑張って下さいね(応援する事と適当な要望を言うくらいしか...)。
これから期待していますね。
あぁ〜〜
早く初期バージョンが見たぁ〜〜い
現在会社のためWinしかないのでプロト4を見られないのですが Mail.appでいうルール(振り分け機能)はあるんでしょうか? Mail.appでのルール(振り分け機能)は受信時のみ適用なのですが 「名無しメール」ではそうならないようにしていただきたいです。 受信後、受信箱(Inbox)で読んだ後にメールを選択して「ルール」を 実行できるようにする。 あるいは、ルールは受信時に適用されても未読メールを一覧で見ら れるフォルダ(?)を設置するかいずれかの方法があるといいんですけど…
466 :
名称未設定 :02/11/25 18:25 ID:twDj502M
すばらしい! あとは、bccが指定できれば何もいうことはありませぬ。 1サソ、草葉の陰から応援してます。
| |´∀`) <1サン ガンガレ〜〜 |⊂ ) | 丿
469 :
名称未設定 :02/11/25 19:06 ID:RCV6bDKd
>>465 まず家に帰ってプロト見てからいろいろ云おうね。
470 :
1 :02/11/25 21:22 ID:AAr8P9U0
こんにちは。いろいろ応援してもらえてうれしいです。
>>462 素で間違えますた・・・
自分でやっといてちょとワラタ
>>463 うーん、今確認してみましたが、ちゃんとupされているような・・・
もし時間があったら、もう一度試してみていただけないでしょうか?
>>464 面白いアイデアありがとうございました。
名付けの儀式はヒットでした。
プログラミングできなくても、どこがいいとか、どこが悪いとか
言ってもらえるだけで、すごく参考になりますので、
これからもぜひご意見くださいね。
471 :
1 :02/11/25 21:22 ID:AAr8P9U0
>>465 一応ルールは用意してありますが、
ルールを適用するタイミングについては考えてませんでした。
これも設定できた方がいいですね。
考えられる設定としては、下の3つくらいでしょうか。
1. メールの受信時
2. 手動(メールを選択して、メニューから明示的に実行)
3. メーラーの終了時
ちなみに、未読メールの一覧は、カスタムビューでも実現できるように
したいと思っています。
>>466 ああ、BCCすっかり忘れてました。これはまずいですね。
Mail.appは、「編集」のメニューからBCCを追加するようになっている
みたいですが、なんかイマイチのような・・・
ちなみに、Mail.appだと、Reply-Toも設定できるみたいですね。
これも出来た方がいいのかな。
アドレス帳の件はどうされますか
>>1 さん
アドレス帳は内部に持たず外部のアドレス帳を利用されるおつもりでしょうか。
(現在グレイアウトしてますね)
OS付属のAddressBook.appとmail.appの連係の場合、宛て先を指定して新規メールと
言うのは出来ますが、新規メールを開いてから送信先を指定する方法がありませんよね。
ドラッグ&ドロップも出来ません(Cc:欄にはできる)→OS X 10.1.5の場合
これができると便利なような気がするのですが。
アドレス帳を内蔵しないと言う方針であれば、例えば「宛て先...」メニューで
直接AddressBook.appのデータファイルを直接読みにいくとかして、名無しメールから
宛て先を挿入できたらなと妄想しております。
実装は難しいかもしれないですが。長文スマソ
>>471 「送信時」
任意のヘッダを指定できるようにしてくれ。
474 :
465 :02/11/26 09:18 ID:WHA9qX5O
>>471 プロトも見てないのに返答いただきありがとうございます。(>469さん申し訳ない…)
※しかもまだ見てないのです(鬱
> 1. メールの受信時
> 2. 手動(メールを選択して、メニューから明示的に実行)
> 3. メーラーの終了時
>
> ちなみに、未読メールの一覧は、カスタムビューでも実現できるように
> したいと思っています。
すごくいいと思います。今後もガンバって下さい!
>473さんの言われている「送信時」ってのいいですね。
送信メールを振り分けしたことはないけど…
私は受信メールはもちろん、 送信メールの振り分けも常用してます。 後日送信メールを参考にする事も多いので 検索で探すより、メールボックスを用途、宛て先、グループ等にわけて そこに送信時振り分けておいた方があとで探しやすいですしね。 ということで私も送信時の振り分けもできるようにしてもらいたいです。
476 :
名称未設定 :02/11/26 12:12 ID:LP9im7QX
>472 >OS付属のAddressBook.appとmail.appの連係の場合、宛て先を指定して新規メールと >言うのは出来ますが、新規メールを開いてから送信先を指定する方法がありませんよね。 普通にできますよ。
>476 かいつまんでやり方教えて下さい お願いします。
478 :
名称未設定 :02/11/26 22:11 ID:RfJRIkuV
>477 送信欄 アルファベット 最初の数文字 かいつまんでみた
479 :
1 :02/11/26 23:02 ID:qJyXcWyF
>>472 アドレス帳に関しては、まだあんまり考えてなかったのですが、
472さんがおっしゃるようなやり方は、実現できた方がいいですよね。
ちなみに、アドレス帳のデータはOSX付属のAddressBookの物を使うとして、
UIはなにか別のものをかぶせた方がいいかなと思っています。
AddressBookってどうも使いにくくってあまり好きではないので。
アドレスの入力方式は、以下の4つくらいが思いつくのですが、
他に何か便利そうなのはあれば教えてください。
1.アドレス帳からの入力(ドラッグアンドドロップか、Mail.app風宛先ボタン)
2.宛先メニュー(コンテクストメニュー?)
3.ニックネームによる省入力
4.新規メールの作成前に、宛先指定画面を挟む。
480 :
1 :02/11/26 23:03 ID:qJyXcWyF
>>473 ,475
了解です。UIに反映しておきます。
受信時と送信時は別々に指定できた方が良いですよね。
自分で使うとしたら、受信メールは終了時に振り分けたいけど、
送信メールは出したと同時に振り分けたいかなー、と思うので。
ところで、ふと思ったんですが、ルールって送信時に適用するものと、
受信時のものを明示的に分けれるようにした方が良いでしょうか?
>478 ありがと。 洩れはマウスだけで宛て先を選択する方法を考えていたんで、こういう方法は 想定外だったけど、472で書いた方法よりは便利だね。 でもキーボード打つのも面倒なものぐさ太郎なんで。 ちなみに今使ってるメーラーはMusashiというやつでして、宛て先欄の横にあるボタンを押すと 種類別に階層化されたメニューが出てきて宛て名(Eudoraでいうニックネーム)を選択できる。 そういうイメージが前提に合った訳です。このこと先に書けば良かったね。 つうか教えてくれてありがとう。
482 :
472 :02/11/26 23:38 ID:sjEoOp3D
乙です>1さん
プロトタイプを見るとほとんど今にも使えそうな気がしてしまい、ついあれこれと
書いてしまいました。
インターネットクライアントはメーラーに始まりメーラーに終わると言う格言の通り(うそ)、
10人いれば10通りのこだわりがあるように感じます。よかれと思って実装した仕様が、
ある人にとっては最大のネックになったり、実に難しいです。
例えば分かりやすいようにニックネームを使うようにしても、アドレスそのものを確認したいから
To:欄には"ニックネーム"<
[email protected] >と表示しろゴルァという心配性な方がいたり。
(実際に某メーラーのメーリングリストで要望が出てました)
ということで1さん、進捗状況はうるさく聞きませんから、実現性と安定性を第一に、
頑張って下さい。
483 :
名称未設定 :02/11/27 01:51 ID:XErx3MRc
>477 ってか新規メールのウィンドウのツールバーに "アドレス"って項目があるやろ?
484 :
名称未設定 :02/11/27 01:57 ID:QHN2fH1W
>>479 クリップボードの中にメールアドレスっぽいものが入ってたら,そのまま宛先に使用するとかはどうだろうか。
あと,最近メールを出した相手の履歴とかがすぐに出てきて,そこから選べてもいいかもね。
>483 うちのには「アドレス帳」はあっても「アドレス」はない。(OS X 10.1.5ね) よしんば「アドレス」=「アドレス帳」だとしても、その後どうするですか。 ...AddressBookが立ち上がって、既に立ち上がっている新規メッセージウインドウの 宛て先欄にどうやってアドレスを挿入してますか。 ちなみにうちではその段階でAddressBookのメール送信ボタンを押すと別途新規メッセージ ウインドウが立ち上がってしまう。本文を書いてから宛て先を入れる自由を下さい。 ...ということです。 みなさんのお宅ではどうですか。
10.2つかえば?
487 :
1 :02/11/27 23:10 ID:BboW1Jf0
>>484 なるほど、クリップボードの中からメールアドレスを探して
宛先にするっていうのはとても面白いアイデアですね。
複数のメールアドレスがバラバラに混じったテキストをコピーして、
そのまま宛先欄に貼り付けたらメールアドレスだけ抽出して宛先になったら、
便利かもしれませんね。
メールアドレスの履歴というのもいいアイデアだと思います。
この場合、どこかのボタンを押すと履歴の一覧が出てくるような
操作方法も考えられるし、
UNIXシェルのコマンド履歴みたいに、↑キーで順番に過去をたどっていくような
操作方法も考えられますね。両方出来た方が便利?
488 :
1 :02/11/27 23:10 ID:BboW1Jf0
>>485 うちは既に10.2にしてしまったので、ちょっと確認できないのですが、
自分もいつも本文書いてから、最後に宛先を入れる方なので、
それができないのはちょっと困りますよね。
昔、先に宛先入れてから本文書き出して、うっかり書きかけで送信ボタンを
押してしまったことがあるので・・・
というわけで、その機能は絶対入れておきますので、お楽しみに。
>>485 ドラッグ&ドロップはできた。10.1.5で。
490 :
483 :02/11/28 00:54 ID:c6bFQoRl
>485 すんません。10.1.5ってトコを完全に見落としてました。 俺は10.2なんで普通にできてたんですね。
そっかー10.2ではできるんですね。でも>489さんはできると言うし... (うちではドラッグ&ドロップも駄目なんで) ま、あんまりこの話題で引っ張っても仕方ないんで終了と言うことで。 でも、もしOSのバージョンで重要な部分の仕様が違うと困りますね。 全てのバージョンをサポートするのは開発負担が大きすぎるし。 またーりとお願いします。
492 :
1 :02/11/28 23:51 ID:8I4fgeKN
ウインドウを閉じる、ってメニューがないですね。
494 :
1 :02/11/30 14:32 ID:66KMsnT9
>>493 指摘ありがとうございます。直しておきますね。
495 :
466 :02/11/30 20:41 ID:0Gt0/ZS9
bccの追加、1サソ どうもありがとう。
β版が楽しみでつ。
>>468 ツッコンでくれてありがとん。
最近滞ってきてるようなのでひとつ要望を。 新規メール自動チェックの間隔をアカウント別にしていただけるとうれしいです。 個別に"5分"とか"10分"とかいうふうに。
>>496 >新規メール自動チェックの間隔をアカウント別に
便乗させてください。さらに、
自動チェック間隔は秒単位で設定可能だと嬉しいです。
ん、秒単位うれしいかも。 自動チェック感覚を設定する時に 5分を300秒と設定する手間は、手間とは言えないくらいのものだものね。
499 :
名称未設定 :02/12/02 16:28 ID:YV4byxc7
>自動チェック間隔は秒単位で設定可能だと嬉しいです。 あまり頻繁なPOPチェックはマナー違反です どうかそのような非常識な実装は思いとどまってください。 少なくとも自動チェックは5分間隔以上にすべきだと思います。
500 :
497 :02/12/02 16:49 ID:ZfH1m/QI
>499 あらら、やっぱり誤解を招いきましたね。すんません。 私が言いたかったのは数秒「ごと」にチェックじゃなくて、例えば アカウントA は 300秒で、 アカウントB は 320秒で、 という風に、設定「単位」を秒で可能に、ということなのでした。 確かに、自動チェックのスパン最低ラインを設けなかったら、 1秒ごとにチェックなんてことも可能になってしまうので、 常識的には300秒=5分ぐらいかな〜、と私も思っとります。
…秒単位のメリットは?
マナー違反だとか非常識だとかって言葉は あまり使わない方がいいと思うなぁ。
>>502 なんで?いつも自分がいわれてるから?
マナー違反とか非常識だとかは明確に指摘してあげるのが優しさだと思う。
504 :
名称未設定 :02/12/03 10:08 ID:NrQxqP8k
マナーを守ればみんなが幸せになれます、 実装レベルでマナー違反不可にして置いていただけるとありがたいです。 POP処理ってサーバーには結構重労働です、 初心者に限ってチェックは短い方がいいとか思って意図せず短く設定しがちです、 その上「メールサーバに残す」設定で沢山たまったPOPBOXに短時間で アクセスされたらサーバーは大忙しです、 そんな香具師が百人もいたら・・・ガクガクブルブルですね。
…それで、秒単位のメリットはナニ?
>例えば >アカウントA は 300秒で、 >アカウントB は 320秒で、 >という風に、設定「単位」を秒で可能に、ということなのでした。 20秒の差は何を意味するの??5分と6分じゃ駄目なの?
>>507 60秒より細かく設定したいから、こういう要望があるんだろうよ...
それぐらい汲み取ろう。
メーラによっては複数並行にアカウント処理すると重くなることもあるしな。
実際300秒以内を設定しようとすると、怒られるようにするなど
にしておけば、㍆おさまるのでは。
分設定だとどの道、秒に換算する処理が必要になるだろうし。
509 :
497 :02/12/03 13:22 ID:V6KYLPBy
思いがけず争いになりかけてたようで恐縮してます。
>>508 さんの言う通り、理由は
>60秒より細かく設定したいから、
>メーラによっては複数並行にアカウント処理すると重くなることもある
ただそれだけなんですが……。
また、より細かくカスタマイズできるようにというのが
このメーラーの特長のようですし、
それなら、と思って「秒単位で」と書いたまででした。
>>509 分単位に設定できるなら、秒単位の設定が有ってもいい。
15分が何秒か計算されられるのは嫌だ。
511 :
1 :02/12/03 23:32 ID:axjV5B1+
こんにちは。
最近ちょっとさぼってますが、週末あたりからまた続きに
とりかかります・・・
>>496 さんの、アカウント毎のチェック時間変更機能は
画面の方に盛り込んでおきます。
問題の秒きざみの設定については、
>>508 さんの案でどうでしょうか。
警告はするけど、あとは自己責任でっていうのが
ちょうどいいスタンスではないかと。
それから、
>>510 さんの意見ですが、
秒刻みにしたい、という方が特殊な要望だと思うので、
単位は分にしておいて、小数点以下を記述すると秒単位でも
指定できる、という仕様でいかがでしょう。
> 単位は分にしておいて、小数点以下を記述すると > 秒単位でも指定できるという仕様 なるほど、いいかも。私は凄く感心しますた。
513 :
497 :02/12/04 00:34 ID:bWpzaQXl
> 単位は分にしておいて、小数点以下を記述すると > 秒単位でも指定できるという仕様 ありがとうございます。異存はありません。
514 :
名称未設定 :02/12/04 12:03 ID:s6hby+jt
>単位は分にしておいて、小数点以下を記述すると秒単位でも >指定できる、という仕様でいかがでしょう。 できれば最低間隔を5分とかにしてもらえるとうれしい。 例えば1分単位なんかを自動で行う意味って無いと思う 基本的にそれ以下の間隔は手動でチェックすればいいとおもうんですよね、 このメーラー凄く期待してます、 だから環境に優しいメーラであってほしいです。 暴力的な実装は「**メーラ使いってうざい、氏ね」って言われかねないんで 一つよろしくお願いします。
3分で良いと思うな、ワシ。
「設定可能なメールチェック最低間隔、個人的には○分以上でオッケー」 ・・・というアンケートに御協力ください。 短かめ派のひとは、なるほど、と思えるような理由なり使用状況なりを 書いてくれるとセクスィ。私は個人的には30分でいいです。 (本音を言うと120分でも構わない)
そんなにリアルタイムにメールチェックしたい人は、 携帯のアドレスに転送するようにすりゃあいいんじゃないの。
>>516 サクーシャタソの意見を読む限り、アカウント毎、
直接フィールドに数値を書き込む仕様になると思われる。
Mail.appだとプルダウンで決められた時間間隔しか選択できないけどね。
故にアンケート無用。
519 :
516 :02/12/05 00:37 ID:68INDrDo
>>518 あんたが正しい。オレの書き方が悪かった。
えーっとね、A、Bふたつのアカウントを持ってて、
Aのチェックを例えば600秒毎にしてる場合、Bのチェックを601秒に設定可能か?
サクーシャタソの意見を読む限り、アカウント毎に直接フィールドに数値を書き込む仕様に
なると思われる。だから601秒も可能だ。最低間隔1秒。
あるいは1秒以下。それはいい。
それはいいが、A(やB)を毎3秒ごとに自動でチェック、なんて設定が
可能だとしたら、それはよくないだろー、環境に優しいメーラであってほしいヨ、
オレは最低5分がいいと思う、いや、
わしは3分は欲しいな、という話になってるわけ。
5分でよい派
俺も5
家にケータイ忘れてきちゃった。会社終わったらデートなのに…。 待ち合わせとか詳細は決めてないしどうしよう…。 終業間際、その旨相手のケータイにメールを入れ あとは激しくメールチェック。Entourageで1分間隔だったかな。 ってなことが、数年前に一度だけあった。普段は手動。 ま、いらん罠…。
>>519 勝手に勇み足してない?
511でサクシャータソは
>警告はするけど、あとは自己責任でっていうのが
>ちょうどいいスタンスではないかと。
と言ってるんだよ。
まず議論されるべき点は
「自己責任においてチェック時間を自由に定められるか、規制すべきか」
ということだと思うんだけど、どうだね。
俺の意見は「なるようになれ」だ。
普段は15分に設定しているから議論の行方が1時間毎にしか選べないという
方向に行かない限り、興味なし。
・・・こんなヘタレだが、もっとサクシャータソの意見を尊重する進行を求む。
524 :
519 :02/12/06 00:52 ID:nv9uzF55
>>523 まーいいじゃないですか、いろんな意見があって。
もちろんおれは規制すべきだと思うからそう書いたんだし、
いや最低を何秒に制限すべきかなんつー議論以前にオレは制限自体に反対だ、
という意見のひとがいれば、そう言えばいいんだし。
525 :
1 :02/12/06 02:03 ID:F/xn420P
こんにちは。
最近忙しくてぜんぜん手がつけられないのですが・・・
>>519 自分のメールチェックに対する意見は、
>>523 さんも
フォローしてくれていますが、
>>511 の通りです。
警告だけではだめでしょうか?
>>1 乙
マナーと言われていることを簡単にスルーできるようなものになったら
ちょっと前に議論になった2ちゃん臭が漂うことになると思われ。
秒単位で細かく設定するメリットは
>>508 > メーラによっては複数並行にアカウント処理すると重くなることもあるしな。
ということのようなので、それならむしろ、
複数アカウントをわざとずらしてチェックするかどうかを選択するオプションをつけるのはいかが?
オプションOFFの場合
アカウント1 *−−−−−−−−−*−−−−−−−−−*−−−−−−−−−
アカウント2 *−−−−−−−−−*−−−−−−−−−*−−−−−−−−−
アカウント3 *−−−−−−−−−*−−−−−−−−−*−−−−−−−−−
アカウント4 *−−−−−−−−−*−−−−−−−−−*−−−−−−−−−
アカウント5 *−−−−−−−−−*−−−−−−−−−*−−−−−−−−−
オプションONの場合
アカウント1 *−−−−−−−−−*−−−−−−−−−*−−−−−−−−−
アカウント2 −−*−−−−−−−−−*−−−−−−−−−*−−−−−−−
アカウント3 −−−−*−−−−−−−−−*−−−−−−−−−*−−−−−
アカウント4 −−−−−−*−−−−−−−−−*−−−−−−−−−*−−−
アカウント5 −−−−−−−−*−−−−−−−−−*−−−−−−−−−*−
>>526 マナーって何のこと?
他人に迷惑をかけうるプログラムは作るな、ってことが言いたいの?
>>527 そんな仰々しいオプションにしなくても、
アカウント毎に個別に更新時間を設定できるとうにしておけば済むのでは?
Mailのような一括で決まった更新時間しか設定できない仕様なら良い案ではあるが。
てか、今の話題は「
>>525 の、警告だけではだめでしょうか?」だろ。
524といい527といい、もっと今何について話されているかを嫁。
質問なんですが、最近のメーラーってアカウントごとにスレッド作っちゃってるわけですか?
xDSLなんかの普及から考えればそうなってもおかしくはないんですが...
うちの回線でそんなことすると無駄に遅くなると思う。
プロトタイプでは、接続スレッドが1個しかないので勝手に
>>527 のON状態になっちゃうんですけどね。
530 :
名称未設定 :02/12/06 18:11 ID:WCn0nJnh
> 最近のメーラーってアカウントごとにスレッド作っちゃってるわけですか おれもアカウントごとにスレッド作ること(時間が別々に設定できる事)って 意味ないと思うんだけど・・・ 別々チェックだとこういったケースで便利! とか 別々チェックじゃないと使えない! って具体的事例を教えて。
俺の場合はメールアカウントを4個ぐらい持っていて、
仕事に使うのは10分毎、プライベートなのは1時間毎、
MLやMMは3時間とかに設定しておきたいなぁ。
メールチェックって非力なマシンだったり、メーラの仕様とかでは
結構重い作業になったりするじゃない。極力分散させておきたいかなと。
>>529 Nameraだと受信タイミングがかち合ったときは、
他を遅らせてくれるようだ。それ以前に全般的に動作がトロクて
しょうもないけどw
532 :
名称未設定 :02/12/06 19:20 ID:lHdLyGbC
やっぱり軽快ってが一番! 1さんがんばってください。
アカウント毎に異なる取得時刻を設定する事と 別スレッドを立てて複数のメールボックスに同時接続する事は 微妙に違った話だと思いまふ。 で、メールボックスに接続するスレッドは一つに絞っておけば 時間を秒単位でずらして接続する設定をする、なんて必要無くなるのでは?
535 :
534 :02/12/07 04:34 ID:ULeUdkC9
>>534 同一アカウントに対してメール更新間隔が短いのが悪いってことで、
527につっこむのは全くお門違いだと思うが?
すぐ上の533の意見とか理解できてるか?
つまりはだ、問題なのは...
(1) 同一アカウントに対してメール更新間隔が短いのはメールサーバに
負担をかけてしまうから、最初から設定できないようにするか、
警告に留めるべきかということ。(この場合、何分をもって短いと
するかという議論は必要なんだろうね。私的には5〜10分)
(2) メールクライアント側(ユーザ側)が非力だったり、回線が細かったり
する場合を考慮すると、受信タイミングが同じ時は同時にメールサーバに
接続するのではなく、
>>527 や
>>533 の意見で回避した方が良いん
じゃない?ということ。
(3) UIとしてはOSXについてくるMailのように予め決められた時間を選択するか、
直接任意の時間を入力できるようにするか。
(4) それはアカウントごとに個別に設定するか、全体で一括管理するか。
...という感じ。
とりわけ(1)と(2)はメーラの内部的な機能の一つで住み分けが違い、
別個に考えるべき話題なのさ
>>533 んで、(3)と(4)の兼ね合いからは四つ場合分けできるが、合理的なのは...
(壱)決められた時間間隔を選択、かつ全体で管理(Mailの方法)
(弐)任意で時間間隔を入力、かつアカウント毎で管理(GyazMailとかBecky(・∀・)!!)
...ま、UIとしてはこの二通りが一般的だろう。
↑
× 別個に考えるべき話題なのさ
>>533 ○ 別個に考えるべき話題なのさ
>>534 UIに関しては、(弐)が応用が効いて良い。
(1)に関しては、5分と設定するとダイアログが出てきて設定不可にする。
(2)に関しては、プロトタイプが出来てから判断したい。
自分の回線がダイヤルアップではないというのもあるが、
送受信動作が軽いのだったら同時接続が活かせると思う。
この場合、ダイヤルアップの方はタイミングを
任意にずらしてくれれば回避できるかなと...
そもそも
>>532 が言う通り、「軽さがウリ」というのも
開発コンセプトだったはずだから、動作が重いのは論外かもしれん。
538 :
534 :02/12/07 11:18 ID:ULeUdkC9
539 :
536 :02/12/07 12:33 ID:2VVR0iYR
Mail.appをみてみました。 アカウント毎にスレッド作ってました。 ぷるぐいんで対応可能ですので、そのままでプロトタイプ作ります。
メール本文を選択して、ウィンドウの外にドラドロすると テキストクリッピングファイルができるとうれしいです。 既出だったらすまそ。
542 :
1 :02/12/11 23:04 ID:NGm0EHZG
こんにちは。ご無沙汰してます。
メール自動チェックについては、ちゃんと議論に参加できなくて
すみませんでした。
>>536 さんんがまとめてくださっているので、一応自分の考えを書きますと、
(1)については、しつこいようですが、やっぱり警告の方がいいような
気がします。これはもう、単なる考え方の問題なのですが、
マナー云々って、アプリが強制すべきものじゃないのではないかという
気がするんですよね。
ただ、3秒とかに設定されると、本当にサーバーに損害与えそうなので、
1分以下は禁止、5分以下は警告、というのが、妥当な線かな、
と思うんですけど、いかがでしょうか。
(2)については、技術的な問題だと思うので、
>>537 さんがおっしゃるように、
まずは試してみてから判断するのが良さそうな気がします。
(3)、(4)は、直接入力+アカウント毎がいいと思っています。
特に、アカウント毎は、個人的に現在もそういう使い方をしているので、
やっておきたいんですよね。
543 :
1 :02/12/11 23:10 ID:NGm0EHZG
すごく下がっていたのであげつつ。
>>540 お疲れ様です。プロトの方、順調に進んでいるみたいで
とても助かります。1もがんばりまつ・・・
>>541 それはいいと思います。多分、Cocoaなら簡単にできるのではないかと
思っています(調べてませんが)
Mail.app も GyazMailもそうだが、メインウィンドウが複数開けるというのは 意味ない様な気がするんだけど、なぜそうなっているのかな? 今つかっているのはGyazMailなんだが、普段はウィンドウを閉じておいて、 新着が来るとウィンドウを開いて確認している。しかし、たまに閉じずに Dockにしまっていて、それに気づかずに新ウィンドウを開いてしまい、 必要もないのにメインウィンドウが2枚に、ってことがあって良くない。 Mail.appのような実装になっていれば、問題ないのだけど、 そもそもメインウィンドウを複数開けるようにする必要は無いんじゃない かなーと思うんですがどんなもんでしょう。
>>544 画面が広い人はウインドウを2つ開けて見比べながら
レスしたりするんじゃない?
メーラーつっても検索が強力だから簡易データベース代わりにも
使えるし...
まぁ俺はGUIで操作することが多く、Dockをクリックするから
2つウインドウが出るなんてことないけどね。
まあ、人には人の使い方があるってね
(;´Д`)…ハァハァ
548 :
名称未設定 :02/12/22 02:35 ID:elCMl6gs
完成した?
期待age
かなり期待しています。 個人的には良いものであれば2600円出してでも欲しい。
その微妙な価格設定はなんですか?w
553 :
名称未設定 :02/12/25 18:56 ID:u769z2Gs
期待しております
(・∀・;)はぁはぁ
555 :
名称未設定 :02/12/29 14:53 ID:aOSHLUW/
ホシュホシュ
ホシュサゲ
ホシュ
558 :
1 :03/01/05 14:39 ID:qfiH6kOr
ども、あけましておめでとうございます。 長い間ほっぽらかしにしてしまってすみません。 スレの保守をしてくださった方々に感謝。 年も明けたことだし、そろそろ開発を再開したいと思ってます 一応、今後のスケジュールは、こんな感じで考えてます。 1月中・・・引き続き要件定義&プロト 2月中・・・基本機能の設計&実装 3〜4月中・・・その他の機能追加 5月・・・ベータ版配布&バグつぶし というわけで、今年もどうぞよろしく。
なんにもできないけど、 応援してます。 頑張れ!
>>558 もうやめちゃったのかと思ってました…
開発はのんきにやってください。
けど、ときどきスレには顔出してくれるとウレシイな
561 :
名称未設定 :03/01/08 12:26 ID:OwZ5n8e4
1さんことしもよろしくがんばってねあげ。
562 :
1 :03/01/11 13:24 ID:aRrzOsUo
こんにちはあげ。応援ありがとうございます。 この3連休はとっても暇なので、がんばりたいと思います。 で、しばらく間が空いたので今の画面を見直していたのですが、 なんとなく今の状態って、ななしメールのコンセプトをうまく 生かしきれていないような気がしてきました。 なんというか、普通のメーラーに、単に名前を付けられるだけのものに なりつつあるというか・・・ もうちょっとアイデアを練り直したほうがいいのかなあ、 なんて思いつつあるんですけど、みなさんはどう思いますか?
>>562 う〜ん…でも基本をおさえて作っていこうとするとどうしても他の
メーラーと似かよってしまうのではないでしょうか…(しょうがないこと)
命名出来るメーラーであることや、Mail.appで出来ないことが可能
(振り分けの既読後処理)などが目玉ではあるんだど…
プログラムのことは分からないのですが、基本のメーラーでその他の
処理・作業はすべてカスタマイズ(プラグイン等)なんてのもおもしろいかも…
564 :
名称未設定 :03/01/11 14:28 ID:vC1rOp+h
>>562 Safariを使ってて思ったんですが、あれは
・ごくごく普通のブラウザ機能(ただし高速)
・プラスα機能(SnapBackやGoogleBar、Bookmark管理機能)
というだけで、すごくシンプルなんですよね。だから、メーラーにしてもまず基本機能は
しっかりおさえて軽く、というのは必須だと思います。そういう意味では、KHTMLのように
オープンソースのメーラーエンジンとかあれば利用できそうなんですけどねー。
アイデアリスト、メーラーとしての基本機能と名無しメールならではの+α機能を整理してみるといいかも...。
基本機能実装は大変だろうけど、期待してますので1さんがんがって!
565 :
1 :03/01/11 15:08 ID:mDtxEEBn
>>563 ご意見ありがとうございます。
そう、基本を押さえるとどうしても似通ってきてしまうんですよね。
メーラーってかなり枯れた分野なんで、
機能性については開拓されつくしているような気がしなくもないです。
そんな中で、このメーラーがどうやれば存在感を示せるのかっていうと、
やっぱり、ななしであることを最大限生かせるものにしたいのですよね。
1つのコンセプトを隅々まで浸透させたいっていうか・・・
で、基本機能以外は全部カスタマイズ、プラグインっていうのは
コンセプトと合っていてとってもいいですね。
ただ、その時に「基本機能っていったい何よ?」って考えると、
非常にあいまいなんですよね。
例えばメールの自動チェックって基本機能のような気もするし、
そうでないような気もするし。
どこからプラグインにしてしまうのか、はっきりさせた方がいいのかも。
566 :
1 :03/01/11 15:08 ID:mDtxEEBn
>>564 Safariは早くってシンプルでいいソフトになりそうですよね。
Safariに限らず、Appleのアプリって
シンプルな機能+2,3個のちょっとした面白いアイデアって感じで、
とても統一がとれていていいな、と思います。
ななしメールもそういう風にできればいいのですが、やっぱりまだちゃんと
詰め切れていないんだと思います。
564さんがおっしゃるように、一度機能を整理してみたいと思います。
568 :
563 :03/01/11 16:27 ID:jk6eVoM1
567さんが書かれているように1さんの「アイデアリスト」ので取りあえず 動くもの(A・B位)が出来てみないと何とも言えないような… Bのなかでも即必要でないものは後回しでいいと思う。
569 :
名称未設定 :03/01/12 01:13 ID:Te8PXgud
570 :
1 :03/01/13 02:26 ID:IkFY6fp8
>>567 ,568
アイデアリストは、はじめに作ってから全然更新していなかったので、
現状が反映されているとは言い難いのです・・・
というわけで、アイデアリストの方を更新してみましたので、
見てみてください。
以前とは、A,B,C,Dの意味づけがちょっと変わっているのでご注意を。
ついでに、サイトの方も色々更新してみました。
http://undmail.sourceforge.jp/ おっしゃるとおり、一度動くものが出来てみないことには
何とも言えない部分があると思いますので、
まずは上のリストに従って作ってみようと思います。
出来たらまたご意見ください。
571 :
563 :03/01/13 02:39 ID:pX9frEDV
アイデアリストが見やすくなりましたね! 口ばっかりで力になれないのですが… ガンバってください。
1さんは「いい人」で、自己主張が薄いと言うか、 押し付けが嫌いと言うか、そういうパーソナリティを感じるのですが、 命名もユーザ任せというアイデアもその表れみたく感じてるのですが、 それはそれで決して悪いことではないので、そういう方向で仮に 「普通のメーラーに、単に名前を付けられるだけのもの」になったとしても 決して悪いことではない。個人的にはそう思う。 「フリーでオープンソースで、最低限いちおう使い物になるメーラー」 ってのが出たら、それだけで大きな存在意義があるんじゃないの? よく知らないけど、つか全然知らないので、そうでもないんだったらゴメン。
アイデアリスト見やすくなって、 どういう要望がでてるのか容易に判断できるようになりましたね。 それでなんですが、ちょっと要望というかアイデアをだしたいと思います。 リストの中にはないはず。 [分類]送受信 [機能名]送信時に宛先とアカウントのチェック マルチアカウントのメーラーを使用していると、 例えば会社の先輩、同僚に個人用のアカウントで送信してしまった、とか 逆にプライベートな相手に会社用のアカウントで送信してしまった、 等という失敗を誰しも一度はしてしまうのでは、と思います。 それをできるだけ避けられるような機能をぜひつけて欲しいかなと。 アカウントごとに、この文字列が宛先のメアドに(入ってる|入ってない)場合警告する、 等ができたらいいかなー、と思います。 あとアイデアリストはどのレス番まで反映したのかを書いておいた方が いいとおもいますよ。 後日また更新するときにどこまでやったのか忘れちゃうからw
574 :
1 :03/01/14 01:18 ID:TEHyvarK
>>571 見やすくなってましたか。苦労したかいがあったなあ・・・
またご意見くださいね。
>>572 いやー、そんなにいい人というわけではないんですが(汗
ちょっと気が楽になりましたです。ありがとうございます。
フリーでオープンソースのメーラーは、UNIX発祥のものだと
色々あるみたいですけど、MacOSX専用のものはあんまり聞いたことないかも。
それだけでも存在意義があると思ってもらえるなら作りがいがあります。
>>573 ご意見ありがとうございます。
さっそくアイデアリストの方に追加しておきましたので見てみてください。
アカウント毎に送信チェックできる機能って、とても面白いですね。
宛先のチェックだけじゃなくて、他にもいろいろ応用できるかも。
575 :
572 :03/01/14 02:27 ID:rssAPY+I
アドレス帳がグループ(フォルダ?)分けできるようになってて、
って、そんなこたぁ常識か、イヤ、それでですね、
グループそれぞれにデフォルトで使うアカウントを指定しとくことが(も)できる、
てのはどうですか。仕事関係はアカウントA、女子関係はアカウントB、とか。
メアドの文字列(入ってる|入ってない)で指定するより楽な気がする。
大企業の会社員とかだったら、そうでもないのかな。
オープンソースの実情を知らないだけでなく、いろんなメーラーの
ことも知らないので自信ないけど、
>>573 を読んで、そう思いました。
新しいアイデアリストとてもイイ! っていうわけで一つアイデア提供 既に読んだメールを表示しないようにする機能があってもいいかも? メニューから『開封済みメールを表示』をON/OFFで切り替えられるような 感じで操作できるとうれしいですね。(次回起動時に覚えていてほしい) あまりにメールが多くなると表示にかかる時間も馬鹿にできないので・・・。 リストには入ってないですよね。 どうでしょ?
>>576 でも、「読んだはずなのにメールが見たありません。自動的に
捨てられちゃったのでしょうか?」っていう奴が増えそう…
環境設定ではなくメールリスト表示部分にボタンがあればいいのかな?
578 :
576 :03/01/14 11:43 ID:gbdil1H8
>>577 >でも、「読んだはずなのにメールが見たありません。自動的に
>捨てられちゃったのでしょうか?」っていう奴が増えそう…
確かに・・・。
でも、自分としてはできるだけいらない情報を排除できる
仕組みが欲しいんですよね。
ほかにもCocoMonarのスレ一覧テーブルみたいにいらないカラムを
非表示できたりしたらいいかも。
特殊な機能がたくさん付いてるソフトっていうのは
その機能が理解できない人からしたら無駄な機能満載な
ソフトになってしまうのが欠点。難しいところだ・・・。
579 :
577 :03/01/14 12:44 ID:+enp1jph
>>578 技術的に可能かどうかは別として、576氏が言われるような付随機能は
プラグイン方式をとったらいいのでは?
名無しメールと名乗るなら(?)基本型が見えないぐらいそのユーザの志向が
プラグイン(またはカスタマイズ)できる!なんてのはどう?
1氏の責任範囲は「基本型」のみで後はカスタマイザーに責任を持ってもらって…
あ〜ぁ プラグラム出来たらなぁ〜口だけ星人でクチオシヤ…
580 :
576 :03/01/14 14:27 ID:gbdil1H8
>>579 >名無しメールと名乗るなら(?)基本型が見えないぐらいそのユーザの志向が
>プラグイン(またはカスタマイズ)できる!なんてのはどう?
これってある意味アプリケーションの究極の姿ですよね(w
こういう風になったら凄いイイ!
あとはいかにプラグインが作りやすくなるか? かな?
1さん、ホームページの方、フレームの左側が文字化けしてみえないです…
582 :
577 :03/01/14 16:04 ID:+enp1jph
>>581 ブラウザのエンコード弄ってやれば見られる
>>582 今見たら直ってました…すみませんですた
1さんがなおしてくれたのだろーか
もしそうならありがとー1さん
584 :
1 :03/01/14 21:50 ID:ZRPpTPgN
こんにちは。色々ご意見ありがとうございます
だしていただいたアイデアはすべてアドレスリストに追加しておきました。
>>575 そのアイデアはいいかも。1の場合もだいたいアドレスのグループによって
アカウントも分かれているので、ちょうどいい感じになりそうですね。
>>576 これもかなり便利そうですね。
一応、カスタムビューでも同等のことは出来ると思いますが、
未読のみ表示って結構頻繁に使うので、
それよりも手軽にできる手段があると良いと思います。
577さんの言うように、ボタンかなんかで簡単に切り替えられた方がいいかもしれませんね。
あと、「開封済み非表示モード」であることが一目で分かるようなUIにしておくと
勘違いも防止できるような気がします。
>>579 ,580
ぜひともそういう風にしたいですね〜。
プラグインは多分Objective-Cのプログラムでメーラー本体の
APIを呼び出しながら作ることになっちゃうと思うんですけど、
単純なものならプログラムレスで機能を追加できるようにできるといいな。
>>581 すいません、左側だけ違うエンコーディングになってました・・・
直しておきましたので、また見てみてくださいね。
585 :
1 :03/01/14 22:07 ID:ZoFLHr01
まちがいた・・・ アドレスリストに追加してどうする・・・
586 :
581 :03/01/14 22:15 ID:UFJN7/64
1さんありがとう がんがってください
587 :
564 :03/01/14 23:45 ID:zjITr5oq
アイデアリスト見やすくなりましたね!早速要望をひとつ・・・。
[分類]アドレス帳・アドレス入力 ("メール作成"になるのかも)
[機能名]送信メールヘッダでのニックネーム表示ON/OFF
これは、アドレス帳に「ハゲ課長:
[email protected] 」となってる場合、
送信メールのTo:(Cc:,Bcc:)ヘッダを
・ハゲ課長 <
[email protected] >
・
[email protected] のどちらの形式で作成するか選択できるようにする機能です。
ARENAにあったんですが、重宝してました。
>>579 さんのおっしゃるようにプラグイン形式を徹底して設計、仕様書公開すれば
とりあえずアプリの骨組みだけ作って、追加機能は募集という形式にできそうでイイ!
ですよね。
X-mailerをアイコン化したら面白いかな。
ドーデもいいことなので読み飛ばして結構です。 マウスで円を描く(クルクルと何回転かする)とウインドウが出てなくても受信する! でもCocoaGesturesで出来ちゃうのか…な?
590 :
1 :03/01/15 21:32 ID:QwIt7tUq
こんにちは。アイデアはリストの方に追加しておきました。
最近たくさんのアイデアを出してもらえてうれしいです。
>>587 1もARENA使いなので、この機能はぜひ欲しいです。
というわけで、"B"にしておきました。
>>588 それは面白い!
もろプラグインって感じですけど、FromとかCcとか、他のヘッダでも、
なんでもアイコン化できるようになると楽しい画面になりそうですね。
>>589 これも面白いなー。作り方はさっぱりわかりませんが(w
CocoaGesturesっていうのはそういうマウスの動きをひろってくれる
ソフトなんでしょうか。便利そうだな。
591 :
576 :03/01/15 21:46 ID:ln8JA40y
1サンがんばって!
どーもです。 マウスで円を描く…ってのは会社で使ってるWin用のランチャーで あるんです。nrLauncherってやつ。 で、マウスでクルクルと円を描くとランチャーが現れる これのパクリです。へへ
アリーナでアカウント設定いじってると いつのまにか他のアカウントが自動署名になっちゃったりしてる 時があるんだけど、ああいうバグは困りますねー。 差出人をフリーメールのアドレスにして匿名でメール送ったつもりなのに、 個人ページのURLと電話番号くっついて送られてしまいかなりびびったことがあります。 攻撃してたわけじゃないのでw 何事もなかったけど、 それからはメール作成するたびに署名使わないを選ぶ変な癖がついてしまいました。。。
期待大・保守
595 :
アイデア :03/01/19 02:29 ID:bgHJGGRT
第1希望)とりあえず触ってみればだいたいの操作はわかるので、 結果としてマニュアルが短くて済むようなメーラー。 第2希望)その上、マニュアルの構成と文体が考え抜かれているために、 もともと短くていいマニュアルが、さらに厳選されて短いようなメーラー。 Photoshop とかのマニュアルが長大なものになるのはある程度 納得するんだけど、Jedit とか ARENA とかのマニュアルは どう考えても長過ぎる。と、思っているのはオレだけか。 結果として長い、ということよりも、読んでみて、 少しでも簡潔にしようという気迫(美学)を感じないのが嫌だ。 プログラマというものは、そういうことに情熱を持つ人種じゃないのか。 プログラミングできないヤツが言うのもアレだけど。 雑誌なんかで紹介されるときに、「それと、基本マニュアルの簡素さは特筆もの」 なんて書かれたら、非常にカコイイと思う。 基本じゃないマニュアルが肥大してでも、 基本マニュアルが簡素になることを願います。
>>595 まったく同じ考えだ。
むしろ通常の動作にはマニュアルが必要ないぐらいがいい。
一般の利用者はマニュアルを見ずにでも快適に操作できるし、
ヘビーユーザはマニュアルみて高度なことも出来るっていうのが好き。
Jeditはマニュアル読んで使うのやめた。
無駄に小難しいのはイクナイ。
>>596 えっ、おれJeditは登場当初から使ってるけど
マニュアルなんて読んだことないよ・・・?
高度なことなんて何にもしてないし。スレ違いごめんねsage
Jeditマニュアルあったっけ? 1から使ってて現在4の登録ユーザー。アップルスクリプトも含め自分に必要な機能だけ使ってます。
599 :
名称未設定 :03/01/19 23:31 ID:rzm8ttAG
金をとる以上、マニュアルをブ厚くっていう風潮があるんでしょう > シェアウェア
プログラムする能力と、物事を他人に分かりやすく文章で書ける能力は別だからなあ 本来そういう物はテクニカルライターが書くべきだけど、シェアウエア作家に そんなひと雇う資金なんかない罠。
601 :
1 :03/01/20 00:36 ID:55ab8YlT
どうも、こんにちは。 マニュアルを簡潔に分かりやすく、っていうのは 1もやりたいところなんですが、 ここらへんはぜひプログラマ以外の方々に協力してもらいたいなあ、、、 なんて思うのはちょっと図々しいでしょうか? 中身を知っている人間が書くと、どうしてもそういう視点が 入って分かりづらくなるような気がするので。 余談ですけど、プログラマでも文章にこだわり持って上手に書く人は たくさんいますよ。 文章を構造的に体系立てて書くのって、プログラミングにも 通ずるものがあると思います。
>>601 作者がマニュアル書くといらないことも書いちゃいますよね。
ひさしぶりに前の方読み返してみたら、 1さんって「OSXからのユーザ」だったんですねー。 そうか・・・ どういうきっかけでマカになったのですか。
604 :
1 :03/01/21 00:25 ID:XTO3rg0l
>>603 PBG4にひとめぼれして衝動買いしてからです。
たしか去年の今頃だったなあ。
で、1も一つアイデアを考えてみたんですけど、どうでしょう?
[分類] 検索・分類
[機能名] Googleみたいな全文検索インターフェース
検索条件を2つ以上指定するときに、いちいち複数のテキストフィールドに
ひとつずつ入力するのが面倒なので、
Googleみたいに検索条件を一つのテキストフィールドにスペースで区切ってならべて
Enter一発で検索開始、みたいなのが欲しいな、と。
で、検索結果の表示も、Googleの結果画面みたいな感じで表示。
ヒットした言葉の前後2〜3行の文章付きでHTMLみたいなリンク付きの画面出して、
リンクをクリックするとそのメールが表示されるような。
プラグイン向けって感じだけど、欲しいなあ。
おいらも欲し(・∀・)イイ!!
606 :
名称未設定 :03/01/21 22:27 ID:cA0rkgJ1
>>604 それいーね!
高速な検索エンジンさえ用意できれば...
あと結果出力方法も、実装が難しそう。いや、漏れは素人だから勘でいってるんだが。
607 :
名称未設定 :03/01/21 22:48 ID:V/mawjFe
googleみたく検索キーワードにマーカーつくといいですな。
608 :
名称未設定 :03/01/21 23:21 ID:P++xs5vx
検索機能の延長として、 条件検索に引っかかったものを、送・受信の区別無く、 擬似的に1つのフォルダに入ってるように表示する機能はどうでしょう? 特定の人とのやりとりを準チャット風に閲覧するための機能です。 行ったり来たり、を繰り返したメールなら 同じフォルダ送信・受信、両方のメールが入った状態で閲覧できるので 時系列を追ってやりとりを再読するのに便利だと思います。 (ざぁ〜っと読みましたが、既出でしたらすみません) 条件には「但し○○は除く」も設定できると尚良いかも。 その条件を保存できるようにし、 プルダウン等で簡単にいつでも実行できるようであると、 細かい条件設定をしてある場合は便利です。 アドレス帳の中の名前をクリックして、 コンテキストメニューから「この人とのやりとりを抽出する」 でもOKかもしれません。 バックアップ機能は ボタンでの表示も可能になると、とても便利だと思います。 色々と取捨選択しないと行けないと思いますが、 がんばってください。
609 :
名称未設定 :03/01/21 23:48 ID:R4S5yVaU
初めてのカキコですが、 漏れは、プログラムお勉強中のプロのライター(広告系)だす。 マニュアルづくりは、お手伝いしたいな〜と立候補です。 プログラムのお勉強は、まだ半年余・・・ とりあえずcocoaを極めようって、目標が定まった所です。 てことで、このスレがとっても気になっていたのです。
610 :
1 :03/01/22 00:39 ID:iWMzcF5V
>>606 はい、実際かなり難しいような気がしてます・・・
検索条件をスペースで切って指定する機能だけなら
簡単にできそうなんですけどね。
UNIX系のオープンソースな検索エンジンとか使えないかな?
>>608 多分、既に要望で上がっているカスタムビューで同等のことが出来ると思います。
でも、アドレス帳の名前から「この人とのやりとり〜」機能は
新しくて面白いなー。アイデアリストの方に加えさせていただきますね。
611 :
1 :03/01/22 00:40 ID:iWMzcF5V
>>609 おお、プロのライターさんですか。
マニュアル作りの方、よろしければ手伝ってください。
よろしくお願いします。
ただ、マニュアル作るのは相当先の話になると思いますので、
すみませんが、ちょっと待っててくださいね。
あと、いきなり申し訳ありませんが、Cocoaを勉強されているとのことで、
もしよかったらメーラーのアドレス帳部分の調査&プロトタイプの作成
なんかやってみませんか?。
MacOSXのアドレス帳と連携させるので、10.2環境が
必要になってしまうのですが。
>>609 プロのライターさんなら三点リーダーを使うのが普通では?
荒しじゃなく素朴にそう思っただけどす。気に障ったらスマソ。
613 :
609(ライターだす) :03/01/22 01:37 ID:1Wfw0Zel
>>1
>ただ、マニュアル作るのは相当先の話になると思います
ので、
ちょうど、良かったです。暇をみて、良いマニュアルって
どんなんかな・・って。ぼちぼちと研究しておきたいと思
ってます。
>もしよかったらメーラーのアドレス帳部分の調査&プロ
トタイプの作成なんかやってみませんか?。
ううう・・・。実際、どんな部品を使ってどんなscriptを
書けば、いいのかも、すぐにはイメージできないのが、
現状です。チャレンジしたいのは、やまやまですが、
かえってご迷惑をかける事になりそうな気がします。
とりあえず、過去スレ読んで、
HPのほうもちゃんと見学するつもりです。
>>612 3点リーダーっすか・・・。やっぱり。編集系の仕事だと
その辺、使わないと怒られちゃうんですかね。
漏れは広告系中心なもんで、テキスト渡して、後はデザイ
ナーさんにおまかせなんで、文字種とかいい加減なんです。
わざわざ、文字パレットとか呼び出すのめんどいし…。
しかし、2chはプロを名乗ると、厳しくて、つらいっす。
でも、がんがります。
614 :
勝手連 :03/01/22 01:43 ID:a2Zd6qtB
そっか〜? ちょと乱暴な気もするけど。
それに原稿として書くときとWebで書くときとの意識の違い、
ってのもあるだろうし。まあそんなことはどうでもいいが。
ところで、わかりやすいマニュアル(ヘルプ?)ができるには
(あるいはマニュアル《ヘルプ?》なんか無くすためには)、
少なくとも、わかりやすい環境設定パネルの構成とかを考えなきゃならんと思うわけで、
……と、いう観点から(三点リーダ二倍)、オレはプログラミングはできないけど、
勝手に環境設定パネルの構成を考えることにした。
ARENAを気に入ってずっと使ってるんだけど、
ARENAの設定パネルの構成にはいろいろと疑問も持っているのだ。
http://undmail.sourceforge.jp/1_gui.html に書いてあることを勝手に無視して勝手に考えます。
もし、お役に立てそうだという感触を得たら、footashidaさん宛にメール出します。
>>601 を読んで、プログラミングできないということを免罪符にして何もしない自分が、
ちょと恥ずかしくなったよ。いや、ちょっとだけだけど。
あまり気負うつもりはないが、できればアイコンなんかも考えてみます。
615 :
勝手連 :03/01/22 01:49 ID:a2Zd6qtB
あ、ごめん。↑さいしょの三行は、 >>プロのライターさんなら三点リーダを使うのが普通では? に対するレスです。まあそんなことはどうでもいいが。
616 :
名称未設定 :03/01/22 02:20 ID:DtNc+v6V
タブ型メーラーでユーザー(アカウント)を切り替えたい、、、
617 :
名称未設定 :03/01/22 02:21 ID:Fen1LsiY
上手く読ませるマニュアルを作ることって大事だよね。 それだけでくだらない質問とか少なく出来ると思う。 マニュアルを読んだ上で使わせるのか、それともマニュアルを読まずに 使うことができるようにし躓いたときに見るようにするのか。 うーん。むずかしいねえ。
>>609 健闘を祈る!
俺もその昔コピーライターだった・・・(現CD)
駆け出しだった頃PC-8801のカタログとマニュアルやったが、
死にそうだった覚えがある。
デザイナーをうまく使って、ヴィジュアルで、読ませるようにしないとな。
2chとはいえ、いろんな人(知識レベルの人)がいるのだから、
そこらの配慮よろしく!
(老婆心ながら)
619 :
609(ライターだす) :03/01/22 03:56 ID:1Wfw0Zel
>>618 アドバイス、どうもです。
漏れも、さること十数年まえ、スパーコンピュータのカタログなぞを
何の因果か、引き受けてしまい、ひどい目にあった事があります。
その辺のトラウマも、克服するためにがんがりたいと思っております。
そのうち、基本コンセプトなんかを提案できたらなんて・・・
今、実はお仕事中でっす。てつやかも、泣き。
>>618 > 俺もその昔コピーライターだった・・・(現CD)
すいませんが、この文脈でCDと書いてある場合、CDとは何の事(何かの
略語?)なのか、どなたか教えて下さいませんか?
>>620 CD=クリエイティブ・ディレクター(想像)
622 :
618 :03/01/22 04:15 ID:rv3jyfz3
>>620 Creative Directorの略。
ま、現場の総元締めみたいなモン。(w
>>609 がんがれ!
こっちも、あさって局入れなのに、トラブってまだ編集中・・・・
年寄りを夜中に呼び出すなって、
説教の一つも小一時間ぐらいしたい・・・が、それにしても眠い。
三点リーダーか二点リーダーかナカグロ連打かは著者、現場によって違うと思うけど…… ってタト。 必ずしもひとつのメールボックスに振り分けできないメールの扱いを 考えてて思いついたんですが、 文字列とかステータスとか、様々な検索にマッチする メールだけを表示する器、っていう考えは既出ですか? メールの実体をそこに入れる(振り分ける)んじゃなくて、 どこか別の場所にあるメールを検索のフィルタを通して提示してくれる器。 で、その器は複数作れて、常設できる(メールボックスの代わりとして)。 でもあんまり一般的なメーラーとは言えそうもないし、 そもそもメールの母集団が多いと速度的にしんどそうですけど……。
624 :
620 :03/01/22 11:03 ID:42aPcsN7
>>621 ,622
ありがとうございました。勉強になりました。
三点リーダーはどうでもいいが、読点が多すぎるのが気になる。
>>623 iTunesのスマートプレイリストみたいなやつでしょ。
いいよね。あれ。
>>623 そういう発想は Emacs のメールリーダではわりとある気が。
Wanderlust とか、ほんとに色々な機能を実現しているから、
参考にするといいかも。
>>623 >そもそもメールの母集団が多いと速度的にしんどそうですけど……。
受信したメールはハッシュか何かで分割した複数のファイルで保存。
でメーラーはそれら複数のファイルをを仮想的に全体受信メールと
して認識。
メールフォルダごとに物理的なファイルとして保存しないことに
よってすべて >626 の言うiTunesのスマートプレイリスト見たいに
メーラー上は見えるっていうのはだめかな?
629 :
1 :03/01/22 23:59 ID:nXK2DX7k
>>613 勝手なお願いしてしまって済みませんでした。
開発の方は、気が向いたらまたメールでもください。
ヘルプの方はのんびり研究しててくださいね。
こちらもかなりまたーりやってますんで。
>>614 環境設定パネルの方、考えてもらえるのはとてもうれしいです。
実は自分の作ったUIにはあんまり自信がないんですよね。
こちらの動きは気にせずに自由に考えてもらって構いませんので。
画面のレイアウトなんかは割と簡単に変更がききますし、
いろんな案があった方が最終的にはいいのができる様な気がしてます。
ところで、リンク先のものは初期案でして、
現在のUIは全く別物になっています。
ちゃんとホムペに案内書いてませんでした・・・ごめんなさい。
下のページからアプリ形式になった最新の画面がダウンロードできます。
http://undmail.sourceforge.jp/guiproto.html
630 :
1 :03/01/22 23:59 ID:nXK2DX7k
>>616 タブ型メーラーですか。また面白い案ですねー
ただ、今のところどのアカウントに来たメールも
いっしょくたのフォルダにしまうような仕様にするつもりだったので、
アイデアを生かせるかどうか分からないのですが・・・
>>623 アイデアリストの方に上がっている「カスタムビュー」と
同じ機能だと思います。
Macのメーラーだと、EntourageやMagelanなんかが対応しています。
1もこの機能はどうにか作りたいと思っているのですが、
おっしゃるとおり、メールの数が増えた時のパフォーマンスが大問題です。
作ってみなければ分からないのですけど、
あらかじめ指定できる検索条件を限定しておくと高速化できるかも。
(本文は検索条件に含められないことにするとか指定できる検索条件を
一つだけにするとか。)
631 :
1 :03/01/22 23:59 ID:nXK2DX7k
>>628 おっしゃるやり方で実現できるような気がします。
ただ、ちょっと問題になるのが、他に「他のメーラーのメールを直接読み書き出来る」とか
「メールの保存形式をユーザーが指定できるようにする」なんていうアイデアが上がっていて、
それを実現しようとするとファイル形式を一つに決められないんですよね。
ここら辺はバランス見て取捨選択するしかないのですが・・・
632 :
名称未設定 :03/01/23 01:28 ID:IYhG+ZCK
1さん、おつです。 現在メーラーはOMEを使ってるんですが、Unnamed Mail期待してまつ。 昨日は1日中Cocoaってたんですが、わけわかりません。 Cの基礎本買ってきます。 要望です。 [分類]メール作成 [機能名]"現在開いてるメールボックス毎にデフォルトの送信アカウント、差出し人を指定" "アドレス帳のグループ毎にデフォルトの送信アカウントを指定"ってのもいいけど、 メーリングリストのメールとか読んでてサクッとメール書きたい時とかに 激しく便利なのでこちらも希望。 一気にスレ読んだとこなので既出ならすんません。
633 :
山崎渉 :03/01/23 02:15 ID:ghhLiS5+
(^^)
Web屋ですが、校正やってます (って前にも書いたかな)。 なんで、どなたかマニュアルを書いていただければ、校正しますよ。 ――仕事でどんづまってなければですが。 というか、これぐらいしかお手伝いできないので……。 # あとは配布時のミラーサイトぐらいかなぁ。
こんなProjectが進行していたとは・・・完全出遅れ。 で、いまさらながらなんだけど「要望」というよりは「妄想」だな(藁 ・Local配送対応(systemから来てspoolに落ちるMailを拾う:biff可) ・上記に加えMaildir対応(Localにqmail/postfix等を入れた時を考慮) ・いまさらだけど、1 Mail 1 File(MSGID??)で、Multipart MIMEも同名+αで保存 ・SSL対応(SSL POPね) ・SMTP Auth対応 ・MailBox(1Mail 1 Fileの場合Folder単位)での暗号化保存 ・POP Pass等のキーチェーン対応 ・アプリ起動時Password認証(キーチェーンとは独立で:読まれたくないMail多いじゃん) ・マルチペインより複数Windowの方が好きだったりするので、出来れば切り替え対応 ・動作Log保存 もち、Plug-in対応でもOKって事になりますね。
636 :
635 :03/01/23 05:49 ID:3kZyon9+
書き忘れ&別件提案 ・Reply-toの追加or編集 場合によってはand ・返信時の引用の冒頭の文言の編集(user name等が変数化して入れられると尚良し) ・受信Mail保存時にContent-Type:ヘッダのcharset削除or書き換え(別メーラに読み込んだ時に化けるのよ) ・念のためだけど、送信前に「半角片仮名」チェック!! ちなみに、1 Mail 1 File 形式にすれば、Apple Event 経由でBrowserにMail File のpath渡すだけでHTMLレンダリングが出来てしまうという罠? SafariなりIEなり面痔裸なりoperaなりomniなりLynxなりw3cなり好きなエンジンを選べば良いんだから。 ただし、その場合はLink画像(添付)のpathを書き換えてやる必要が有るかもしれん。 で、もっというとLocalに案山子突っ込めば全文検索出来るんじゃない?? 名無しはそのGUIだけって事で済む。 いえ、1 Mail 1 Fileを押し通そうってワケじゃないけど開発に二度手間、 三度手間を掛けずに機能を充実させるには手っ取り早い方法じゃないかと 思うんすよ。
637 :
635 :03/01/23 05:55 ID:3kZyon9+
>案山子 「ナマズ」の間違い。 逝ってくる。
既出ではありますが、あまり議論になっていないようなので・・・ 私はcocoaの大きなメリットである ローカライズの完全対応を目指して頂きたいです。 ご存知の方も多いと思いますが、osXのインストールディスクは、 世界で一種類だけ。50カ国語くらいに対応しています。 これと同じことをUnnamed Mail でも実現を目指すとカッコいいです。 「名無しさんなのに、世界標準。」 なんて、キャッチができてしまいます。なんか、うきうきしませんか。 実作業としては、 (1)プログラムコードを翻訳対応にしておくこと (2)翻訳者を探すこと (3)インターフェイスおよびテキストの翻訳ファイルへの組み込み。 ということになります。 (1)については、1さん、ちょっとめんどうですがお願いしたいです。 (2)は、2chならではの機動力を活かせば簡単そのもの??? 外国語を勉強してる人や留学生ならこころ良く引き受けてくれる人が いるはずです。 (3)については、基本的に翻訳者にお願いしちゃう。ということでいける と思います。マニュアルを作っておけば、プログラム経験がなくても、 少しマックになれた人なら可能です。(そこが、cocoaのすごいところ) てな、ことを、考えたのですが、いかがでしょう。
↑すいません。638は私です。
>>638 いいかも。
んでもCocoaって割とローカライズ簡単そうなので意外と(2)が大変だったりして。
>>1 アドレス帳のプロトタイプなんですけど、何かGUIのアイデアって出てましたっけ?
ざっと見た感じだと、一応メーラー内でMail.appみたいなAddressBook.app
互換のアドレス帳をつけるってとこくらいしか見当たらないんですが。
>>638 要望するまでもないよ。
Cocoaアプリなら当然だし
コード内で日本語使えないからローカライズ可で作るしかない。
>>641 やはり、普通はそうなんですか。
私の場合、英語環境のまま、ごしょごしょと日本語入れて作ってしまうもんで。
おはずかしい、限りです。(土素人です)
643 :
名称未設定 :03/01/23 21:11 ID:DaU/1klS
アドレス帳っていってもそんなにバリエーションないのでは? Apple MailにしろGyazMailにしろ同じようなもんだし。 つかその2つくらいしか知らんが。
>>638 Project Builderでプロジェクトを作成すると、英語のみをサポートしている状態
のプロジェクトファイルが作成される。
だから、正確に言うとはじめに日本語化が必要。
パッケージ内のEnglish.lprojをコピーし Japanese.lproj作成し中のものを日本語化します。
ってことは最初に English.lprojがあるのだから多各国語化するのには英語から他言語と
いうふうになるので、日本語から他言語よりは翻訳者(外人さん)楽かな?
探すのは面倒だけど…
>>640 アドレス帳の件はAddressBook.appをそのまんま利用すればいいのでは?
アドレス帳のたぐいが増えるのは管理が面倒でしょ?
645 :
643 :03/01/23 22:57 ID:DUXjQvaQ
>>644 アドレス帳が増えると面倒というのは同感だが、
AddressBook.appをそのまんま利用ってのはなー。
前に出てるように、Mail同様にOSXのAddressBookのAPI利用するようにしてデーターは共用
ってのがいい。
んで、カスタムペインやドロワーで表示できると嬉しい。
単にAddressBookのインターフェースが嫌いなんだが。
Address帳がメインというのはどう? 名前 件数/未読 受信日時 山田一郎 24 (2) 03/01/23 22:57 佐藤花子 16 (4) 03/01/23 22:39 ホゲホゲ 36 (0) 03/01/20 12:45 みたいに差出人でメールがグループ化されてんの。 何通もやりとりしてる人が前に送ってきたメールとか読むのが楽チン。
647 :
664 :03/01/23 23:31 ID:hvnBqVXL
>>645 あっそうそう、俺もそれでいいと思う。
名無しメール独自にアドレスデータを保持するのでなく
AddressBook.appのデータ共有いいよね
645さんみたいにAddressBook.appのインターフェースが
好みじゃない人は名無しメールからアドレス管理できるし、
AddressBook.appでいいやって人はそっちでも出来る…
どっちでみても同じアドレスデータが反映されるといいね
今、ウチではMail.appとARENAと宛名職人に似たようかな
データベースがって管理が面倒で…
649 :
1 :03/01/24 01:18 ID:X3o7QE87
>>632 ご意見ありがとうございます。
そのアイデアはとってもよさそうですね。
1もだいたいフォルダ毎に送信先が決まっているので
とても便利そう。リストの方に加えておきます。
>>634 いつもご意見ありがとうございます。
DayTripperさんは校正の方だったのですね。
マニュアルの方、手伝って頂けたらうれしいです。
ライターさんとかDayTripperさんとか、文章のプロの方に手伝ってもらえて、
マク板にスレ立てて良かったなあと思う今日この頃です。
650 :
1 :03/01/24 01:19 ID:X3o7QE87
>>635 たくさんの意見ありがとうございます。
内容はアイデアリストの方に追加しておきますね。
635さんはUNIXに詳しい方のようですが、
名無しメールもせっかくGPLにするので、
オープンソースなソフトの資産をできたら使っていきたいと思っています。
でもいかんせん知識が少ないので、今後も色々アドバイスいただけたらうれしいです。
Namazuも、もしかしたら使えるのかな、なんて思ってはいたんですけど、
具体的にそれをどうやってメーラーに組み込んでいけばいいのかって
考えるとさっぱりだったりします。
あと、1メール1ファイルの件なんですが、
>>631 にも書いたように
いろんなファイル形式のメールを混在できるようにするっていうアイデアがあって、
なんとかこれを作ってみたいと思っているのですね。
というわけで、せっかくご意見くださったのですが、当面は
1メール1ファイルに限定するつもりはありません。ごめんなさい。
651 :
1 :03/01/24 01:19 ID:X3o7QE87
>>638 ライターさんこんにちは。いろいろご意見くださってうれしいです。
他の方も書いてくださってますが、Cocoaで開発すると
自然にローカライズが簡単になるので、その辺は心配ありません。
ただ、1が英語超苦手のため、最初開発は日本語リソースのみで
進めていくつもりでいます。(推奨されてないのですが可能です)
というわけで、やっぱり翻訳してくださる方を見つけなければなりません。
アドレス帳については、
>>645 さんと同じで1もUIにすごく不満があります。
ATOK使ってる時のバグもちっとも直らないし・・・
そんなわけで、AddressBook APIを使ってデータだけ共有しつつ、
新しいUIを提供したいと思っています。
アドレス帳のプロトタイプを作りながら
http://undmail.sourceforge.jp/idea_list.htmlで上がっている 要望の実現方法を探っていければな、と思っていたわけです。
>>646 それは面白いかも・・・
アドレス帳とメーラーを独立させないで統合する感じですね。
内部的にはカスタムビューと同じ仕組みで動作できるように思えるので、
そういうUIを考えてみるのもありかも。
特殊なインターフェースなので、プラグイン向きかな。
652 :
643 :03/01/24 13:30 ID:QLlm/odQ
>>651 1さんは何か新しいUIのアイデアお持ちですか?
ちなみに俺は。。。ないっす。
AddressBookのUIでいやなのは重い、メタル調、メーラーのアドレス帳として使うには
一番右のペインがうっとうしい。
つーことなのでメーラーのアドレス帳としてはデフォルトはMail.appみたいなので
まぁいいかなと思うんですが。
んでカスタムペインやドロワーでも表示できると嬉しい。
って、書いてるだけだとあれなんでとりあえずアドレス帳のプロトタイプに
なりそうなやつでっち上げてみました。
ソース(かなーり適当)置いといたんでみんなでいじりませう。
ttp://www.geocities.co.jp/SiliconValley-SantaClara/1630/ こっから落として。
このスレ初めて覗いてみたんだけど。おもしろそうですね。
>>1 さんがんばってね。
>>652 シンプルでいいねぇ。
だけど、俺の中でまだアドレスブックの機能というか雰囲気が
見えてこないからなんとも言えないです。(悪い意味ではありませぬ
これを叩き台にして攻めていくのもありですね。
メーラとの一体感を出すことを考えるとまずメーラがある程度固まらないと
煮詰めにくいかなぁ。
機能の依存関係もあるだろうし。
>>646 さんの意見も好きだしなぁ。
って口だけになっちゃってすいません。
ちょっと俺なりに考えてみます。
655 :
643 :03/01/24 15:22 ID:ChFH/6zM
>>654 >メーラとの一体感を出すことを考えるとまずメーラがある程度固まらないと
>煮詰めにくいかなぁ。
>機能の依存関係もあるだろうし。
うん、確かにそうだすね。
もともとアップしたやつは自分がOME用に作ろうかと思ってた
やつをでっち上げたやつなのでしかとモードで全然OKです。
ふと思ったんだけど、Safariのブックマークみたいに全画面使っちゃうてのも
ありかも。んでその画面のときは646さんのみたいにメールを表示すると。
単なり思いつきなので要望じゃなくてオフトピです。
656 :
1 :03/01/24 21:22 ID:AbIED1kn
>>652 見せてもらいました。とてもいい感じですね〜
標準でつけるアドレス帳なので、こういうふうにシンプルで
分かりやすいインターフェースがいいと思います。
643さんさえよろしければ、これをベースとしてみんなで発展させていきませんか?
メーラ本体との一体感という意味だと、Cocoaの標準的な部品を使って
つくればそれなりに統一感は出てくると思うので、
大丈夫なんじゃないかな、と思っています。
もちろん、他にも良いアイデアがあればそれも作ってみるのもアリだと思います。
まだプロトタイプなので、いろいろ試してみましょう。
657 :
643 :03/01/24 23:24 ID:cTgDTUQs
>>656 >643さんさえよろしければ、これをベースとしてみんなで発展させていきませんか?
もちろん俺はかまいませんよ。
もともと1さんの
>もしよかったらメーラーのアドレス帳部分の調査&プロトタイプの作成
>なんかやってみませんか?。
とか、勝手連さんの
>>614 を見たときにちょうどAddressBook APIの
ヘッダ読んでたんで、んじゃ俺もってなかんじででっち上げたやつなので。
*んでもUIとかは発想が大切なのでアップすると悪いかなぁとかも
考えたんですが。ま、そんときゃシカトってことで。
シカトって聞く度にウゴウゴルーガを思い出す…
>>654 ARENAとポスペしか使ったことない世間知らずなんでわからないんだけど、
『アドレス帳ファイルはメールボックスの数だけ自動的に生成される。
メールを開いた状態からショートカットかなんかで、
同名のアドレス帳ファイルに一発で登録できる』
・・・てな仕様って、常識? たぶん結果として、
>>646 のように
使えそうな気がするんだけど。ARENAだと、どのアドレス帳に登録するか
いちいち選ばなきゃならんのが、ちょとメンド臭い。
それともそういう機能もあるのにオレが気付いてないだけか。
『すべてのメールをひとつのメールボックスで管理し、
アドレス帳の方はジャンル分けしときたい』
なんて人には、逆に不便なのかなー?
∧∧ ∧∧ ポシュ━━━━ (*゚∀゚) (∀゚*)━━━━━━!!!!!!!!!!!! 彡 ⊂ つ⊂ つ ミ (( ⊂、 / \ 〜つ )) ミ ∪ ≡ U′ 彡
(´・ω・`)行頭クウハク...
ユーザーが命名できるってことは、コピーで増やしてそれぞれを命名すれば、 まったくの別アプリとして扱える、ってことになるんでしょーか。 それだと「アカウントごとに完全別管理」派にとって ひじょーに直感的で、マニュアルも短くなると思うんですが。
>>662 そういう使い方は考えても見なかったですけど、ちょっとした工夫で
出来るようになるはずです。
664 :
662 :03/01/29 20:15 ID:U0cJaZ+g
あ、即レスどうもです。 アカウントの使い分けについていろいろ考えて周囲にインタビューしてるうちに、 「会社関係はアウトルックでプライベートはネスケ。 くつろぎ気分でメールチェックしたときに仕事メールが目に入るのイヤだから。 面倒と指摘されればそりゃ面倒なのかも知れんけど、 ややこしく考える必要ないからむしろ楽チ〜ン」 みたいな人が案外いることを知ったので、そーゆーことを思い付きました。
それだったら設定をパッケージかなんかで書き出せて、 そのパッケージをダブルクリックするとその設定で立ち上がるってのは? もちろん起動した後でもメニューかなんかから切り替えられるっと。 いや、アプリが増えても容量食うだけだし。。。
>>663 漢字Talk頃からのユーザーなら、
割と普通な使い方だったりもします。
>>666 なるほど、そうなんですか。
イメージ的にはプライベート用のメーラー、仕事用のメーラー、、、
みたいな感じになるんですよね。
面白そう、単純に動作も軽くなるだろうし(余計なメールを受信しないから)
いいなぁ、これ。
>>667 それってマルチユーザ機能で代用できるんじゃないの?
669 :
662 :03/01/30 02:22 ID:M//D5H5z
>>665 も
>>668 も正しいと思います。
ただ、インタビューするうちに感じたのは、
『マルチユーザー? ってナニ? マルチアカウント? 知らな〜い。
アカウントってナニ?え、そんなややこしいこと毎日考えるわけ?
めんどくさいよ。第一間違えちゃうじゃん』
・・・ってな層がじつはかなり多い、ということ、
(例えば、『パーティション』と言っても通じないような層)
(例えば、『デフォルト』の意味を知らないような層)
そういう人が(いわば無意識自主自然発生的に)(つまり直感的に)
複数メーラーの使い分けによって複数アカウントを管理してる実例も
けっこう[*註]あるようだ、ということです。
ま、そういう層は「UnnamedMailer」の存在を知ってダウンロードしたり
しない層だから関係ないだろ、とも考えられるけど。いやしかし、
そうじゃない層にとってもじつはとても直感的な方法でしょ、だって
上級なユーザーが「差出人を間違えちゃって鬱〜」なんて話、
よく聞くぞ、とも思います。
[*註:「けっこう」と言っても、母集団は10人程度なんすけどね・・・]
670 :
1 :03/01/30 06:09 ID:OKBFR9VX
こんにちは。だいぶ下がってきてたのであげつつ、
久々に画面プロトを更新してみました。
http://undmail.sourceforge.jp/guiproto.html まず、643さん作成のアドレス帳を本体に取り込んでみました。
本体との連携を考えやすくなるかな、と思いまして。
勝手に取り込んでしまいましたが、許してください
>>643 さん
あと、サンプルのメールデータを表示できるようにしました。
(プロジェクトのメーリングリストのメールがサンプルになっています)
やっぱり動かしながらじゃないとなかなか仕様を決めにくいので。
今後も動きのあるプロトタイプを作って色々試していきたい思っています。
>>657 ありがとうございます。遅レスですいません。
上にも書きましたが、本体の方にも取り込んでみましたので
雰囲気を見てもらえればと思います。
671 :
1 :03/01/30 06:09 ID:OKBFR9VX
>>659 メールボックスとアドレス帳が1対1で結びついているような
メーラーって、少なくとも自分は見たことないので、
そういう考え方はとても面白いと思います。
ただ、必ずしも1対1の対応が便利なケースばかりじゃないと思うので、
「メールボックス毎にデフォルトアドレス帳(グループ?)を手動で作成」みたいな
機能にすると良いかも。それで、そのメールボックス内のメールを
のFromを全部自動抽出して、まとめてデフォルトアドレス帳に登録できるとか、
そこに振り分けられた時点で、メールのFromを自動的にアドレス帳に
登録できるとか。
672 :
1 :03/01/30 06:09 ID:OKBFR9VX
>>662 なるほど・・・そういう考え方もあるのかと、妙に感心してしまいました。
確かに言われてみればメーラーの細かい設定なんかに全然興味がない人には、
こっちの方が楽なのかもなー。
なんかこれ、すごく重要なことのような気がしてきました。
なにかそういう使い方を便利にするような機能をメーラーに取り込めないかな、
などと考えてみたのですが、思いつかないまま朝になってしまったので
そろそろ寝ようかな。。。
>>665 それもいいですね。
名無しメールは設定項目が多くなりそうなので、設定のパッケージ化みたいな
考え方は是非とも採り入れたいです。
その中にアイコンやプラグインとか組み合わせて含められるようにして、
誰かが作った設定パッケージをみんなで使い回せたりできると楽しいかも。
673 :
名称未設定 :03/01/30 09:55 ID:wgr6QY+V
スレッド表示はできればA対応にして頂きたいです。
初めてこのプロジェクト拝見させていただきました。 自分には応援、または意見くらいしかできませんが、 心から応援致します。 もう少し勉強して出直しますー。
676 :
643 :03/01/30 23:31 ID:zWpZQ3d6
>>672 >その中にアイコンやプラグインとか組み合わせて含められるようにして、
>誰かが作った設定パッケージをみんなで使い回せたりできると楽しいかも。
カレイドスコープのスキンみたいで面白いですね。
プラグインを含めるとなると著作権とかちょっと
大変そうだけど。
でも設定を共有できるってのはすごくいいかも。
>>670 1さん、おつです。
あんなのでよければ全然OKです。
もともと何か表示された方が考えやすいか、と思ってアップしたものなので。
あ、ちなみに 665 = 643です。
677 :
643 :03/01/30 23:35 ID:zWpZQ3d6
>>675 >それからアドレス帳はドロワで出るのってどうでしょう(左右どちらでも)
これ激しく希望。
本文中にメアドがあった場合とかD&Dで登録できたりとかすると
便利かな、と。
もちろんウインドウがいい人はそっちを選べるようにしておけばいいかと。
>>1 さん
直実に進んでますね。
これからも微力ながら応援(できればお手伝いも)しますのでがんばって下さい!
679 :
1 :03/01/31 04:10 ID:XoYNPiK+
>>673 すみません、A対応っていうのはどのようなものなのでしょうか?
>>675 メタル調ありがとうございます、けっこういい感じかも。
「N」の意味はおっしゃるとおりです。
アイコン作るのが面倒だったので、とりあえず文字で表示させてしまいました。
本物はアイコンでやりたいと思っています。
で、ドロワーなんですけど簡単に出来そうだったので
早速作ってみました。下のページの、undproto.app_006_2.sitという
ファイルをダウンロードしてみてください。
http://undmail.sourceforge.jp/resource ところでドロワーは新規メールウィンドウにくっつけたんですけど、
本体の方にもあった方がいいのかな。
680 :
1 :03/01/31 04:10 ID:XoYNPiK+
>>676 =643
お疲れ様です。OKしてくださってありがとうございました。
事後承諾になってしまってすみません。
もし良かったら、今後もいろいろ機能追加を試してもらえるとうれしいです。
プロトの方にはいつでもマージしますので。
もちろん、画面プロトのソースを直接いじってもらっても構いません。
スクリーンショット見ました。 すごく▼・∀・▼イイ! 応援してます。
682 :
675 :03/01/31 22:44 ID:QZdn6tLu
そりゃあ本体の方にもアドレス帳ボタンつけとかないとね。
684 :
643 :03/02/01 19:32 ID:dQAz6X0b
>>679 うぉ!早速ありがとうございます。
アドレス帳は確かに本体の方にもあった方がいいですね。
2ペインで使う人には新規メールウィンドウ、およびそれぞれの
メールウィンドウでアドレス帳が表示されると便利だし、
3ペインで使う人にとっては本体にもドロワーないと不便だと思うので。
んでお手伝いなんですが、もちろんできる範囲でできる限り
協力させていただきます。ただ、AppleScript以外プログラミングとか
やったことほとんどなくて。。。
現在Cの基本書とCocoaの本見ながら勉強しております。
なんかできたらまたうpします。
685 :
1 :03/02/02 01:18 ID:lrB2LTqY
>>682 いつもありがとうございます。
ところでこの画像、せっかく作ってもらったので
良かったらプロジェクトのホームページに貼らせてもらえないでしょうか。
メインがOS9という方にも見てもらいたいので、アプリ形式で配布する以外に、
スクリーンショットも乗せた方がいいような気がしてきました。
>>683 ,684
では近いうちに付けてみます。
ところで、本体の方に付けるアドレス帳には、「To:」や「Cc:」ボタンって
いらないかな。それとも、そのボタンを押すと宛先にその人が入った状態で
「新規メール作成」画面が出るようにすると便利?
あと、「新規アドレス作成」ボタンとかもあった方がいいかな。
>>643 さん
ありがとうございます。
時間のある時にのんびりで構わないので、一緒にがんばりましょう。
686 :
675 :03/02/02 01:44 ID:W1VDe5NP
687 :
675 :03/02/02 01:59 ID:W1VDe5NP
ついでなんですが…添付ファイルの扱いはアイデアリストに載ってます?
アドレス帳がドロワーってのもいいですね。 アドレス帳のレイアウトについて 見て思ったのは、こんなに大きいなら、と言うか、 この場合一般にかなり天地がデカくなるだろうから、 縦長タテ分割の2ペインよりも ・左上:グループリスト ・右上:ボタン ・下 :アドレスリスト みたいな3ペインの方がいいかも、ということです。
689 :
1 :03/02/02 14:19 ID:MMTSjrBK
いろんな機能のどこまでを基本機能とみなし、 どこからを拡張機能ってことにするか、という議論について。 【軽快性の論理】で判定するのがいいんじゃないか。 Aという機能を、「実装されてるけど使わない」状態と、 「そもそも、その機能が付いてない」状態とを比較して、 起動または動作の、軽快さに有意な差がない場合は、実装する。 起動または動作の、軽快さに有意な差がある場合は、プラグインに廻す。 作ってみないと判定できないのかも知れませんが。
>>689 お疲れさまです。
アイデアリストへの取り込み、ありがとうございます。
>何かアイデアが
まずは受信時。
いわゆる普通のメーラみたいにMIME Partを切り出してしまうのではなく、
Mail Boxに残しておく形式が良いのではないかと考えています。
(既にリストに入っていますが、念のため)
添付書類を自動的に分離してしまうと、Mail Boxだけを他のマシンに持っ
て行った際、肝心の添付が無くて困る事って有りません? :-)
さすがにViewerを使用している際にはこの部分が見えると鬱陶しいですけど。
例えばNewsWatcherみたいにMSGを選択して「抽出」するってのでも良いし。
(これで、分割送信されたMailにも対応出来る?)
送信時も、やはり受信時と同じく「現状保存」が良いかと。
添付して送信した後に、修正入れたり回復不可能なダメージを受けた場合、
送信Logから再現出来るってのは、仕事でMail多用している時には嬉しい機
能だったりするかもしれません。
BackUp替わりに使うってのも面白い?
・・・ま、Mail Boxの容量は増えちゃいますけどね。
692 :
名称未設定 :03/02/03 19:39 ID:94YArpb1
すみません初心者なんですけど 宛先とかCCとかのところをsafariのBookmarks Barのような外見にしたらかっこいいと思います iChatのAvailable Awayの表示のように なにも手伝えませんが がんばってください
>>692 使ってバグ報告したりそうやって要望出したりだって立派な手伝い。
卑下することないよ。
694 :
1 :03/02/04 00:30 ID:6FZppGLq
>>690 なるほどです。一つの基準として充分役に立ちそうです。
参考にさせていただきます。
基本機能とプラグインの境界は、そろそろ決めていかねばいかんな、
と思っています。(そうしないと仕様が固まらない・・・)
>>691 どうもこんにちは。
1も、どちらかというとMIME Partは切り離さないでおいておける方が
安心感があって好きです。デフォルトはそうしたいですね。
もちろん、切り離したい人もいると思いますので、
切り離せるような仕組みもあった方がいいと思うのですが。
あと、ちょっと話がずれますが、バックアップっていう観点からだと、
送受信ログをメールボックスとは別に生の形式で保存出来て、
そこからメールを復元できるようにする、というやり方なんかもどうでしょう。
メールボックスが変になった時なんかには便利かなと。
ますます容量が増えちゃいますけど・・・
一応、ログを残す期間も設定できるようにして。
あと、添付ファイルについては別分類としてまとめてみましたので、
良かったらまた見てみてください。
http://undmail.sourceforge.jp/idea_list.html
695 :
1 :03/02/04 00:31 ID:6FZppGLq
>>692 Safariのあのボタンはかっこ良くてよいですね〜。
できたら作ってみたいと思います。(すぐにはできないかもしれませんが・・・)
あと、693さんも書いてくれていますが、みんなでアイデアを出し合って
メーラーを作ろう、というプロジェクトなので
初心者だからとかあまり気にせずにこれからも
色々意見を出してもらえればと思います。
どもです、自分じゃプログラムとか組めないから感心して見よったとですが
何げに思い付いた点をば
外観の件で
>>692 さんがSafari風にするとカコイイって思いますので、テーマの差し替えが出来る、または自分で作れるように出来んもんでしょうか??
詳すぃ人ならプロジェクトビルダーで入れ替えとか出来ますが、何も知らない人もおるけんですねぇ
御一考してほしかです
697 :
691 :03/02/04 06:23 ID:tCV5+Djz
>>694 >送受信ログをメールボックスとは別に生の形式で保存出来て
それって、もしかして1 Mail 1 File(Directory)管理になっちゃうのでは? :-)
個別Fileを恒久的(任意)とし、Logを一時的な物として考えると良いのかも。
もち、Logは実FileのAliasとして存在し、設定によ残存期間を設定出来る様に
するという感じになるのかな。
698 :
名称未設定 :03/02/04 22:37 ID:tBIiEgfJ
ガイシュツならスマソだがMail.appの迷惑メールを自動的に判断してゴミ箱に移動させる機能はパクってほしい。 ログもろくに読まない奴に言われてもいい気はしないとは思うけど、がんがってください。
700 :
675 :03/02/04 22:51 ID:RwixZN2A
>>689 (1さん)
スクリーンショット見させていただました(恥ずかし…)
ノーマル(アクア)のほうもあった方がいいような…
それと
添付ファイルのアイデアリスト件遅ればせながらご苦労様でした。
PS
会社で串規制で書き込めないので辛い…
んで、 今何%くらいつつんでるんですか? (*´д`*)ハァハァ
702 :
名称未設定 :03/02/05 02:28 ID:2m5DAVsO
703 :
697 :03/02/05 02:37 ID:uqqiTEdB
アイデアリストなんですが、UNICODEは片仮名じゃ無い方がスーパーや コンビニと間違いにくくて良いと思うんですが :-)
いまからプラグインを作りたくてうずうずしてます。
>>702 スマソ・・
そうだよね。1さんのプレッシャーにもなっちゃうし。
アントラージュがあまりにも重いので焦っちゃった。
申し訳ない。ヽ(´ー`)ノマターリ
OS 9までの「初期設定」ってのは「Preference」の日本語訳だと思うけど、 OS Xの「環境設定」って、どういう英語の訳なの?
707 :
名称未設定 :03/02/05 22:15 ID:wbSPZoJ6
やっぱり「Preference」じゃないですか?
708 :
1 :03/02/05 22:29 ID:4tUqmWJ7
>>696 ご意見ありがとうございます。
テーマ(スキン)については、以前から要望に上がっていたのですが
作るのが大変そうという理由で対応しないことに決めていました。
でも名無しメールの性格上、テーマの変更ができないのは
イマイチかな、なんて最近思い始めてちょっと揺れ動いてます。
作り方くらいは模索してみようかな・・・
>>697 うーん、1Mail1Fileとする手もありますが、それ以外のファイル形式でも
できると思っているのですが。
考えていたやり方は、日付毎とか月毎にログファイルを一個作って、
POPサーバから取得したメールデータをそのままファイルの末尾に
どんどん追加していく、っていうなんとも単純な方式でした。
709 :
1 :03/02/05 22:29 ID:4tUqmWJ7
>>698 迷惑メール対策ですか。確かにあると便利そうですね。
Mail.appはあまり使ったことがないので使い心地は分からないのですが、
迷惑メールかどうかをどうやって判別しているのか検討がつかない・・・
>>699 hotmailの解析結果ですね。ありがとうございました。
hotmail使っている人って実際かなり多いみたいですね。
対応はプラグインでっていう方向で考えているのですが、
うまくいったら多くの人に使ってもらえるかな。
>>700 お疲れ様です。
アクアな画面の方も確かにあった方が良いですね。
1も使っているCATVプロバイダが串規制で書き込めないため、
一日一回ダイアルアップでまとめレスです。つらい・・・
710 :
1 :03/02/05 22:30 ID:4tUqmWJ7
>>701 ,702,705
うーん、まだプロトタイプ作っているだけなので、
全体的にみると5%くらいかな・・・
出来る範囲でマイペースで作業してますので、
NGワードにするほど気にしなくてもいいですよ。
ハァハァされるほど期待されるのはちょとうれしいです。
>>703 はい、直しておきます。
標準規格はちゃんと表記するクセつけないとな・・・
>>704 プラグインの仕様を公開できるのはだいぶ先の話なので
その前に本体の開発やってみたいなーなんて思いませんか?
712 :
名称未設定 :03/02/05 23:54 ID:nhnth9IM
>>1 さん
乙です。スキンというほどではなくて、アイコンを変えられるだけでも便利かも。例えば、
"Undmail.app/Resources/Sent.tiff" の代わりに、指定されたアイコンセットのSend.tiff
("~/Library/Application Support/Undmail/Iconset/Safariset/Sent.tiff"のように)を
読み込むことができれば、イイ!
ARENAのアートセットの様な独自形式よりはこちらのほうがいいかと思います。
ヘタレなじぶんには712さんの言ってることが理解できないけど、
なんとなく素晴らしい提言のような気がする・・・。
711さんにもありがとー。
ところで。
コピペを繰り返して、環境設定の画面イメージを勝手につくりました。
機能のまとめかたの提案、という面と
機能自体の提案、という面と
UI の提案、という面とか、いろいろまぜこぜになってるんで
ややこしいんだけど、とりあえず晒します。ご批判くださいませ。
(OS 9.2でIE5、しか、表示確認してません。)
http://www.geocities.jp/blue_tyo/nanasi/nanasi.html ※「名付けの儀式」は、環境設定からじゃなく、
「名無しメールについて...」から行う、というつもり。勝手に。
※フィルターも、環境設定には入れてません。勝手に。
※フィルター設定画面のイメージも考えてみたいと思います。
まー、確定申告作業が済んだら。
※「メール作成」とか「印刷」とかには興味ないので、考えてません。すいません。
基本機能もプラグインにして本体の機能はプラグインを読み込むことだけ というのはどうでしょうとか言ってみるテストヽ(´ー`)ノ
プラグイン同士で衝突しまくりの悪寒...。
>>712 NameraでNFaceってのがあって、AppleScriptsでリソース内の
アイコンを書き換えられるヤツみたいなのでいいんじゃない?
それをUnNamedMailに内包するか、別アプリにするかは
>>1 さんに
決めてもらえばいいんじゃないのかなぁ?
>>713 いゃ〜面白いことやってますね。興味津々
環境設定のGUIって自分は結構重要視するんです。
ここが分かりづらいと使うのヤになっちまう…頑張って
フィルタもあるといいなぁ…
717 :
1 :03/02/06 23:29 ID:IG9TzRG9
>>711 アクアの方も作ってくださったのですね〜。いつも助かります。
というわけで、早速反映してみましたので、また見てみてください。
>>712 なるほど・・・これはとってもいいアイデアだと思います。
こういう形式にしておけば、すごく簡単にアイコンセットが出来てしまいますね。
アイコン作れない人でも色々楽しめそう。
是非採りいれたいと思います。
718 :
1 :03/02/06 23:30 ID:IG9TzRG9
>>713 =614さんでしょうか。
環境設定案、見せてもらいました。
すばらしいです。とても気に入りました。
ヘルプと環境設定が一体化しているのは、初心者にはとてもわかりやすいと
思いますし、いちいちヘルプを見なくてよいから、上級者にも楽だと思います。
あと、アイコンもシンプルで落ち着いていて、それでいてちょっと
あったかみもあって、1的には大好きなデザインです。
それから、ラベルとボタンの間に「...」が入っているのは、
ラベルとボタンの対応関係を分かりやすくするための配慮でしょうか。
細かいことですけど、とても見やすくなると思います。
あと、少し気づいた点も上げておきます。主に機能的な面です。
結構細かいことを書いてしまいましたが、気に障ったらごめんなさい。
pref:A 差出人について ・「差出人」と「差出人名」を別々に指定できることの意図が ちょっとよく分かりませんでした。 pref:A 警告オプションについて ・「〜というアドレス帳に含まれる」という部分には、アドレス帳に登録された グループ名を指定するのでしょうか。 だとすると、文字列でそれをユーザーに指定させるのはやや不親切のような気がします。 プルダウンメニュー等を用いて、アドレス帳のグループを選択できるようにする方が 良いのではないでしょうか。 ・警告オプションとして指定できるのが、文字列とアドレス帳各4つずつという風に 固定化されているのは、少し柔軟性に乏しいような気がします。 テーブルやリストなどを使って、いくつでも登録できるようにした方がいいのかな、 なんてちょっと思いました。(4つあれば実用上は充分かもしれませんが・・・) ・でも、アカウント毎にメール作成ウィンドウの色を変えられるのはとってもイイです。 pref:A マルチユーザーについて ・OSXだと、あまりマルチユーザーの機能って出番がないのかな、なんてちょっと 思ったのですが、どうなのでしょう・・・。
あと、環境設定パネルのアイコンにある「ショートカット」というのは、 何を設定するところなのでしょうか。 それから、アカウントの組み合わせの考え方はARENAのサーバーセットの考え方に 基づいていると思ったのですが、 アカウントをそもそも一つしか持っていない人にとって、サーバーセットの 意味って少し分かりにくいのではないかな、なんて思っています。 ARENAみたいな簡易設定モードもあった方が良いような気がします。 (これは、1の作った環境設定パネルでも同じなのですが・・・) 以上です。
721 :
1 :03/02/06 23:32 ID:IG9TzRG9
>>714 実は、メーラーの基幹部分のプロトを担当している方(
>>540 とかの方です)が、
そういうやり方を考えてくれていて、実装中だったりします。
衝突もうまく避けられるかもしれません。(ですよね?違ったら指摘お願いします)
>>1 お疲れ様です。
マルチユーザの件ですが、アカウントを多数持っていてそれでいて、そこで
メールを全く別々に管理したい俺にとっては便利な機能だと思います。
>662で提案された事を実現されるのであれば、マルチユーザ機能は不要かも
しれませんが。
723 :
643 :03/02/06 23:52 ID:1soVQpXA
新規メールの作成画面を考えてみました。
今あがってるプロトの画面だとちょっと宛先とかの順序に
違和感があったので(個人的には、ですが)。
つってもいじればいじるほどふつーの画面になってまうなぁ。
んでついでにリストにあがってた"Reply-toの追加or編集"をシートで
編集するのはどうよ?ってことでくっ付けてみました(headerボタン)。
ヘッダの編集とかしない人は全然しないと思うんで。
ついでのついでで
"宛て先欄の横にあるボタンを押すと 種類別に階層化されたメニューが出てきて
宛て名(Eudoraでいうニックネーム)を選択できる"
ってのもちょこっといじってみました(To:のみ、AddressBookのデータ使用)。
スクリーンショットなどはまたこっから。
ttp://www.geocities.co.jp/SiliconValley-SantaClara/1630/ (ごめん、直リンぢゃなくて)
724 :
643 :03/02/06 23:53 ID:1soVQpXA
>1さん 毎度おつです。 ハァハァしながら待ってます(w >もちろん、画面プロトのソースを直接いじってもらっても構いません。 プログラムの行数が300を超えると頭がわかめになるので、 今回も自分で"プロト"の"プロト"をでっち上げてしまいました。 もちっと俺の頭が良くなったらいじらせていただきます。
725 :
712 :03/02/07 00:25 ID:+U+kem/T
726 :
713 :03/02/07 03:00 ID:4jVHMxwJ
あ、突っ込みありがとうございます。
小心者なんでけっこうどきどきしたんですが、
晒しただけの意味はいちおうあったようでうれしいです。
●「差出人」と「差出人名」を別々に指定できることの意図
これはですねー、
仕事のメールは「
[email protected] 」
プライベートは「
[email protected] 」、
だけどメンド臭いので差出人名はどっちも「gondawara」と
ゆーよーな需要もあるのか? と思ったからです。
●警告オプションについて
警告オプションについてのご指摘はすべて、もっともだと思いました。
じつは現時点での本音は、「このアカウントで作成するメールに特別な
ウィンドウ色を指定」オプションさえあれば(この思い付きは
気に入ってるのー)、文字列での警告も不要かな、というものです。
●マルチユーザーについて
なるほど・・・私はマルチユーザー機能って使ったことないので、
じつは、わかりません。
>>614 は私ですが、
>>662 も私です。
ただ、
>>665 さんの「この設定をパッケージとして書き出す」という
アイデアはいいかも、と思ったので、付けてみました。
●「ショートカット」というのは何を設定するところ
すいません。「キー・バインド」です。
727 :
713 :03/02/07 03:01 ID:4jVHMxwJ
●アカウントの扱いについて アカウントの扱いというのはユーザーインターフェース以前の 根本的な問題で、まさにそこがいちばん詰めるべきところですよね。 たとえば「Becky」ではどういう扱いをするのか、とか、 いろいろもーちょっと知りたいと思ってるのですが。 >アカウントをそもそも一つしか持っていない人にとって、 >サーバーセットの意味って少し分かりにくい これはまったく同感です。 私の考えは、 ・「アカウント」という概念のもとに、 差出人、送信サーバー、受信サーバー、署名を関連付ける。 ・ただし送信サーバーに関しては「指定なし」という選択ができる。 ・そのことの意味がわからない人はこれを(???と思いつつも) 素通りするし、そのことの意味がわかる人には それは便利であろう、サーバーセットという概念は使わないが 結果としてサーバーセットみたく使える。 というものです。 ・ついでに署名の扱いについて。 「指定なし」の場合、「署名...」メニューのサブメニューから 署名を選択してカーソル位置に入れることができる。 「関連付けはするが自動挿入はしない」場合、 「署名...」が「署名」になって、指定した署名を動作1発で (サブメニューで選ぶ手間抜きで)入れることができる 「自動挿入する」場合は、自動挿入する。
728 :
713 :03/02/07 03:01 ID:4jVHMxwJ
>ARENAみたいな簡易設定モードもあった方が良いような気がします。 そうかも知れません。でも、個人的には不同意。 簡易設定パネルと簡易じゃない方との関連がなかなか把握できなくて、 つまり、初心者向きと通向きとでべつべつの入り口を作った結果、 ARENAはかえって中級者にはわかりにくくなってる面がある、と感じます。 このへんの評価は人それぞれですけど。 私としては、「アカウントいっこだけのひとはいっこだけ打ち込めば済み、 追加したい人は追加できる」を追求したいんだけど、 まだぜんぜん最適解に達してない、という点はご指摘通りです。 ポスペV.3 の設定画面なんかいじると、あ、 むしろこっちの方が優れてるかもなー、などと感じるとこもありますねー。
今のウィンドウだと添付ファイルのリストがないですね。 本文の上下どちらかに三角ボタンでリスト表示、非表示を切り替えるのが一般的かと思いますが、 添付ありのときは勝手に小皿が出てきてファイルリストを表示する。 (保存、削除、画像プレビューボタンなど込み) 画像の場合はメーラー内でプレビューできるようにする。 (本文中に表示か別ウィンドウで表示かは設定で選べるようにする) があるといいと思います。 送信メール作成のウィンドウも添付が上のアイコンだけで未実装?ですが、 アドレス帳のように小皿でリストが出るのがよいかと。 あと環境設定系、メールログ系のファイルはアプリと同じフォルダ内に 保存して欲しいです。 MOに入れて別機での受信が簡単に出来るので。1フォルダのコピーで済むのが理想です。 これだと複数作って家族で使い分けも簡単です(アプリ自体も複数になるので容量は損ですが) 最強メーラー、期待してます。頑張って下さい。
>>729 > あと環境設定系、メールログ系のファイルはアプリと同じフォルダ内に
> 保存して欲しいです。
> MOに入れて別機での受信が簡単に出来るので。1フォルダのコピーで済むのが理想です。
> これだと複数作って家族で使い分けも簡単です(アプリ自体も複数になるので容量は損ですが)
賛否両論な気もするけど、個人的には同意。
ファイルサーバにバックアップしたはいいけど、メインマシンの再セットアップが
なかなか終わらないときでも、ファイルサーバ側で受信できるというのがすごく
便利な気がする。
問題点としては、やっぱり複数ある場合の容量が厳しいんじゃないのか? ってのと、
<~/Library> を使わないのはどーよ? ってぐらいだろうか……。
妥協点は普通の初期設定は~/Library以下に収めといて、 別環境に持っていっても困らないようにアカウント情報&メールログの在り処は 別途指定できる、という感じかな。 つーか、半分ぐらいのメーラはこの方式な気がする。
732 :
1 :03/02/09 10:04 ID:LKqXMqB1
>>716 どもこんにちは。
なるほど、確かに本体とは別のソフトでも良いのかもしれませんね。
712さんのやり方も、本体に組み込むのはそれほど難しくなさそうなので、
まあ、何かしらのアイコンを変更できる手段を提供するってことで、
やり方は追々決めていきたいと思います。
ところで今、初めてNameraをいじってみているのですが、
なかなか面白い機能がたくさんありますね。画面のペイン分割の設定とか、
こういうやり方もあるんだな、とかなり参考になりました。
>>722 そういう風に使っているのですね。参考になります。
マルチユーザーと、
>>662 のやり方って境界線が非常に微妙なので、
提供するとしたらどちらか一方のような気がします。
733 :
1 :03/02/09 10:05 ID:LKqXMqB1
>>723 =643
こんにちは。いつもありがとうございます。
早速みせていただきました。
個人的に、ヘッダの追加をシートで行う方法は、表示領域を節約できるので
とてもいいと思いました。
アドレス帳の階層メニューもばっちりだと思います。
また本体に組み込ませてもらってもいいでしょうか。
Title(=Subject)の順序、個人的には今の画面プロトの方がしっくりくるのですが
この辺、メーラーによってまちまちみたいですね。手元にあるメーラーだと、
Mail.app,Entourage,NameraはTo,Cc,Subjectという順番で、GyazMail、ARENAは
Subjectが一番上に来ていました。
あ、あと643さんのページにプロジェクトのホームページからリンクを
貼らせてもらってもいいでしょうか?
>>725 どうもありがとうございます。こうやって、アイコンが変えられるわけですね。
実装方式については、上にも書きましたが、追々決めていきたいと思っています。
ところでどうでもいいんですが、山崎渉ってあちこちで見かけるけど、何者?
734 :
1 :03/02/09 10:05 ID:LKqXMqB1
>>726 =713さん
差出人のことについては、理解しました。
差出人名とメールアドレスを少し右にインデントさせたり、枠で囲ったりすると、
ちょっと分かりやすくなるかも、なんて思いました。
アカウント毎にウィンドウの色を付けるオプションは、1もすごくイイと思ってます。
なので、これを「警告オプション」みたいなあまり目立たない部分に置いておくのは
ちょっともったいない気がしなくもないです。
もっと目立つ部分(アカウント設定画面の最初とか)にしても良いかなと思いました。
他の文字列の警告オプションについては、アカウントの設定画面に置くのではなく、
「メール作成」の設定画面に「送信時チェック」みたいなものを置いて、
半角カナチェックとかとまとめて設定出来るようにするというのはどうでしょうか。
あと、713さんの、アカウントの考え方については理解しました。
サーバーセットとは少し異なりますね。ちょっと勘違いしていました。
確かに、ARENAのアカウント設定は最初かなりとまどいました。
設定できるのは、簡易設定と、サーバーセットなので、
フツーのマルチアカウント設定はどうやってやればいいのかな、と。
多分ですが、メールのアカウントに受信サーバと送信サーバの2つが
あることの意味を理解できている人ならば713さんの画面で充分わかりやすいと思います。
なので、その2つがあることを理解していない人向けにどういう支援が出来るかを
考えていけば良いのかな、と思ったのですが、いかがでしょうか。
考えられるパターンとしては、
(1)初回起動時のウィザード。(名付けの儀式と一緒にやる)
(2)環境設定画面中のヘルプを、とにかくわかりやすくする。
(3)そもそも無視(初級者は名無しメール使わないだろう、と想定)
あ、それから713さんの画面案のページに、プロジェクトのホームページから
リンクをはらせてもらってもいいでしょうか。
735 :
1 :03/02/09 10:06 ID:LKqXMqB1
>>729 添付ファイルの表示ってまだ何も考えてなかったので、案を出してもらえて助かります。
三角ボタンで表示よりも、ドロワー使った方が作るのはラクチンなんで、
1度729さん案で画面イメージを作ってみたいと思います。
一点不安なのは、アドレス帳も添付ファイルもドロワーだと表示する場所がかぶりそうな
ところでしょうか。下にドロワーを付けることも出来るのですが、
それだとちょっとイマイチの様な気もする・・・
環境設定とメールのログの件も、そういう使い方もあるのか、と
すごく参考になりました。
>>662 みたいな使い方を想定するのであれば、むしろそっちの方が
自然な保存方式かもしれませんね。
ただ、730(=DayTripperさん)や731さんもおっしゃってますが、
基本的に他のアプリの環境設定がほとんど~/Library以下に置かれているので、
デフォルトはそっちにしておいて、選べるようにするのがいいのかな、という気がします。
>>734 (1)が無難な線だと思いました。
(2)もいいですが、文章などで説明するのは少し難しいと思いました。
(3)の無視というのは少し反対です。分かりやすくしてこその最強メーラーだと思います : )
(1)だね そのうち自分で勉強して理解すれば良いし あんまり詳しく書いても余計分からなくなると言うこともありそう
738 :
643 :03/02/09 23:09 ID:JIi50oXo
1さん乙です。
>>733 あー、俺ずっとARENA使ってたからそう思っちゃうんですね。
あくまで個人的感想なので順序にそんなにこだわってるわけではありません。
なんでToが上でもかまいません。
アイデアリストのメールチェッカーって、メニューバーに常駐するやつですよね?
MailTickerみたいに。もしそうならそのメニューにもアドレスを階層メニューで
表示しとくと便利そうなんですが。
メールを出したい時にいちいちメーラー立ち上げてアドレス選ぶより、
メニューから直接アドレス選ぶ >
メーラーが立ち上がる >
アドレスが既に挿入された新規メール画面が開く
ってかんじだと便利だと思うんですけど。
あと、組み込み&リンクOKです。
1さん、こんちは!
1さんは今はARENA使ってるんでしたっけ?
Ginkoはご存知?かな〜ARENAライクなんで一度見てみてはいかがでしょうか?
英語版だけですが…一応リンク貼っときます。
ttp://www.objectpark.org/Ginko.html >>734 の件は
私も(1)がいいと思います。
後は「環境設定」の「インターネット」の「メール」から引っ張ってくるってはどうでしょう?
ウィザード方式ならその段階で「メール」設定から引っ張るか、自分で設定するかを
選択できればいいのではないでしょうか?
ウィザードってなに? 可愛いキャラクターが出て来て「ようこそ!」 とか言うヤツ? そういうことじゃなくて、「インターネット接続アシスタント」 みたいな、「一問一答を繰り返すことで設定完了」っていう意味? 後者ならいいとは思うけど、何もそこまで、、、とも思うなー。 少なくとも第一号バージョンには要らないと思う。当たり前か。 勝手な個人的感覚だけど、 「簡素だが直感的でわかりやすい」ってのが素敵なわけで、 或いは、簡素さの範囲で「わかりやすくあろうと志す」のがいいんで、 「懇切丁寧でわかりやすい」のは、あんまり素敵と思えない。 OS 9 までの「インターネット接続アシスタント」だって、たしかに 各種のコンパネを個別に設定するより親切だけど、ほんとは「各種のコンパネを 個別に設定しないと接続できない」構成の方を反省するのが本筋だと思う。 いや、ウィザードってのもプログラミング的には簡素なのかも知れないけど。 「環境設定」から引っぱって来る、ってのは、たしかに合理的ですね。
741 :
643 :03/02/09 23:27 ID:JIi50oXo
742 :
713 :03/02/09 23:47 ID:R32Nj2ye
気に入ったアイコンを手に入れたら、グラコン使えばその画像をARENAの、 たとえばメール作成ウィンドウにある6つのボタンに貼ることができる。 気に入った彼女の写真だって貼ることができる。 さらに頑張って色変換したりして、ノーマル以外に 「選択不可」「マウスが上に来た」「押した瞬間」の画像を用意するだって、 ひじょーにメンド臭いけど、決して難しくはない。 必要なスキルはごく低い、という意味では簡単だ。メンド臭いけど。 で、アートセットっていうのはそのメンド臭さを解消するための親切な工夫なんだけど、 「アートセットで手軽にカスタマイズ可能」ってことを強調した結果、 「じぶんで一個ずつ簡単に張り替えられる」ってことはさほど注目されなかったような気がする。と言うか、じつはオレはこのスレのおかげで、さいきんはじめて気付いた。 考えてると、わかりやすさとはなんだろう、てな気になるですね。 当たり前ですいません。 >画面案のページに、プロジェクトのホームページからリンク はい。はずぃけど、了解です。
>勝手な個人的感覚だけど、 >「簡素だが直感的でわかりやすい」ってのが素敵なわけで、 >或いは、簡素さの範囲で「わかりやすくあろうと志す」のがいいんで、 >「懇切丁寧でわかりやすい」のは、あんまり素敵と思えない。 禿しく同意!
>>740 んー、確かに。
そいえば、Appleもウィザード形式は勧めてなかった気がするな。
# 詳細失念。Human Interface Guideline読まないとわからん。
まぁ、付けるとしたら初回起動時に――
あなたのレベルはどれぐらいですか?
○ メールを使うのは初めて
○ メールの設定は慣れている
# 文言は仮 (当たり前だけど)。
みたいなダイアログで簡易設定と詳細設定に振り分けるとかかなぁ。
でもこれもあんまりよろしくないな……。
つか、この辺は大枠が固まってから決めた方が良いかもねぇ。
ということで (?)
>>740 氏の下記意見に同意。
> 「簡素だが直感的でわかりやすい」ってのが素敵なわけで、
> 或いは、簡素さの範囲で「わかりやすくあろうと志す」のがいいんで、
> 「懇切丁寧でわかりやすい」のは、あんまり素敵と思えない。
>>740 1さんの言ってるのは「ウィザード」って言ったってそんな大それたものではないと
思いますよ。 <キャラが出てくる
「名付け儀式」の後に
>>739 で言ったように選択画面が出て「環境設定」の
設定を使用するとした場合はそれで終わってすぐにUnNamedMailを利用で
きて、もう一方を選択したらUnNamedMailの環境設定の画面が出る位で
いいのではないでしょうか?
(自分で設定できる人なら直接設定画面に行っても問題ないでしょうし…)
>>741 (643)
メールチェッカー機能(本アプリ未起動状態での)は内包する予定なのでしょうか?<1さん
これを内包しているOSX用メーラーは現存するの?
OSX以前では「Dolphin」(知ってる人もういないかなぁ?)でこの機能を内包していたんだけど…
結構便利だったの覚えてる…
Dolphinは、同じフォルダに入った別アプリがチェックしてたんじゃなかったっけ。
>>746 >Dolphinは、同じフォルダに入った別アプリがチェックしてたんじゃなかったっけ。
そうだったけ…ゴメン
745でのチェッカー機能のことは忘れてください… アイデアリストに「別アプリと意識させないアプリ構成」とちゃんと書いてありました(鬱
試しにインストールしてみたら断わりもなくメニューバーに独自メニュー (しかもお茶目なイラスト付き)を追加したのでムッとして、 すぐ捨てた記憶がある... 便利だったのかー、アレ。すまんかった。 できれば「メールチェッカをメニューバーに常駐させる:on/off」を 初期設定で選べるようにして欲しい。 いま考えてみると、もしかしてDolphinも選べたんだろーか。
>>749 さんの機能だけじゃなくって
OS9機能拡張マネージャーの様に追加したプラグインをon/ofできるようにした方がわかりやすいともいます。
チェックボタン/プラグイン名/プラグインのバージョン/プラグインの種類/プラグインの機能の説明
っていうリストで環境設定で設定できるといいかも
「初回起動時に名付けの儀式」ていうのは、すでに確立された 合意事項なんでしょうか。そうだったらあまりかき回したくないけど、 そうでもないとしたら、『初回』はちょっとなー、と思うんだけど。 「まず命名しないと起動できません」、なんて言われたら、面倒なメーラー 要らねーYO! つって速攻で捨てるひとだって結構いるんじゃないか。 それに、予期せずそう言われて、その場でいきなり気の効いた名前を 思いつくというのも、一般論として難しいし。 「『UnnamedMail』(あるいは『名無しメール』)っていうヘンな名前だけど、 じつはユーザーが命名し直せる」って程度の方がいいんじゃなかろーか。
参考までに httpmail plugin www.geocities.com/danielparnell/macosx.html Mail.appでhotmailが見られるようにするプラグイン(β版・フリー)
>751さんのレスを読んでて気になったのですが、「名付けの儀式」を 行なってもPreferencesの設定ファイル名や「UnNameMail」の専用 フォルダなんかの名前はどうするんでしょうか? それぞれのファイルやフォルダ名は「UnNameMail」うんねんになるんで すよね。そうしないとサポートなどもやりづらくなるし… 自分は単にアプリケーションメニューのところやアプリケーションについて の部分・スプラッシュで表示されるぐらいに「名付けの儀式」で命名した 名前が適用される程度に思っているのすが… >「まず命名しないと起動できません」、なんて言われたら、面倒なメーラー >要らねーYO! って部分はそれはそれでいいんでないの?閉じられた感じがしてしまうかも しれないけど、それをこのメーラーの「個性」としてHPで謳っておけばいいと 思うのですが。 はじめにある程度のユーザのターゲットを決めてみた方がいいのかな? 1.初心者にも分かりやすいものにする 2.ある程度(微妙…)メーラーの設定・操作に慣れている人をターゲットにする 1.の場合は前途の設定ウィザード(みたいなもの)なんかや、各設定での丁寧な 説明が必要となってくるでしょうし、2.の場合だったらある程度は手抜き(ちょっと 語弊はあるけど)でReadmeに簡単に説明があればいいと思うし… 皆さんは、どうですか?
>それはそれでいいんでないの? という点は、たしかにそれはそれでいいのかも、とも思います。 設定ファイル名や専用フォルダ名なんかはどうなるのか、というあたりは、 じつはばくぜんと疑問を持ちながら、深く考えずにやり過ごしてたなー。 それらの名前が『UnNameMail xxxxxx』のママ、ってことだと、 「コピーで増やして別々の名前を付ければまったくの別アプリとして扱える」 って話は、それで、可能なんだろうか。
「名付けの儀式」ってX-Mailerヘッダを変えて、よりアプリに愛着をもてるように... というところが出発点だったと思う。それ以上の機能じゃないのでは...。 >753 >はじめにある程度のユーザのターゲットを決めてみた方がいいのかな? ターゲットはあらゆる層じゃないか? 本体はシンプル、プラグインで自分好みに拡張していく仕様であるし。 設定ウィザードは別アプリで提供すれば全ての人に優しい気がする。 俺は余計な機能はつけんなゴラァ派なんですよねw さて、1タソはちと前の書き込みでメーラの基本機能もプラグイン化するような方向もあると 言っていたから、マニュアル作りは難しいかも。 基本機能も他のプラグインですげ替えることができるのなら、本体の説明はどこまで すればよいことやら、、、なんてことに。 プラグインをメーラにインスコしたら、マニュアルもシームレスに項目が 増える、差し替わる...ような感じだとよかね。
>>755 >プラグインをメーラにインスコしたら、マニュアルもシームレスに項目が
>増える、差し替わる...ような感じだとよかね。
プラグインって詳しくないからわからないけど、こういうことをしようとしたら
アプリ自体に『プラグインを読みこむ』ってメニューを用意するかプラグインを
インストール形式にするかってことですよね。
単純に指定のフォルダに投げてやればいいってことでもなさそう。。
まぁ、アプリ自体に読み込むメニューが有った方が分かりやすいからいいけどね。
それとも普通はこういう風にするものなの?
>>756 現状ではpluginの認識の仕方まで話が進んでないので、
インスコっていうのは「指定のフォルダに投げる」「メニューから呼び込む」も何も
定まっとらんです。もっと広義に考えてくれ。
758 :
756 :03/02/11 18:21 ID:X1zYJQXj
>>757 いわれてみればそうですね。
失礼しました。
759 :
1 :03/02/11 19:09 ID:DtL1HDAy
>>738 ,741=643
お疲れ様です。
リンクの件、ありがとうございます。近日中に加えさせていただきます。
1も順序にはこだわってないので、どちらでもいいのですが、
一応Mail.app使っている人が多そうなので、とりあえずそれに合わせておくということに
しとこうかな、なんて思っています。
メールチェッカーにアドレス表示出すというアイデアはとてもいいと思います。
メールチェッカーについては、実はまだ何にも考えていなかったので、
そういうアイデア大歓迎です。
あと、MailPeeperと、MailTicker、どちらも試してみました。
ちょうどMailTickerみたいなイメージを思い浮かべていました。
MailPeeperの方は、そのままだとメニューには表示できないみたいですが
(できるのだったらすみません)
自分で拡張してメニュー表示しているのですか?
実はメニューバー表示するプログラムの実装方法を全然知らないので、
もしも良かったら、なんですけど、
ソースを見せてもらったりなんかできないでしょうか・・・
760 :
1 :03/02/11 19:09 ID:DtL1HDAy
>>739 =700=675
こんにちは。Ginkoさっき落としてみてみました。
まだ開発途中な感じですが、たしかにちょっとARENAっぽいですね。
スレッド表示の仕方が特に面白いなー。
Replyのメッセージは件名なしで、差出人だけ表示していますね。
メールリストの見た目が、とてもすっきりします。
OSXの場合、部品の作りが基本的に大きいので、
表示項目をいかに少なくするかっていうのが良いUIのテーマになるんじゃないかと
ちょっと思いました。これはとても参考になります。
>>742 =713
こんにちは。
ARENAってボタン一つ一つアイコン変更できたのですね。知らなかった・・・
と思ってやってみたのですが、うまくいきませんでした。OSX版はできない?
あと、リンクの件ありがとうございました。近日中に貼らせてもらいます。
わかりやすさって、確かによく分からないですね。
わかりやすさと便利さは違うし、そもそも使われなければ分かりやすくても意味ないし・・・
761 :
1 :03/02/11 19:10 ID:DtL1HDAy
>>752 どうもありがとうございます。
Mail.appって、プラグインが組み込めるようになっているのですね。
ちょっとびっくりです。
hotmailを使っていないので動かしてはいないのですが、
ReadMeを読んだ感じだと、プラグインを適用するとアカウントの作成をするときに
指定できるアカウントの種類が増えるようになっているのですね。
とても参考になりました。
762 :
1 :03/02/11 19:11 ID:DtL1HDAy
ここからは話題毎にまとめレスです・・・
・環境設定画面のインターフェース、ウィザード等について
基本的には、おっしゃる通りだと思います・・・
ただ、画面を簡素に保つことと、知識のない人でも簡単に使えることって
いうのはやっぱり相容れないものがあるような気もします。
740さんの意見を読んだ上で考えたのですが、
いわゆる「初級者」はターゲットからはずした方が良いと思いました。
分かりやすい設定画面っていうものが、どういうものなのかって考えたときに、
1が思うのは、「設定項目の意図が伝わりやすい」というものです。
つまり、使い手がそれを設定することでどういう効果が得られるのかが
予測できて、なおかつ予測通りに効果が現れるということです。
ここで、最小限の情報だけから、使い手が高い精度で効果を予想できるようにすれば、
簡素で分かりやすい画面が実現できるのではないでしょうか。
でも、最小限の情報から効果を予測するためには、ある程度のバックボーンっていうか、
経験値が必要だと思うのです。それがないことを前提としてしまうと、753=675さんが
言うように、やっぱりウィザードや丁寧なヘルプやらで積極的に
支援しなければならなくなってしまいます。
そういうわけで、ターゲットを完全に中級者に絞って、その人たちにとって
簡素でわかりやすい画面作りをしていくのがいいんじゃないかな、と思うようになりました。
ターゲットを絞って考えた方が、変にいろんな層に対応しようとしてバランスを崩したものより
結果的に初級者にとってもわかりやすいくなるかもしれないです。
あと、初級者や上級者に対しては、
>>755 さんが言うようにプラグインという仕組みで
拡張できるとすれば、それでカバーできるので、その辺は今は考えなくてもいいかもしれません。
こんな方針はどうでしょうか?
763 :
1 :03/02/11 19:11 ID:DtL1HDAy
・名付けの儀式について
個人的にはやっぱり初回起動時がいいのかな、という風に考えています。
753=675さんが言うように、それがこのメーラーの売りなわけなので、
やっぱり前面に出していった方がいいんじゃないでしょうか。
初回の名前を入力する画面に、「後で考えたい場合はとりあえず完了を押して下さい」みたいな
メッセージを入れておいて、デフォルトの名前ですぐに起動できるようにしておけば、
面倒な人にもそれほど手間はかからないかな、と思っています。
あと、設定ファイルやフォルダの名前をどうするかってことですが、
多分、技術的な制約に左右されるので、調べてみないと今はなんとも言えないです。
ごめんなさい。
・プラグインについて
プラグインの提供方法や、インストール方法などについては、
>>757 さん(=masakihさん?)が
言うようにちょっとまだ決まっていなくってなんとも言い難いところなのですが、
>>750 さんや
>>755 さんみたいなやり方が実現できれば確かに面白いですね。
プラグインとマニュアルを連動させるためには、プラグイン自体にマニュアルなり、
ネット上のURLなりを埋め込むことも考えなければならなそうですが、
ちょっと大がかりになってしまうかな。
764 :
643 :03/02/11 19:59 ID:UUlxL5Sf
>>759 >実はメニューバー表示するプログラムの実装方法を全然知らないので、
>もしも良かったら、なんですけど、
>ソースを見せてもらったりなんかできないでしょうか・・・
もちろん了解です。
MailPeeperがGPLとして公開されているので変更点を明記してソースをアップしておきました。
//anneとなっているのが変更したところです。
んで、メニューバー表示する部分は
applicationDidFinishLaunching : (NSNotification *) aNote内に記述してあります。
あと、Target設定のInfo.plist Entries内のExpert Viewで、LSUIElement = 1 を
指定してあります。
あ、info.plistのidentiferを変更しているのでアプリ動かすときは
オリジナルのMailPeeperでアカウント設定してあってもアカウントの再設定が必要です。
ttp://www.geocities.co.jp/SiliconValley-SantaClara/1630/
>>756 >単純に指定のフォルダに投げてやればいいってことでもなさそう。。
単に指定フォルダに掘込むだけです。フォルダは変更可能です。
今用意してあるのは起動時にかき集めるだけです。
バンドル形式になってますので、
ヘルプを独自に持つようにするのはそれほど難しくはありません。
Contents/Resoucese/Japnese.lproj/Documentations/
あたりに入れればいいだけでしょう。
あとは、プラグイン情報にヘルプに関するエントリを追加すればいけますね。
HTML,PDF,Textならシステムに投げるだけでなんとかしてくれるので
実装は簡単だと思います。
ただこの方法だとユーザーがどの機能がどのプラグインに依存しているのかを知っている必要がありますね。
一対一なら簡単でしょうが、Aという機能はBとCが協調動作して提供している。
んでもって、BもCも差し替え可能だとするとヘルプはどう管理するのか。
例えばプロトタイプでもPOP関連は
POPControllerがスレッド管理やユーザーとのやり取りをしますが、
実際にPOPサーバーとお話しするのはPOPEngineになってます。
これら両方が個別に差し替え可能です。
>1さん
実装遅れてます。すみません。
最近仕事が忙しくて日祝しか時間を割けません;-)
なるほど、、、 HowTo と Index と、アピール。一般論として、 マニュアル(ヘルプ)に必要なのはこの三要素だと思う。 HowToってのはつまり、いわゆるマニュアル本文。やり方解説。 Indexは「XXXってどうやるんだっけ?」と思ったときに見るところ。目次。 で、「XXXってどうやるんだっけ?」という疑問は、 「メーラーなんだから当然 XXX はできるハズだ」とか思ってる事項についてしか、 こういう疑問自体が湧かないわけで、 言われなきゃーそもそも存在に気付かないような機能については、 「アピール」が必要。 HowToは本体に付いててもプラグインの側に付いててもアリな気がするけど、 (たぶんプラグイン側の方が親切か? ちょと確信なし) すくなくともアピールとIndexは本体に付いてるのがいいんじゃないかしら。
767 :
740 :03/02/12 02:14 ID:X9Qa5Gax
>>762 >こんな方針はどうでしょうか?
支持!
特に、そういう割り切りがあった方がじつは
「結果的に初級者にとってもわかりやすい」のができるかも、
ってとこに大いに同感です。
768 :
740 :03/02/12 03:18 ID:X9Qa5Gax
>>760 >OSX版はできない?
私は OS 9.2 がメインなもので、
OS X の「ARENA Folder」にはOS 9 の方の「Users」フォルダの
エイリアスを入れて使ってます。
なのでちょっと純正 X 環境とは違うのかも知れませんが、
/Documents/ARENA Folder/Users/Main/Arts/
っていうフォルダはないですか? そこに
「Toolbar」って名前でフォルダを作って、(以下、マニュアルから引用)
************************************************
以下に説明する予約されたファイル名でPNG形式のアイコンファイルを作成し、
各ユーザーフォルダ内の「Arts」の中にある「Toolbar」フォルダ内に保存します。
(中略)(大きさの制限はない、だそうです)
・sendnow.png=即時送信
・queue.png=送信待ち
・draft.png=保留
・discard.png=削除
・address.png=アドレス
・attach.png=添付
(中略)
マウスの位置や状態によって、違ったアイコンを
表示できます。例えば、アート名をsend.pngとすると以下のようなルールで
ファイル名を設定します。
・マウスが上にある状態(eを付加):sende.png
・押した状態(pを付加):sendp.png
・押せない状態(dを付加):sendd.png
************************************************
1さん 方針、固まってきたみたいですね。 1さんの考えている方向、とても良いと思います。 期待しております。 つまんない事なんですが、名無しメールって 起動時にスプラッシュって出ます?? このへん自分好みに作ってみたいなぁなどと思っているのですが。 Cocoaアプリでスプラッシュ出るのってみたことないような 気がする...。
>>762 >分かりやすい設定画面っていうものが、どういうものなのかって考えたときに、
>1が思うのは、「設定項目の意図が伝わりやすい」というものです。
>つまり、使い手がそれを設定することでどういう効果が得られるのかが
>予測できて、なおかつ予測通りに効果が現れるということです。
個人的な見解ですが、osX付属のテキストエディットの環境設定は
初心者にもわかりやすく、1さんの理想に近い
扱いやすいインターフェイスになっていると思います。
その特徴は
1.すべての設定項目が一枚のウインドウにまとめられている。
2.めんどくさい設定は、別ウィンドウが開く。
3.設定項目のわかりにくい部分にコメント文が掲載されている。
1.については、Unnamed Mailの場合は、ウィンドウを一枚にするのは、ちと無理が
ありますが、基本設定とオプション設定の2枚(2タブ)ぐらいにすることは可能かと思います。
(何枚もあるタブは、初心者に恐怖を与え、無駄な設定変更をさせる元凶かも・・・)
2.については、ここでも議論があったように、パネルシートやドロワー、フローティング
ウィンドウなどを活用することは、無駄なくスペースを利用して、
かつわかりやすくするのに効果的です。
3.については、例え意味がいまいちわからなくても、初心者に安心感を与え、無駄な設定変更
をするのを防ぐ効果もあるかと思います。
で、前記方針でインターフェイスは作成し、
本当の初心者への情報提供や、めんどくさい設定内容などはヘルプに任せる・・・
という考え方が良いと思うのですが、どうでしょうか。
※ちなみに私は609の「ライターだす」です。今後は「WriterX」を名乗りますです。
>>766 >HowTo と Index と、アピール。一般論として、
>マニュアル(ヘルプ)に必要なのはこの三要素だと思う。
とってもわかりやすく、適切な分析だと思います。
>言われなきゃーそもそも存在に気付かないような機能については、
>「アピール」が必要。
これが、一番難しそうですね。やはり。
ひとつの方法として、アプリケーションメニューの、「この○○○○について」
(普通アプリケーション名とかバージョンナンバーぐらいしか書いていない)
を活用する手があるのではないかなあ・・・と思います。
Unnamed Mailならではの特徴をアピールしつつ、
ヘルプや環境設定とリンクさせるなんて方法もあると思います。
その他、Read meやヘルプでの冒頭、ダウンロード元なんかでアピールするのも必要ですね。
当然だけど・・・
※ところで、このウィンドウを大きくしたり、ここからリンクするのはosX的に、
反則なんてことはないっすよね。
Internet Explolerでは、サポート情報なんてのを提示しているので、いいとは思うけど。
訂正です。 ●771の下から3行目 めんどくさい設定内容などはヘルプに任せる・・・ ↓ めんどくさい設定の操作方法などはヘルプに任せる・・・
おはようございます。ゴホ…(風邪ひいちまった >762については支持します。 1さんに要望なのですがHPのほうで進捗状況が分かるように できませんでしょうか? アイデアリストの右側に10%とか…。また、現状どのアイデアが プラグインで進行しているとか…。 厳密でなくてもよいので是非お願いしたいのですが…
全体の進捗状況は5パーセントくらい、とこの前ゆってたから、 アイデアごとに何パーセント、なんて言える段階には まだ全然来てないんじゃないかしら(想像)。
776 :
1 :03/02/14 21:48 ID:m4s6cYrd
みなさん、お疲れ様です。遅レスですみません。
>>764 =643さん
早速ありがとうございます。すばらしいですね。
そのまま使わせて頂きます(w
ソースも見せて頂きましたが、NSStatusbarというクラスを使うのですね。
とても参考になりました。
777 :
1 :03/02/14 21:49 ID:m4s6cYrd
>>765 お疲れ様です。
プロトの方は、こちらも充分遅れてますので、気にしないでください・・・
忙しいところ、ほんとにありがとうございます。
確かに、プラグイン同士の協調で実現する機能もあるはずだから、
それをきれいに差し替えるのは難しそうですね。。。
プラグインには、画面を持つものと持たないものがあるんじゃないかと
思っているのですが(イメージ違ったらすみません)
仮にヘルプが、画面毎にHowtoを持つような構成になっていれば
indexも画面毎に項目が作られるはずなので、
ヘルプを持つものは画面を持つプラグインだけに限ってしまって、
indexのリンク先だけプラグインの持つHowtoに差し替える、という手も
あるかもしれません。
でも、ヘルプの構成が画面単位という風に限定されてしまうのは
イマイチですよね。
分かりやすいヘルプを目指す上で大きな制約が出来てしまいます。
778 :
1 :03/02/14 21:49 ID:m4s6cYrd
>>766-768 =740さん
このヘルプの分類の仕方、非常に分かりやすくて便利ですね。
上でも早速使わせてもらいました。
方針について、支持してもらえてうれしいです。
おかげさまで、UIについては方向性が見えてきて、少し楽になりました。
あと、ARENAについては教えていただいた方法でうまくできました。
ありがとうございました。
ARENAのヘルプには、下のようなやり方も書いてあったのですが、
これがうまくできなかったので、出来ないのかなと思ってしまいました
*****************************
・アイコンの変更
メールボックスやフォルダのアイコンは、ドラッグ&ドロップで簡単に変更できます。
Finderから、変更したいアイコンを持ったファイルやフォルダを、
コマンドキーを押しながら、ARENAのメールボックスアイコンにドロップすると、
変更することができます。"
*****************************
と、ふと読み返して気付いたのですが、これはひょっとしてツールバーのアイコンじゃなくて
フォルダのアイコンの変更のことか・・・しまった
779 :
1 :03/02/14 21:50 ID:m4s6cYrd
>>769 はい、もちろん作っていただけたらとても助かります。
確かにCocoaアプリにはスプラッシュがないものも多いですが、
Unnamed Mailがプラグインでの機能強化を強調している以上、
プラグインが多くなった場合に起動時間がかかることを考慮して
おかなければならないので、スプラッシュは必須だと思っています。
ただ、プラグインが少ない場合は起動時間はあまりかかからないと思うので、
その場合はできたらスプラッシュを切れるようにできたほうがいいですね。
780 :
1 :03/02/14 21:51 ID:m4s6cYrd
>>771-773 お疲れ様です。名前かっこよくなりましたね(w
確かに、テキストエディットくらいコンパクトにまとまっていれば、
かなり分かりやすいですよね。
でも、Unnamed Mailの場合、カスタマイズ性の高さも売りの一つにしたいので、
ちょっと2タブおさめるのは難しいかな・・・
もちろん、設定項目が多くなりすぎないように機能を抑えることも
重要だと思いますが。
あと、ヘルプの件ですが、上の方針に従うならやっぱりヘルプも
中級者ターゲットにして、簡潔な記述にとどめた方が良いかな、なんて
個人的には思います。
初心者向けのものを作るのなら、ヘルプとは別に「スタートアップガイド」
みたいなやつをホムペかなんかに公開するとかして、切り分けした方が良いと思います。
などと考えてみたのですが、どうでしょうか?またご意見下さい。
アピールのために「この〜について」の部分を使うっていうのは
面白いアイデアですね。
一つ思いついたんですけど、「知っておくと便利な機能」みたいのを1行くらいで
表示させてみるというのはどうでしょうか。
「この〜について」を開くごとに、内容が変わるようにして。
Windowsのアプリによくある「今日のヒント」みたいなやつです。
あれは起動時に表示されてうっとおしいのであんまり好きじゃないのですが、
「この〜について」の部分なら見たいときにみれるので邪魔にはならないと思います。
プラグインで「今日の運勢」や「今日の格言」にすることもできたり・・・
リンクを張るのは、いろんなアプリで同様のことをやっているので問題ないと思います。
ウィンドウを大きくするのは・・・うーん、程度によりけりだと思います。
781 :
1 :03/02/14 21:51 ID:m4s6cYrd
>>774 =700=675さん
こんにちは。風邪ですか?大変ですね。
1もちょっと最近のどが痛いです。タバコの吸いすぎか。
進捗状況ですが、775さんがおっしゃるように、まだちょっと・・・
という段階です。まだプロトなので、本物の実装という意味ではまだ全部0%です。
でも、どのアイデアの部分をプロトで作っているのか、それが終わったのかどうか、
などは示すことはできるので、それで良ければ作ります。
関係ないんですけど、最近アイデアリストの項目が増えて
管理が大変になってきたので、近々SourceForge.jpにある
「Future Requests」というやつに移そうかな、などと考えています。
http://sourceforge.jp/tracker/?atid=1208&group_id=297&func=browse でもこれ、あんまり見やすくないんですよね。
>>769 さんはたぶん、スプラッシュが表示されるなら自分好みにカスタマイズしたい、
という意味で書いたんじゃないかと思うけど、1さんの言うように、
ゼヒ勝手にデザインして勝手に公開(または1さんに送りつける)
してください。かっちょいいヤツを。
>>781 (1さん)
進捗状況の件了解しました。
>でも、どのアイデアの部分をプロトで作っているのか、それが終わったのかどうか、
>などは示すことはできるので、それで良ければ作ります。
お手の空いたときお願いします。
#風邪をひいててもつい一服、よってなかなか治らない…。
#1さんお大事に(風邪ひきに言われてもしょうがないか!?
784 :
643 :03/02/15 00:32 ID:4YDITTpU
ども、乙です。
風邪はやってますね(w
>>772 >※ところで、このウィンドウを大きくしたり、ここからリンクするのはosX的に、
>反則なんてことはないっすよね。
これはOKでしょう。なんたって「このMacについて」から"Apple System Profiler"を
起動させるくらいですから:-)
スプラッシュは必要だと思う。もちon,off切り替えれるってのが理想ですが。
へたするとメールってやたら数たまってくるのでそっちの読み込みも結構大変かと。
んで、マニュアルの件なんですが、後一つ、参照性ってのも大事かと。
indexで事足りることも多いんですが、知りたいことをサクッと検索できるってのは
重要かなと思うんですが。
メーリングリストの方でHTMLってのがでてましたが、複数ページに渡ると
検索めんどくさそう。それならまだPDFのほうがましじゃないでしょうか?
んでもそれだとプラグインが...
785 :
643 :03/02/15 00:37 ID:4YDITTpU
上の784ですが、なんかヘルプとマニュアルがごっちゃになってました。 すんません。 過去ログちゃんと読みます。 んで、ふと思ったんですが、当然プラグインによってはその プラグインのための設定が必要な場合がありますよね。 そういうプラグインの設定はどこでやるんでしょう? "システム環境設定"みたいな感じでできると少なくともOSX使ってる人には 分かりやすいと思うんですが。 ちなみに何となく熱はかってみたら37.3。 なんや、俺も風邪引いてるやん...
>>780 >一つ思いついたんですけど、「知っておくと便利な機能」みたいのを1行くらいで
>表示させてみるというのはどうでしょうか。
>「この〜について」を開くごとに、内容が変わるようにして。
これってスプラッシュが表示される時に出す事できませんか?
>>784 ,785(643)さんも仲間入り!(あめでとさん
>スプラッシュは必要だと思う。もちon,off切り替えれるってのが理想ですが。
>へたするとメールってやたら数たまってくるのでそっちの読み込みも結構大変かと。
ARENA(カーボンだけど)なんかはフォルダ数が増えただけで起動に時間かかる。
Cocoaはそんなことないんかな?Mail.appはそうでもないみたいだけど…
>>786 スプラッシュに表示されてもすぐ忘れちゃうんじゃない?
「知っておくと便利な機能」とかは、いま流行のKonfabulatorのwidgetみたいに
別ウィンドウでテキストロールするとかどうでしょう?
「未受信メールのsubject」なんかは特にメーラが未起動時でも表示できるなんて
いいとは思わない?(熱の所為で言いたい放題だオレ)
788 :
675 :03/02/15 01:58 ID:xpR7EQHG
誤 (643)さんも仲間入り!(あめでとさん 正 (643)さんも仲間入り!(おめでとさん ごめん
789 :
643 :03/02/15 02:34 ID:TFIT/g82
>>788 >仲間入り!(おめでとさん
ぬりがとう、もとい、ありがとう(w
>スプラッシュに表示されてもすぐ忘れちゃうんじゃない?
同意。
起動時に表示されるやつはまず間違いなく最初に非表示にしてまいます。
>「未受信メールのsubject」なんかは特にメーラが未起動時でも表示できるなんて
>いいとは思わない?(熱の所為で言いたい放題だオレ)
これは「未読メールのsubject」ってこと?それとも「未受信メールのsubject」ってこと?
メールチェッカをつけるんならそっちでやった方がいいかも。
メニューバーにメールチェッカが常駐するんなら、そっちで未受信の件数と
タイトルを参照できるようにしておくといいかと思うんですが。
("アイデアリスト>メールチェッカ"の項の上から三番目の
"新着あり/なしの2種のステータス表示"をちょっと拡張する感じで)
790 :
712 :03/02/15 19:20 ID:H4bDrAIl
791 :
675 :03/02/15 21:46 ID:xpR7EQHG
>>789 >これは「未読メールのsubject」ってこと?それとも「未受信メールのsubject」ってこと?
>メールチェッカをつけるんならそっちでやった方がいいかも。
それもそうだ…ね
>>790 >ここまで多機能である必要はないと思いますが、とりあえずSubject, From
>ぐらい見られると便利ですよね。
MailTickerなら今でもその程度なら出来るよ
メールチェッカは今「MailTicker」を使ってるんだけど、これと同等の機能なら独自のものは
いらないと思います。むろん親和性が高いのならUnNamedMailチェッカを優先するとは思
うけど…
>>787 で言った新着メールの「テキストロール」もメニューバー上ではあるけどやってくれるし
POP3 アカウントから個々のメッセージを削除することも可能だし…
他になんかアイデアありますぅ?<ALL
792 :
643 :03/02/16 00:01 ID:MRkyGWqb
>>791 とりあえず今あがってるアイデアリストと、MailTickerを比較してみます。
とりあえず整理っつーことで長いけど勘弁。
●A対応のもの
メニューバーに新着通知
→可能
新着あり/なしの2種のステータス表示
→できる(音声通知、新規メール数の表示)
アカウントごとに、チェックする/しない、受信もする/しないを設定
→複数のアカウントが登録できるが、登録したアカウントを一時的に、
個別にオフにはできない(独立したアプリケーションなので当然の仕様か?)
別アプリと意識させないアプリ構成
→ていうか別アプリ
すべての設定は本体の環境設定から(も)できる
→ていうか本体
メールのヘッダも表示
→FromとSubjectを表示
アカウント別メールチェック
→複数のアカウントが登録できる
秒単位でメールチェック
→1,5,15分間隔の三通り
メールチェック時間の最低ライン(警告?)
→一分。それ以下は不可。
793 :
643 :03/02/16 00:01 ID:MRkyGWqb
●B対応のもの ログイン時に起動するかどうかの選択 →まぁログイン項目に追加ということで メールチェッカーでフィルタリング →フィルタリングが何を意味するかちと分からんのだが、 一旦チェックしたメールは個別にサーバー上で削除可能 ●C対応のもの スキン →不可 簡単なログ表示 →不可
794 :
643 :03/02/16 00:02 ID:MRkyGWqb
以上をふまえてみると、A対応のほとんどはMailTickerでも可能。 ただ、MailTickerは独立したアプリであり汎用性が高い分、特定のメーラーと 密接な動作は期待できない。 たとえば ○名無しメーラー側とはまた別にアカウントを設定しなければならない。 (名無しメーラー側でアカウントを変更したり、追加した場合、別途メールチェッカ側でも 設定を変更、追加しなければならない) ○"秒単位でメールチェック"などある意味マニアックな要求には応えられない ("マニアック"呼ばわりすんません) ○カスタマイズ性が低い メールチェッカが名無しメーラーのアカウントを完全に反映してくれるのであれば、 メーラーの設定をすませれば、メールチェッカを立ち上げてメールチェックの間隔だけ 指定すればすぐ導入できるため、初心者や面倒くさがりな人でもOK。 やっぱキーワードは675さんのいう通り、親和性っすかね。 って、長々書いたけどあんま意味ないレスですんません。
俺個人的には高機能よりは低機能でも速いっていうのが好き。
ただこのプロジェクト的にはひたすら速くて無能よりもいろいろな機能が
有った方がいいのかな?そのためのプラグインですもんね。
プラグインとかを必要最小限しか入れなかった時にそれなりに速いと嬉しい!
メールチェッカは俺もMailTickerを使用してます。
今のところ不便が無いからundmailにこの機能が無くてもいいと思う。
だから
>>791 に100%同意
メールチェッカ作るって言ってるんだから作るでいいんじゃないの? 「別アプリと意識させないアプリ構成」というのは良いことでそ。 メーラ本体とアカウント設定の同期がとれるのも便利ぽ。 MailTickerマンセーな人がたくさんいるようならplugin化の方向が一番かもしれんが。
797 :
1 :03/02/16 03:05 ID:Qj3jHGxF
どもお疲れ様です。
>>782 ああ、そういう意味だったのかな・・・
>>769 さんすみません、勘違いしてしまいました。
>>784 参照性の件なんですが、OSXのヘルプビューアに対応ってことでは
イマイチでしょうか。あれはほとんど普通のHTMLで作れるらしいので
最初のバージョンではそれでいいのかな、と思っていたのですが。
メーリングリストの方でWriterXさんとも相談していたのですが、
最初はプレーンHTML+ヘルプビューアで対応して、
将来的にもう少し高機能な独自ヘルプビューアをつくる、みたいな
感じで考えていました。
で、ヘルプとマニュアルですが、実は私は同じモノと思っていました・・・
分けた方がいいのかっていうと・・・うーん、微妙ですね。
798 :
1 :03/02/16 03:05 ID:Qj3jHGxF
>>785 プラグインの設定については、プラグイン読み込み時に環境設定パネルに
動的に追加出来るようにするか、メニューに「プラグイン」みたいなものを
追加して、そこからプラグイン毎に「環境設定」メニューを用意してもらうか
どっちかかな、と思っていました。
本体側としては、何通りかのやり方を用意しておいて、
あとはプラグインの開発者におまかせ、っていうのがいいかな。
>>786 他の方もおっしゃってますが、スプラッシュだとアプリが起動したらすぐ
消えてしまうので、あんまり良くないかも・・・
>>787 別ウィンドウでテキストスクロールっていうのも面白いですね。
いずれにしても、どこかにさりげなくいれとくくらいが良いような気がします。
799 :
1 :03/02/16 03:08 ID:Z2ikjehA
メールチェッカについてですが、皆さんの意見を読んでいたら、 ちょっと優先度を落としてもいいかな、という気持ちになってきました。 現状で使いやすい別のアプリがあるのならば、 最初から作るよりも、まずは本体の方に作業を集中した方が良いかも。 でも、元々要望の多い機能だったので、最終的には作るつもりです。 なんて考えたのですが、いかがでしょうか>皆さん
800 :
名称未設定 :03/02/16 13:21 ID:4tegveax
多機能と軽快さは両立しない→じゃあ、プラグイン方式
って流れで来てるんで、
>プラグインとかを必要最小限しか入れなかった時にそれなりに速いと嬉しい!
これに同感。
>>797 ヘルプビューアに対応ってことではもちろんイマイチだと思いますが、
最初のバージョンはそれでいい、というのは同感。
というか、率直なところ、最初のバージョンは動けばそれでいい。
最終的にはMagellanの「クイックヘルプ」が個人的には理想形です。
優先順ということで言えば私の勝手な最優先は、
『フリーでオープンソースでほぼ全面的にプラグイン方式で、ちゃんと動く』
ですね。それが達成できたらそれだけでかなり素晴らしいと思ってるんですが。
メールチェッカーで他のメアドに転送するって話出てましたよね?(携帯とか) あれ、かなり期待してたんですがMailTickerというのはどうなんでしょう。
ああ、でもチェッカーで転送となるとヘッダだけになっちゃうのかな。 それはそれで半端ですね・・・
>ヘルプとマニュアルですが、実は私は同じモノと・・・ 実現性は判断できないけど考え方としては、 各局面で出るヘルプを統合するものとしてヘルプのインデックス(含:アピール) がある、ってのがいいんじゃないかなー。 と思う。 その場合に「ヘルプのインデックス(含:アピール)」のことを、 「マニュアル」と呼ぶのもアリじゃないかと思う。
804 :
675 :03/02/16 23:49 ID:7G8Id8l6
>>798 (1さん)
>プラグインの設定について(省略)本体側としては、何通りかのやり方を用意しておいて…
これはどうなんでしょうか?
開発者の立場ではないので申し訳ないですが、出来ましたらどちらか(一定の方法)に
統一してもらった方が使う側からすればいいような気がします。
プラグインによって設定方法がかわると混乱するのではないでしょうか?
チェッカの件…
643さん、比較(>792-794)ありがとうございます。
>○名無しメーラー側とはまた別にアカウントを設定しなければならない。
>○"秒単位でメールチェック"などある意味マニアックな要求には応えられない
>○カスタマイズ性が低い(一部省略)
やはりこの辺ですね。UnNamedMailの親和性を重視するなら
>メールチェッカが名無しメーラーのアカウントを完全に反映してくれるのであれば…
に尽きるでしょうね。
ですから
>>799 (1さん)の見解でいいと思います。
PS:
けして要らないと言ってるのではなく、優先度を落としても必ず搭載して欲しいとは
思ってますので誤解のないように…
805 :
1 :03/02/19 01:10 ID:344JJMRH
ども、お疲れ様です。
遅レスですみません。
>>800 そうですね・・・
最初のバージョンをどこで切るのかっていうのは
ちょっと考え直した方がいいんじゃないかと思ってきています。
今まではアイデアリストのA,B含めたものが最初のバージョンにしようかと
思っていたのですが、正直ちょっと作業の負担が大きくって、
今のままだと終わりそうな気がしません・・・
800さんが言うように、最初は動けばそれでいいやって感じで割り切るのも
一つの手ですね。さてどうしようかな・・
806 :
1 :03/02/19 01:10 ID:344JJMRH
>>801 ,802
799でも書きましたが、
メールチェッカを作らないわけではありません。
ただ、今まではメールチェッカって最優先課題だったけど、
少し優先度を落としてそれよりも本体に集中したいと思っています。
>>803 なるほどです。
マニュアルっていう響きだと頭から読むもの、
ヘルプだと使いながら参照するものっていうイメージがあるのですが、
個人的にはメーラーのマニュアルって
頭から読む人は少ないんじゃないかな、という気がしていて、
どちらかというとヘルプの項目をうまく分類して、情報を見つけやすく
する方に重点を置いた方が良いような気がします。
そういう意味で、803さんの
>「ヘルプのインデックス(含:アピール)」のことを、 「マニュアル」と呼ぶ
という意見には、賛成します。
807 :
1 :03/02/19 01:11 ID:344JJMRH
>>804 =675さん
一言で環境設定といっても色々種類があるような気がしていまして、
例えばアカウントの設定やらアドレス帳の設定ならば環境設定パネルに
作るのがいいと思うんですけど、メールボックスの設定なんかは
メールボックスからコンテクストメニューでメールボックスに独立した
環境設定画面が開けるのがいいと思います。
プラグインって、こちらからはどういう機能が作られるのか想像できないので、
どういった環境設定方法が最適なのかって、分からないんですよね。
だから、いくつかの方法をガイドラインとして示して、あとは
プラグイン開発者にまかせるっていうのがいいんじゃないかな、
と思ったのですけど、どうでしょうか。
メールチェッカについては、同意してくださってありがとうございます。
808 :
1 :03/02/19 01:13 ID:344JJMRH
>805 先週、GyazMail のサイトで修正履歴を読んでて、 メールソフトひとつ作るのがどんなに気の遠くなるような作業か、 一端を知りました(いや、知ったとは言えないけど、とにかく強くそう感じた)。 もちろん完成させることが大事ですが、そのためにも「こんな酔狂なこと 始めたせいで、いま毎日が楽しい」って感じが大事と思います。 高いハードルを設定した結果、辛さばかり感じて嫌になる、 なんてことじゃー元も子もないので。 まあとにかくなんと言いますか、ほどほどに頑張ってください。
810 :
712 :03/02/19 02:56 ID:EKmMdHWT
1さん乙です。アイデアリストを見返してiTunesっぽい画面構成っていうのをしばらく 考えてみたんだけど、パターンとしては左ペインの受信箱とかに並べて"Library"項目を 入れる形になると思います。 そして、Libraryをクリックすると右上ペインにカラムが表示され、絞り込み項目(左から "グループ"->"差出人"->"Subject"のように)表示、右下ペインに選択した条件に合致する メールの一覧が表示される・・・、とここまではいいんだけど、これじゃあ肝心のメール 本文を表示する場所がないんですよねー(別ウィンドウになってしまう)。 Safariのブックマークウィンドウを整理の時以外使わなくなるのも、同じ理由なんですね。 iTunesが使いやすいのはメールと違って音楽が流れるので、1ペイン節約できるからだと 気付きました。 やっぱりiTunes方式の絞り込み表示は、メーラーには無理があるのかなあ。 スマートプレイリストのように、条件をあらかじめ指定しておく形式(カスタムビュー)が 条件指定の絞り込み表示としては一番使いやすいのかもしれません。
811 :
643 :03/02/19 13:15 ID:cQnr2d+A
1さん乙です。
>>855 = 1
アドレスやらメールチェッカやら結果的にせっつくような形になってしまって申し訳ない。
>今のままだと終わりそうな気がしません・・・
マターリとやりましょう。
>800さんが言うように、最初は動けばそれでいいやって感じで割り切るのも
>一つの手ですね。さてどうしようかな・・
とりあえず動くものが出てくればそれをいじる人も出てくるでしょうから
最初は本当に基本的なものだけでいいと思います。
メールチェッカにしても本体のPOP関連のクラスを使えば作るのそれほど大変そうじゃ
ないのでみなで形にしていけば言いわけだし。
オープンソースなんだから(ってあんまり意味とか分かってないですが)。
>プラグインって、こちらからはどういう機能が作られるのか想像できないので、
>どういった環境設定方法が最適なのかって、分からないんですよね。
ああ、そうですよね。
プラグインの数が増えればシステム環境設定みたいに一つのペインで済まそうとしても
どうしても煩雑になるし。うーん。
>809
あ、809さんがいいこといってる。
その通りですね。
812 :
643 :03/02/19 19:05 ID:EyiKkF9c
みなさん、乙です。
そうそう、1さんリンクはっていただいたんですね。どうもです。
>>759 >メールチェッカーにアドレス表示出すというアイデアはとてもいいと思います。
ふとこれ思い出してくっ付けてみました。HPに置いてあるんで、
暇な時にでも見てみて下さい。>all
(今んとこ、ほんとに表示してるだけですが)
>>807 >一言で環境設定といっても色々種類があるような気がしていまして、
私の場合、「環境設定(osXにおいての)は一度設定してしまえば、
後は基本的にいじらなくてもいいもの。」というイメージがあり
ます。とはいってもアプリケーションによって、その操作内容は
違いますから、例外が出てしまうのもしょうがない気がします。
しかし、使いやすいメーラーにするためには、環境設定ばかり
でなく、その他の設定や操作の内容や性格を分類し、適切でわか
りやすい場所に配置する必要があると思います。
で、言い出しっぺということで、私の分類イメージをば・・・
1.スタートアップ設定
これをしないと、メーラーの使用をはじめられないもの。
●名付けの儀式、メインアカウント設定など・・・
※方法としては、はじめてソフトを立ち上げた時に開くのが普通
かな・・・しかし、あまりに設定項目が多いとうざいと思うな。
そして、その結果は環境設定に反映される。
2.環境設定
使い始めたメーラーを、自分なりにカスタマイズする場所。
●フォントとカラー、フォーマット、ヘッダーの有無、署名の有無、
各種表示など・・・
※基本的に一度設定してしまえば、後はいじらない可能性が高い
設定類。osXのシステム環境設定をイメージするといいかも。
続く
続き 3.編集作業的な設定項目(わかりにくい表現だ) 日常的なメーラーの使用において、個人的な事情やメールの 送付相手により、変更の必要が生じる設定項目。 ●アカウントの追加●メールボックスの追加●アドレスブックの編集 ●署名・ヘッダの編集など・・・ ※メニューバー及びツールバーの両方からアクセスできる・・ ってかんじかな。場合によっては環境設定からも。 4.日常作業 メールの送受信、書き込みなどに伴う日々おこなう作業達。 ※個人的にはウインドウ内のボタンやポップアップメニューなど、 ウィンドウ上ですべての操作が簡潔するととってもうれしい。 (現在のプロトタイプ案は近いものがあってうれしい) しかし、全部が全部そうもいかないよな、やっぱり。 5.プラグイン項目 やはり、いちばんの悩みの種になるプラグイン。 ※私見ではメニューバーに「プラグイン設定」って項目をつく ったらどうでしょう。あと、ツールバーも使える様にするとか。 以上、あまり深く考えた訳ではないですが・・・ たたき台にしてもらえるとうれしいです。
815 :
675 :03/02/19 23:10 ID:nIxh1Kri
>>807 =1さん
お疲れさま!
プラグイン設定の件了解しました。
>809,811=643両氏が言われるように
マタリとやってください。
開発組のみなさんの苦悩(?)をよそに、
無責任な外野は好き勝手なことして意味なく遊んでるのであったー。
ってことで、ツールバーのボタンを勝手に試作しました。
トップ→「factory」→「Button」ってとこです。なごんでください。
ついでにトップ→「research center」として他のメーラーの研究資料(笑)も
アップしたので、興味のあるひとは見てくだされ。
今後(どいつだかわかった方がいいと思う場合は)taxi
(またはタクシー、またはタクスィ)と名乗ります。
http://www.geocities.jp/blue_tyo/nanasi/nanasi.html
817 :
643 :03/02/21 21:45 ID:j8l6v5Vj
ども、乙です。今日もマターリいきませう。 >4.日常作業 >ウィンドウ上ですべての操作が簡潔するととってもうれしい。 そう考えるとARENAのメール作成画面はよくできてますよね。 最下部のポップアップメニューからそのメールだけの設定を いじれたりとか。 >しかし、全部が全部そうもいかないよな、やっぱり。 そうですよね。 今日改めてスレを読んでみたんですが、> 304さん、> 795さんがいうような 視点を常にもちつつ各機能を実装していくってのはやっぱり大変ですよね。 >816 = taxiさん "basic[aqua]"、"YAMAHA 1"はマウスポインタが上に載ると 色が変わる(アイコンが変わる)んですよね?すんごくいい!! アイコン発表している方って、みなさんセンスいいですよね。うらやますぃー。 以下余談 リンクしていただいたHP更新しやした。 にしてもCocoaっていいっすね。プログラムしたことない漏れでも いじってるととりあえず何とかなる(ような気がする)(w メールチェッカ作るようになる頃にはもちっと手伝えるようにがんがりやす。
818 :
643 :03/02/21 21:48 ID:j8l6v5Vj
819 :
1 :03/02/22 01:42 ID:binpK1BJ
どうもお疲れ様です。
>>809 どうもありがとうございます。
809さんの言う通りだな、と思いました。
1は根っからのマイナス思考人間なので、
また、たまに励ましてやってください(w
またーりと、楽しく作っていくことにします。
820 :
1 :03/02/22 01:42 ID:binpK1BJ
>>810 =712さん
こんにちは。いつもご意見ありがとうございます。
確かに、iTunesっぽい画面は、メーラーには向かないかなあ・・・
条件の絞り込みにカラム表示を使うっていうのは面白いと思うのですが。
下ペインにメールの一覧を置くことになるならば、
別ウィンドウで開く以外に、メールをダブルクリックすると、
そのペイン内で、本文表示に切り替わるっていうやり方もありますね。
でも、素直に3ペイン+カスタムビューにした方が使いやすいかな・・・
821 :
1 :03/02/22 01:43 ID:binpK1BJ
>>811 =643さん
いえいえ、せっつかれたなんて思っていませんので(汗
それはそうと、MailPeeperについたアドレスリスト、
選択すると、ちゃんとデフォルトメーラが立ち上がるし、便利ですね。
もし良かったら、メールチェッカの部分はこれからも643さんの方で
本体の進行とは別に色々考えてもらえたらうれしいです。
メールチェッカって、割と独立した機能なので、
本体との統合は、後で考えることにしても良いような気もしますし。
822 :
1 :03/02/22 01:43 ID:binpK1BJ
>>813 =WriterXさん
設定や操作を分かりやすい場所に配置するというのは
とても重要ですよね。おっしゃるとおり、
基本的に、使用頻度の高い機能はアクセスしやすいところに置いておく、
というのが良いのだろうと思います。
>※私見ではメニューバーに「プラグイン設定」って項目をつく
>ったらどうでしょう。あと、ツールバーも使える様にするとか。
これは、ありだと思います。
プラグインによっては、使用頻度が高いものもあると思うので、
そういうのはツールバーにボタンも配置できるべきですよね。
(幸いCocoaはツールバーのカスタマイズ機能がものすごく簡単にできるし)
823 :
1 :03/02/22 01:43 ID:binpK1BJ
>>816 =taxiさん
ボタン見ました。どれも非常にカコイイ・・・
メールの送受信や保留なんかを、CDやMDのリモコンみたいな記号(ですよね?)で
表すというアイデアは、正直しびれますた。
シンプルなのに面白い。
ところで、もし良かったらなんですが
アイコンを画面プロトの方で使わせてもらえないでしょうか。
今画面プロトの方ではGNUMail.appというメーラのアイコンを勝手に
借用して作っているので、今のままだと逮捕されそうです・・・
(GPLだから大丈夫かなと思っていたのですが、ライセンス読んでみたら微妙)
>>818 =643さん
情報ありがとうございました。
>"Cocoa Programming"っていう弁当箱
あー、これ私も買いました。1200ページもあるんですよね。
しかも洋書だし・・・でも、結構いい本ですよね。
突然ですが、PG募集します。
使用言語: Objective-C。
お仕事: InternetMessageのクラス化。
InternetMessageをヘッダ、添付ファイル、コンテントに分割しそれぞれをクラス化します。
詳細な仕様は追って連絡します。
ソースはGPLになります。
参加なさりたい方はMLに入会後、
「作ってやるから、仕様出さんかい。ゴルア」
メールをMLにポストして下さい。
↓ML入会ページ
http://lists.sourceforge.jp/mailman/listinfo/undmail-dev なお、SourceForgeに参加されなくてもMLに入会できます。
その場合、ML→私 経由でCVSに反映します。
CVS上のAutherは私になりますが、CVSログを "変更内容 by 貴方のHN" とさせていただきます。
御希望であればHNを伏せても結構です。
SourceForgeとUnnamed Mail Projectに参加なさる場合は、
>1さんが CVSのフルアクセス権限を下さると思います。
825 :
taxi :03/02/22 23:33 ID:XXqQ9r+J
826 :
643 :03/02/23 13:04 ID:R8ZZUZgK
>816=825=taxiさん
「research center」のEudoraのページの「どーゆーつもりなんだ、コレ。」に
笑いました。ほんとにどーゆーつもりなんでしょう(w
>1さんに限らず、ARENA持ってるひとは試しに使ってみてください。
えー、いきなりいただきました。ありがとうございます。
>それと643さん、リンク張らせてくださいませ。
えーと、これは俺のことっすよね?もしそうならもちOKです。
>>821 =823=1さん
>選択すると、ちゃんとデフォルトメーラが立ち上がる
自分の好きなように改造しています(w
今んとこメールを選択するとヘッダを表示して、アドレスを選択すると
デフォルトメーラーで宛先入り新規メールを開きます。
Unnamed Mailでもこういう動作がいいなぁと。
Unnamed Mailのアイデアリスト見ながらぼちぼちいじります。
にしてもMailPeeperのコードはきれいだなーと。
>>"Cocoa Programming"っていう弁当箱
この本いいですよね。俺はこいつと、萩原先生の"Objective-C"と
結城浩さんのC言語プログラミングレッスン(w でプログラミングの
勉強してます。
>824=masakihさん
うーん、面白そう。今すぐ参加してもろくにコードかけないので
とりあえずMLの方に参加させてもらってもいいですかね?
今日初めてここを知って、最初から全部読みました。 新入りで恐縮ですが、僕なりに思いついた要望です。 [分類]:メール作成 同じような意見が出ていましたが、宛先(To)ごとに標準で用いるFromを記憶 できればいいと思います。 これに関しては、アドレス帳のグループ毎、開いているメールボックス毎など の意見があったと思いますが、できればアドレス帳の個々のアドレス毎に管理 されればうれしいです。 個々のアドレス毎に利用するFrom(このソフトだと「差出人」?)を登録。 また登録がない相手にメールを出したときに、用いたFromが自動的に登録さ れれば便利です。 [分類]:メール作成 文字数カウント機能。 imodeメールに送信するときの為。 [分類]:ルール 「送信先(To)が」を追加。 僕的な使い勝手だけで言えば、「差出人か送信先が」があればもっと便利。
828 :
827 :03/02/23 22:56 ID:S1sWu1PC
[分類]:ルール メインウィンドウ、アドレス帳などからメールアドレスなどの文字列を ルールに取り込む。 開いている受信メールの差出人、アドレス帳のメールアドレスなどを フィルタリングの対象にする際の、ルール登録のプロセスを効率化する。 [分類]:ウィンドウ構成 Safariのブックマークバーのようなものがあって、そこからメールボッ クスの切り替えができればいいな〜と思います。 これがあれば、2ペインで作業する時にすごく便利になると思う。 ただし、3ペインで作業する人にはあんまり意味がないのかもしれない。 我儘に思った事を書きましたが、何らかの参考になれば嬉しいです。
>>826 >とりあえずMLの方に参加させてもらってもいいですかね?
基本的にMLは来るもの拒まずのシステムですから気軽に参加してください。
830 :
名付け :03/02/24 17:37 ID:FlzBy7Qa
あら、しばらくお留守にしている間にスレが伸びてますね。
>>1 さん、プログラム以外でお手伝いできる事があれば仰って下さいね。
頑張って下さい。
.....今はこれしか言えない.....
831 :
1 :03/02/26 23:27 ID:GV0o7RIi
こんにちは。遅レスすみません。そしてあげ。
>>824 いつもお疲れ様です
プロトの方、最近頻繁に更新されているみたいで
とても頼もしいっす。
>プログラマの方々
そういうわけで、プロトの開発メンバーを募集しています。
ぜひぜひ挑戦してみてくださいね。
>>825 =taxiさん
お疲れ様です。アイコンの件、快く提供してくださって
ありがとうございました。
かっこいいアイコンだと、やっぱり開発もやる気がでます。
>「根っからのマイナス思考人間」・・・って、ほんとかなー。
>そーゆー人がわざわざフリーのメーラー作るなんて、信じられん。
えへへ。まあ、そういうことにしといてくださいな。
832 :
1 :03/02/26 23:28 ID:GV0o7RIi
あげてなかった・・・
>>826 =643さん
>今んとこメールを選択するとヘッダを表示して
おお、ほんとですね。前見たときはメールが来てなかったから
気付かなかった。
これは面白い機能ですね。
>>827 ,828
色々ご意見ありがとうございます。
アイデアリストの方に追加しておきますね。
>[分類]:ルール
>メインウィンドウ、アドレス帳などからメールアドレスなどの文字列を
>ルールに取り込む。
これは是非やりたいですね。ルールの登録って結構めんどくさいので、
とてもいいと思います。
833 :
1 :03/02/26 23:28 ID:GV0o7RIi
>>830 どうもお久しぶりです。
・・・って、どのレス番の方か教えてください・・・
名前から察するに、名付けの儀式のアイデアを考えてくれた
>>389 さんでしょうか。
>プログラム以外でお手伝いできる事があれば仰って下さいね。
あります・・・
アイデアリストの更新作業を手伝っていただけないでしょうか。
830さんに限らず、どなたでも構わないので手伝って頂けると
非常に助かるのですが。。。
ヤフーBB 書き込み規制で職場から書けない。。。 >手伝って頂けると、、、 はーい。私にできることならやるよー。 GoLiveとかFetchとか持ってなくてもできますか。 テーブルについての知識がなくてもできますか。 具体的にはどーゆーことをすればいいですか。
>>835 それはアイコンデザインを指しているのですか?
ツールバーのカスタマイズ画面を指しているのですか?
837 :
835 :03/03/02 23:05 ID:D+zzebJ9
画面がそっくりだと書いたのに対して、 それはアイコンデザインのことか画面のことか、と訊かれるのには 何か私の気付いてない理由があるのかも知れませんが、 これらの画面を「そっくり」と感じるのは以下のような点です。 ◎ドラッグ&ドロップでツールバーのボタンを選べる、という仕様そのもの。 無知ゆえかも知れませんが、メーラーでは初めて見た。 ◎それが共通してプルダウンシート(?)方式であり、さらに ◎「Drag your favorite item into the toolbar...」 「...or choose the default set」 「Show 【Icon & Text】↑↓」 「[checkbox] Use Small icons」「Done」・・・という構成が共通。 ◎英語のと日本語のがあるのに、「...」の位置まで共通。 ◎他のボタンはともかく、「Separator」「Flexible Space」「Space」 という(あまり一般的とは思えない)ボタンが、共通して存在する。
>>837 そいつはCocoa (Carbonもだっけか?)の仕様なのでみんな共通です。
あらゆるソフトで同じものが使われているんです。
>Cocoaだとこーなる(或いはなりやすい?)、ってことなのか?
っていうのが解答に近いですね。
>>837 そいつはCocoa (Carbonもだっけか?)の仕様なのでみんな共通です。
あらゆるソフトで同じものが使われているんです。
>Cocoaだとこーなる(或いはなりやすい?)、ってことなのか?
っていうのが解答に近いですね。
ごめんなさい( ´Д⊂
>>837 > 無知ゆえかも知れませんが、メーラーでは初めて見た。
AppleMailで「表示」「ツールバーのカスタマイズ...」
を選ぶとびっくりするかもね?
Writer X さん江 ググると; Simple Mail Transfer Protocol : 約91,200件 Simple Mail Transport Protocol : 約12,700件
わたしの記憶が正しければ、 Macでドラッグアンドドロップでツールバーにボタンを追加したり削除したりするインターフェースは Internet Explorer 5あたりで最初に見たような気が。
844 :
1 :03/03/03 01:11 ID:DnBr3Sdw
>>834 どうもありがとうございます。具体的にやって欲しいことは、
このスレの中でみなさんに出してもらったアイデアを、
下のページのアイデアリストの方に追加していっていただきたいのです。
http://undmail.sourceforge.jp/idea_list.html (今はちょっと落ちているみたいでつながりませんが・・・)
GoLiveとかは必要ありませんが、その場合はテキストエディタを使って
HTMLを直接編集してもらうことになるので、HTMLのテーブルの知識は必要です。
もし無理そうでしたらおっしゃってください。
あと、編集したHTMLファイルをサーバーにアップする方法ですが、
FetchみたいなFTPソフトを使ってやるわけではなくて、
ちょっと特殊な方法を使わなければならないので、
ファイルをメールで私に送ってもらって、私がサーバにアップするような
形にしたいと思います。
(次のレスに続く)
845 :
1(844の続き) :03/03/03 01:12 ID:DnBr3Sdw
作業の流れは、こんな感じになります。 1.私宛に、メールで834さんのメールアドレスを送って下さい。(捨てアドでいいです) 私のメールアドレスは、このレスのメール欄に書いてあります。 2.私から、834さん宛にメールでアイデアリストのHTMLファイルを送ります。 3.このスレ内で、上げてもらったアイデアを、送ったHTMLファイルの方に追加して下さい。 (既にアイデアリストの方に上がっているものは、追加しないようにしてください) 4.できあがったら、編集済みのHTMLファイルを私宛にメールで送って下さい。 5.いただいたHTMLファイルを、私がサーバにアップします。 なお、アイデアリストの冒頭に、どのレス番までアイデアリストに反映したかを 書いてありますので、作業はそのレス番以降についてのみで結構です。 ところでこの作業は、今回1回限りではなく、今後もずっと続けて いただきたいと思っています。 もしも継続的にお手伝いいただくことが難しければ、 あきらめて私の方で作業を続けますので、そのようにおっしゃっていただければと。 よく分からない点がありましたら、また質問して下さいね。
846 :
1 :03/03/03 01:13 ID:DnBr3Sdw
>>835 >Ginkoって、Cocoaでフリーでオープンソースだそうですが、
>使えるところはごそっと使わせてもらう、ってわけにはいかないんですか。
出来るかもしれませんが、正直あまりやりたくないです。
このプロジェクトは、「自分の手でメーラーを作りたい」という1の
欲望を元に成り立っているので(w、
あんまり他のメーラーからコードをもらってしまうと、私が楽しめないのです・・・
非効率かもしれないけど、趣味のプログラミングなのでいいんです。多分。
ちなみに、そのそっくりな画面の件は、
>>838 さんが解説して下さっている
とおりだと思います。
847 :
837 :03/03/04 01:52 ID:tRFVcLT6
>>841 えっ、そうだったの、、、、
まだ確認してないけど、聞いただけでびっくりしますた。
これじゃOS X使ってないのバレバレだー。
838さんもありがとー。
>>846 なるほど。明快なお返事をありがとうございます。
1さんはもしかして苦悩しておられるのかと頓珍漢な心配してたけど、
意外にも(?)頼もしいコメントが聞けてうれしいなり。
どうぞ我侭な欲望を追求して、楽しんでくださいませ。
848 :
834 :03/03/04 01:59 ID:tRFVcLT6
>>845 ゆうべメール出したけど、届いてますか。
849 :
WriterX :03/03/04 03:07 ID:ZTGqzIIR
スターオンライン
Writer Xさんお疲れさまです。 INDEXが画面の左側にくるHTML、という前提でINDEXの構成を考えると、 自分ならたぶん、以下のようにします。まず 1:ようこそ名無しメールへ 2:ヘルプ ・・・・・・・というのが第一(最大)分類の二部構成。 で、正直言ってたいがいの人が読まずにトバすような部分を1に集め、 2は実用性を追求する。
853 :
続き :03/03/05 16:37 ID:iFoGUjtK
●1:ようこそ名無しメールへ 「設計思想 」「名付けの儀式」「誕生秘話」「動作環境」「インストール」 「基本スペック」「仕様一覧表 」など。 ●2:ヘルプ 2―1:お勧め機能 or できることできないこと、を短く箇条書き。 単行本で言うと巻頭言あるいは腰巻き(オビ)。 2―2:単行本で言うなら本文。 ・機能別分類INDEX ・GUI別(ウィンドウ別とかメニュー項目別とか)分類INDEX ・あいうえお順分類INDEX ・ABC順分類INDEX もしかして「お勧め機能 or できることできないこと」なんかも 最初からINDEXに入れといた方が簡潔でいいかも。 2―3:単行本で言うと巻末資料。単行本で言うと活字小さめ。 ・初心者向け解説 ・用語解説
854 :
WriterX :03/03/06 01:12 ID:N7gMoT86
>>852-853 ヘルプについてのわたすの意見さん、ご意見いろいろとありがとうございます。
私が少し勘違いしている可能性もあるけれど、基本的な方向性は同じかな、
なんて思ってます。
> 1:ようこそ名無しメールへ
> 2:ヘルプ
>・・・・・・・というのが第一(最大)分類の二部構成。
まず、「1:ようこそ名無しメールへ」の部分が、
現状の「名無しメールヘルプ」における「■はじめに■名無しメールの概略」かな・・・
そして「2:ヘルプ」にあたる所が「■名無しメールの使い方」の部分です。
※言葉遣いの問題ですが、ヘルプと言うのは、「名無しメールヘルプ」全体を指す言葉に
なると思います。メニューバーそのものに「ヘルプ」という言葉が設定されますので・・
>で、正直言ってたいがいの人が読まずにトバすような部分を1に集め、
うーん、ちょっと、わたしと発想が逆かも・・・私の場合、読み飛ばさずに是非とも
読んで欲しい内容、及び読まないとトラブルの原因になるかもしれない内容を、
「■はじめに」(冒頭)の部分に集めたいと思っています。
(現状がベストかどうかは別として)
続く・・・
855 :
WriterX :03/03/06 01:15 ID:N7gMoT86
・・・続き >●2:ヘルプ >2―1:お勧め機能 or できることできないこと、を短く箇条書き。 >単行本で言うと巻頭言あるいは腰巻き(オビ)。 この辺の内容の置き場所がなやみどころですね・・・。 >2―2:単行本で言うなら本文。 >・機能別分類INDEX >・GUI別(ウィンドウ別とかメニュー項目別とか)分類INDEX >・あいうえお順分類INDEX >・ABC順分類INDEX いろんなINDEXから、アクセスできるのはいいなと思いますが、 いまいち完成型のイメージが浮かびません。 たとえば、・あいうえお順分類INDEX・ABC順分類INDEXは、 単行本における索引のイメージでしょうか・・・・・。 もしそうなら、索引表みたいなのが右側の本文ページに現れて そこから文字クリックで該当ページに飛べるなんてのもいいかも。 >・初心者向け解説 現状では、「初心者さん御用達」ってことで、最初の方に出して いますが、最後の方でも、いいかなあと思います。 でも、初心者の方はヘルプ上で迷子になりやすいので、 目につきやすい所に配置しました。上級者の方はしっかりと 読み飛ばしてくれるという考えもあります。どうでしょう・・・
856 :
WriterX :03/03/06 02:08 ID:N7gMoT86
>>842 >Simple Mail Transfer Protocol : 約91,200件
お返事遅くてすいません。最初、なんの事かわからなかった・・・
こっちの方が一般的なんですね。直しておきます。
857 :
675 :03/03/06 02:31 ID:popl83EH
ご無沙汰… 会社では書き込みできず、YBB規制で自宅でも書き込みできずの 二重苦を味わっていた675です(;_;) WriterXさんお疲れさんです。 さて、ヘルプの件なのですがこれはUnNamedMailに実装する予定の ヘルプと考えていいのでしょうか? もしそうであるのならば ・名付けの儀式 ・基本スペック ・インストール などはヘルプよりもReadMeに記載した方がいいのではないでしょうか? インストール後にアプリのヘルプの「インストール」や「基本スペック」を見る 意味がないように思います。 (Winのフリーウェアでよくあるのですがこれは意味がないような) また、インストールの後にアプリを起動すると「名付けの儀式」が初めに 現れるとする(予想なのですが…)と「名付けの儀式」を読んで欲しいのは やはりインストール前になるかと思います。 インストールは「*.pkg」方式をとるならその中で先程の3点を入れると言うのも ありかと思います。 ホームページ上のヘルプとしては自分的には満点!なので私が勘違いして いるのならゴメン…
ども。 新たなアイデアを考えました。 PGP対応 ライブアップデート こっちばっかり気になってコード書いてません。すみません。 PGPって使ったことないんだけどね。
859 :
これ? :03/03/07 03:23 ID:XkRuKXE6
**************************** PGP (Pretty Good Privacy) とは、暗号化技術の一つです。 PGP を使うことによって、第三者に 解読されないメールのやりとりができるようになります。 ****************************
860 :
WriterX :03/03/07 21:11 ID:AJVDPvIq
>>857 >さて、ヘルプの件なのですがこれはUnNamedMailに実装する予定の
>ヘルプと考えていいのでしょうか?
えーと、実装版については、今のところ何も決まっていないです。
osxのヘルプビューアーに対応させよう・・・なんて考えていますが、実際に
どの段階で実装するかも、どうなるかも未定です。
とりあえずは、ホームページ(オンラインヘルプ)で見てもらえるようにしておこう。
そして、様子を見て実装・・・って事になると思います。
内容は基本的に同じですが、857さんの指摘する問題がありますね。
実装段階になったら、その辺も十分配慮したいと思います。
>ホームページ上のヘルプとしては自分的には満点!なので
どうもです。ペコリ
>私が勘違いしているのならゴメン…
いえいえ、どんどんご意見をください。
861 :
852 :03/03/08 04:44 ID:iPhLPfuk
>>854 >読み飛ばさずに是非とも読んで欲しい内容、及び
>読まないとトラブルの原因になるかもしれない内容を、
>冒頭に集めたいと思っています。
それはそうですね。はじめて使うユーザーから見て
ゼヒ聞いておきたい情報を冒頭に集めるということには賛成です。
だけど例えばARENAのPDFヘルプの第1章なんか、
正直言ってたいがいの人が読まずにトバすんじゃないですか。
アレはトバされてもしょうがないような内容だと思う。
アレについて、『Coolなメーラーでありたい』とか
『ユニークな機能を数多く装備』とか『バランスのとれた使い勝手』とか
『皆さんのフィードバックのおかげです』とかいう
よくある結婚式の祝辞のような、卒業式の訓辞のような、
選挙演説に出てくる『生活者本位の街づくり』とかいうセリフみたいな、
どーとでもとれるキャッチコピーはなるべく削って、
(と言うか、そーゆー演説はヘルプ以外の何かに回して)
『メールボックスごとにさまざまな設定が可能』とか、
『メールボックスのアイコンやツールバーがカスタマイズ可能』などの
ユーザにとって耳よりな具体的な情報だけを簡潔にアピールした方が
はるかに実用的である、というのがオレの主張です。
862 :
852 :03/03/08 04:49 ID:iPhLPfuk
(続き) だって「メールボックスごとにさまざまな設定が可能」と聞いて 「ほう」と思う人は多いだろうけど、 「Coolでユニークでバランスのとれた使い勝手」と聞いて 「ほう」と思う人はたぶん、いないだろうからです。 同じ意味合いで、「誕生秘話」「設計思想」など(のうちのたぶん大部分)は ヘルプ以外のどこかに回す方がイイのではないかと、今のところ思うわけです。 「INDEXから読みたい箇所にジャンプできるんだからべつに いいじゃん」という考え方もアリとは思いますが。 長くてすいません。
863 :
1 :03/03/09 03:00 ID:mWUBgrov
どもこんにちは。みなさん乙です。
>WriterXさん
遅ればせながら、プロジェクトのホームページから
リンクを貼らせて頂きました。
ありがとうございました。
http://undmail.sourceforge.jp/link.html ヘルプの方、議論が進んでいていい感じですね。
私もちょっとだけ意見など発言させて下さい。
まず、ヘルプのトップには、「特徴」があった方がいいのかなって思います。
そこには、
>>861 =852さんが書かれているように、
このメーラーで出来ることのうち、特にいいものを厳選して
箇条書きでぱっと見られるようになっているといいんじゃないでしょうか。
今の目次でいうと、最初は「誕生秘話」になっているんですが、
これって末尾に「おまけ」として付いているくらいで充分だと思います。
ユーザーは、メーラーの生い立ちよりも、これを使って何が便利になるか、
ってところに興味があるんじゃないでしょうか。
864 :
1 :03/03/09 03:02 ID:mWUBgrov
それと、「初心者さん御用達」の項目をみると、 電子メールの仕組みが中心になっているようですけど、 初心者が興味を持っていることって、メールがどうやって動いているかよりも、 手っ取り早く動かすためにはどうすればいいか?ってとこじゃないかな、と思います。 まず、こうやればすぐにメールの送受信ができるんですよ、 ってとこから初めて、いつも使うアドレスは、アドレス帳に登録すると便利ですよ、 とか、メールが増えてきたら振り分けやカスタムビューを使うと便利ですよ、 とか、そういう便利に使うための情報を入れて、 最後の方で興味がある人向けにメールの仕組みを解説するみたいな 筋立てでいくのがいいんじゃないかと思います。 あと、やっぱり初心者向けの情報は別扱いにした方がいいと思ってます。 WriterXさんも仰っているように、初心者の人は迷いやすいので そういう場合は中級者向けの情報と混ぜた構成にするよりも、 初心者が日常で使うのに困らない程度の情報を選択して、 10分くらいですぐ読めるようなものを作った方が親切かな、と思いました。 ではまた。
>>861-862 >だけど例えばARENAのPDFヘルプの第1章なんか、
>正直言ってたいがいの人が読まずにトバすんじゃないですか。
>中略
>ユーザにとって耳よりな具体的な情報だけを簡潔にアピールした方が
>はるかに実用的である、というのがオレの主張です。
たしかに、ARENAのヘルプは悠長な部分が多いような気がします。
そもそも、あの量には閉口してしまいます。
しかし、良く読んで見ると、ほとんどの場合、情報としてはあった方が良い monoなんですよね。
クールだどうだ・・・の場合は無駄なのは確かだが、作者が主張したいのは
わかるし、うまくアピールできれば、個性にもなりえる。
つまり、クールであることのメリットが伝わってこないのが駄目な原因ですね。きっと。
てことで、具体的なメリットを箇条書きでアピールするのは良い方法だと思います。
実作業としては「何を削って、何をアピールするか。」が問題になりそうです。
実用的であることは、常に配慮したいと思います。
>同じ意味合いで、「誕生秘話」「設計思想」など(のうちのたぶん大部分)は
>ヘルプ以外のどこかに回す方がイイのではないかと、今のところ思うわけです。
はい、内容については、まだ具体的なイメージはないのですが、
必要最低限(実用的)のものにするか、別の置き場所を考えたいと思います。
>>864-865 >今の目次でいうと、最初は「誕生秘話」になっているんですが、
>これって末尾に「おまけ」として付いているくらいで充分だと思います。
うーん。どうかな・・・。
「誕生秘話」の題名はともかくとして、まず、私が、これを一番最初にした理由。
それは、「名無しメール」を知らしめる方法の一つが、
フリーソフトであることを明確にすることだと、思うからです。
そして、そのフリーソフトであることを、わかりやすく説明する方法として
「誕生秘話」を冒頭に置いているわけです。
へたをすると、自己満足ないやらしいものに見えてしまう可能性もありますけど。
>電子メールの仕組みが中心になっているようですけど、
>初心者が興味を持っていることって、メールがどうやって動いているかよりも、
>手っ取り早く動かすためにはどうすればいいか?ってとこじゃないかな、と思います。
はい、おっしゃる通りだと思います。
自分が、すぐ理由を知りたがるもんで、あんな見出し構成になってしまったようです。
>あと、やっぱり初心者向けの情報は別扱いにした方がいいと思ってます。
はい、そうします。別扱いの構成にしたほうが、すっきりしますね。やはり。
ギャズメールのヘルプを作ってくれたほうがよっぽどうれしかったりします。
>>867 GyazのHPによるとバージョン1.0までの予定に入っているから
もうちょい待てば搭載されるんじゃないの?
今0.9.9.5だから、あと4回のバージョンアップのどれかで。
>>867 あんたが作ってくれよー。と、思うわけだが、考えてみれば
あれは(今はフリーだとしても)フリーじゃないもんね。
フリーじゃないものに赤の他人が助力することはないか。
と考えると、フリーというのは偉大なことだと思ったりして。
ほんとはよくわかってないけど。
870 :
1 :03/03/13 00:35 ID:YkpfRTJf
どうもお疲れ様です。
>WriterXさん
>「誕生秘話」の題名はともかくとして、まず、私が、これを一番最初にした理由。
>それは、「名無しメール」を知らしめる方法の一つが、
>フリーソフトであることを明確にすることだと、思うからです。
うーん、ヘルプの目的は、機能とその操作方法の解説であって、
メーラーの宣伝ではないのではないでしょうか。
フリーソフトであることを明確にすることは重要だと思いますが、
誕生秘話と結びつけなくても、一言「フリーソフトです」と
書くだけでもよいような気がします。
手伝ってもらっておいて、色々言ってしまってすみません・・・
>>867 正直な気持ちかも知れないけど、その発言ははっきり言って腹立つよ。
わざわざここに書かんでもいーだろ。
『Coolな上にバランスがいい』 『ボタンが貼り換えられる』 この、前者が、あんまり意味ないのは、 「メリットが伝わってこない」からと言うよりも、 [真 or 偽]が明確でない(イメージっぽい)命題だからでわ。 もちろん、なんでもかんでも具体性や実用性ばかり重視するのは間違ってる。 ココロザシを語るとかイメージを羽ばたかせるとかいうことも重要である。 現に、ほとんどのCMはその線で作られているではないか。 アップルのトップページなんかいつもその線だし、 それはそれなりに妥当な戦略である。 ただ、ヘルプとかマニュアルとか名が付くものには、 そういう要素は無い方がいいと思う。 カメラでもオーディオでも、売り場に置いてあるパンフレットには 高揚感のある詩的な言葉が書いてあるでしょ。 「目も眩む...」とか「琥珀色の時が...」とか。 だけど買って来て箱開けてトリセツ開くと、基本的には実用的な 情報だけ書いてあるじゃないですか。そーゆー感じがいいと思う。
872 :
名称未設定 :03/03/14 13:06 ID:YOoDFfpV
保守age
873 :
1 :03/03/16 21:22 ID:nVo5XmDD
どもこんにちは。 今、添付ファイルのエンコード形式など調べているのですが、 みなさんは、BinHexや、AppleDouble、uuencodeなどは 使ってますか? 最初はBase64だけ対応ってことにしておきたいな、 などと考えているのですけど、ARENAとかだとBinHexがデフォルトに なっていたりするので、このへんちょっと使用事情を聞いてみたいと 思っています。
874 :
名称未設定 :03/03/17 00:34 ID:0owxykSl
BinHex。 たんにARENAのデフォルトがそうなってるからで、 無知なのでBinHexを「使ってる」なんて意識はぜんぜんない。 それぞれのメリットデメリットも知らない。 それで困ったことはないけど、あらためて考えると、 メール相手もマカばかりだからなのか? 「Base64だけ対応」ってメーラーも多いのですか。
電子メールユーザ全体から考えるとBinHexって極端に少ないんではないでしょうか。
おれ9erなんであんま参考になんないかもだが 相手がマカーならBinHex,それ以外はBase64かな 因みに俺の使ってるメーラはPostinoなんでデフォルトはAppleDouble なにげに名無しメールには期待しててこのまま正常進化してゆくならXに移行した時に使おうと思ってる
877 :
1 :03/03/17 23:28 ID:17WyOOPy
>>874-876 どうもありがとうございます。
実は、私も今まであんまりエンコード方式のことよく分かっていなくって、
電子メールの技術書読んでたらBase64のことしか書いてなかったんで、
これだけでいいのかな、なんて思っていたんですが
ARENAやPostinoみたいなメジャーなメーラーが
BinHexやAppleDoubleがデフォルトになっているのなら、
少なくとも読めるようにはしておかないといけないですね。
ちょっとぐぐって調べてみたんですが、きょうびのメーラーは
どんなエンコード方式でもだいたい読む方はできるように
なっているみたいです。
出す方はBase64だけっていうのも結構多いみたい。
逆にBase64が読めないメーラーってあるのかな。
>なにげに名無しメールには期待しててこのまま正常進化してゆくならXに移行した時に使おうと思ってる
どもです。進行はのろいけど、ちゃんと完成させるつもりなので、
気長にお待ち下さいね。
878 :
9er :03/03/18 03:19 ID:vzpYPm06
本日のフィールドワークの結果: ---------------------------------- Netscape Communicator 4.7 出す方2種: Base64(デフォルト) UUEncode 読む方:わからん。 ---------------------------------- Outlook Express 5.02 出す方4種: AppleDouble(デフォルト) BinHex Base64 UUEncode 読む方:わからん。 ----------------------------------
>>36 >ID:UBEe0PPy
>添付ファイルのエンコード選べないメーラー最近多くない?
>あれ、困るんだよねー。。是非。
>>67 >ID:UBEe0PPy
>GyazMailって添付ファイルのエンコードかえられんからつかえん。
・・・誰か、どういう場面で困るのか解説希望。
36でも67でもないが質問。 OEでは問題なく送れていた、素の(非圧縮)エクセル添付データ。 OS 9のときに圧縮したら読めなかったことがあったので素で送っていたのだが GyazMailで送ったら『どうやっても開けない』と言われた。 LZHで圧縮して送り直したら大丈夫だったようなんだが、これって どういうことなんだろう……。 エンコードの問題なのかと思ったのだが、すまん、誰かわかる? それと、余談。 バンドルのFaxSTFがあまりに使えないんでFax Sender落としてみた。 メール送信も選べてなかなか使い勝手よさげ。 しかーし! 選べるメールクライアントにGyazがねーよ! ベータ版だからか、シェア(予定)だからか、理由はそこらだろうが… PowerMailは入っているのに〜。 送受信遅いようだけど、落としてみるかな>PowerMail
881 :
880 :03/03/19 09:23 ID:xdekwRxi
ごめん、自己レス。だいぶ時間差だが… 書いているうちにOS Xメールスレと勘違いしちゃった。 上の質問は無視してくだちゃい。 あ、でもエンコード、俺も謎です。 名無しメーラーではどうなるんでしょう? 1氏、メーラー大期待してまっとりますんで… その他の方々も含めて頑張ってくだちい。 じゃ、BASE64にエンコードされて逝ってくる。
883 :
名称未設定 :03/03/19 11:08 ID:uypo5u0A
俺も分からんから教えれ。
>>882 「Base64が読めないメーラーってあるのかな?」
と、1さんが訊いてるんだからさ、これは大体のところ、
「エンコードはとりあえずBase64だけでいいか?」
ってことなんだから、イヤ、選べなきゃ困る、と思うんだったら
どういう場面で困るのか語ってくれよ。その方が親切でしょ。
勿論どうでもいいならどうでもいいんだが。
885 :
1 :03/03/21 00:47 ID:B4YwiP1G
こんにちは。明日から三連休、がんばりまつ。
>>879 36さんや67さんが困ると言っているのは、
きっと送信相手に特定のエンコード方式の添付ファイルしか
読めないメーラーを使っている人がいるということでしょうね。
あれからまたちょっと調べてみたんですけど、
Eudoraの古いバージョンだと、Base64は読めないみたいです。
他にも古いバージョンのメーラーなら、結構そういうのが
あるのかも。
>>880 GyazMailの変更履歴をみると、0.9.9.5に
・特定メーラーからの添付ファイルが正しく表示されない問題を修正。
というのがあったから、最新版だと直っているのでは
ないでしょうか。
base64ってアイコン剥がれたりpict壊れたりしないの? だとしたら、何らかの理由で圧縮無しでファイル送る事がある人は 困る事もあるんじゃない?
>>886 こわれます
DiskCopyの圧縮イメージはおくれません
888 :
1 :03/03/21 17:26 ID:WCf2/hRx
>>886 ,887
そ、そうなんですか。
うーん、なんでそういうことになってしまうのでしょう。
Base64もBinHexもバイト列をメールとして送れるようにASCII文字に変換している
だけなのかと思っていたので、原理的には符号化方式の違いによってデータが
抜けたりすることはないのかなと思うのですが、違うのかなあ。
ひょっとして、Macのファイルのリソースフォークというのが
関係するのでしょうか。
この辺のことあんまり良く分かってないからなー。
ちと勉強してきます。
>>888 あたり、リソースフォークです
たしかAppleDoubleは符号化自体はBase64と同じだったはず
リソースフォークとデータフォークを両方送るからDoubleなんだね
ちなみにDiskCopyのファイルOS9以下では
アップルがインターネットでファイル送る時の標準アーカイブでしたが
BinHexでエンコードしていました
OS Xの.dmgのファイルってリソースフォークいらないんじゃないですか? ネットにそのまんま上げてあったりするし。(まず普通はサーバーが対応してないので白紙ファイルになるけど)
891 :
名称未設定 :03/03/21 20:21 ID:96aVi12N
>>886 名無しメールは
「無圧縮で送るのは誤り」という前提で
作ってしまってもいいと思うけどなあ……。
cocoaメーラーなのでOS X環境に限定すると、ものにもよるけど 拡張子で判断できる物はリソースなくても開くことが出来るものもある。 リソースにある情報は主に ・クリエータ ・ファイルタイプ ・アイコン ・各アプリ独自の付加情報 なので、jpeg/mp3/Plain textなんかはリソース無くなっても特に問題ないけど 古いアプリとかを圧縮無しで送ると起動すら出来なかったりする。 まぁ取りあえずはBase64だけで開発して、 ある程度完成してからAppleDoubleとか追加すればよくないですか?
893 :
675 :03/03/22 05:35 ID:8DzEhP9F
まさかとは思いますが、勘違いしているといけませんので書いときます。 圧縮≠BASA64 uuencode 等のエンコード です。 ていうかBASE64エンコードかけると膨張します。 この場合のエンコードは有意の8bit目を持つバイトコードを 7bitASCIIの範囲に変換かけるものです。 それ以上でもそれ以下でもありません。 #なぜ俺は会社にいるんだ。。。不景気のバカ。
895 :
1 :03/03/22 12:03 ID:VZ/dRssX
ども、みなさん色々ありがとうございます。
勉強になります。
あれからまたちょっとごちゃごちゃ調べたんですけど、
結局、以下のように考えるとすべて納得がいくのですが、
どうでしょう?間違っていたら教えて下さい。
・まず、リソースフォークが落ちる問題は、符号化方式の違いとは関係がない。
>>894 でmasakihさんがおっしゃっているように、Base64は8bitバイトコードを
64種類のASCII文字に変換しているだけなので、普通にエンコードかければ
リソースフォークもそのままついてくるはず。
・しかし、Macのメーラーの中には符号化方式としてBase64を指定すると、
他OSとの互換性を意識して、自動的にリソースフォークを取り除く"ものもある"。
BinHexを指定した場合は、相手もMacだと想定できるので、リソースフォークを
取り除かないでそのまま送る。
・StuffItのような圧縮ツールを使うと、上のようなメーラーを使っていた場合に
Base64で送っても、解凍後のファイルにはリソースフォークはついている。
(あたりまえ)。でも、LHA系圧縮ツールだと、圧縮するときにリソースフォークを
自動的に取り除くものもある。
これはWindows上でも開けるように、という配慮でそうなっている。
で、このように考えると、
>>880 さんの疑問は氷解する様な気がします。
・880さんのメールの送信相手はWindowsを使っている。
・GyazMailは、Base64で送信するときもリソースフォークを取り除かないタイプの
メーラー。だからファイルを生で送るとWindows上では開けない。
・OEは、Base64で送信すると、リソースフォークを取り除くタイプのメーラー。
だから、Windows上で開くことができる。
・880さんは、リソースフォークを取り除くタイプのLHA圧縮ツールを使っている。
だから、圧縮後に送信すると、相手先はファイルを読むことができる。
あくまで推測ですが・・・
>>892 クリエータとファイルタイプはリソースフォークじゃなくて
HFSファイルシステムが保持しています。
897 :
masakih :03/03/22 17:41 ID:hPc2skqV
>1さん
>・まず、リソースフォークが落ちる問題は、符号化方式の違いとは関係がない。
この部分はある意味あってます。
>
>>894 でmasakihさんがおっしゃっているように、Base64は8bitバイトコードを
>64種類のASCII文字に変換しているだけなので、普通にエンコードかければ
>リソースフォークもそのままついてくるはず。
普通にエンコードかけるとリソースフォーク及びファインダーインフォは欠落します。
何も考えずにファイルを開くとデータフォークのみが開きます。(fopenで開くとか)
で、エンコードはこの部分に掛けられます。
AppleSingle,MacBinaryは二つのフォークをひとつにまとめる事でこの問題を解決しています。
但し、これらのフォーマットを知らないコンピュータはフォークを分離できません。
AppleDoubleは2つのフォークを別のファイルに分離する事でこの問題を解決しています。
このフォーマットを知らないコンピュータであっても、正しいデータと意味不明なゴミデータの
2つのファイルを認識できるので、データフォーク側のファイルを開く事ができます。
どちらの場合もファインダーインフォはリソースフォーク側に付随されます。
んでもって、メール転送する場合は、これを更にBASE64等でエンコードします。
まとめると、Mac特有のファイルをメール転送する場合は、
1、フォークを処理する。
2、圧縮するならする。(フォークを理解する圧縮プログラムでは1、の処理は必要ありません)
3、7bitASCII範囲内に符号化する。
となります。
898 :
1 :03/03/23 00:55 ID:V8msEOrb
>>897 =masakihさん
ありがとうございます。
おかげさまで理解に近づきつつあるような気がします。
リソースフォークについて私はかなり誤解していたみたいです。
プログラム内でファイルを開くと、その先頭数バイトが
リソースフォークとなっていて、残りの部分がデータフォーク、
みたいな感じになっているのかと思っていたのですが、
そうじゃないのですね。
あと、AppleSingle、AppleDoubleについても分かってきました。
これらは、本質的にBase64のような符号化方式とは
違うもので、リソースフォークとデータフォークからなるMacのファイルを
バイト列で表現するための形式の一種、みたいな風にとらえれば
良いのでしょうか。
一個だけ位置づけがよく分からないのが、BinHexです。
BinHexでエンコードされたメールをテキストエディタで開くと、
Base64とは違うけど、確かに7bit符号化されていました。
これは、AppleSingleやAppleDoubleみたいなバイト列の規格と、
Base64みたいな7bit符号化方式を合わせてBinHexと呼んでいる、
というふうにとらえればいいのでしょうか。
あと、MacBinaryというのは、BinHexとはちょっと違うモノなのでしょうか。
語感からすると、MacBinary=バイト列形式、BinHex=7bit符号化方式
みたいな感じかな、っていう気もするのですが。
899 :
1 :03/03/23 00:57 ID:V8msEOrb
で、名無しメールの仕様としては、
>>891 さん、
>>892 さんが
おっしゃるような感じで、当初はリソースフォークは無視、
送るときは必ず圧縮かけるようにユーザーに呼びかけ、
符号化方式はBase64だけ、ということにしておいて、
それから順次他のものにも対応という具合に
進めていけばいいかな、と思っています。
900 :
名称未設定 :03/03/23 01:10 ID:lpV+OUID
イエーイ!! 900get!!
901 :
880 :03/03/23 09:43 ID:vROmaZT/
>1氏、masakih氏 ありがとうございます。遅レスですが… 895,897は大変ためになりました! OS XになってMacLZHが使えないので(Classicは立ち上げたくない)、 DROP LHAという強制的にリソースフォークを取り除く圧縮ソフトを使いました。 相手がMacとWindows両方使っているので送信方法も迷ったのですが… Gyazでは送信時エンコード方法を選択できないのですが、MIME対応ということは 内部でBASE64なのかな? とりあえず、相手がどちらのPCで開いたか、聞いてみます。 んで、897を読んで目からうろこ。 AppleDoubleとかAppleSingle,MacBinary=フォーマット/ファイルの取り扱い であって、エンコード方法では無いのですね? 自分も1氏と同じく、てっきりBASE64に並ぶエンコードの仕方だと 思っておりました。 私もBASE64はリソースフォークを落とす、AppleSingle,MacBinaryを選択 するとリソース付きで送るんだとばかり。 ちなみにClassicでOEの送信オプションを見てみると。 『エンコード』としてAppleDouble(汎用)、Macintosh(BinHex)、 Windows(MIME/BASE64)、UNIX(UUEncode) とありました。ううむ。
長いので別レス。 899でエンコードについての名無しメールの方針がだいぶ固まったようですね。 OEでは、Winユーザーとのやり取りも多かったため。BASE64送信選択、 データは極力圧縮、というふうに心がけてはいたので、自分的には899でも 全然オッケーです。 『リソースフォークがついてて開けないから送り直せ!』とうるさくしつけて くれたWin人がいたもんで…(苦藁 回りにそういう環境がないと、初心者やあまりPCに詳しくない人は データについてほとんど意識しないでしょうし。 素でデータを送っているに対して、『データは素で送るものではない』と いうことを啓蒙する意味でも(そんな大義ではないかもしれませんが(藁 割り切っちゃっていいかもしれません。 んで、添付ファイルの初めての送信時に『データ圧縮しましたか?』と ダイアログ出すとか。 『なんで?』というボタンを押すと、ヘルプの『圧縮について』、 『Winとのデータのやり取りについて』の解説が呼び出されるとか…。 初心者向け、というか学習ソフトみたい?(w あ、ヘルプ作者さんも大変になるか。
904 :
1 :03/03/24 00:56 ID:u7Uc4vOa
>>901 ,902=880
すいません、895は間違った知識を元に書いてますので、
あんまり気にしないで下さい・・・
>んで、添付ファイルの初めての送信時に『データ圧縮しましたか?』と
>ダイアログ出すとか。
>>762 の方針のこともあるので、あんまり親切にダイアログ出すのは
やめとこうかと思っているのですが、
こういうのは中級者でも結構ひっかかりそうだからなんかガイド出すのも
いいかもしれませんね。ていうか、自分が知らなかっただけなんだけどね・・・
Macの世界では常識ってことなら、問題はないと思うのですが。
>>903 RFC1740,1741のあたりに、Macのファイルの扱いが書いてありましたね。
ごめんなさい、あんまり読んでませんでした。また勉強して参ります。
しかし、標準に準拠させるのも結構たいへんだな、と思う今日この頃。
標準だけならまだしも、慣習っていうやっかいなものもあるしなー。
ブラウザとかメーラとか完成させている人たちはやっぱたいしたもんだな、
とまじで思います。私もがんばろ。
905 :
taxi :03/03/25 19:35 ID:yzzKxqFM
『リストのステイタス』って、ARENAのデフォルトのデザインでは ――――――――――――――――― ■未処理メール 下矢印:未読 上矢印:未送信 ――――――――――――――――― ■読んだだけのメール(処理済み) 印ナシ:既読 ――――――――――――――――― ■読んだ上になんかしたメール(処理済み) S字印:送信済 R字印:返信メール作成済 F字印:転送メール作成済 D字印:RDTed.png=回送メール作成済 ――――――――――――――――― こーゆー感じの3グループ↑に見えるんだけど、これがベストなもんでしょうか。 RとFとDはやっぱ区別しないと困ることあるのかな。 みなさんどうですか教えてくだされ。
906 :
taxi :03/03/25 19:36 ID:yzzKxqFM
オレは↓この方がいいような気がするんだけど。 ――――――――――――――――― ■未処理メール(処理済み) 下矢印:未読 上矢印:未送信 ――――――――――――――――― ■受け取ったメール(処理済み) 印ナシ:既読 小さい点:返信メール作成済 小さい点:転送メール作成済 小さい点:RDTed.png=回送メール作成済 ――――――――――――――――― ■自分が書いたメール S字印:送信済 ―――――――――――――――――
>>905-906 リスト表示のstatusってARENAを踏襲するんだっけ?
ラベルも搭載される予定だし取りあえず、未読・既読、添付ファイルの有無、、、
といった最低限必要なものだけにしておいて、リスト表示の表示速度を重視
させてくれた方が嬉しいなぁ。
ま、骨組みはシンプルに、肉付けはプラグインで、、、つーのが基本路線だと思いまつ。
908 :
taxi :03/03/26 01:34 ID:OjcJnIJc
>ARENAを踏襲するんだっけ? いや、たまたま私がARENAしか知らないだけっす。他のメーラーの様子も、 ボタンのデザインくらいならいろいろいじって見てみるけど、 リストアイコンを各種類チェックするのはけっこう面倒だから、 訊いてみようかと思って。少なくとも ・種類=「普通のメール」「添付アリ」「HTML」などの区別 ・ステイタス=「未読」「既読」などの区別 ・優先度=優先度の区別 って3列構成は必然なのかと思ってたけど、今ネスケ4.7触ってみたら、 べつにそんなこともないらしい、と知りました。
909 :
1 :03/03/26 23:07 ID:UfWBVgXS
>>905-906 お疲れ様です。
私の場合、欲しいのは、「返信済み」という
マークだけで、転送済みはあんまり必要性は感じません。
でも、返信と転送が同じ印っていうのはちょっと
抵抗があるかなー。この二つがごっちゃになると、
誰か第三者にメールを転送したことを、
返信した、と勘違いして返事を忘れそう・・・
そういえば、「マーク」っていうのを付けられるメーラーって
ありますよね。私はあんまり使わないんだけど、
みなさんは使ってますか?
>>907 はい、基本はシンプルにですよね。
ただ、これらの記号って基本的にディスクに保存される情報だから、
プラグインで追加っていうのは、結構難しいかも・・・
私は、これらの記号って種類が多いのは別に構わないんですけど、
種類毎にリストの列が一個ずつ増えるのはあんまり良くないかなって
思っています。できれば、一つの列内で、複数の記号
(例えば返信済みと添付付きとか)が両立出来た方が
UI的にはすっきりしますよね。
910 :
taxi :03/03/27 03:00 ID:LyfF7Cdk
>>909 なるほど。たぶん需要があるんだろうとは思ってましたが、
やっぱ要るんですね、「返信済み」。
んー、やっぱり「転送済み」と「返信済み」は区別して欲しいですねぇ。 理由は1さんが書いたとおり、転送の必要があるメールを転送したのはいいけど、 出してきた本人への返事を忘れることが結構あるから(´・ω・`) 1つの列内でっていうと、EdMaxが参考になるかな。 転送済み: アイコン左上に→ 返信済み: アイコン左下にページのめくれたような表示 添付あり: アイコン右下にクリップのアイコン など。
912 :
taxi :03/03/28 19:01 ID:ba8RrY+O
>「マーク」っていうのを付けられるメーラー アウトルック(やアントラージュ)には「重要度」とはべつに 「フラグ」ってのがあるけど、1さんの言う「マーク」ってそれですか。 「重要度」とはまた意味が違うんでしょうか今んとこよくわからず。 >種類毎にリストの列が一個ずつ増えるのはあんまり・・・ アントラージュって記号だけで5列くらいあるんだっけ・・・・・? >アイコン左下にページのめくれたような表示 なるほど。めくれたような表示ってのはアリですね。素晴らしい。
913 :
taxi :03/03/28 19:14 ID:ba8RrY+O
>>911 ちなみにEdMaxでは「HTMLメール」はどういう表示ですか。
914 :
何もできませんが。。。 :03/03/29 23:53 ID:DXlhSDe2
アゲ
>>1 お疲れ様です!応援しています。
転送済みマークですが、仕事の仲介などをしていると
届いたメールを注釈を加えて第三者に回したりすることが
けっこう多いと思うので、ないと不便な人いるんじゃないでしょうか。
僕はそれほど頻繁にやりとりしているわけでもなく
送信箱で確認すれば充分なので、マーク見る事は滅多にありませんが・・・
期待age
917 :
名称未設定 :03/04/04 14:31 ID:Kx4CPSq6
ごめん
捕手
920 :
名称未設定 :03/04/14 01:12 ID:k/bQ8gBP
なんかスレ沈んでるんであげます おれは未だに7500なんて骨董品使ってるんでβテスタも出来ないけど 方向性としてはすきなので応援してます
このスレを読み込んだときはまだ地下485階
>>920 その機種ならOSX入るとおもいますが?
裏技使って。
どこのスレか忘れたけど。
そういう問題じゃ無くて?
922 :
名称未設定 :03/04/14 01:53 ID:5K8jB/Ze
>>921 入れても実用には程遠いからね
金も無いから改造したり拡張したりもきついからね
どうせなら新しいマック買う金を貯めた方がよいかと
沈んでるなぁ…
山崎で消えたかと思ってあせった。。。
925 :
山崎歩 :03/04/18 20:07 ID:ckaQy1a1
(^^)
プログラムは全くわかりませんので なにもお手伝いできずもどかしいですが、 (メーリングリストも、ただ傍観するのみですが) とにかく期待しています。
927 :
1 :03/04/18 22:56 ID:JQ/n8vBo
どうも、長いことほったらかしですみません。 明日あたりから再開します。 しかし、スレが沈みすぎてて上げるのがなんかもったいないな。 このままにしておくとdat落ちしてしまうのかな。
sageでも保守になりますよ かげながら応援しております
>>925 はニセモノだよね。なぜかこのスレはsageにしてるし。
あっ・・・1さんキターーー!!!!━━━(゚∀゚(クルクル 廻ル))━━━!!!!
>>913 激遅レス……。すいません(;´д⊂)
メール一覧表示のアイコン部分のことでしょうか? (< EdMax)
であれば、特に表示はなかったような……。
ビューワ部 (本文表示部分) でも特になかった気が……。
ただのプレーンテキストとして表示されていたと思います。
# 自宅 (Macオンリー) なんでちょいと確認できないっす。申し訳ない。
934 :
山崎渉 :03/04/20 04:27 ID:ZHDoPsUy
∧_∧ ( ^^ )< ぬるぽ(^^)
935 :
名称未設定 :03/04/20 20:55 ID:VOijXZNY
保守党
いろいろ試したけどどれもしっくりこない。 期待してます。
937 :
taxi :03/04/22 07:12 ID:CzRAmyN7
>>933 いえいえ。ご教示ありがとうございます。
>>938 スクリーンショットになにげに日本語が含まれてますね(w
940 :
675 :03/04/22 22:45 ID:w4sCU13T
>>938 GNUMail.app当初から>1さんが参考にしてたんではないかな?
アイコンも借りてる見たいだし…
>>938 GNUMailは大分古いですが、今のバージョンでCVSが整理されて、GNUMailとPantmimeで落せる
用になったのが嬉しいですな。
GNUstep環境でも動くのが凄いです。
つーかソースがこれのせいでifdefとか多いのがちっと読みにくいのが厳しいとこかな?
とりあえずMailのフレームワークとしてのPantmimeだけでも使ってみると楽できるかも。
942 :
1 :03/04/24 00:28 ID:wm2HgDEJ
どもお疲れです。
>>941 Pantomimeは一応使うつもりでいるのですが、
日本語の添付ファイル名の扱いなど、細かいところで
少し問題があるかもしれません。
こっちでソースを修正してしまうか、問題がある部分だけ
自前でやってしまうかはちょっと悩み中。
>>942 うわ。1さんだ♪
とりあえず自前でやっつけちゃうに1票。
944 :
名称未設定 :03/04/26 13:39 ID:61w6Ypui
その後の発展状況は・・・・? とにかくがんがってくれ!
945 :
名称未設定 :03/05/02 07:11 ID:BAo7qiHH
こ、高速ダウンローダー2000
またぁりと待ってます…
捕手します捕手します
Gyaz 0.9.9.9 出たけどマタリ待ちます。
949 :
taxi :03/05/10 23:02 ID:WJEP+Zud
950 :
1 :03/05/11 00:36 ID:gXzd2QE+
どもご無沙汰です。
今ちょっと会社が忙しいので、しばらくメーラ作りは休んでおります。
そのうち復帰します。6月くらいには、ちょっと落ち着けるはず。
>>949 taxiさん、メールの返事出しておきましたので、
暇な時にでも読んで下さい。
952 :
taxi :03/05/11 22:52 ID:y5fDCAzM
わかりました。急かしたみたいになってすいません。 じつは「根っからのマイナス思考人間(待ち合わせに相手が10分遅れると、 交通事故に会ったんじゃないかと心配するような)」なんで、 すっかり悲観してましたよー。 急かす意図はないので、これで安心して待ってます。 お仕事がんばってくだされ。
953 :
名称未設定 :03/05/21 02:59 ID:+o++623A
叩き台
954 :
山崎渉 :03/05/22 04:40 ID:sgoL8cF8
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―
↑で、この山崎スクリプト誰か根元から叩いてくれ
ぼちぼちまちます
957 :
山崎渉 :03/05/28 13:18 ID:H9PCzhbR
∧_∧ ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。 =〔~∪ ̄ ̄〕 = ◎――◎ 山崎渉
CocoMonar CocoMailer
959 :
名称未設定 :03/06/07 15:36 ID:oUDqSn6M
がんばってください。 あげます。
持ってます。 待ってます。 侍ってます。
MLにSPAMが投稿されたのには驚いた。
>>961 久々にメール流れたなーと思ったらアレだったから腰が砕けた。
>>1 さん、進捗とかちょっと流してほすぃっす。
963 :
名称未設定 :03/06/20 18:44 ID:Bzjx/Ni3
964 :
1 :03/06/21 12:35 ID:DCgvvISN
こんにちは。お久しぶりです。 すみません、ここ2ヶ月ほど進捗は0です。 今日からちょっとずつ進めていきます。 この調子だと、何年かかるかわからんなあ・・・
965 :
名称未設定 :03/06/22 17:30 ID:7KHYKg1l
激しく期待ヽ(`Д´)ノアゲー!
>>1 お疲れさまでございます。何年かかっても、期待しております。
ほちゅ
968 :
名称未設定 :03/07/09 09:18 ID:dGSHMhAg
本日遅ればせながら初めてこのスレッド拝見させていただきました。 当方ARENAのCarbon版を現在使用中ですが、 開発終了とのことでCocoaでよさそうなメーラー物色中。 もの凄く期待してます! 個人的にはCocoa版のARENAがあればなぁって思ってます。
sharewareだけど、GyazMailが結構良い感じになっちゃってるんだよね。 ・Cocoa ・1 mail 1 file ・Multi Account ・Milti Pain ・mbox読み込み ・POP Befor SMTP対応 ・SMTP Auth対応 ・SMTP Over SSL対応 ・POP3 Over SSL対応 さて、これに対抗するためにはどんな機能を組み込めば良いのかな? 個人的にはEudoraからのmbox移行機能が欲しいんじゃが。 Gyazへ持って行く場合、やっぱContent-Type:削らなきゃ駄目だったし。 送信側は???@???なセパレータから送信日時を抜き出し、Date header用に 変換してやった上、To:をFrom:に書き換える必用が有った。 どっちも簡単なPerl Scriptで処理出来なくは無いんだが、mbox毎に処理し なくちゃならんので面倒。
971 :
山崎 渉 :03/07/15 10:32 ID:34L7LbqJ
__∧_∧_ |( ^^ )| <寝るぽ(^^) |\⌒⌒⌒\ \ |⌒⌒⌒~| 山崎渉 ~ ̄ ̄ ̄ ̄
972 :
山崎 渉 :03/07/15 14:10 ID:/6SaCgsj
__∧_∧_ |( ^^ )| <寝るぽ(^^) |\⌒⌒⌒\ \ |⌒⌒⌒~| 山崎渉 ~ ̄ ̄ ̄ ̄
>>970 おいおい。Gyazはまだまだつっこみどころ
おおいだろーに。
まだ、レジする気にはならんなぁ。
>>973 フィードバックしてます?
ここでポイント挙げれたら書いてみてください。
975 :
名称未設定 :03/07/19 15:26 ID:6Li27+vU
974人も釣れたのか・・・・
釣られていたのかっ(T-T)