+++ ファイラーを語ろう Part34 ---

ファイラーとはエクスプローラーにもっと便利な機能を付けたようなソフトです

+++ ファイラーを語ろう Part33 ---
https://egg.5ch.net/test/read.cgi/software/1710396573/

追加
yazi
6s(初回表示)
0.1s以下(戻る、進むでの再表示)

ファイラーで戻る、進むでキャッシュしたの使うのアリなのか
表示してないキャッシュしたフォルダ監視して差分更新できるけど

100万ファイルを作るのに手間取ったので試したい人はこちらでどうぞ
(解凍は3分程度)

https://15.gigafile.nu/0507-ibbd576116ec4472330ee03dc8ef134c7
(保持期間は5日)

>>778
解凍ソフト付属ファイラーは、7-Zipのが優秀やね

十分速いと思ってたのに40秒かかったのがショックで
プロファイラ見ながら遅いところ全部潰したら15秒切った
14.862 <module> main.pyw:1
├─ 9.512 [self] main.pyw
├─ 0.752 App.__init__ main.pyw:79
│ └─ 0.730 App.setup_ui > MainView.__init__
│ └─ 0.359 MainView._create_widgets > _create_nav_bar
├─ 0.556 DirectoryTreeDelegate.paint
├─ 0.514 DirectoryViewModel._on_scan_complete
│ └─ 0.375 DirectoryViewModel._finalize_scan
│ └─ 0.340 FileSystemModel.add_items_chunk_progressive
│ └─ 0.340 FileSystemModel.sort > _execute_sort > _sort_internal
├─ 0.475 DirectoryTreeView.mouseReleaseEvent
│ └─ 0.475 DirectoryTreeView._schedule_pending_click
│ └─ 0.475 MainView._on_tree_navigate > PaneViewModel.navigate_to
│ └─ 0.475 DirectoryViewModel.change_directory
│ └─ 0.475 DirectoryViewModel._perform_full_scan
│ └─ 0.438 FileSystemModel.update_items_diff
│ ├─ 0.229 [self] model\file_system_model.py
│ └─ 0.168 FileSystemModel._remove_rows_grouped
├─ 0.440 IconLoader._on_needs_provider
│ └─ 0.437 FileIconProvider.fetch_and_cache > _make_flat_icon
│ └─ 0.371 QIcon.pixmap <built-in>
├─ 0.432 <module> view\main_view.py > viewmodel\main_view_model.py
├─ 0.375 FileViewKeyHandler.eventFilter
├─ 0.280 FileSystemModel.flags
├─ 0.210 DirectoryTreeView.mouseMoveEvent
└─ 0.383 Other (rowCount, updateGeometries, etc.)

claudeに作ってもらったばっかのファイラで試したら、zipの中身を覗くのに4秒くらい、フォルダを潜るのに4秒くらいだった
多分これ、spiとかDLLとかで変わるよね
最初にちょっとだけ読み込んですぐ表示させて、その後はバックグラウンド処理とか出来るDLLなら高速になると思うけど
それを自分で作らないといけない

>>779
zipの状態のままで 詳細表示 日付降順ソート
7-zip
1s(zipを覗く)
7s(1Mファルダ内を覗く)

>>780
DirectoryTreeView~が見えるのでオフにして詳細リスト表示だけにしたらもう少し速そうですね

>>781
> 最初にちょっとだけ読み込んですぐ表示...
実ファイルシステムでyaziがそのような動作ですが、ソートが絡むので結局は全部スキャンしてからでないと正しい表示順にならないですね

>>750,768や>>774-776は実ファイルシステムでの計測です

zip状態との対比で実ファイルシステムと呼んだのですが少し不正確でした
>>750は仮想環境と書かれてますね
>>774-776はRAMディスクです

SSDへのzip解凍は8分程度かかりました

SSD 実ファイルシステム
FilePilot
9s(初回表示)
0.1s(親フォルダ表示で先読み済みの場合。戻る、進むでの再表示)

Filedini
4s(初回表示)
4s(戻る、進むでの再表示)

