漫画ビューア総合スレ Part2

漫画ビューア総合スレです

前スレ
漫画ビューア総合スレ (Part1)
https://egg.5ch.io/test/read.cgi/software/1752914772/

話題多め
画像ビューアー NeeView Part7　【ﾜｯﾁｮｲあり】
https://egg.5ch.io/test/read.cgi/software/1781159107/
https://github.com/neelabo/NeeView/

漫画用画像ビューア マンガミーヤ MangaMeeya 24
https://egg.5ch.io/test/read.cgi/software/1742548602/

【画像/漫画/動画ビューア】mImageViewer 1【mIV】
https://egg.5ch.io/test/read.cgi/software/1782419551/
https://www.mikage.to/mimageviewer/

前スレリンクから
https://github.com/julyx10/lap/
https://github.com/SoraKumo001/quick-image-viewer/
https://github.com/kirinonakar/Uviewer
https://github.com/ggand0/viewskater
https://github.com/p-almighty/Piewer
https://github.com/yasuflatland-lf/gashuu
https://github.com/nalltama/RAIV
https://womanprojects.web.fc2.com/

>>162
mImageViewer v3.0.0
特に変わらないと思う(設定が必要?)
AI関連は無しにしてキャッシュ系は最大値、ビューワモードは複数ウィンドウにしてます
これにするとメインウィンドウのサムネ表示との連動がないので

入力速度␣平均処理漏れ数(5回計測)
5 Hz␣1個
30 Hz␣1個
40 Hz␣2.6個
50 Hz␣8.2個
60 Hz␣19.7個
100 Hz␣228.2個
2000 Hz␣549.8個

低速度でも1個漏れるのは多分バグ
30Hz越えで漏れ数が増えるのは処理速度限界突破でしょうか(バグと呼ぶかは諸説あり)

>>163
mImageViewer作者です。詳しい検証ありがとうございます。

コードを確認しました。
mImageViewerは、キーを押しっぱなしにしたときのリピート入力を、
すべて回数として蓄積する作りにはしていません。

押しっぱなし中は、各ページを飛ばさず順番に見せつつ、
読み込み待ちで引っかからないよう、通過中はサムネイル画質で表示します。
キーを離すと、その時点で実際に表示していたページをフル画質へ切り替えます。

今回のツールが、キーを押したまま任意の間隔でリピート入力を送り、
最後の入力直後にキーを離す方式であれば、
最後のリピート入力とキーを離した情報が同時に処理されることがあります。

この場合、最後のリピート分まで進めると、キーを離した後に次のページへ
移動する動きになるため、その1回は実行しないようにしています。
低い頻度でも1回ほど差が出るのは、この動作による可能性が高そうです。

また、処理速度を超える入力についても、後からまとめて移動し続けないよう、
未処理のページ送りをキューへ溜め込まない設計です。
そのため、高い頻度では入力回数との差が大きくなります。

>>164
> キーを押しっぱなしにしたときのリピート入力を、
リピートだと64 Hzがシステム限界なので
キー送信アプリでは、SendInput APIで押す、離すをセットにして高速に呼び出してます

>>165
詳しい説明ありがとうございます。

毎回 SendInput で「押す→離す」を送っている方式であれば、
先ほど書いた「最後のリピートとキーを離した情報が同時に処理される」
という説明とは別の原因がありそうです。

高い頻度で差が増える点は現在のページ送りの仕組みで説明できますが、
5Hzで554回送った場合にも平均1回ほど欠ける点は、
こちらの通常のキー操作では再現できていません。

開始時のフォーカス切り替えか、どこか一度だけページの表示確定に
200ms以上かかっている可能性などは考えられますが、
現状の情報だけでは特定が難しそうです。

検証アプリを公開可能でしたら、こちらでも同じ条件で確認してみます。

>>166
確認よろしくお願いします

ダウンロード期限：2026年11月23日(月)
https://96.gigafile.nu/1123-b14d5d9d903ece99395b0aa05dbd6adb7

ソース一式の他、binフォルダにビルド済みexeとslint_cpp.dllを同梱しています
Slint SDK(含むdll)オリジナルはここにあります
https://github.com/slint-ui/slint/releases/download/v1.17.1/slint-compiler-Windows-AMD64.tar.gz

Key / Shortcutはボタンを押すと入力出来ますがCtrlなどのキー入力はバグっていて上手く行きません
フリー版AIが直してくれないので放置してますが直してもらえると嬉しいです

