Skip to content
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

ドラッグ操作でタブの並び替え、最後のタブより右の位置にドラッグした場合に最後のタブの位置にする #1099

Merged
merged 1 commit into from
Nov 24, 2019

Conversation

beru
Copy link
Contributor

@beru beru commented Nov 24, 2019

PR の目的

マウスを使ったドラッグ操作によるタブの並び替えでドラッグしてるタブを一番右端に並び替える際の操作性を改善するのが目的です。

現在の実装ではマウスカーソルがタブの上を通るようにドラッグすれば問題なく一番右端に移動できます。

しかしマウスカーソルがずっとタブの上を通るのではなくエディタ領域上を通過して右端のタブを飛び越えた位置にマウスカーソルをドラッグ操作すると並び替えが行われません。

このPRでは上記の操作を行った場合にもドラッグしたタブが右端に並び替えられるようにします。

カテゴリ

  • その他

@AppVeyorBot
Copy link

Build sakura 1.0.2399 completed (commit a4fb3ec807 by @)

@berryzplus
Copy link
Contributor

マウスを使ったドラッグ操作によるタブの並び替えでドラッグしてるタブを一番右端に並び替える際の操作性を改善するのが目的です。

目的には賛成。

挙動に関しても、気になる点を「制限」と捉えるなら「問題なし」と言えると思います。

気になる点

  • タブの右端に「空きスペース」がない場合の挙動がやや微妙。
    • タブを沢山開いて収まり切らない状態にすると再現できます。
    • 具体的に説明できますが、実際にやってみたほうがイメージしやすいと思います。
    • ぶっちゃけ、今回作りこんだ謎挙動じゃないと思うんですけどね・・・。
  • タブ複数行モードのときの挙動はどうなるんでしたっけ?
    • タブ複数行モードについては元々動作が怪しくて、廃止提案を見たことある気が・・・。
    • なので、タブ複数行モードの優先度は低いです。