OneCommander
12s(初回表示)
12s(戻る、進むでの再表示)

yazi
6s(初回表示)
0.1s以下(戻る、進むでの再表示)

>>779
AS/Rはオプション→リスト→表示→表示共通で、一覧に表示できる上限数に0を登録すると上限の制限が解除できます
100万ファイルある状態で、ファイルの追加・編集・削除が普通にできるように、とヘルプで述べられているので上限を解除するのは問題ないかと
あの作者さんは、一覧の生成速度よりも、更新速度の方が作業の快適さには重要と言ってたのが印象的だったです

ひょっとしてFilepilotが速いのってカラム幅を計算してなかったり、取得属性が少ない状態だからじゃないのか
うちのでも詳細モードじゃなくてサムネイルモードでアクセスしたら1秒で操作可能になった

IOなんちゃらで読み込むんだよ
データの整形とか一切しない生データみたいなやつ

そもそもファイルアクセス中に操作不能になるのがおかしい

127500個で180秒ジャストファイラーじゃないんで比較にならんけど

>>768
Everything 1.5a はどんなもんだろ
表示カラムやソートモード次第である程度ブレが出そうではあるけど

負荷のかかる作業で操作不可能＝固まるのが当たり前だとすりこまれてるから
Windows界隈は
ファイルアクセスやサムネ作成程度で固まるのを疑問にも持たない

>>789
everythingはあらかじめキャッシュされたデータの中から検索するからちょっと比較対象としては難しいかも

>>791
フォルダパネルを表示して対象フォルダをクリックするだけだよ
達成可能なパフォーマンスの限界（到達点）のひとつとして、有意な指標になると思う

Everythingみたいな高速検索ソフトはMFT型やなー
NTFS形式にしてるとこういうソフトが強いぞいー
MFTサーチ以外のソフトもありますぞー

>>750
100万ファイルを全部1画面に表示できる解像度ってよく考えたらそれだけですごいな

>>794
１画面に表示するって情報はどこから？

おらワクワクしてきたぞ！

>>796
いいから寝てなさい
魔封波ァ！！

>>797
される方は黙ってて

MFT扱うようなアプリはAIで作るの勇気がいるなｗ
テスト起動1発目でデータ全損とかなりかねん
最終的に、厳重なチェックの元で運用しなきゃならんのは人の手でやるしか無いのは変わらなさそう

そうなのねーはじめてしゅりましたぁｗ

>>778
zip内のファイル閲覧できるの少ないな。
WinRAR、Explzh、PeaZip、Total Commander、Double Commander
みんなダメ。ダメというか一分以上で強制終了させた。

100万ファイルを圧縮したファイルの中身を見ようとしてる？なぜ？

困ったときのターミナル
なるほどLinuxやMacがGUIを捨てるはずだ

>>801
Windows10Home64bit仮想環境
WinRAR7.20
「ファイルを表示」で表示できた

>>801
7zipが速かった

SSD
7zip 8秒
Directory Opus 15秒
Explzh 18秒
Bandizip 22秒
WinRAR 150秒

Sandy Bridgeでそんなスピード出るか？？
お前ら何使ってるの？

普通に4秒くらいで表示できたけどな
windows標準のzipのdllだと思うけど

>>801
>>806
が何使ってるんだ

WinRARそんなに遅いのか？ｗ

アプリの名前だけじゃなくver.も書いた方がいいんじゃない？ｼﾗﾝｹﾄﾞ

もうすぐ1か月の使用期限が切れるけど、これでほんとに完成で良いんだろうかと不安になる
追加機能思いつかないんだけどね

1か月の使用期限って何使っているの？

流れからするとちょっと上の方でAIで開発してるって言ってた人物じゃねぇかな

画面くらい見せてほしいよな

作り込むほどに自分色に染め上がった代物なんだろう

作り込めば作り込むほど細かいところが気になって永遠に終わらなくなるものだ

機能や性能とユーザビリティは別だしな
追及しだしたら終わり無いし

