Giraffe+

左上
タスクバー(上)の下

左下
ぴったり角につけるんじゃなくて少し間あけてる
タスクバーは右に縦配置

>>558
C:\Giraffe\readme.txt に
"gi"で
C:\Giraffe\hoge
C:\Giraffe\hage
C:\Giraffe\fuga
C:\gi\hoge
C:\gira\hoge
C:\hoge\giraffe

とかの候補を表示する感じとかも無理？

>>566
異なるディレクトリをまたいで部分一致したパスをリストアップするということかな。
それだと一般的なオートコンプリートというより検索になるような気が。

"c:;gi"と入力してc-fとすればそれらしい結果が得られると思う。
これだとその都度Cドライブに検索をかけるので遅いけど。

そういうのはfenrirみたいな検索型ランチャの得意分野だったりする。

>>566
まず、入力窓の状態がパスの場合、そのディレクトリにあるファイルのみが補完対象になる。
例:
　入力窓が
　C:\Giraffe\gi
　の場合、
　C:\Giraffe\にあるgiを含むものが補完対象になる。

んで、入力窓の状態がパスじゃない場合、登録アイテムが対象になる。
例:
　入力窓が
　gi
　の場合、
　登録アイテム名にgiを含むものが補完対象になる。

これが基本動作なんだけど、パスそのものもテキストファイルで登録アイテムにできるから、
C:\Giraffe\hoge
C:\Giraffe\hage
C:\Giraffe\fuga
C:\gi\hoge
C:\gira\hoge
C:\hoge\giraffe
が登録アイテムにあるなら、
gi
の候補として表示される。

テキストファイルにもアイテムを登録できることを失念してた。
下はエディットのディレクトリ以下のパスを登録するスクリプトなのだが…。
テキストファイルに大量にアイテムを登録するとオートコンプリートがかなり重たくなってしまう。
今のとこオートコンプリート毎に参照する仕様らしいから仕方ないかな。

Giraffe.Event.Key.f12: `*[
dataFile: 'test_data.txt'
data_list: dataFile.file_load.split(CRLF)
new_items: {}

AddTextData: `path[
data:: true
data_list.each% `item[
item.iequals(path).? [data.= false return]
]
data.? [new_items.push_back(path)]
]

'Script/find.giraffe'.file_load.replace('AddListItem' 'AddTextData').eval(local)
dataFile.file_save(dataFile.file_load.+ (new_items.join(CRLF)).+ CRLF)
]

>>566的使い方でGiraffe.RegisteredItemsを用いたスクリプト。
siteinit.giraffeか、setting-setupで使うことを想定。
test_data.txtはConfig.Path.Dataには設定しない。

新機能を試すために書いたのでアイテムひとつだけ登録などいろいろ欠けてます。
使ってやろうと思う人は補ってください。

それでもパスを登録し過ぎると速度的に厳しいので注意。
テキストファイルのアイテム登録は補助的な機能だと割り切ろう。

'テキストファイルをアイテムとして登録する'
global.ItemsFileName: 'test_data.txt'

ItemsFileName.file_load.split("\r\n").each% `item[
Giraffe.RegisteredItems.push_back(item)
]

Giraffe.Event.Key.f12: `*[
'ParameterをフィルタにエディットのTarget以下の未登録パスをアイテムに登録'
old_items:: Giraffe.RegisteredItems

RegisterItem: `path[
old_items.each% `item[
item.iequals(path).? [parent.return]
]
Giraffe.RegisteredItems.push_back(path)
]

'script/find.giraffe'.file_load.replace('AddListItem' 'RegisterItem').eval(local)
ItemsFileName.file_save(Giraffe.RegisteredItems.join("\r\n"))
]

Giraffe.Event.Key.c-f12: `*[
'登録されたパスが存在しなければアイテムから削除'
old_size: Giraffe.RegisteredItems.size

index:: 0
Giraffe.RegisteredItems.each& `item.is_path.|| [item.is_iidl].&& [item.exists.not][
Giraffe.RegisteredItems.erase(index)
].| `*[index.++]

Giraffe.RegisteredItems.size.!= old_size.? [
ItemsFileName.file_save(Giraffe.RegisteredItems.join("\r\n"))
]
]

0.5.16.309

なんかGiraffe常駐してる状態でRO（Ragnarok Online）起動するとGiraffeが反応なくなる・・・
nProtectの影響なんかな…

Craft Launch EXとGiraffe+。どっちが出来ることが多いの？拡張性の高さも。

俺はGiraffe+だと思うぜ。

Craft Launch EXの方が拡張性は高いよ。
Python使うんだから当たり前だけど。

拡張性＝使いやすさ＆見易さではないので。念のため。
限界まで使いこなせる力量があれば別だけど。
膨大なスクリプトを書いた上デバッグするはめになるのなら本末転倒。

>>576
Pythonであることと拡張性には何の関係も無いでしょ。

AHKやmayuもそうだけど、この手のソフトの拡張性ってのは、APIやイベントが全て。
一方通行の拡張なら、DLLを書けばいいし、それに勝る拡張手段なんて無い。
Bluewindや旧giraffeみたいに単機能exeを実行するだけでも十分だったりする。

>>574が想定してる「拡張性」や「出来ること」は、
リストのアイコンの表示のOn/Offができるとか、
スタートメニューの内容をそのままコマンドリストとして使えるとか、
そういうのだと思うけど。

面白そうだけどなんか重いなぁ。

>>578
DLL書けば良いというなら、自分好みのを作れば良いじゃないか。
574見たいな質問をする人にそんな回答は無意味。

>>580
そのDLLの行は1行目の「拡張性 = APIやイベント」って話を踏まえての、
それらを無視した「一方通行の拡張」の話なんだが、その辺理解してる？
Pythonスクリプトを実行したいだけならpython.exeを呼ぶなりすればいいだけでしょ？

>DLL書けば良いというなら、自分好みのを作れば良いじゃないか。
DLLをなんか凄いもののように思ってない？
スクリプトより多少手間がかかるのは確かだけど、書く内容は似たようなもんだよ。
ついでに言うと、>>574みたいな人にとってもDLLとスクリプトは似たようなもん。どっちも書けない。

>574見たいな質問をする人にそんな回答は無意味。
いや、その部分は>>576に対する回答。
拡張性とPythonを結びつけるとそうなるって話。
そういう話が>>574に対しての回答にふさわしくないってのは、その下の段落で言及してる。

それぞれの拡張の手段であるGiraffeスクリプトとPythonを比べると
直感的に言語として地位をすでに築いてるPythonが守備範囲が広い気がする。

スクリプトによる拡張と、単なるスクリプトの実行の違いなんて、
分からないほうが普通なんだよな。
APIやイベントなんて言葉、知ってるほうがおかしい。

拡張というより柔軟な設定変更といった方が良い気がする。
設定変更のために複雑なコードを書きたがる人はいない。

拡張性というと「なんでもスクリプトでやらなくては、それならいっそ汎用言語で…」
と使用目的がランチャーから脱線していく罠があるように見える。

スクリプトでやるということはGiraffe.exeのプロセス上で動くってことだろう。
ランチャーと関連の薄いことをスクリプトでやりすぎるとクラッシュしたときがあ
ミンナミチヅレダヨ。

以下、Script2/settings/hotkey/...で使うとよさげ。
これもランチャー上で動かす意義はあんまりないが。

'カーソルの座標、ピクセルの色情報を表示'
include('number')
SRCCOPY: 0x00CC0020
pt: Windows_POINT.clone
User32.GetCursorPos(pt.ref)

dc: User32.GetDC(0)
memdc: Gdi32.CreateCompatibleDC(0)
bmpobj: Gdi32.CreateCompatibleBitmap(dc 1 1)
obj: Gdi32.SelectObject(memdc bmpobj)
Gdi32.BitBlt(memdc 0 0 1 1 dc pt.x pt.y SRCCOPY)
color: Gdi32.GetPixel(memdc 0 0)
Gdi32.SelectObject(dc obj)
Gdi32.DeleteObject(bmpobj)
Gdi32.DeleteDC(memdc)
User32.ReleaseDC(0 dc)

red: color.& 0xff
green: color.& 0xff00.>> 8
blue: color.& 0xff0000.>> 16
red16: number:convert(red 16)
green16: number:convert(green 16)
blue16: number:convert(blue 16)
Balloon.show("x, y = %1%,%2%\nr,g,b = %3%,%4%,%5%(#%6%%7%%8%)".format(pt.x pt.y red green blue red16 green16 blue16) 'GetCursorPos' IDI_INFORMATION pt.x pt.y)

>>581
そういう意味では賛成できるが
現状を見るかぎり、やはり、Craftの方が拡張性は高いと思うよ。
例えば、少し上に出ているパスの中間一致とかはCraftなら出来る。
fenrirを使えと出ているけど、Craft使えば、fenrirもどきの動きはする。

>>584
結局自分も、その考えから、使用頻度が高いものは拡張するより
始めからその機能が付いている方が速くていいなと気づいて
ランチャはそういうのにしている。

>>586
>そういう意味では賛成できるが
Pythonであることと拡張性に関係が無いこと、だよね？
その話しかしてないよ？
>現状を見るかぎり、やはり、Craftの方が拡張性は高いと思うよ。
Giraffe+のほうが高いなんて言ってないよ？
比較できるほどCraftのことを知らないから。
>例えば、少し上に出ているパスの中間一致とかはCraftなら出来る。
>fenrirを使えと出ているけど、Craft使えば、fenrirもどきの動きはする。
その次のレスにやり方出てるけど？

比較できるほど本当に両方のソフトのこと知ってる？
>>587を見ると、どっちも使ってないみたいだけど。
デフォルトで設定ダイアログから使えるスクリプトだけでこんなにあるよ？
http://www.ric.hi-ho.ne.jp/giraffe/giraffe/doc/settings.xml
さらにConfigや色の設定もあるし。

>>587
なんでコード書くこと自体否定するような解釈をしたがるのか理解に苦しむ。
使う気がないのに何が目的にこのスレにいるの？

好みにうるさくなければbluewindをどうぞ。
見た目も大事。柔軟な設定をしたい方。Giraffeへようこそ。
中身が全て。コード読むのも書くのも任せろ。Craftがあります。

あなたと波長のあわないソフトのスレで議論しなくても良いんじゃないかな？

あれ？>>587さんはコード書くことが全くない人か。
汎用言語使うよりもシンプルなコードで設定できるんだよ、と書いたつもりだったんだが。
書かない人にはGiraffeもPythonも複雑だろうから話がかみ合わないよ。

>>588さんもお互いスクリプトが書ける前提で議論してると見た。

お前らなんか反応キモｗ
Giaffeの中の人も大変だ。まあ、作者かもしれないけど。

General.CheckDataLinkTo
やるとかなり動作が遅くなる。
と説明してあるが４年前の箱でも変わらないぞ。

version 0.5.19.325

0.5.20.351

どなたかお助けを。
アクティブ時と非アクティブ時に表示位置とフォントの大きさとウィンドウの高さを変えたくて次のようにしてみました。

InsertEvent(
(Activate)
(ChangeFontHeight(16)))

AddEvent(
(Activate)
(var(
(top) Window.GetPos($Giraffe:Handle()(top))
(left) Window.GetPos($Giraffe:Handle()(left))
(width) Window.GetPos($Giraffe:Handle()(width))
(height) Window.GetPos($Giraffe:Handle()(height)))
Window.SetPos($Giraffe:Handle()
$left(460) $top(300) $width() $height(36))))

続く

続き

InsertEvent(
(Deactivate)
(ChangeFontHeight(14)))

AddEvent(
(Deactivate)
(var(
(top) Window.GetPos($Giraffe:Handle()(top))
(left) Window.GetPos($Giraffe:Handle()(left))
(width) Window.GetPos($Giraffe:Handle()(width))
(height) Window.GetPos($Giraffe:Handle()(height)))
Window.SetPos($Giraffe:Handle()
$left(18) $top(0) $width() $height(25))))

一応動いてるんですが、非アクティブ時のウィンドウの高さが
元の高さ(36)を強引に切り詰めた感じ(うまい言い方が見つからない)になってしまいます。
ダイアログで設定したときのようにきちんと(?)高さが縮んで欲しいのですがどうしたらいいでしょう。

ApplyConfig((size))をWindow.SetPos後に挿入

>597
出来ました。ありがとうございます。
こうですね

AddEvent(
(Deactivate)
(var(
(top) Window.GetPos($Giraffe:Handle()(top))
(left) Window.GetPos($Giraffe:Handle()(left))
(width) Window.GetPos($Giraffe:Handle()(width))
(height) Window.GetPos($Giraffe:Handle()(height)))
Window.SetPos($Giraffe:Handle()
$left(18) $top(0) $width() $height(25))
ApplyConfig((size))))

おれ、すごい前のバージョンをつかってて
久しぶりにバージョナップしようと思ってこのスレ来てみたら・・・


いったい何に使えばいいんだ・・・確かランチャーだったよな・・・

これはランチャー以外にもやりたいことがある人向けのソフト

Yet Another Alt+Tab Replacement
でリストを絞り込んで表示できるようになりませんか？
該当するwindowタイトル以外は表示しないようにしたい

>>601
作者に要望か
SwitchWindow.giraffeを見て考える

foobarで音楽を再生中の場合に、これにジャケットとか表示できないかな〜？

アクティベイト、ディアクティベイトする度に
少しずつメモリ使用量が上昇していくんだけど、なんかバグっぽくないですか？そんなもん？

あとmigemo使用時のメモリ使用量が
他のmigemoを使うソフトウェアに比べて多すぎるんだけど
(migemo使用時と未使用時で20Mくらい違う)
どーにかする方法ないですか？

>メモリ使用量上昇
GCはそんなもん、だと思う。
ゆっくりと段階的に開放してるはず。

>migemoのメモリ使用量
自分の環境だとxyzzyと同じ。
siteinit.giraffeでオープンしてて、なおかつ設定ダイアログでもやってて二倍になってるとか。
"Migemo.close"でF1して減るメモリ使用量を確認してみるといいかも。

定期あげ

0.5.29.460

デスクトップと解像度の違うフルスクリーンのゲームすると、Giraffeの位置が変わっちゃって
その後Girffe終了するときに位置を保存したくないんですがどうすればいいですか？
フルスクリーン後の位置が変わってしまうのはどうしようもないと思うんですが、
Giraffe.iniをRead-onlyにすると思い通りになりましたが、何かもっとスマートな方法があれば教えてください。

siteinit.giraffeに、
SetConfig('Unload')
で、終了時の設定保存を、
SetConfig('OnMove_MainWnd' [true])
で、ウインドウが動いたときのConfig更新を殺せる。

>>608
ありがとう。まったく違うとこさがしてた。
結構前から気になってたからすごい助かりました。

あ、SetConfigじゃなくてSetEventだ。

>>610
aaしっかりEventに変換して記入してたｗ　ありがとう

作者様のblog中に、スクリプトの試行には、コードをコピーして、giraffeに
get-cb.evalと入力し、F1を押すとありますが、特に何も起きないようです。
何が間違っているのでしょうか？
おそらくget-cbのcbはクリップボードの意味と思われるので、コピーしてから
クリップボードに保存されたコードをevalする、という意味かと思うので、
操作的には間違いないように思うのですが。

何も起きてないように見える内容のものを評価してるだけじゃないかと。
get-cb.flushでF1押して、クリップボードの中身とF1が有効かどうかの確認をしてみるといいかも。