最強のGUI環境って？ 105
ストーリー by wakatono
X+twm 部門より
X+twm 部門より
runeyokohama曰く、" 最強のGUI環境に必要な条件って何でしょう。 私は、関数型プログラミングやUnixなどのマイナー（？）指向なので、次のような条件を満たしてほしい。
- OS非依存
- プラグラム言語非依存
- 国際化対応
- オープンソース
かなり昔に X Window System をはじめて使った時にはカルチャーショックが走ったが、それから早十数年、いろんなGUIが出てきている。あなたはどんな環境なら満足するのかな？それとももう今ので十分？
レスポンス (スコア:3, すばらしい洞察)
るものとしてはやはりレスポンスです。人間が感じられないギリギリまでは遅
くても全然構わないのですが、さすがにコンマ何秒や数秒も待たされると思考
が中断されてイラつきます。
CPUの性能はどんどん上がっているのに、常に微妙にイラつくぐらいのCPUパワー
を消費するGUIって多いと思いませんか? MS系はもちろんですけど、他にもい
くらか。
思考を邪魔するなんてものはプロの道具として失格だと思います。
# 自分でUIを選べるならば困りませんけど、往々にしてそうはいかず…
Re:レスポンス (スコア:1)
この主な原因は、priorityを引き上げたprocessがすぐにscheduleされないことにあります。となると、対策としてはcpuよりもむしろkernelの改良になります。具体的には、preemptive kernelやpriority inversionの防止などになります。
が、これがマトモにできているのはSolarisぐらいしか思いつきません。追い付かなければならないのはわかっていますが...
Re:レスポンス (スコア:2, すばらしい洞察)
それも一因とは思いますけど、根本的な原因はむしろGUI設計者のポリシだと 思います。結局、レスポンスというのはCPU性能とUIの機能とのトレードオフ で決まるものですから、一番効いてくるのはGUI設計者がバランス点をどこに 見出すかでしょう。
それでどうも、世のGUI設計者は、常に快適なレスポンスから二三歩後退し た位置にバランス点を見出す気がするのです。まあ、CPUが速くなったら いろんな機能を付けてみたくなる、という気持ちは分かりますけどね。 GUI設計者にはぜひロースペックなマシンで開発してもらいたいものです。
> これがマトモにできているのはSolarisぐらいしか思いつきません。
> 追い付かなければならないのはわかっていますが...
Solarisって、負荷や並列度が高かったりするときにはいいOSですね。 (というか、他のOSはハイエンドユースでの経験値が少ないというか…)
ところで、オフトピ気味ですが、ここで追いつかなければならないのは誰(ど のOS)でしょう?
Re:レスポンス (スコア:2, 参考になる)
書きわすれてました。Solaris以外のUnix-likeなOS全てです。大抵はkernelに入ると出てくるまでcpuを使いっぱなしになってしまいます。一部realtime向けUnixもあったりしますが、applicationは限定されてしまいます。TSSとrealtimeを同居させるのはSolarisの得意技。
個人的には自分で手を加えられるFreeBSDですが、それに限った話ではないということで。
Re:レスポンス (スコア:2, 興味深い)
理由はいくつかあると思います。
Re:レスポンス (スコア:2, 参考になる)
http://www.tech9.net/rml/linux/ [tech9.net]
完全にまともと言えるかどうかはともかく、まぁ動くしアプリケーションによっては目に見えるレベルの改善がはかれます。
病的な願望 (スコア:3, おもしろおかしい)
空気の入り込む隙間もないように念入りに詰める。それでこそ安心。
Re:病的な願望 (スコア:1)
"Quidquid latine dictum sit, altum videtur."
GUI便利だけど (スコア:2, 興味深い)
Re:GUI便利だけど (スコア:2, 興味深い)
ありますね、そういうの。ワタシは未だにＶＺが手放せない人ですし。
個人的にはいまや表示面積が十分あるので、タイルウインドウが
復活してほしいです。後ろに隠れているウインドウを見つける
必要がないので、結構使い勝手がよかったなぁ。
という事でOberonはいかがでしょうか。フロッピー１枚位に
収まるし。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:GUI便利だけど (スコア:1)
ぼくは FD でなくて WD 使いだったけど (FILMTN だっていう人もいるだろうけど)、あれほど快適な環境は、それ以降は経験したことがありません。それに比べたら、Windows か Macintosh かなんて、どんぐりの背比べみたいなもの。
というのが個人的な感想です。(ほんとに個人的なことを言えば、FILMTN はカスタマイズが弱すぎてだめ。FD もいまいち。WD がやっぱり強力でいい)。
ちなみに当時のはエディタは Vz でした。
Re:GUI便利だけど (スコア:1)
Windows では Dyna [vector.co.jp] というのを使ってます。
他にも あふ [at-m.or.jp] とか DF [nifty.com] とかが人気あるらしいです。
ツィンウィンドー系のファイラー便利です。
あと、UNIX 系なら FDClone [vector.co.jp] が最近ツィンウィンドーに対応しましたね。
Re:GUI便利だけど (スコア:1)
X68K の MINT が最強っぽかったっす。
# というか、他のファイラーはほとんど使わなかった。
uxi
Re:GUI便利だけど (スコア:1)
で、Windows 9x時代はFM(File Manager)なるDOS汎用ファイラーを
Cプログラム書いていじり倒していました。
ソースが公開されているので、その気になれば何でもあり。
どうでしょう。
最近は、Paper Plane xUIで落ち着いていますけど。
VCあってもいじり倒す気力湧かないし。
個人的には・・・ (スコア:2, 参考になる)
結構なんでも出来るし、UNIX系のオペレーションもこなせるので、使っていて心地いい。
ただし、現状のスピードはたまにいらつく事があるので、長い間使っていてフラストレーションが貯まるけど。
仕様書、とか（笑） (スコア:2, 参考になる)
技術的な部分はどーでもいいから、GUIとしてのポリシーが一番大事でない？
ちゃんとしたユーザーインタフェースガイドラインあってのGUIでしょうから。単にパーツだけ揃えて、後は好き勝手じゃ、結局使い難いものしか生まれないでしょ？
まあ、こういう曖昧模糊としたものって、フリーの世界ではなかなか生まれ難いのかもしれませんが。
マイナー指向に走るなら (スコア:2, 興味深い)
ポインティングデバイス (スコア:2, 参考になる)
いわゆる (スコア:2, 興味深い)
コンセプトとしてはBTRONやOpenDocをもっと徹底したような感じ。
# あくまで書類はただの書類であって、～書類ではない。ってね。
ペンパレットとダイアログ以外ならどこにでも落書きできるくらいの柔軟性がほしいな～。とか思ってます。
共同作業の出来る環境・・・(XP？) (スコア:2, 興味深い)
・マウスカーソル複数
・ウィンドウオーダはカーソルのオーナ毎
・ウィンドウのフィルタ機能付き(～の上げたウィンドウは見えるとか)
# 基本的に、マルチタスクマルチログイン可能OSの機能を
# ビジュアルまで持ってきた版かな？
エクストリームプログラミングに威力を発揮！
しかも、さぼれない！！！！(さぼると共同作業者にバレルから)
ないですかねぇ？
別のXP (スコア:1)
# Linux なんかの仮想コンソールのノリかな？
こういう機能もった GUI (と言うかマルチウィンドウ)環境他にありませんかねぇ？
もしくは X で実現する方法とか？
# XFree86 で２面以上デスクトップ(って言うんでしょうか？)を
# 持てれば問題は解決っぽいのですが。
uxi
Re:別のXP (スコア:1)
＞# 持てれば問題は解決っぽいのですが。
まず、firstがログインする。
startx
で、起動する。
仮想コンソールからsecondがログイン
X :1
もう１つの仮想コンソールからsecondがログイン
DISPLAY=:1 sh .xsession
こんな感じでF7にfirstのGUI環境。F8にsecondの
GUI環境が構築できましたが、このような具合いでしょうか。
ちなみに片方はWinXP風、片方はMacOS-X風、
むー。変なデスクトップだ。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:共同作業の出来る環境・・・(XP？) (スコア:1)
X上でexport DISPLAY=hogehoge:0してrloginして
xhost +hogehogeしてサーバーのアプリを
起動するんじゃだめなん？
（環境によるだろうけど）
（研究室にいたころSunのIPCからP5-120のマシンにrloginしてP5-120マシンにインストールされた
Netscapeをつかったっけなぁ。）
理想のGUI (スコア:1)
#5年前ならOPENSTEPと断言していたのだが...
快発環境 (スコア:1)
・賢いウィザード
どうしてもコールバック関数はウィザードに頼らないと開発が面倒です。でも、頭の悪いウィザードはダメ
コールバックがいっぱい散らかるので、それもうまく解決してくれるようなものがほしい。
ところで ＞編集者 (スコア:1)
本来なら「スラドに聞く」にするべきモノだと思うんですが？
＃恣意的……とも言いにくいような。
Re:ところで ＞編集者 (スコア:2, 参考になる)
GUIは使えるようになるまでが大切？ (スコア:1)
KDEやGnomeは実務で使ってとても満足しています。ただバージョンアップの際にまだまだ問題が、、、。
----------- 一生勉強を続けなきゃ！
Re:GUIは使えるようになるまでが大切？ (スコア:3, 興味深い)
覚えることが少ないので初心者にはもってこい。
（コマンドを覚えなくてはならないという突っ込みは無し）
上級者はテキストファイルで細かく設定。
媚びない、群れない、奢らない。
上質を知る人のWindow Manager、twm。
Re:GUIは使えるようになるまでが大切？ (スコア:1)
参った！でも、実はmac68kでnetbsdしていた頃は、twnよく使いましたよ。どうしてもCPUが非力なコンピュータの場合は良い選択ですね。
----------- 一生勉強を続けなきゃ！
ごめんなさい (スコア:1)
MyGUI (スコア:1)
kinput2 -canna &
kterm &
blackbox
こんな感じでオッケーですね。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
俺なら (スコア:1)
欲を言えば、
「プロトコルをテキストにして、シェルスクリプトでも扱えるくらいに単純化する」
「サウンドなどのイベントも一元化する」
「それどころか任意のイベントを透過的に扱える」
くらいやってくれると嬉しいが、
それは X のようなプロトコルとはレイヤが違うと思われるので、
むしろ下層のレイヤには、より単純であることだけを求めたいな。
# mishimaは本田透先生を熱烈に応援しています
昔からあこがれだった…… (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:昔からあこがれだった…… (スコア:2, おもしろおかしい)
Kiyotan
Re:昔からあこがれだった…… (スコア:1)
でもクリップは,クビになったはずなので,
一緒にリストラされているかも.
オフトピ (スコア:1)
＊ビル・ゲイツは？
「ビル・ゲイツ」という項目はわかりません。
＊マイクロソフトは？
「マイクロソフト」という項目はわかりません。
自社のことを知らなかったのでリストラになったんでしょうね。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:昔からあこがれだった…… (スコア:1)
OS非依存って (スコア:1)
一見素敵ですが、そのせいか速度が犠牲にされていて残念感漂いまくりです。
まあ速度は将来的にマシンパワーの向上により気にならなくなるとしても、
それぞれのOSのお約束が通用しないので慣れるまでかえって
使いづらかったりします。というか慣れたところで
「なんで△△△ができないんだ！△△△ができてこその◇◇◇（←任意のOS名をどうぞ）だろーが！」
という不満は消えません。
もちろんOSを乗り換えても戸惑う事無く同じアプリが使えて便利という側面もありますけど。
OS非依存の統一されたGUIって理想だと思いますが、
実現しちゃったらきっとPCってつまらなくなるだろうな、と思います。
Re:OS非依存って (スコア:1)
＞実現しちゃったらきっとPCってつまらなくなるだろうな、と思います。
昔、国産のＰＣハードウエアに対して同じ気持ちを抱いた方は多数いらっしゃると思いますが、今どうですか？楽しくなった？詰まらなくなった？
ワタシ？ワタシはキラーアプリがVZを使いやすい環境、という観点でしかPCは見ていないのでアレですが:-)
-----------------
#そんなワタシはOS/2ユーザー:-)
とりあえず複数のインプットキュー (スコア:1)
入り口が一つしかないと、いくらkernelが生きてても、
表に出てるアプリケーションが握ったまま逝って
しまったとき、ちょっとストレスを感じます。
httpd + HTML (スコア:1)
HTMLで
<form method="post">
<input type="text" name="textarea">
<input type="submit" value="submit">
<input type="reset" value="reset">
</form>
してCGIに渡す。というのはどうだ？
char *A;
モータースポーツ部 [slashdot.jp]
Re:httpd + HTML (スコア:1)
どのレベルのGUI? (スコア:1)
Xに代わるシステムか、その他のOSに付随したWindow Systemフレームワークの
話かと思ったんですが、・・・みなさんGUIアプリケーションとかWindow Managerの話を
してらっしゃって、どのレベルから唾をつけるべきか混乱してます・・・。
＃Xに代わるものとしては、ネットワーク透過性にセキュリティを組み込んだもの、
＃ポリシーの明確なものが欲しいですねぇ・・・。
＃あ、あとMI/MDの区分がはっきりしていて、VGAの性能をもっと引き出せる仕組みが
＃あれば最高なんだけど。
＃・・・その上で動くWindow ManagerやGUIアプリケーションは、わたし自身が想定してるものが
＃ぼんやりしすぎてるので、明確なイメージを持てないです。
＃・・・m17nフレームワークは2バイト文字圏の人が作ったものが欲しいな(苦笑)。
---- redbrick
Re:どのレベルのGUI? (スコア:1)
runeyokohama 氏のタレコミはツールキットのレベルの話のような気がしたんだけど。「OS 非依存」ということは、現在普及している Linux/BSD/Un*x/Windows/Mac/... などさまざまなシステムの上でそのまま使いたい、というニーズを表現しているのだと思うんですが、そうすると、OS そのものは解には当然なりえないけど、X Window System を変えるのもちょっと大ごとかな、と。
「言語非依存」って書いているので、ユーザからの観点ではなくて開発者からの観点でしょう。(それとも、ここで「言語」って自然言語のこと?)
たとえば Qt は国際化はそこそこいいし X でも Windows でも動くけど C++ という言語に縛られてしまう、とか。
Tk なんかはどうでしょう? X/Win/Mac で動くし、Tcl/Perl/Ruby/Python などが対応してるし、X 上では国際化がいまいちだけど、「Tcl/Tk 日本語版」なんてのもあるし。
Re:どのレベルのGUI? (スコア:3, 参考になる)
いやぁ、実際はひどい物ですよ。
XIM関連の実装はひどいものだし(gtk+のimmoduleはうらやましい)、
selectionまわりも未だにCOMPOUND_TEXT対応はオリジナルには実装されてません。
よく、multibyte圏のことを忘れて、1byte圏向けにパフォーマンス改善のための修正が入ったりして、
バグ報告をする羽目になったりしますし。
国際化を除いても、最近は検証してないだろうというようなバグを含んだ形でリリースされることが多いですね。
Qt2系は2.3.1が未だに推奨バージョンです(しかるべきパッチを当てれば2.3.2も多分大丈夫)。
Qt3系は3.0.2が一応推奨バージョンですが、3.0.2リリース直後に多数の修正が入ってきています。
defaultのXIM入力スタイルがOnTheSpotでその実装が駄目駄目なことを考慮すると、好きもの以外にはQt3系は進められませんね。
KDE3はかなり良くなってきているだけに(日本語対応もかなり本家に取り込まれました。問題はまだまだ残ってるけど)、そのあたりが残念。
使いやすいtoolkitだし、パッチを当てた上で細かいところを気にしなければ通常は充分なことのほうが多いですけどね。
-- Che Che - Bye Bye
M17Nの根本的な問題 (スコア:1)
アプリケーション実装する人間が multibyte 使っていない、
という状況が問題なんだよね。
文字列そのものに触らないようにすれば
ある程度は解決できるんだろうけど（ gettext とかが近いかな）、
それだけじゃあ当然ダメなんだろうなぁ。
どんな操作があれば文字列操作に必要十分なんだろ？
正規表現か？（それも multibyte 化すんの大変そうだけど…）
# mishimaは本田透先生を熱烈に応援しています
char *を使わせるな (スコア:3, 参考になる)
内部はQStringクラスを用いるようになってます。
ときどき、ぎりぎりまでchar *で扱ってて、最後の最後でQStringに変換してQtに渡すアプリがありますが、
素直に作れば入出力のところでQStringに変換されるため、
I18Nを意識していない人が作ったアプリでも、割と楽にI18N化できます。
char *を直接扱えるようなAPIになってると、I18Nですら面倒です。
内部コードと変換関数を用意し、出来る限りはやい時点で(出来れば半自動的に)変換させるようにしてないと難しいでしょうね。
できれば、内部コードとchar *形式とで、互換性がないといいかも。
内部でmultibyte charを使っているようでは国際化は手間がかかるだけです。
wide charを使うべきでしょう。
-- Che Che - Bye Bye
Re:M17Nの根本的な問題 (スコア:2, 興味深い)
使ってない人はテストできない、というのはその通りで、現在のさまざまなソフトウェアのヘボい m17n が抱えている問題がまさしくそれなんですが、一方で、multibyte も使うし combining character も使うし bidi も使うし、なんていう人は世の中にはそんなにいないので、「テストできなければ良い m17n ができない」という状況を作り出しているようなフレームワーク (OS とか API とかツールキットとか) の側に責任を求めてもいいと思います。つまり、何も考えなくても自然と m17n なアプリケーションが作れてしまう (それに違反するほうが難しい) という状況を作り出していく必要があります。
それでも、もし理想的なフレームワークができたとしても、それが提供してくれるような一般的な m17n だけではだめでもっときめ細かな操作が必要なアプリケーションなんてのもあるだろうから、そういう分野では最後までアプリケーション開発者の責任が残っていくのでしょうが。
Re:どのレベルのGUI? (スコア:1)
ここ [kde.org]をご覧いただければ分かりますが、
「Qt(とKDE)をC++以外の言語から使えるようにしよう」というプロジェクトも
いくつか存在しています。
使ったことがないので、現状がどの程度なのかは分かりませんが。