アカウント名:
パスワード:
仮想ターミナル(*BSDならALT+F?)やscreenを使えばいらないです.
screen は window manager なんだけどね。
ところで、screen なら split できるので、同時に 2 つ以上の端末見られますね。
Emacsで画面分割して M-x shell とかはいかがでしょ?
つうことで、Ctrl-Alt-F? の画面切り替えだけの暮らしにはちと耐えらないかな。emacs と vi は、同じ画面で同時に使いたいし。
なるほど…そういう縛りですか. それだとつらいですね.
やれそうなことと言ったら processを止めて fg とかで切替るくらいですかねぇ. emacs と vi を同時にってのは無理ですが. 僕は less とエディタ って組合わせが多いですけど.
手元のVine Linuxだと
また, 隣の仮想terminalへ移るときは Alt+矢印でも行けます. Window Makerの仮想デスクトップだと Ctrl+Alt+矢印になるわけですが ここでもCtrlが有無の差が……
Xとconsoleとで覚えるのがめんどーな場合は Ctrl つけて覚えちゃった方が確実な気がしますが, 手が小さいせいかCtrl+Alt+F1 ってナニゲに押しづらいっす.
1. キーボードで操作するCLI 2. キーボードで操作するGUI 3. ポインティングデバイスで操作するGUI
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
ふつうかなぁ...と思いつつ... (スコア:1)
Re:ふつうかなぁ...と思いつつ... (スコア:3, すばらしい洞察)
ウィンドウシステムは必須だと感じてますけど。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
仮想ターミナル(*BSDならALT+F?)やscreenを使えばいらないです.
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Alt+Fn1-8の切り替えはどうでしょう
And now for something completely different...
Re:ふつうかなぁ...と思いつつ... (スコア:1)
ホットキーで全画面を切り替えるってのは勘弁。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ふつうかなぁ...と思いつつ... (スコア:0)
複数画面を全部という意味の全画面だと思う。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
screen は window manager なんだけどね。
ところで、screen なら split できるので、同時に 2 つ以上の端末見られますね。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Emacsで画面分割して M-x shell とかはいかがでしょ?
Re:ふつうかなぁ...と思いつつ... (スコア:1)
つうことで、Ctrl-Alt-F? の画面切り替えだけの暮らしにはちと耐えらないかな。emacs と vi は、同じ画面で同時に使いたいし。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
なるほど…そういう縛りですか. それだとつらいですね.
やれそうなことと言ったら processを止めて fg とかで切替るくらいですかねぇ.
emacs と vi を同時にってのは無理ですが.
僕は less とエディタ って組合わせが多いですけど.
Re:ふつうかなぁ...と思いつつ... (スコア:0)
器用な方ですね :-)
Re:ふつうかなぁ...と思いつつ... (スコア:1)
>ホットキーで全画面を切り替えるってのは勘弁。
ターミナルを見たい画面の分だけ用意してください。
# 実際そうしてたので、ID
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Re:ふつうかなぁ...と思いつつ... (スコア:0)
因みに、OpenBSDはCtrl+Alt+Fnです。:-)
Re:ふつうかなぁ...と思いつつ... (スコア:1)
手元のVine Linuxだと
Xを使ってるときは Ctrl+alt+F2とかで移動して その後はAlt+Fn で操作できます. Ctrlをつけてもいけるようです. でもって Alt+Fn は Window Makerでの仮想デスクトップの切替に使われています. VNCとかでWindowsとか使ってるときにAlt+F4で違うワークスペースに移っちゃうのがタマに傷:-p
他のWindow Managerとかはどうなんでしょ?
また, 隣の仮想terminalへ移るときは Alt+矢印でも行けます. Window Makerの仮想デスクトップだと Ctrl+Alt+矢印になるわけですが ここでもCtrlが有無の差が……
Xとconsoleとで覚えるのがめんどーな場合は Ctrl つけて覚えちゃった方が確実な気がしますが, 手が小さいせいかCtrl+Alt+F1 ってナニゲに押しづらいっす.
Re:ふつうかなぁ...と思いつつ... (スコア:0)
HHKだと四つキーを押さなきゃいかんのか…
Re:ふつうかなぁ...と思いつつ... (スコア:0)
# しばらく/dev/consoleしか使えなかったAC
Re:ふつうかなぁ...と思いつつ... (スコア:0)
Re:ふつうかなぁ...と思いつつ... (スコア:0)
Re:ふつうかなぁ...と思いつつ... (スコア:0)
画面上に大量にウインドウを開けまくって「あっ!今後ろの方で何か動いた!」って感じで使うのが良いです。
CLIのために高額グフィクカードや大画面ディスプレイ買った方もいらっしゃるんじゃないでしょうか?
Re:ふつうかなぁ...と思いつつ... (スコア:2, 興味深い)
cliのRSSリーダさえあれば今でも結構生きていけそうな気がします...
Re:ふつうかなぁ...と思いつつ... (スコア:0)
自作のwebサーバで動くタイプなRSSリーダ(言語はphp)を使ってます。
w3mで見ればおっけー。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Visual Editor も使って良さそうな感じだし。
# 最初、termcap 系も使わない環境なのかと思ったバカ者。
Re:ふつうかなぁ...と思いつつ... (スコア:0)
同じく。それぐらいじゃないとニュースにならないと感じてしまう。
#catでプログラムを書くぐらいの伝説は欲しい。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
catでアセンブラコーディングが書ければグルで,
catでデバイスドライバ書けるようになればウィザードだっけか?
Re:ふつうかなぁ...と思いつつ... (スコア:0)
catとまでは言わないけど、edで書くべきでしょう。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
w3mならウェブでも耐えられるんじゃないかと。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
CLIを見直す姿勢は基本的には支持たいのですが,一方,なぜかUNIX由来のGUIツールに限っては,Windows以上にポインティングデバイス依存しているものが少なくないような印象です。もちろん最近のツールキットを利用しているものなら良いのですが,ダメなものはとことんダメだったり。
個人的にはグラフィカル・キーボード・インターフェース(仮称)なソフトウェアを提唱したいです。
上の中では,個人的には 2 を歓迎します。
Re:ふつうかなぁ...と思いつつ... (スコア:2)
例えば
Ctrl+F → 検索ダイアログ表示 → キーワード入力 → Enter
でテキストを検索を行うソフトは多くあります。
しかしそれらのソフトのほとんどがCtrl+Fを押してから検索ダイアログが出る前にキーワードを入力してしまうと上手く動きません。
伝統的なCUIソフトの場合どんなに速く入力してもそれは1つのキューに溜められて1つの集中管理されたイベント処理ルーチンが1つずつ逐次処理していきますので正常に動作します。
しかし現状のたいていのウインドウシステムではイベント処理は分散され、各ウィジェットに割り当てられたイベントハンドラが処理を行います。
別にイベント処理を分散することは自体は問題ありません。オブジェクト指向としても自然です。
問題はイベントのディスパッチがウィジェットが表示されているかどうかに依存していて、しかもイベントのディスパッチを行うスレッドとウィジェットの表示を行うスレッドが非同期に動いている別のスレッドだという点です。
これは単純に2つのスレッドを同期させれば(細かい問題はいろいろありますが)解決できます。そうすれば伝統的なCUIのソフトのようにウィジェットを表示するのに時間がかかっても入力は遅れながらも正しく処理されます。
しかし、本当にこれでいいのでしょうか。
こうしてしまうと今度は逆に、ウインドウを表示した後、元のウインドウを操作しようとしても新しいウインドウが表示されるまで操作ができません。そもそもGUIでは操作対象はすべて目に見えるものであるべきです。見えないものが入力を受けとれる状態はセキュリティーの問題にも繋がります。
ではどうしたらいいのでしょうか。
どちらのイベントディスパッチ方法も一長一短なのであればディスパッチ方法をユーザーが明示的に指定してやればいいのです。
そしてGUIの枠組み内でそれを自然に行うにはコマンドをオブジェクト化すればいいのです。
つまりユーザーの操作はこうなります。
Ctrl+F → コマンドオブジェクト作成開始コマンド入力 → 検索キーワード入力 → Enter → コマンドオブジェクト作成終了コマンド入力 → 検索ダイアログが表示されたところでコマンドオブジェクトを検索ダイアログに適用
こうすればウインドウの表示されるタイミングに影響されずに入力を行うことができます。
また、この方法ではコマンドオブジェクトを使わない場合操作は従来のままとなり、初心者や既存の操作方法に慣れたユーザーを惑わせません。
もし、この方法でも検索ダイアログが表示されるのさえ待てないと感じるならば、それは検索という操作を検索ダイアログに対して行うものではなく文章そのものに対して行うものと考えているからです。よって検索ダイアログを使わずに検索コマンドを直接文章へのコマンドとして実装するべきです。
#イベントディスパッチをどのレベルで止めるのかとかいろいろ考える必要があります。
Re:ふつうかなぁ...と思いつつ... (スコア:0)
良くもあり悪くもあり
# アプリがキュー放さないで死んじゃうとねぇ
Re:ふつうかなぁ...と思いつつ... (スコア:0)
Ctrl+Fから始まる遷移は、ユーザの操作というよりはユーザがキーボードで
何かを入力することによってプログラム側のオブジェクトはこういう風に生成されるよ、
というのを表しているだけだと思うんだけど、
見えないところに対して入力するのってそもそもGUIと言えるのだろうか。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
>見えないところに対して入力するのってそもそもGUIと言えるのだろうか。
ですのでコマンドオブジェクトを生成します。
>検索ダイアログと置き換えダイアログが共通である設計のソフトの場合
>フォーカスがどこに当たっているか指定できないという問題もあるし。
それはCUIのソフトでも検索文字列と置き換え文字列のどちらを先に入力するかわからないので同じです。ここではソフトに十分慣れたユーザーを前提に話をしています。
>それと、オブジェクト指向はいいけど、操作上の問題になるほど検索ダイアログの表示が遅いのは設計に問題があるんじゃない?
2点。
検索ダイアログはあくまで例でありもっとウィザードなど初期化に時間のかかるダイアログがあるかも知れない。
コンピューターがビジーであれば小さなダイアログボックスでも表示に時間がかかる。
確かに人間様の扱うUIがバックグラウンド処理ごときでもたつくのは設計に問題がありますが、いくらスレッドの優先順位を調整しても限界があります。周辺機器から割り込みがたくさん入っていたり複数人でコンピューターを使っていたり。
Re:ふつうかなぁ...と思いつつ... (スコア:0)
>>周辺機器から割り込みがたくさん入っていたり複数人でコンピューターを使っていたり。
処理能力を超えた物はCUIであろうがGUIであろうがなにやってもだめ
Re:ふつうかなぁ...と思いつつ... (スコア:0)
まあ負荷が高くなくてもネットワーク越しに使えば検索ウインドウが遅れることなんか普通にあるな。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Re:ふつうかなぁ...と思いつつ... (スコア:0)
Ctrl + F で検索ウィンドウが出るのは良いけど、
Alt + U / Dとかで検索方向を変更出来なかったりするしね…。
Re:ふつうかなぁ...と思いつつ... (スコア:0)
Web -> lynx
Mail -> emacs + wl
2ちゃん -> emacs + navi2ch
chat -> もともとやんないし。
テキストいじり -> vim
ファイル操作 -> 普段から仮想端末上からコマンドでやってるので no problem
画面の切替え -> ALT + Fn
ゲーム -> とりあえず rogue でもやっとくか。
あ、デスクトップ用途でも CLI オン
Re:ふつうかなぁ...と思いつつ... (スコア:0)