あと1,2年したらAIに頼むだけで猛烈な完成度のファイラーがぽんと出てくるんだろう

それはない

AIのちからでX-Finderをスーパー進化させてくれ！

AIのお陰で長年手こずっていたif文が書けました！
次はwhileだ！

現時点でファイラーをAIに頼んで作ってもらえるんだろ？
じゃあ1年後は余裕だろ

SNSでAIでファイラー作ったー、言ってるのいくつか見つかるけど、それ試用してみればよいよ。どれもこれもだよ。出来はAI関係ない、作る人しだいだな。

AI開発ファイラーでこんなのがあったよ
FDライク タブあり なんかいろいろできそう
MidFD
https://github.com/tk999jp/MidFD

100万ファイル読み込み（仮想環境 Windows10Home64bit HDD）
9分
ファイル一覧全選択でハング 残念

静的メソッドだらけだな

mainが800KBの単一ファイルってところが一番やべえよ

ワロた
UI系の方は見てなかったわ
つかWinFormsなんだね

AIで作成した場合は
その生成物には著作権は発生せず
尚且つ
ソースコードは必ず公開しなければならない責務がある
らしい

それは単純すぎる

生成AIで作った作品が著作物として扱われる条件
創作意図と創作的寄与の有無は、以下の要素を総合的に判断して決められます。

指示（プロンプト）の詳細さと具体性
生成を繰り返した試行回数
複数の生成物からの選択過程
生成後の編集や修正の程度
詳細で具体的な指示を与え、何度も試行錯誤や編集・修正を重ねながら理想的な作品を作り上げた場合は、
著作権が認められる可能性が高くなります。

そんな法律聞いたことないけど、、、

そんなことよりDOSライクなファイラーのオススメ教えてくれ
WinFM2008使ってて乗り換えたいんだが、しっくりくるのが無いZeroとFiledini試したが
ファイルのソート順がWinFM形式と違って使いづらい

両方とも今定期的に更新しているから要望してみればとおもう。
にしても、WinFM形式と違うとなぜ使いずらいのか。その理屈説明してよ。

そんなことより、あなたの感覚を変えたほうがはやいかもね。

要望出すわ

>>830
著作権法って言うんだよ
聞いたことないかな？
Ainの生成物に関しては法務省が見解を出してる

DOSライクならPPC以外になかろう

いやWinFDだろ

FILMTN for FMR 2.45 FREE ファイルメンテナンス for FMR (95.12.22公開 108K)
にはお世話になった
FM-RにはFDの移植版がなかったから

FMR詳しくないので自信ないんだけど、これ違うのか？
https://takeda-toshiya.my.coocan.jp/fmr50/081017-6.png

これ以降のが出てないってことか

>>832
> そんなことより、あなたの感覚を変えたほうがはやいかもね。

ホントそれ
vimmer/emacserですらその多くが背に腹は代えられなくてvscodeのバインディングに染まっていくのに、ファイラー程度ならすぐに慣れる

◯◯おじさん図鑑が話題らしいがファイラーおじさんはないようだ

keyhacでemacsキーバインド使ってるわ

AI使ってなんか出来たし、動作も問題ない、ええやんこれ
↓
期間まだ残ってるし、AIにバグチェックさせよ
↓
バグ50個ありました
↓
？？？

WhiteBrowserスレででてきたIndigoなんたらもソース見たけど
やべぇのだらけだな

やべぇとは？

File Pilot
次回のバージョンのリリース予定日はいつ頃でしょうか？前回のアップデートから3ヶ月以上経っています。

Vjekoslav
今月末までに実現できるよう、本当に一生懸命取り組んでいます。

>>845
file pilot
不明
作者はこの前別作者の起動や動作の早いタスクマネージャソフトをベタ褒めしてた
Xのポスト少なめだから弄ってはいるとは思う
作者に凸するべし

マックロソフトがベタ褒めだったFile Pilot
まあ一般人向け速度だよな

日本語に対応する日は絶対来ない
そういうポリシーで作られてるソフトだろ

