PythonでカッコイイGUIライブラリ "PyUI" 26
ストーリー by wakatono
これはカッコイイぞ 部門より
これはカッコイイぞ 部門より
bravo 曰く、 "http://pyui.sourceforge.net/でまた新たなGUIが誕生しているようである。スクリーンショット(同サイトでいくらか紹介されています) どうやらゲーム開発での利用を前提に作られており、見た目もなかなかクールだ。もちろんプラットフォームもWin32、Gnome、KDEと一通り対応していて、ライセンスもLGPLである。今までのPython/Tkや、wxWindows for Pythonのようなありきたりなウィジェットに飽きている方にもぜひ試して頂きたい。"
ありきたりだから悪いというわけでもないだろうが、今回のPyUI(ぴゅい?)はなかなかカッコイイ。でも、オレPythonユーザじゃないんだよなぁ…Pythonを使えという何かの啓示だろうか?
透過 (スコア:2, すばらしい洞察)
今の GUI って、Window を重ねた時の使いにくさったらないもので。
3Dなんていらないから、次のウィンドウシステムでサポートしてほしい。
-- wanna be the biggest dreamer
透過なんてCPU食いよりも他にやることが山積… (スコア:2, 参考になる)
そういうものなんでしょうかね?
机の上に乱雑に散らかされた書類の山が、
その素材が紙からOHPシートに替わっただけで、
そんな劇的に机は使いやすくなるんでしょうか?
とても俺にはyesと思えないのですが。
勝手な思いこみですが俺は、「見えない」かどうかよりも
「(手が)届かない」かどうかのほうが、重要な問題だと思っています。
だからAlt-Tabで窓を切りかえられるwindows(もちろんunixの各種wmでも
同じことは出来ますし)は、そういう意味ではあんまり辛くないです。
マウス使わずに「手が届く」ことがそれなりにできるから。
#もちろん他の辛さはいっぱいあるけどね>win
あるいは、そもそも窓を「重ねる」ってのが無理だという話も。
Overwrap窓って、計算機でわざわざ整理されてない乱雑に散らかった机を再現
するっていう悪趣味だと思うんですよね。
タブブラウザみたいに全部タブにしちゃえばいいんだ。
いや実際そういうwmもたしか有りましたよね。
あるいは「すべてのアプリをフルスクリーン表示のみにする」という
wmもある(たしか「鼠殺し」という名(和訳by俺)だったような。
ScreenShotを見てもwm自体は「なにも」見えない(笑))わけですし。
人々が窓を重ねるのに拘る理由って、それこそ単なる慣れでしかないと思います。
べつに便利でもなんでもないのに。
余談:
Overwrapさせるなら、もっと他の用途に使わないと駄目だと思う。
重ねることに論理的意味があるような、さ。
身近なものを真似たメタファとして、ルーペとかセロハンとかが有るわけで、
あーいう使いかたなら俺も歓迎。
そうでないならただのCPUの無駄にしか思えん。
Re:透過なんてCPU食いよりも他にやることが山積… (スコア:1)
Re:透過なんてCPU食いよりも他にやることが山積… (スコア:1)
>たりするもんじゃない?
そりゃまそうなんですが、逆に言えば現時点で判る範囲では無駄っつーことで。
というか、単に透ける「だけ」なら、無駄になり易いんじゃないかと思うんです。
透けたことのメリットを活かすような更なる仕掛を、なにか追加したほうが良いような気が。
例えば、複数の窓が位置の情報をやり取りする、そして移動や拡大縮小を「連動」する、とか。
そうすりゃ、透けてるものを上から一撃で見通せることのメリットが、かなり有ると思うなあ。
これ、リアルワールドで言えば、OHPシートを「重ねて」いるのに相当する操作のつもりです。
重ねてセロテープとかで固定したりするっしょ?あの作業です。
位置あわせをした状態を永続化(^^;するわけね。
単に乱雑かつ無節操に重なるだけでは、目に入る「ノイズ」が増えるだけだと思うんです。
少なくとも、隠れた窓を探すためだけ(誰も「だけ」とは言ってないわけですが)に
透過を使うってのは、Alt-Tabのほうがずっと良好なUIだとしか思えないです。
なので、それこそ他の用途のアイデアを模索したいところなんですが、
透ける「だけ」じゃ、ちょっとねえ、怪しい通販製品みたいな(笑)使えなさを予感しちゃうです。
リアルワールドのモノと違って計算機上のUIは、プログラムされた動作を超えたことは
できないので、たとえば透けてるからってそこにマジックで絵を描く自由は
(そういうアプリを窓の中で起動しないかぎり)ユーザーには無いわけです。
応用は結構し辛いものがあります。
なにかメタな自由度を提供できればユーザーも色々工夫を行う余地が生じるわけですが
(CUIもそうやって繁栄したわけですし)。なんか見つかるといいなあ。
Re:透過なんてCPU食いよりも他にやることが山積… (スコア:1)
>「(手が)届かない」かどうかのほうが、重要な問題だと思っています。
さっき偶然見つけたんですが、
http://homepage1.nifty.com/salt/fsw.htm
>Holer for Windows95
>ウインドに穴をあけて、デスクトップ上のショートカットをクリック出来るようにするソフトを作ってみました
まだ俺も使ってみてないので実際どういうソフトか確認してないんですが、想像するに、
まさに「届く」ようにするソフトの一種なのではないかと。
これだよこれ。例えばこーゆー路線がきっと…
#ただ、
#>ほとんど動作確認してませんので、覚悟してお使いください(笑)
#とのことではありますが(^^;;;;;
Re:透過なんてCPU食いよりも他にやることが山積… (スコア:0)
具体的には、任意のウィンドウやフレームをグループと呼ぶことにします。フレームとはオーバラップで配置されているグループの集合だったり、タイリングにより配置されているグループの集合だったり、タブで整理されたグループの集合だったり、です。
これによりグループは再帰的にグルー
Re:透過なんてCPU食いよりも他にやることが山積… (スコア:2, 興味深い)
それですそれ。だいぶ前から思っていたんですが、
windowsの1つ間抜けな点は、MDIという概念を持っているにもかかわらず、
MDI(のGUI)を再帰的に適用するという概念を持ってない、という点だと思います。
親子は1代かぎりなんだよね。
というか、あれをマルチ「ドキュメント」インターフェースと
呼んでいるってのが、思考を制限している点だと思っています。
つまり1窓が1「ドキュメント(=Model)」の反映(=View)だと
捉えているわけですが、win(MFCか)のDocument-Viewって
DocやViewをあくまで「アプリ」とか「データファイル」とかの
大きい単位でしか捉えてなくて、線一本とかの「小さいMVC」を
サポートしてない、という点だと思っています。
これ、不便つーか邪魔だなと思うことが、多いです。
#なので、DocViewと関係なくプログラムできるdelphiのほうがMFCなVCよりずっと好きです(笑)
窓を再帰的に表示することによって便利がもたらされた、という解釈を
してないよねMFCは。勿体ないなあ。
Re:透過 (スコア:2, 興味深い)
とりあえず、こんなのが思い付きましたが。
Re:透過 (スコア:1)
が、もっと発展させると色々と面白そうですね。
<blockquote> </blockquote>
透明で無視というのは、MacOS みたいにタイトルバーにしまう感じかな。これが後者の「透明度による困難の度合い」で統一されるとすっきりしそう。
部分的な透明化とかどうだろう。
もはやデスクトップ操作がグラフィックツールになりそうだ^^;
-- wanna be the biggest dreamer
Re:透過 (スコア:1)
>部分的な透明化とかどうだろう。
>もはやデスクトップ操作がグラフィックツールになりそうだ^^;
「マジックワンドで文章を選択してペースト&境界線のぼかし」で、勝手に文体や用語の統一をしてくれるようになってくれたら嬉しいんですけどねぇ。
#可能なような不可能なような、、、、
Re:透過 (スコア:1)
そういうツールキットを作ればよいのではないかと。
で、もしそれを作るのに「Xの仕様が」邪魔なったら、それはXの替え時だ、ということで。
#mswinでも同じこと
Pythonを使えという啓示でしょう (スコア:1)
そうだと思う(^_^;)
Python Japan User's Grou [python.jp]
にまずいくべし。
〈オフトピ〉
Pythonトピックできたんのでそこに登録すべきだったと思います。
選択が1番したで見つけずらいのがちょっとあれですけど・・・
タレコミ時点ではなかったのかな??
〈/オフトピ〉
影はいいの? (スコア:1)
でも、ウィンドウの外側に影をつけるのはAppleの著作権として認められたのではなかったかしら?その昔あった対Microsoftルック&フィール裁判でそんな判決が出ていたと思ったけれども。(ソースは見つけられず)
Ninjaneering (スコア:1)
同様に彼らが関わっているTwisted Matrix Laboratories [twistedmatrix.com]もユニークなプロジェクトなんで注目してます。
Re:Ninjaneering (スコア:0)
Re:Ninjaneering (スコア:1)
cool! (スコア:1)
しかもこれはPurePythonってのがいいですね。
ただこれはゲーム用ライブラリという割には描画性能があまりよくなさそうです。(実際使ったことなくてソースみただけなんでなんとも…)
シミュレーションゲームとかならCoolですね。
ぷらっとほーむ? (スコア:1)
当然? 使えるの?
# Python user になるかも
---------- yuzo ----------
Re:ぷらっとほーむ? (スコア:1)
必要とされる、Python本体、PyGame、PyOpenGL、Python Imaging Liblary (PIL)で動きそうです。それぞれのダウンロード先はリンク先アーティクル中にあるのでそこからダウンロードすれば良いはずです。
Re:ぷらっとほーむ? (スコア:1)
たぶんBlackboxで動かすなら、TkかOpenGLを使って動かすと思います。
描画エンジンを動的に決定したりすることで、ほとんどの環境で同じソースが動くんじゃないでしょうか。
Re:ぷらっとほーむ? (スコア:1)
X11をインストールしていないMacOS X でもOKということになりますね。
Re:ぷらっとほーむ? (スコア:1)
付属のサンプルは動くものと動かないものがありましたが
多分wmは関係ないと思います。(Cのモジュールが組み込めないとかそんな感じでした)
実際どうなってるのか分かりませんが、とりあえず引数で指定して
OpenGLとTkと両方動いているようでした
まあ、予想通りというかものすごく重いです。
これ [sourceforge.net]ならまあそれほどストレスは感じませんが
ウインドウが透過しているやつは、2枚重なるとかなり厳しいです
3枚だともうへろへろでした
色々気になる所はありますが、これだけのGUIを簡単に書けるのはすごく魅力的です。
(元記事がリンクしてるスクリーンショットは106行)
もうちょっとパフォーマンスアップすればかなり使えそうな気がします。
PythonでGUIというと (スコア:1)
かっこいい! (スコア:0)
かっこいいから使ってみる=その開発言語も好きになる
この図式に乗ってしまいそう。
Re:かっこいい! (スコア:1)
WM+Etermとか、e+Etermとかつかって仕事してるのを、Mac使いなデザイナーさんに見られると、たいていの人が「Linuxいいなー、やってみようかなー」などと言い出しますよ、はい。
実際やってるのはxemacsでメール+コード書きでEtermではsshやscpやcvsやrsyncだったりするんで、全然見た目関係なかったりするんだけど^^;
|かっこいいから使ってみる=その開発言語も好きになる
って図式は、昔のボーランドとかが一部ではそうだったのかもしれないなー
Re:かっこいい! (スコア:0)