提案 #1536
完了openimg_gtk: 画像プレビューウィンドウの初期サイズを固定値ではなく、画面解像度からの割合にしたい
説明
画像プレビューウィンドウは常に640x480を初期サイズとして開くのが現在の仕様ですが、近年はディスプレイが高解像度化しているので流石に小さすぎると感じています。
そのため、例えば実行環境の画面解像度の70%のサイズ……みたいな感じで割合で求めるようになると良いなと考えています。
既にサードパーティプラグインではそのようにパッチする実装があります。
https://github.com/shibafu528/mikutter_openimg_window_size
もし良さそうであれば本体に取り込む作業をしますが、その際は今ならgtk3向けで入れたほうが良いでしょうか。
Shibafu Midorino さんが約3年前に更新
- ステータス を 実装待ち から レビュー待ち に変更
- ブランチ を topic/1536-openimg-window-size にセット
https://github.com/shibafu528/mikutter_openimg_window_size からGTK3向けの実装を抽出しました。
設定キーに関しては、なんか元からあんまりサードパーティっぽくない名前使ってたのでそのままにしちゃいました。
Izumi Tsutsui さんが約3年前に更新
「サイズの基準」のデフォルトが
full: デスクトップ全体
mainwindow: メインウィンドウがあるディスプレイ
manual: ディスプレイ番号を指定
のうち full なのは議論の余地ありそうという気もしますが、どんなもんですかね。
普通は横に2枚並べる程度、かつ、超横長の画像はあんまりないので気にならなそうですが、
L字に3枚並べてる環境とか 業務用メイン+ツイ用サブみたいな環境だとどういう印象になるかよくわからんです。
(そういう特殊な人は手動で変えればいいと言われたらそう)
Shibafu Midorino さんが約3年前に更新
Izumi Tsutsui さんは #note-3 で書きました:
「サイズの基準」のデフォルトが
full: デスクトップ全体
mainwindow: メインウィンドウがあるディスプレイ
manual: ディスプレイ番号を指定
のうち full なのは議論の余地ありそうという気もしますが、どんなもんですかね。
ああ、確かに!
今はディスプレイを1枚しか持っていなくて、どれ選んでも同じなせいで気が回っていませんでした。 (原作のプラグインを書いた時は2枚だったはずなのに、どうして……)
私の感覚では mainwindow がいいかなーと思っています。
大抵、メインウィンドウに近い場所 = 同じディスプレイに出ますよ……ね……? かなり自信ないので、違うかも。
Izumi Tsutsui さんが約3年前に更新
Shibafu Midorino さんは #note-4 で書きました:
私の感覚では mainwindow がいいかなーと思っています。
大抵、メインウィンドウに近い場所 = 同じディスプレイに出ますよ……ね……? かなり自信ないので、違うかも。
中の構造まで想像できてしまうプログラマユーザーに対しては mainwindow デフォルトのほうがクレーム出にくいかなと思います。
以下は与太話:
要件定義問題¶
教科書的には、ユースケース定義して要件を書き下ろさないと作ってからいろいろ言われるパターンになりそうです。
- デスクトップ全体
- デスクトップが長方形で定義されている場合、つまり
同一サイズのディスプレーを偶数枚タイル状に置く場合はこれでいいと思います - 2枚のディスプレーのサイズが異なる場合、3枚ディスプレーの場合、
同一サイズ2枚ディスプレーでも両者の間に原点オフセットがある場合、
等々を考えると、おそらくGTK API的には XとYについて最大値(外包する長方形サイズ)を返すけれど
実際にそのサイズで出すと非表示領域にかかってしまう、ということになってしまう?
- デスクトップが長方形で定義されている場合、つまり
- メインウインドウ
- メインウインドウが複数画面にまたがってたらどうなるんだと言われそう。
たぶんAPI的にはウインドウ原点(左上?)の座標が基準? - ウインドウマネージャーによっては「ウインドウを出す瞬間にマウスカーソルのあった画面」にクライアントを表示するので
「マウスカーソルのあった画面のサイズ基準」という要望が出そうですが、実際はクリックした瞬間はほぼメインウインドウで、
その後にカーソルを動かされた場合はあんまり実装できる気がしませんね
- メインウインドウが複数画面にまたがってたらどうなるんだと言われそう。
- ウインドウ番号
- Windowsだとウインドウ番号を表示できますが、 XやGTK APIだとどれが1番なのかという話になったりする?
職業病で、こういうUIや「2ボタンマウスの中ボタンエミュレーション」みたいなネタを見ると
新人向け要件定義演習問題を作ってしまうのでした。
Shibafu Midorino さんが約3年前に更新
「サイズの基準」のデフォルトは mainwindow に変更しました。
デスクトップ全体で計算するのは、挙げられている通りの問題点があって実用できる事は少ないと思っています。(じゃあなんで置いたのかは当時の自分しか知らない)
複数画面に跨って表示させたいニーズもあまり無いと勝手に思っていて。
ドキュメントのどこに書いてあるのか分からないんですが、私の環境だとメインウィンドウの所属する画面は面積で判定されているようでした。最も大きな面を表示できている画面に所属している扱い。
ちゃんと資料をあたっていないので、X仕様なのかGTK仕様なのかも良く分からないです…
manualは通常の設定で納得行く配置にならなかった人が試行錯誤する用に置いてるだけなので、深く考えずに生の値を入力させている事をここにメモしておきます。何なら私もどう番号が振られるか良く分かっていないし、昔自分がメインだと思っていた画面が2番だった回もあった気がする。
Izumi Tsutsui さんが約3年前に更新
コードとして、デフォルト mainwindow の変更とそれに伴うメニュー順序の変更、それぞれOKと思います。
動作として、 git merge topic/1536-openimg-window-size
してもともとの定義に対する動作はOKです。
仕様定義の話もあるので、レビュー判断は toshi_a 初音 さん待ちですかね。
以下はわがまま顧客による要件ちゃぶ台返し演習:
- 個人的には、メインウインドウが 16:10 で表示させたい画像が 4:3 だと確かにサイズ的には 70%なんだけど
左右に黒帯が出るというのが今一つという感じ - 思いつきレベルだと以下?
(想像なのでやってみたら別の文句をいうわがまま顧客シミュレーションが必要)- 元画像の縦横比を求める
- メインウインドウの縦横比を求める
- メインウインドウに元画像縦横比の画像を表示したときに、
元画像の縦横比、かつ、縦または横の余白が少ない軸方向サイズがメインウインドウの70%になるサイズ
Izumi Tsutsui さんが約3年前に更新
いろいろいじってたら気づいたのでもう一点。
manualは通常の設定で納得行く配置にならなかった人が試行錯誤する用に置いてるだけなので、深く考えずに生の値を入力させている事をここにメモしておきます。
ということなのでわかっている人向けということだと思いますが、
manual の場合のディスプレー番号の上限が 99
固定で存在しない番号が選べてしまうと思います。
ちょっと試したところでは存在しない番号を指定すると 0番扱いになるようで、クラッシュしたりはしないようですが。
toshi_a 初音 さんが約3年前に更新
- ステータス を レビュー待ち から 終了 に変更
merged.
以下議論についての見解をメモしておきます
複数のウィンドウ
1枚しか持ってないので考慮不要です。デュアルに戻したら手のひら返します。
メインウインドウが 16:10 で表示させたい画像が 4:3 だと確かにサイズ的には 70%なんだけど
左右に黒帯が出るというのが今一つ
対応不要です。画像を見終わったら閉じるので、画像ウィンドウ裏側のウィンドウの内容に関心はないです。
ポップアップにしている理由は:
- YoruFukurouの画像ビューアを模倣したかった
- ごく稀に、画像を横にフロート表示できるのは便利なこともあるけれど…
- タブにすると、細長くして使っているときに全然画像が見えない
- フルスクリーンにした場合、道端で捕まえた虫の画像を度々送られてくるので、ある程度小さくしたい
冬の間だけ大きめに設定できるのはgood