>>167
C++用のビルド済みSDKはこちらでした
https://github.com/slint-ui/slint/releases/download/v1.17.1/Slint-cpp-1.17.1-win64-MSVC-AMD64.exe

上記インストーラーexeが何所までやってくれるのか分かりませんが自分は手動で解凍して
cmake用の環境変数 Slint_DIR を 解凍先\lib\cmake\Slint に設定しました

そもそも意味あるベンチマークかもわからないのに速攻で作者飛びついてて草
落ち着けよ

そもそも1000hzとかで切り替えられて何なの？
高速でページ送りしたい時でも、10hzくらいあれば十分なんだが

>>66-67の流れで分かるんだけど、「.Netだと遅い/あるいは何かしらの問題がある」と信じている人が一定数いるんだよね

suzuniaがそうであるように、実際はそんなことないのに

suzuniaはネイティブアプリじゃないの?
設定アプリが.netアプリ
違った?

.net c#なら早いけどね
昔の.netで語る人が多いからね

Windows は Win32 API 直書き、macOS は AppKit 直書き。どちらも NativeAOT で、GUI フレームワーク (WPF / WinForms) を使いません

suzuniaのgithubとかいてある

NativeAOTって.Netのことだよ？
>Native AOT（Ahead-Of-Time）とは、.NET アプリケーションのビルド時に、中間言語（IL）からOS固有の機械語（ネイティブコード）へ完全にコンパイルする技術です。

どこかのアプリが「.Netのせいで起動が遅い」とか書いたのを鵜呑みにしてるのかな？

>>167
ツールとソースの公開ありがとうございます。
おかげで原因を特定できました。

A. 5Hz / 1秒 / Max Countなし
B. 5Hz / 1秒 / Max Count=5

で確認すると、どちらも5回キーを送信しますが、修正前のmIVは
Aでは5ページ、Bでは4ページ進みました。

Aでは5回目の送信後も次の周期まで約200ms待ってから、
キー送信ツールが自身のウィンドウを前面へ戻します。
Bでは5回目を送った直後に前面へ戻るため、mIVが最後の入力を
処理する時点ではフォーカスが外れていました。

mIVは、フレーム単位で描画するときに、それまでのキー入力を判断して
動作をするような作りになっています。
このキー入力判断時に、自身がフォアグラウンドでなければ処理をしない、
というロジックがありました。
この判定は、フルスクリーンを別ウィンドウで扱うようになった際に、
別ウィンドウでの入力誤処理を防ぐために追加したものでした。
その後のリファクタリングでキー処理全体の入口へ移され、今回の
入力まで処理しない状態になっていました。

これがBパターンのときに影響し、１回分の処理が減る原因となっていました。
キー入力時点の配送先を基準に処理するよう修正し、修正後はBでも5ページ
進むことを確認しました。次のリリースに反映します。

通常操作では見つけづらいタイミングのバグでしたので、
再現条件を絞った検証とソース公開、大変助かりました。
ありがとうございます。

なお、mIVは通過するページを1枚ずつ順番に表示する方針です。
表示速度を超える連打は、後から実行するために蓄積しないため、
レートを上げると押した回数より進むページ数は少なくなります。

ただし、表示されるページの順序自体は飛びません。
1ページ目から100ページ目まで進める入力をした場合、
100ページ目へ届かないことはあっても、途中のページを飛ばして進むことはありません。
こちらは意図した動作です。

動作検証には影響しませんが、ツール側で1点だけ気づいたところがあります。
Max Count指定時のActual Rateは、最初の送信から最後の送信までを経過時間として
「送信回数÷経過時間」で計算しているようです。

N回の送信間隔はN-1区間なので、表示値がN/(N-1)倍になります。
例えばBでは設定5Hzに対して約6.24Hzと表示されます。

.netのNativeAOTは知ってるけど
c++で書いてもNativeでAhead of timeだし
どっちが正解かわからない
まぁ、作者答えてくれるやろ

>(本体に静的リンク) .NET ランタイム
MacOSばんだとこんなこと書いてあるし
正解は.netのNativeAOTかもね

今ならCsWin32辺りでWin32やら呼んでるのかな

てっきりC++とかで書いてるのかと思った

>>163
v3.1.0来たぞ

suzunia、「外部プログラム起動」機能が無いという指摘を見落としていたので追加しました。
その他いくつかのバグ修正や小さい機能追加を行っています。

さて。実はsuzuniaは「.NETは何故か遅いと勘違いされているから、最速の画像ビューアを.NETで作ろう」が立脚点になっています。
当然.NETで作られています。
このスレの反応を見ても分かりますが、この意図（.NETで最速の画像ビューアを作る）は達成されたと見て問題無いかと思います。
（機能不足に関する突っ込みも多いですが当然の話で、機能を目的としたアプリではそもそもないから、なんですね。
　いま現在、いつの間にか多機能なアプリになってしまいましたが、これは単純に私が凝り性だからというだけで、言ってみればただの蛇足です）

>>67「.net 終了」なんかは自演じゃないかと自分で疑うくらいに狙い通りの反応ですし、
>>172「suzuniaはネイティブアプリじゃないの?」と、ネイティブ実装と勘違いする程度には高速であることも証明されました。
しかもこのレスは「.NETは遅い」という間違った思い込みがあるからこそ出てくる発言で、二重の意味で期待通りでした。

という感じで、まあアプリを使う側からしたらこんなどうでもいいことは考えずに、
Meeyaの代替としての一つの選択肢が出てきた、相性が合えば使い続ければいいし合わなければゴミ扱いする、で良いのではないでしょうか。

>>181
改めて最新をDLしてみたが操作にスクロールの設定がない
幅に合わせた場合にないと致命的でドラッグ移動出来るとはいえチャタリングでも起きたらページ移動しちゃう
付随してドラッグ終了→ページ移動した際にウインドウ位置が遷移する前の位置にとどまって本来後に読むべきコマを先に読まされることになる
ページ移動したらウインドウ位置のリセットを設定でONOFFさせてほしい

幅に合わせた場合WEB閲覧の様に縦読み型でもいいのかもね
確か前スレで誰か話題出してたし

このスレでsuzuniaの存在を初めて知りました。全ての動作が軽量で小気味いいです（NeeView比）
マウスジェスチャーがあれば完璧なのですが、実装は難しいでしょうか？

起動が重い（遅い）ってだけで8割方は.netかで終わってしまうからなぁ

>>176,177
お役に立てて良かったです、N/(N-1)倍の件見落としてました

>>180
試してないけど変更内容と仕様から判断して30Hzだと思う

じゃあ何で他の.NETアプリは遅いの？

おじいちゃん、質問は一回チャッピーに聞いてからって言ったでしょ（言ってない

c#じゃないから
.netが遅いって言う人は昔の.net Frameworkのアプリの話でしょ
.net c#でAIにサンプルレベルでもいいからメモリに積極的にキャッシュするタイプの画像ビューアーを作ってもらえば.netでも速いとわかる

c#使ったけど遅かったぞ
チャッピーも仕方ないと言ってた

>>186
計測して30Hzでした

mImageViewer v3.1.0
入力速度␣平均処理漏れ数(5回計測)
30 Hz␣0個
35 Hz␣0.8個

>>181
意図が達成されたそうですが更なるスピードアップはありそうですか？
場合によっては送信ツールの改良をしないといけないと思ってます

個人的には起動後のNeeviewはトップクラスに高速だと思いますが
>>184 小気味いいです（NeeView比）
とある様にsuzuniaが更にその上を行っているのは自分も感じました

今回の基準でのキー送信ツール計測が良い指標になるのではないかと思ってます

「偉そうなこと語りやがってカスが」みたいな反応が来るかと覚悟していたのに、普通に受け入れられてて笑いました。

>>182
スクロールというか、ズーム周りは作ってる途中で時間切れが来て、それ以降何も弄ってないんですよね。
実装が中途半端で終わっていることは自覚しているので、いずれ改修します。

>>184
右クリック+上下左右のシンプルなマウスジェスチャーは既に対応しています。
右クリック+複数方向の真面目なマウスジェスチャーは、要望の声がもっと多く届けば。

>>187
私から言えるのは「そのアプリが遅いのは.NETのせいではない。suzuniaがその証拠」までです。これ以上は、空気を読んで。

>>192
今のところ、律速の要因が画像デコードに集中していて不可侵なので、これ以上のチューニングは不要と考えています。
プリフェッチのアルゴリズムが少し雑だなと思う部分はあるのですが、まあ目的は達していますので。

しかし皆さん、起動速度はあまり気にしないんですね。私はここが重要ポイントなので、Meeya代替が見当たらなくて困っていたのですが。