あと、仕様的なことで気になる点が1つ。

  • タブをドロップできない領域にドラッグオーバーしても禁止マークが出なくなってる気がします。
    • 既存では右端のタブボタンにドラッグオーバーしたときに出ていました。
      • 変更後ビルドでは出なくなってる気がします。
      • 既存でもたまに出ないことがあるっぽいです(マテ
    • ドロップ禁止領域をなくしました、という説明で理解できなくもない挙動だと思いますが・・・。

というわけで、一旦どーよ?と訊いてみることにしました。

次アクションは、上記2つの「?」への見解を踏まえて、以下の2択になると思います。

  1. なんらかの対処を行ってからマージしていく
  2. 問題と思しき事象は既存からの継承なのでスルーしてマージしていく

@beru
Copy link
Contributor Author

beru commented Nov 24, 2019

気になる点

  • タブの右端に「空きスペース」がない場合の挙動がやや微妙。

    • タブを沢山開いて収まり切らない状態にすると再現できます。
    • 具体的に説明できますが、実際にやってみたほうがイメージしやすいと思います。
    • ぶっちゃけ、今回作りこんだ謎挙動じゃないと思うんですけどね・・・。

Ctrl + N キーを押して (無題) 文書のタブをたくさん作成すると収まりきらなくなった時にスクロールする用途の左右ボタンが表示されますね。これは SysTabControl32 クラスのタブコントロールのスタイルが TCS_SINGLELINE の場合(つまり TCS_MULTILINE が指定されていない場合)の挙動のようですね。

左右ボタンの右には一覧表示を行うボタンが表示されますがこれは CTabWnd::DrawListBtn で描画してるようです。

さて空きスペースが無い箇所にドラッグするとスクロールが自動で行われずに左右ボタンの後ろ側にあると思われるタブの位置に並び替えが行われているようです。ただしボタンの後ろに隠れていて見えないのでユーザーはその事に気づきにくいと思います。

微妙な挙動というのはこの事でしょうか?

  • タブ複数行モードのときの挙動はどうなるんでしたっけ?

    • タブ複数行モードについては元々動作が怪しくて、廃止提案を見たことある気が・・・。
    • なので、タブ複数行モードの優先度は低いです。

複数行モードについては自分が使っていない事もあって全然考慮出来ていませんでした。

確認してみましたが標準のタブコントロールの複数行モードって、選択されたたタブの行が最下行に自動的に移動するんですね。この挙動は共通設定画面を使う際にちょっと使いにくいなぁと思ってましたが、まぁいっか、といつのまにか気にしないようになりました…。

ChromeやFirefox等のタブブラウザは今では拡張を入れないと多段タブ表示が出来なくなっていますね。

まぁ思った通りの表示や挙動にしようと思ったらオーナードロー使ったり自分で独自のタブコントロール作らないと駄目ですね。他にスクロールバー描画とかも改善したいのでそうなると文書部分の描画と合わせて描画は全部自前で1つのウィンドウ上でやるのが良いでしょうね。

あと、仕様的なことで気になる点が1つ。

  • タブをドロップできない領域にドラッグオーバーしても禁止マークが出なくなってる気がします。

    • 既存では右端のタブボタンにドラッグオーバーしたときに出ていました。

      • 変更後ビルドでは出なくなってる気がします。
      • 既存でもたまに出ないことがあるっぽいです(マテ
    • ドロップ禁止領域をなくしました、という説明で理解できなくもない挙動だと思いますが・・・。

というわけで、一旦どーよ?と訊いてみることにしました。

右端のタブボタンを越えた位置にドラッグした際にマウスカーソルがドロップ禁止にならなくなったのは意図した挙動の変更です。

既存では一番右端のタブにドラッグオーバーして重ねた際は、ドラッグ元のタブの位置がその右端のタブの位置に移ります。その動作は変更後も同じです。

既存では一番右端のタブを超えた位置にドラッグオーバーした際にマウスカーソルがドロップ禁止になります。タブボタンの上を通してドラッグ操作をした場合にはその時点でドラッグ元のタブの位置は右端に移っていると思います。しかし他のタブボタンの上を通さずに、例えばメニューや文書領域の上をカーソルが通過するようにドラッグ操作をして、一番右端のタブを越えた位置にカーソルを持っていくと、そこではマウスカーソルがドロップ禁止になってドラッグ元のタブの位置が右端のタブの位置に移りません。

その挙動が良くないと考え、このPRではそのような操作を行った場合にドラッグ元のタブの位置が右端のタブの位置に移るようにしました。この動作の方がどちらかというとFirefox等のタブブラウザに近いと思います。

次アクションは、上記2つの「?」への見解を踏まえて、以下の2択になると思います。

  1. なんらかの対処を行ってからマージしていく
  2. 問題と思しき事象は既存からの継承なのでスルーしてマージしていく

どのような挙動が好ましいかは使う人によって意見が異なるかもしれないですね。今のままでも問題無く使えてるんだから無暗にいじるな、っていう意見もあると思います。

なので問題提起なり、ここをこうしたら使いやすくなるからこうしたい、とかを分かりやすく説明するのも進め方の一つかもしれないですね。説明なしでもみんなが操作感や使い心地が抜群に良い!と感じられるUIを作れれば一番ですが…。

@berryzplus
Copy link
Contributor

さて空きスペースが無い箇所にドラッグするとスクロールが自動で行われずに左右ボタンの後ろ側にあると思われるタブの位置に並び替えが行われているようです。ただしボタンの後ろに隠れていて見えないのでユーザーはその事に気づきにくいと思います。

微妙な挙動というのはこの事でしょうか?

yes。

既存踏襲っす! で通してよさげですが、アレ?って動きしますよね。
しかも言葉で説明しづらい感じの。

タブ複数行モードは一旦、気付かなかった感じで進めてきたいな、と思っています。

右端のタブボタンを越えた位置にドラッグした際にマウスカーソルがドロップ禁止にならなくなったのは意図した挙動の変更です。

これって「タブの右端にスペースが表示されてる場合のみ」とかにするの難しいですか?

  • むつかしい/むつかしくない
  • めんどい/そうでもない

むつかしい×めんどい、だったら後回しにした方がいいと思ってます。

これまでの経緯で、突貫で追加した挙動はロクな結果になってないので、新しい観点の要望が出たらそれ向けの対策は個別に考えるほうがいいような気がしてきています。

2.問題と思しき事象は既存からの継承なのでスルーしてマージしていく

これになるのかな 😃

@beru
Copy link
Contributor Author

beru commented Nov 24, 2019

タブ複数行モードは一旦、気付かなかった感じで進めてきたいな、と思っています。

そうですねぇ。タブブラウザで数十のタブを同時に開いたまま使う人がたまにいますがテキストエディタのユーザーにもそういう人がいるのかなぁ。。それぐらい数が多いとバッファ切替を部分一致の文字列検索で候補絞って行うインターフェースの方が使いやすそうですね。

右端のタブボタンを越えた位置にドラッグした際にマウスカーソルがドロップ禁止にならなくなったのは意図した挙動の変更です。

これって「タブの右端にスペースが表示されてる場合のみ」とかにするの難しいですか?

  • むつかしい/むつかしくない
  • めんどい/そうでもない

むつかしい×めんどい、だったら後回しにした方がいいと思ってます。

左右ボタンで隠れていて表示されているタブの位置にドラッグ操作しても位置を変える動作にしない方が良いという事でしょうか?

左右ボタンの正確な位置が分かればそこ以降ではドラッグしても位置を変えないという判定が出来ると思いますがその位置を取る方法は分かりません。各タブの右端の座標は CTabWnd::m_nTabBorderArray に記録されますが、ウィンドウサイズ的に1行に表示しきれない分も記録されてました。なので GetClientRect で取得したクライアント領域と比較すればスペースがあるかどうかの大体の判定は出来るかもしれないです。

これまでの経緯で、突貫で追加した挙動はロクな結果になってないので、新しい観点の要望が出たらそれ向けの対策は個別に考えるほうがいいような気がしてきています。

2.問題と思しき事象は既存からの継承なのでスルーしてマージしていく

これになるのかな 😃

まぁ色々変更してるとどうしてもバグ的な変な挙動が気付かないうちに入っちゃいますね。なのでノーチェックは良くは無いですね。

「マウスホイールでタブ切替」を有効にして、タブのドラッグ中にホイール操作を行うとその後のタブ切替の挙動が何だか怪しくなりますね。ここらへんの挙動を完璧(とは一体?)にしようとすると大変そうなのでウルトラマンゾフィーのAAを出してスルーしたいです。

@berryzplus
Copy link
Contributor

結論は出た気がしますが、疑問形なので一旦回答を。

左右ボタンで隠れていて表示されているタブの位置にドラッグ操作しても位置を変える動作にしない方が良いという事でしょうか?

はい。そうなります。

タブ1 | タブ2 | __________| ▼ | × |
こうなってるなら、[タブ2] の右側にドラッグできるのが自然な気がします。

タブ1 | タブ2 | タブ|⇦|⇨| ▼ | × |
こうなってる場合、隠れてるタブが実際どうなっているかは不明です。

タブ1 | タブ2 | タブ3 | __________ |⇦|⇨| ▼ | × |
ウインドウの横幅を広げてみたときこうしかありえないならなんの問題もないんですが、そうじゃない気がします。

タブ1 | タブ2 | タブ3 | ブタ3 | __ |⇦|⇨| ▼ | × |
ウインドウの横幅を広げてみたときこうなってる可能性があります。
[タブ1] を [タブ2] の次の次に移動するつもりが、最後に移動してしまいます。

@berryzplus
Copy link
Contributor

目視から想定される挿入位置:
タブ3 と ブタ3 の間
実装から想定される挿入位置:
ブタ3 の後(最後)

@berryzplus
Copy link
Contributor

さて空きスペースが無い箇所にドラッグするとスクロールが自動で行われずに左右ボタンの後ろ側にあると思われるタブの位置に並び替えが行われているようです。ただしボタンの後ろに隠れていて見えないのでユーザーはその事に気づきにくいと思います。

既存で禁止マークが出ないことがある原因って、これっぽいですね。
オーナードロータブコントロールの「タブじゃない領域」を考慮せずにhittestしてる?
描画実装から「タブじゃない領域」を抜いて来れば対応はできそうです。
まぁ、それだけで済むか?というとこに疑問があるので後回しでいいような気がします。

Copy link
Contributor

@berryzplus berryzplus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

とくに問題ないと思います。

#1099 (comment) に書いた通り1点懸念がありますが、無理に対応するとハマりそうなので別件としたいです。(やれたらそのうちやる感じで。

@beru
Copy link
Contributor Author

beru commented Nov 24, 2019

レビューありがとうございます。Mergeします。
もし問題が見つかった場合は別PRで対処します。

@beru beru merged commit 031e02e into sakura-editor:master Nov 24, 2019
@beru
Copy link
Contributor Author

beru commented Nov 24, 2019

左右ボタンで隠れていて表示されているタブの位置にドラッグ操作しても位置を変える動作にしない方が良いという事でしょうか?

はい。そうなります。

タブ1 | タブ2 | __________| ▼ | × |
こうなってるなら、[タブ2] の右側にドラッグできるのが自然な気がします。

タブ1 | タブ2 | タブ|⇦|⇨| ▼ | × |
こうなってる場合、隠れてるタブが実際どうなっているかは不明です。

タブ1 | タブ2 | タブ3 | __________ |⇦|⇨| ▼ | × |
ウインドウの横幅を広げてみたときこうしかありえないならなんの問題もないんですが、そうじゃない気がします。

タブ1 | タブ2 | タブ3 | ブタ3 | __ |⇦|⇨| ▼ | × |
ウインドウの横幅を広げてみたときこうなってる可能性があります。
[タブ1] を [タブ2] の次の次に移動するつもりが、最後に移動してしまいます。

結構再現度が高い AA ですね!

本当は一行の表示領域に表示しきれないくらいタブの数が増えてスクロール表示する場合は、左右端にドラッグ操作した際に自動でスクロールしてくれると良いですね。標準のタブコントロールでも何かのメッセージを送ればそういう操作が実現出来るかもしれないし出来ないかもしれませんが…。

ここから少し話が脱線してウェブブラウザの話になります。

Firefoxウェブブラウザは1行に表示しきれないくらいタブの数を増やすと左右端にスクロール用のボタンが表示されます。その状態で左右端にタブをドラッグ操作すると自動でスクロールしてくれます。

Chromeウェブブラウザはタブの数を増やすとタブの横幅がどんどんと縮みますがスクロール表示はされません。

なお Ctrl +T や Ctrl + W キーを押し続けた場合にキーリピートで複数のタブを開いたり閉じたりする操作を行うかどうかは、FirefoxはキーリピートになりますがChromeはキーリピートになりません。

ここらへんの差異は思想の違いでしょうかね。

@beru
Copy link
Contributor Author

beru commented Nov 24, 2019

既存で禁止マークが出ないことがある原因って、これっぽいですね。
オーナードロータブコントロールの「タブじゃない領域」を考慮せずにhittestしてる?
描画実装から「タブじゃない領域」を抜いて来れば対応はできそうです。
まぁ、それだけで済むか?というとこに疑問があるので後回しでいいような気がします。

コードを見返してみたんですが、タブコントロール上には一覧ボタンやタブを閉じるボタンは描画していないようです。親であるタブバーウィンドウ(CTabWnd)に描画しています。タブコントロールを作る際に右側の余白が TAB_MARGIN_RIGHT で大きく取られています。

という事で「タブじゃない領域」の判定もやろうと思えば出来そうですね。ただし本来は左右端にドラッグ時にスクロールが出来れば良いですがそのやり方は分からないので諦めて後回しにします。標準コントロールに頼らずに全部自前で描画する方式にした方が良いんじゃないか?と思ったりしますが、実装が大変なので先延ばしで…。

@beru beru deleted the OnTabMouseMove branch November 30, 2019 04:31
@m-tmatma m-tmatma added this to the v2.4.0 milestone Dec 29, 2019
@KENCHjp KENCHjp added the enhancement ■機能追加 label Jan 7, 2020
HoppingTappy pushed a commit to HoppingTappy/sakura that referenced this pull request Jun 16, 2020
ドラッグ操作でタブの並び替え、最後のタブより右の位置にドラッグした場合に最後のタブの位置にする
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ■機能追加
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants