New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Windows 7 の Aero Snap に対応させる修正 #120
[WIP] Windows 7 の Aero Snap に対応させる修正 #120
Conversation
https://sourceforge.net/p/sakura-editor/patchunicode/1009/ SetAeroSnap_v219_r4011.patch 強引にSendInputを使ってSnap状態を引き継ぐようにしてみたパッチを添付します。 rev4011用のパッチですが、最近のrevでもそのまま使えると思います。 Tab切り替え時に画面がちらつくのが難点です。 (ちらつきを抑える方法はいろいろ試してみましたが、うまい方法は見つかっていません) ちらついてでもSnapが引き継げることのほうが自分には重要なので、自分専用にはずっとこれを使っています。 強引な方法なのでオプション対応にしておいたほうが無難かもしれません。 下記のように様々なパターンでSnapを引き継げるようにしたつもりですが、 漏れていてうまくいかないようなパターンがあったら教えて下さい。 ・Tab切り替え ・[ファイル]-[新規作成]でのTab追加 ・[ファイル]-[開く]でのTab追加 ・エクスプローラからのファイルダブルクリックによるTab追加 ・エクスプローラからのファイルドロップによるTab追加 ・タスクトレイからのWindow選択 ・別Tab GroupからのWindow選択 ・画面右上の☓(閉じる)ボタンで一気に閉じていく最中のTab切り替え ・Snap状態から最小化し、タスクトレイから別TabをActiveにした場合のTab切り替え ・Snap状態から最小化し、エクスプローラでファイルダブルクリックした場合のTab追加 動作確認は64bit Windows(Win7, 8, 8.1, 10)、32bit Win7あたりの環境でやっています。
大した問題ではないのですが一応突っ込んでおくと、ブランチ名が |
新規機能じゃないので feature じゃないな、と思いました。 マージ先は master を想定していて、 困るんでしたっけ? |
たぶん hotfix という言葉の意味を誤解されているように思いました。 現在配布されている最新版は v2.3.2.0 です。
どうでしょう?認識合ってますか? |
すみません、基本的には「困る」ということが認識できました。
これだけのためにリリースを行う意図はありませんでした。 先に書いた通り、新規開発ではない + リリース済み機能の修正で hotfix としました。 ただ、次バージョンに含めるために作っているか、 hot(致命的、緊急対処が必要)ではないと認識しているのも事実なんですが、 このあたりについては別途相談させてください。 |
困ってないです。意図を確認したかったのです。
意識合わせをしておきたいのですが、少なくとも今の master ブランチに入る内容は全て「次バージョン」を見据えたものです。そうでないバージョンへのコミットを考える場合には別のブランチにマージするような PR を投げることになります。
これはたとえ話なので全ての数字は仮のものです。
「僕が」「考えてそう」という意味ですか? 対応内容関係なく、「hotfix」と宣言されているのであれば「緊急である理由があるのだろう」と思慮を巡らせます。これは一般的な慣習です。 まとめ僕から確認したいのは「この PR は本当に hotfix ですか?」の一点だけで、それ以外についての言及は今のところ無いです。 「hotfix ではありませんでした」であれば「そうですかわかりました」となりますし、 おまけ:考察のヒントこの質疑、本来は一言二言で終わる話なのですが、なんだか混乱されているようなので回答のヒントを書き残しておきます。 客観的に見るとこれは hotfix にするものではないです。 |
いいえ、です。 |
おけです。そこのコンセンサスがとれていれば良いです。 |
AeroSnap対応によりSTabGroupInfo構造体にメンバrcTopが追加された。 追加したrcTopは本メソッド内でセットしているが、従来から取得できる変数をセットしているので追加の意味がない。 従来方式では取得できない情報を追加したかったと推定されるのでバグとして修正する。 変更対象はCEditWndが作成時にタブグループ情報を取得するために使用しているメソッド。 影響箇所はAeroSnap対応のための追加コード内のみ。
スナップ状態への遷移が必要な場合のみ、AeroSnap操作を行うように変更。
Aero Snap状態に遷移させるための操作は、ユーザのキー入力をプログラム的に生成して行っている。 このため、Aero Snap操作中にユーザがctrlキーを押しっぱなしにしていた場合、強制的にキー押下状態が解除されてしまう。 この事象にはタブ切替のデフォルト割り付けが「Ctrl + Tab」であったために気付いた。 対策として、ctrl,shift,altの押下状態を操作前に記録し、操作後は元に戻すように修正した。
win10 で見たら怪しげな動きをしている(低確率でaerosnap解除される)のでWIPに戻します。 あと「 win + 方向キー 」のあと、方向キーを離す、winキーを離すの順に操作すると、 |
win 10 の妙な動きの原因が判明。
このコミット自体の問題ではなさそう・・・。 タブをたくさん開いていくとだんだんおかしな動きをし始めるので、 |
取り込みを断念します。 |
目的
windows7 の AeroSnapに対応させる。
課題内容
タブを表示中のサクラエディタをエアロスナップさせた状態で、
別のタブに切り替えるとエアロスナップが解除されてしまう。
これまでの経緯については関連issueを参照。
関連issue:
#45, #65, #107
タスク
対応方法
sourceforge.netに上がっていたパッチを取り込み、
修正を加えることで対応を完了させる。
取込元パッチの情報
https://sourceforge.net/p/sakura-editor/patchunicode/1009/
SetAeroSnap_v219_r4011.patch
取込手順
#47
※そのまま取り込むことに賛同できなかった理由
ウインドウ拡張メモリが無駄遣いされているように感じ、精査が必要と判断したため。
↓
結局、ウインドウ拡張メモリは使わずに済ませることができた。
メモ
パッチを取り込むことによりスキップできたタスクは以下の通り。
GetWindowRect と GetWindowPlacement の戻り値を比較して差異があればスナップ状態
Winキー+方向キーの入力イベントを送出すれば遷移が可能
タブ切替、新規作成
エアロスナップ
ウインドウをエアロスナップ状態に遷移させるための専用APIは存在しない。
調査にあたっては Designing Aero Snap などの設計資料も参照した。
どうしたらエアロスナップ状態に遷移できるか?の観点で調査。
エアロスナップに遷移させる方法は5つ。
※ Winキーと方向キー「↑」を押下すると最大化されるが、これはエアロスナップではない。
※ Winキーと方向キー「↓」を押下すると最小化されるが、これはエアロスナップではない。
※ キー操作による遷移は方向によって異なるが、マウス操作の結果はすべて同じ。
※ プログラム的にはキー操作とマウス操作の 2 パターンとみることができる。
メモ
調査により完了できたタスクは以下の通り。
「タイトルバーの上端をダブルクリック」の入力イベントを送出すれば遷移が可能
修正内容
タブ切替時の位置合わせに使用している CTabWnd::SetCarmWindowPlacement を拡張し、切替元の CEditWnd の表示状態に合わせて AeroSnap 状態を引き継ぐ(=設定する)ように変更する。
検証方法
上記「エアロスナップ」を参考にサクラエディタを Aero Snap 状態にする。
問題が起きていたのは、Aero Snap 状態から、新規作成(Ctrl+N) or タブ切替(Ctrl + Tab)した場合の挙動。
実際に何が起きるか挙動を検証する。
お願い
動作について不明点があれば、コメントでお知らせください。
コードについての不明点にもできる限りでお答えしますので、お気軽にどうぞ。
プログラム起動時の同期不具合の対処ができるまで凍結中です。
準備ができたら WIP 外します。もうしばらくお待ちください・・・・。