都度閉じるタイプのビューアの人は起動時間も気にするかもしれないがファイラ併設型だと一度起動したらそのまま次の本を選ぶだけだから起動よりはページの表示時間の方が重視されるのかと

起動が速いアプリはそれ以外も速いから
起動が遅いのはただデメリットでしかない

トレードオフだよ
suzuniaはページスライダーや情報ウィンドウのように
ユーザーへの情報や状態のフィードバック表示が弱い(デザインや一体感)

起動が遅くても全キャッシュしてページ移動が速いほうがいいね
ミーヤでもキャッシュの設定でそうしている

ミーヤはページ移動も遅くは感じないが…

>>131あたりからの流れでミーヤの計測ないな？
どのくらいだったんだ

>>199
公式配布が無いのでmeeyaは持ってないです

>>194,197
(.netでの)目的は達成とのことで(他言語を含めて)起動の早いUIを探してるのならSlintは良さそうです
公式サンプルのgalleryが40msで起動します
https://i.imgur.com/dL3WqPS.png
https://i.imgur.com/xM168yK.png
https://i.imgur.com/HTuAIa7.png
https://i.imgur.com/sAyFUQh.png

>>132,167もSlint製で40ms弱で起動します

>>201,202
40msで起動とは空のウィンドウではなく内容の描画された画面の起動です

suzunia-20260818は初回起動しただけのデフォルト状態(ペンギン付)で起動時間45msでした

QTだと150msくらい
サムネイル描画も向いてないみたいだからビュアの作成には使わんほうが良い

suzuniaの目的は「.NETは遅くないことを証明する」なので、45msと40msで争っても仕方ないので正直どうでもいいかなって思います。
起動に数秒掛かる異常なアプリが「.NETのせいです」って言い訳できないようにしたいだけなので。

起動時にライセンスチェックとか通信しちゃう系だと関係なく起動遅そうとは思う

suzunia haruhi no yu-utsu

>>206
でもこれって、デブのせいでリレーが遅いっていうのを、走れるデブもいるからデブが原因ではないって言ってるだけだと思うんだよね

>>206
.net製アプリが遅いのはコンポーネントとか利用するからだってのは周知なんよ
それらを利用する事で「簡単に」作れる事がウリなんだから

あんたのは「速くなるように設計してそれが目的になったアプリ」なんだからそれで他のと比べて速く無かったら文句の対象にはなるって話

目的が達成されても「あんたの作ったアプリが特別早いだけ」って査定にしかならんのよ
他のよく使われてるユーザーの多い大多数のアプリは遅いまんまなんだから

周知ではないですね。例えば >>67 「.net 終了」といった、".NETな時点で駄目だ"という反応が分かりやすい証明になっています。
なんというか、噛みつきたいだけのレスに対応するのはこれで最後にしますね。

デスクトップUIフレームワーク15種のメモリ使用量計測
https://zenn.dev/mizugeeks/articles/1019cf2353d343

比較対象:
WebView系 Electron, Tauri, Wails, Neutralino
クロスプラットフォーム Flutter, Compose Multiplatform(JVM), Avalonia(.NET), Fyne (Go)
Rust系 Slint, egui, iced
ネイティブ GTK4 (C), Qt 6 (C++), AppKit (Swift), SwiftUI

そもそもあんた噛みつきたくてアプリ作ったんじゃんｗ

論より証拠でアプリ提出してる側のが強いわな
御託と違って他人の役にも立ってるし

>>214
.netで遅くなる要素を使ってないから速いのであって、.netが速いって証明をしたわけではないよ

>>215
suzunia作者さん含め,netが速いか遅いかで戦ってるが一ユーザーからしたら書かれてる言語が速いか遅いかではなく自分が使うアプリが速いか遅いかにしか興味はない
自分の中ではsuziniaが既存のアプリの中では速いって事で充分

>>216
そりゃ自分の中の話じゃんか
他人はそれ以外の事で争ってんだから

>>217
興味はないが傍から見るに
ゼロヨンレースにホットロッド持ち込んだら後出しで市販車に限るって言いだしてる感じにしか見えん

プログラマさん達には譲れない線があるっぽいのは把握したので意向ROMに戻ります

AI使えば自分でもソフト作れるかなって思ったけど、導入の部分で躓いて終わった

人には人のリビドーがある
ただ、評価の暴力によって特定議題に誘導した結果、
ユーザーにも開発者にも視野狭窄を強いてしまっている感覚は残る

