アカウント名:
パスワード:
最近はマシンが速くなったので数十秒でもトロく感じますが、貧弱なメモリと CPU で動いていた昔のマシンだとアプリ起動に数分とかあったんじゃないでしょうか。で、しかもメモリがないので、「ちゃんとダブルクリックしたのかな」ってアプリ二個目立ち上げると、メモリが貧弱なだけに仮想メモリに書き込みが始まってさらに遅くなって、フリーズ（Mac）もしくは青画面（win）。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
些細なことだけど (スコア:0)
変更しないでくれればいいのに...
Re:些細なことだけど (スコア:1)
プログラムがインストールされているディレクトリツリーの中から、
ファイル"sofficerc"（Windowsなら"soffice.ini"）を探して、
[Bootstrap]
Logo=1
を
Logo=0
に変えてください。
別に起動が早くなるわけじゃありませんが。
Re:些細なことだけど (スコア:1, 興味深い)
ものによってはウィンドウの後ろに回せなくて、起動まで他の作業を止めて待ってないといけないものもありました。起動が長かったりすると最悪ですね。
Re:些細なことだけど (スコア:1)
ユーザはアプリケーションを使いたいのではなくて
作業したいだけなのに、自己主張されてもねぇ。
AdobeなりMSなりのスプラッシュはブランディング/広告の為であって
オープンソースの製品なら省いてしまっても良さそうなもの。
もちろん、オープンソース製品に
ブランディングが必要ないといっている訳ではなく
ユーザの使い勝手とどちらを優先するかという場合に
よりストイックに対処できるのではないかと思うのです。
スプラッシュ (スコア:1)
最近はマシンが速くなったので数十秒でもトロく感じますが、貧弱なメモリと CPU で動いていた昔のマシンだとアプリ起動に数分とかあったんじゃないでしょうか。で、しかもメモリがないので、「ちゃんとダブルクリックしたのかな」ってアプリ二個目立ち上げると、メモリが貧弱なだけに仮想メモリに書き込みが始まってさらに遅くなって、フリーズ（Mac）もしくは青画面（win）。
Re:スプラッシュ (スコア:1)
「ああ、これはOSとアプリの両方の設計の悪さの相乗効果の賜物(反語)だなー」
と感じています。
プロセスが
「只今わたくしめは起動最中でございます」
という意思(もとい状態)表示を、
OSやユーザや他のプロセスに、もっと旨く示せば(示せれば)、
あんな見るからに暑苦しいスプラッシュなんてものとは
オサラバできるんだと思うんですが。
まず、MacOS 6じゃあるまいし、(擬似も含めた)マルチタスクなGUI OSにおいては、
ユーザの行く手(?)をドドーンと遮るような窓なんて、出しちゃいかんのですよ。
＃そういう意味では、「ダイアログボックス(Modal窓)」全般が、同罪だとも言えますが。
常にユーザに、切り替えの自由を与え続けなきゃ。
「でも起動最中のthisな窓に触られたら困るっしょ」って？
じゃあ、こうすりゃいいじゃんよ。
起動中は窓を「表示しない」！！
窓を下手に半端な状態で表示してるから、触られてトラブるんだわ。
だったら出さなきゃいい。
起動中という状態が落ち着く(通常状態にまで遷移し終わる)まで
Visibleでなけりゃいいんだよ。
「そんなことしたら、起動してるかどうかユーザに見せれない」って？
そりゃ、普通の意味での窓自体を以って起動中であるってのを見せようとするから
あかんのであって。
思うんだけど、一部のMailソフトとかにあるように、
画面の「隅っこ」に、今起動中な奴が居るぜって、表示したらどうだ？
てゆーか、起動したら先ず画面(窓)が「表示」されるってのを止めたらどうだ？
例えば一案として、
起動されたプロセスは、必ず、Windows用語でいう「最小化」状態になる、ってことにしたらどうだ？
そして、プロセスが起動状態から通常状態に遷移するまでは、そもそも拡大メッセージを受け付けないことにすりゃいい。
そしてユーザは数秒後に、タスクバーから「出来上がってるはずのプロセス」を
「とりだす」
っていうイメージで、使うの。
Unix由来の「プロセス」っていう考え方は、GUI環境に馴染まないと思うのでG7
プロセス(==処理)、つまり起動と同時に仕事を始める、っていうモデルじゃなく、
起動によって仕事の「準備」をするっていうモデルだよね、GUIってさ。
＃仕事用のオブジェクト(インスタンス)を、その場で作るんだよね。
だから、いきなり目の前で立ち上がろうとするってのは、変なんだと思う。
たとえば時計が欲しいと思ったとき、目の前でいきなり時計の組み立てを始められても困るだろ。
間違えて素人が組み立て最中の時計に指触れて壊してしまう恐れだって有る。
だから、完成して初めてユーザの手に渡す、っていう順序にするのは当然だ。
今のGUIは、それと同じ過ちをしてると思う。
未完成のプロセスをユーザに触られかねない、という状態を防いでいない。
え？その防ぎがスプラッシュだろって？
ご冗談を。
時計を欲しいといったとき、
時計が出来るまで「(時計以外も含めて)全ての」道具に触らないでくれ、なんていう
傲慢な要求をされたら、誰だって困るだろ。
未完成の時計(だけ)をユーザの目から隠せば、それで済むんだ。
で、出来上がった頃合を見て時計を「とりだせ」ばいいのだし、
未だ出来上がってなければとりだせないようにLOCKしとけばいいのだし。
自動販売機の商品出口、みたいな感じにすればいいんじゃないかな。
注文したら、Prepareされたものが口から出てくるわけだろ。
もちろん注文を待つ間に客は電話を掛けられない、なんて言う不自由は被らない。
ああいう感じにさ。
---
あと、二重起動を防いだほうがいい状況ならば、
「今起動中です」ていう情報を、きちんとOS内で伝達できるようにしとかないとならない。
その際問題になるのは、その伝達ってのが「何から何へ」行なわれるのか、という問題だろう。
俺が思うに、それへの一番すっきりした回答は、
「起動中のプロセスObjectから、起動の元ネタであるプログラム(実行ファイル)Objectへ」だ。
最近思うんだが、プロセスと実行ファイルは、インスタンスとクラスの関係に似てる。
クラスもまたオブジェクトっていう感じで捉えると、
実行ファイルのmain関数は、プロセス「クラス」のnewメソッドであり、
それはプロセスから見ればクラスメソッドであり、
実行ファイルから見ればインスタンスメソッドだ。
＃前にも言ったかも知れないが、WindowsのAPIでいえば、
＃WinMain(普通のCのmainに相当する)はクラスメソッドであり、
＃WinProcはインスタンスメソッドだ。
で、そのプロセスから実行ファイルにMessageをSendする、という風に考えれ
Re:スプラッシュ (スコア:0)
Re:スプラッシュ (スコア:0)
> 「ああ、これはOSとアプリの両方の設計の悪さの相乗効果の賜物(反語)だなー」
> と感じています。
私は、プログレスバーが不均一な進捗を報告するたびに、
「ああ、これは物理法則の限界だなー」
と感じています。
# 関係ないな。