そんなポリシー書いてるの見た事ないけど

対応しようと思ったら直ぐにできることを何年もやらないってことはそういうことだ
わからんでもないよ、自分が絶対使わない機能を入れてコードを汚したくないって気持ちは

対応言語一つ増やしたところでコード自体は変わらんだろ
メンテにリソース割きたくないだけでしょ

>>848
そういうの書くと差別的とか言われるから単純に英語圏しか見てない可能性じゃね？ｗ
あんまエビデンスのないコメントするんじゃないｗ

FPの場合はローカリゼーションでの対応言語追加の話ではない

ImGUIの上にユニコード対応をしてない独自UIを構築しててAscii文字以外表示すらできなかった
アルファ版ではDirectXになっているのでユニコード対応の基礎は整っているので
あとは作者のやる気/リソース次第かな

DirectX版は描画やリサイズのチラつきが目立つようになったそうだ
まあWebview2を使ったアプリのチラつきは相当ひどいけどそれほど問題視されてないけど

エラーメッセージや表示を他言語に変換するＡＩがあれば
自分で対応しなくてよくなる

FilePilot
100万ファイル全選択しての右クリックでハングしたよ
このとき使用メモリは1GBくらい

上でも100万どうたらやってたけど負荷テストやってるのか？
ほとんどの人には縁がなさそうな操作だが

評価の一要素にはなるだろうが100万件どころか10万件での表示速度の違いであっても
使い勝手に直結するとは言えないだろうね

AIに複数回チェックさせるとデバグとエンバグの繰り返しで笑えない

変なバグがあるけど再現性が分からんくてAIに指示出せん

株式会社アイ・エス・ビー
https://kizuna.5ch.io/test/read.cgi/infosys/1756826944/

正規表現で複数ファイルのリネームとか実装しようとしても煩雑で無理か

正規表現で複数ファイルのリネームとか実装しようとしたけど、煩雑すぎて無理ゲー

あまり何にでも生成AI使ってると知らんところでコストかかるからやめろだってよ
餅は餅屋でいこうぜ

>>858
特にこれがヤバいらしい

なんで脳死ジジイって所構わず薄っぺらいAI話したがるの？

正規表現で複数ファイルのリネームとか実装しようとしたけど、毎回正規表現入力するのが面倒くさすぎて現実的じゃなかった

毎回エラーでてるのに、書き込めてるじゃん？？？

うちのだと正規表現で複数ファイルのリネームは去年のうちに実装済み
入力に合わせてリアルタイムに表示が変化する
でも大抵は正規表現使うまでもない

https://gzo.ai/i/JRzS8Y8.png

複数一括リネームの難しい所はエラー処理かな

名前衝突、ダメ文字、末尾ダメ文字、文字数など1ファイルだけで起こるエラー処理の他に
一括だとリネームによる名前入れ替え(逐次処理だと名前衝突)とか、全部成功しなかっからキャンセルするアトミック的な処理も要るかと

それとリネームでフォルダ移動も出来ると尚良い

>>861
>>862

正規表現からスピンアウトした改名表現を作るといいと思うんだが、
あまり使われなさそうだからだれも作らない

正規表現に固執するのはアホ
スクリプトと組み合わせたほうが遥かに柔軟でシンプル
d:\src\*とd:\data\*で適用するルールセットを変えるとか簡単だしな

まぁ、全部同じフォルダにぶっこんでる人多いからな

>>872
汚部屋住まいの人によくある

>>862
大量処理は単純なら正規表現でいいと思うが複雑ならPythonやJSマクロとかでやれば？
最近正規表現で連番+置換やろうとしたら正規表現よりマクロの方がいいとAIに言われたわｗ

あーこれファイラーの話限定か....
リネームは専用ソフトかPythonかマクロじゃない？

ファイラーからリネーマーにファイルリスト渡してテキストエディタで好きに編集
これがベスト
rangerってTUIファイラーに:bulkrenameってのがあるけどあれも良い
ただあれ多分デフォルトのエディタでしか編集出来ないんじゃないかな