よくわかんないけぢどパイプラインとアーキテクチャ次第である程度は速くなります

>>218
例えがズレてんな

>>206
なるほどですね
試しにSlintで画像を表示させてみたら、今まで40msで起動していたSlintデフォルトのレンダリングバックエンドでは、4K幅いっぱいにして縦スクロールするとスムーズにならないことが分かりました
GPU系のバックエンドにしたら1フレーム1pxのスクロールが見た目完全スムーズでpresent-monで60fps出ましたが、起動時間は180msになりました
こう言うのがトレードオフなんですね

>>212
Slintが総合でメモリ使用量が一番少ないと思ったらフォントが関係してた...
確かに何も指定しなくても日本語やカラー絵文字表示出来るのでインストール済みフォントを使っているのでしょうね

> 日本語表示のため egui, iced は CJKフォントをプロセス内に読み込むのでメモリ使用量が約25MBほど増えています。実用アプリとしての計測を行いたかったので日本語は必須とさせていただきました。それを除くと egui, iced は Slint と互角以上のパフォーマンスです。

>>205
GPU系バックエンドで起動時間150mなら速いですね、でも
qview 240ms
quickviewer 1340ms
でした

>>214
ほんとそれな
結局、役に立ってる側と役に立ってない側ってだけの話だ

？

suzuniaのアプリ名の命名由来は？

管理で画像を書庫を圧縮したり
書庫をネストにして圧縮したり
何でそういうことをするのかな
巻数管理なら無圧縮でサブディレクトリでいいでしょ
圧縮していると読み込みのに時間がかかるし
それで読み込みが遅いとかファイルが読めないとか開発者には同情する

最悪なのがソリッド圧縮やネスト書庫している書庫
バックアップや配布用じゃないし
それ管理用で使うものじゃないだろう
メモリでもディスクでも解凍必死じゃん

自分で管理してるのか怪しいよな

漫画ビューアなんて用途のメインは割れだろ
何を今更

いらん事をしたり顔でいう間抜けってほんとに居るんだな

ビューアがネスト無しの無圧縮zipに変換すれば良いじゃん
オリジナルは削除で

mIV作者です。話題に関連して補足です。

mIVでは、画像自体は再圧縮せず、ZIPの圧縮方式を無圧縮にした
1つのZIPへ変換する機能を実装しています。

入れ子になったZIP/RAR/7z/LZH等も再帰的に展開し、
inner.zip/01.jpg のように元の書庫名をフォルダ相当のパスとして残して、
1つの無圧縮ZIPへまとめます。

変換後は内側の書庫をその都度展開せず、各画像を直接読み出せます。
メニューの「変換 → ZIP変換」から利用できます。

なお、変換元のアーカイブは自動では削除しないため、
変換後は元ファイルとZIPの両方が残ります。

>>234
良いね、そのまま削除する設定を設けたらどう?
タイムスタンプを完全復元して文字化け検知でOKならutf-8フラグも立てて

>>235
変換処理については安全寄りにしており、
変換中に画像や入れ子書庫の読み取りエラーがあれば失敗扱いにしています。

変換後も、完成したZIPをいったん開き直し、全画像を最後まで読み取って
CRCと画像件数を確認してから、完成ファイルとして出しています。

AIにも念入りにテストさせていますが、それでもソフトウェアである以上、
完全に問題がないとは言い切れません。

元ファイルを自動削除し、万が一変換漏れや破損があった場合は
取り返しがつかなくなるため、変換元は自動削除しない方針にしています。

実際に変換後のZIPを開いて内容を確認いただいたうえで、
必要に応じて元ファイルを削除していただく形でお願いしたいと考えています。

>>236

> 変換後も、完成したZIPをいったん開き直し、全画像を最後まで読み取って
> CRCと画像件数を確認してから、完成ファイルとして出しています。
ファイル移動系のツールならここまで出来ていれば普通に元ファイル削除で移動完了だけど

> AIにも念入りにテストさせていますが、それでもソフトウェアである以上、
> 完全に問題がないとは言い切れません。
確かにAIがプログラムを書いてAIがテストしてるだけだと作者すら自信を持てないという事か

>>237
本業プログラマなので自分でもコードは書きますが、
自分で書いたものでも「安全です」と言い切る自信は持てないですね。
なにより検証するのが自分一人なので、どうしても限界があります。

SQLiteは、テストコードとテストスクリプトが本体の約590倍あると
公表しているほど念入りに検証されていますが、それでも今年、
15年以上前から存在していたデータ破損バグが見つかったそうです。

このニュースはわたしも驚きましたし、そういう事例を見ると、
変換元を自動削除しても安全ですとは、とても言えない気分です。

ユーザーが自分で変換して管理すればいいの

>>238,239
ユーザーが勝手に使ったツールで勝手に失敗する分には我関せずで貫けるからね

でもSQLiteとは状況が違って
> 変換後も、完成したZIPをいったん開き直し、全画像を最後まで読み取ってCRCと画像件数を確認
この時点で完全に継承済みだから、この検証コードだけ念入りにテストするのが作者の務めだと思うけど
AIがいつ勝手に変更するかも分からないし難しいな

>>240
完全に検証済み

アドバイス罪を背負ったおじさんもそうだそうだと言っています

タダで提供してるツールで実害が起きても対応無理やしなぁ
でも利便性は追及したいよねっていう折衷案を用意してくれてるってこと結構なことじゃないすか

画像ビューアーでもソースの公開されているアプリは多いのだから要望厨はどうして自分でAIを使いアプリを作らないの
クリーンコードでなくてもソースの公開されているアプリをフォークして作ればいいでしょ

安易にAIに尾任せ従順して
OS巻き込んで壊れるのが居ても
ちょっと驚かない

>>243
とりあえず試してみようの価値観がないんでしょ....
まーこういう言い方はあまりよくないけども日本のコミュニティはとりあえず試すというのがないのかも
恥の文化や失敗が怖いという人が多いんだろうけどそれを無視して試すと見えてくるものはあるな

レールに敷かれた状態を批判する人はいるけど
レールの作り方や正しい乗り方を伝授する人がいないのもま～問題かもね
ここも>>243みたいに疑問を書く人はいるけどそれ以上の啓発がないｗ

>>245
ってより使えなかったら使えないって批評残すより黙って使わないだけの人が多いだけだと思う

俺も試してすぐ記憶から消える事多い

ソフトウェアは育てるものですよね

作り手が作りたいものを作り使い手が使いたいものを使う
それだけだろ
mIVは高スペック仕様だったから足切りされた
suzuniaはスクロールのキーコンフィグがなくて不便と伝えたが放置されてるがまあ仕方ない
フィードバックしても実装するしないは作者の自由だしな

画像ビューアーの最低動作要求
CPU Ryzen 3000
RAM OS込みで32GB
解像度 最低FHD 4K推奨
SSD必須
快適に使うならこれぐらいのPCは用意してほしい
でもこのスレをみると怪しい

そんなミドルよりちょっと上あたりのスペックを最低基準にされましても

いやいや10万円ノートパソコンが基準でしょ
CPU AMD Ryzen 5 230 3.5GHz/6コア
GPU iGPU CPU内蔵
RAM 16 GB
M.2 SSD：512GB
OS Windows 11 Home 25H2

もうすぐスマホネイティブ世代のサブPCはメモリ8GBになる
> Windows 11、メモリ8GB環境への最適化を年内実施へ

>>249
そういう側面もあるけどエンジニアとユーザーが協力して発展してるソフトウェアもあるんじゃない？
確かに自分のニーズと合うソフトを探して使えばいいだけだけど
そういうユーザーだけだとソフトウェア自体が育たないと思うぞ？ｗ

>>254
一連の書き込み内容が全然頭に入ってこない
要するに自分の作ったアプリを誰も使ってくれなくて悲しい、という事かな

>>255くんよ>>248が書いた反応へのレスが>>254でしょ

図星、中らずと雖も遠からず、火のない所に煙は立たぬ、男か女

アプリを公開しようと何度か考えたけど公開する前に他のアプリが公開されてスレで批判されたりしていて微妙でした
もう少し作り込もうと思った
そしてまだライセンス画面を作っていないことに気がついて数週間がたった
なんていうか短期なユーザーが多いねアップデートなんて月1くらいあればいいじゃんと思うのでした

>>258
>>214

批判を気にしてるようじゃ公開しない方がいいと思う

ぶっちゃけカスハラとか誹謗中傷以外の論外コメントは除外して
批判や指摘を恐れるようじゃソフトウェアは公開できないよ？？
そうやって改善点を上げてくれるユーザーがいるから変化するものもあるからな

批判の中にも建設的なものがあるけどな
一切批判は受け付けない、承認だけしろ、なら
公開初期ハネムーン期間が終わったらトンズラしろ