-
Notifications
You must be signed in to change notification settings - Fork 163
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
Conversation
✅ Build sakura 1.0.2399 completed (commit a4fb3ec807 by @) |
目的には賛成。 挙動に関しても、気になる点を「制限」と捉えるなら「問題なし」と言えると思います。 気になる点
あと、仕様的なことで気になる点が1つ。
というわけで、一旦どーよ?と訊いてみることにしました。 次アクションは、上記2つの「?」への見解を踏まえて、以下の2択になると思います。
|
Ctrl + N キーを押して 左右ボタンの右には一覧表示を行うボタンが表示されますがこれは さて空きスペースが無い箇所にドラッグするとスクロールが自動で行われずに左右ボタンの後ろ側にあると思われるタブの位置に並び替えが行われているようです。ただしボタンの後ろに隠れていて見えないのでユーザーはその事に気づきにくいと思います。 微妙な挙動というのはこの事でしょうか?
複数行モードについては自分が使っていない事もあって全然考慮出来ていませんでした。 確認してみましたが標準のタブコントロールの複数行モードって、選択されたたタブの行が最下行に自動的に移動するんですね。この挙動は共通設定画面を使う際にちょっと使いにくいなぁと思ってましたが、まぁいっか、といつのまにか気にしないようになりました…。 ChromeやFirefox等のタブブラウザは今では拡張を入れないと多段タブ表示が出来なくなっていますね。 まぁ思った通りの表示や挙動にしようと思ったらオーナードロー使ったり自分で独自のタブコントロール作らないと駄目ですね。他にスクロールバー描画とかも改善したいのでそうなると文書部分の描画と合わせて描画は全部自前で1つのウィンドウ上でやるのが良いでしょうね。
右端のタブボタンを越えた位置にドラッグした際にマウスカーソルがドロップ禁止にならなくなったのは意図した挙動の変更です。 既存では一番右端のタブにドラッグオーバーして重ねた際は、ドラッグ元のタブの位置がその右端のタブの位置に移ります。その動作は変更後も同じです。 既存では一番右端のタブを超えた位置にドラッグオーバーした際にマウスカーソルがドロップ禁止になります。タブボタンの上を通してドラッグ操作をした場合にはその時点でドラッグ元のタブの位置は右端に移っていると思います。しかし他のタブボタンの上を通さずに、例えばメニューや文書領域の上をカーソルが通過するようにドラッグ操作をして、一番右端のタブを越えた位置にカーソルを持っていくと、そこではマウスカーソルがドロップ禁止になってドラッグ元のタブの位置が右端のタブの位置に移りません。 その挙動が良くないと考え、このPRではそのような操作を行った場合にドラッグ元のタブの位置が右端のタブの位置に移るようにしました。この動作の方がどちらかというとFirefox等のタブブラウザに近いと思います。
どのような挙動が好ましいかは使う人によって意見が異なるかもしれないですね。今のままでも問題無く使えてるんだから無暗にいじるな、っていう意見もあると思います。 なので問題提起なり、ここをこうしたら使いやすくなるからこうしたい、とかを分かりやすく説明するのも進め方の一つかもしれないですね。説明なしでもみんなが操作感や使い心地が抜群に良い!と感じられるUIを作れれば一番ですが…。 |
yes。
タブ複数行モードは一旦、気付かなかった感じで進めてきたいな、と思っています。
これって「タブの右端にスペースが表示されてる場合のみ」とかにするの難しいですか?
むつかしい×めんどい、だったら後回しにした方がいいと思ってます。 これまでの経緯で、突貫で追加した挙動はロクな結果になってないので、新しい観点の要望が出たらそれ向けの対策は個別に考えるほうがいいような気がしてきています。
これになるのかな 😃 |
そうですねぇ。タブブラウザで数十のタブを同時に開いたまま使う人がたまにいますがテキストエディタのユーザーにもそういう人がいるのかなぁ。。それぐらい数が多いとバッファ切替を部分一致の文字列検索で候補絞って行うインターフェースの方が使いやすそうですね。
左右ボタンで隠れていて表示されているタブの位置にドラッグ操作しても位置を変える動作にしない方が良いという事でしょうか? 左右ボタンの正確な位置が分かればそこ以降ではドラッグしても位置を変えないという判定が出来ると思いますがその位置を取る方法は分かりません。各タブの右端の座標は
まぁ色々変更してるとどうしてもバグ的な変な挙動が気付かないうちに入っちゃいますね。なのでノーチェックは良くは無いですね。 「マウスホイールでタブ切替」を有効にして、タブのドラッグ中にホイール操作を行うとその後のタブ切替の挙動が何だか怪しくなりますね。ここらへんの挙動を完璧(とは一体?)にしようとすると大変そうなのでウルトラマンゾフィーのAAを出してスルーしたいです。 |
結論は出た気がしますが、疑問形なので一旦回答を。
はい。そうなります。
|
目視から想定される挿入位置: |
既存で禁止マークが出ないことがある原因って、これっぽいですね。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
とくに問題ないと思います。
#1099 (comment) に書いた通り1点懸念がありますが、無理に対応するとハマりそうなので別件としたいです。(やれたらそのうちやる感じで。
レビューありがとうございます。Mergeします。 |
結構再現度が高い AA ですね! 本当は一行の表示領域に表示しきれないくらいタブの数が増えてスクロール表示する場合は、左右端にドラッグ操作した際に自動でスクロールしてくれると良いですね。標準のタブコントロールでも何かのメッセージを送ればそういう操作が実現出来るかもしれないし出来ないかもしれませんが…。 ここから少し話が脱線してウェブブラウザの話になります。 Firefoxウェブブラウザは1行に表示しきれないくらいタブの数を増やすと左右端にスクロール用のボタンが表示されます。その状態で左右端にタブをドラッグ操作すると自動でスクロールしてくれます。 Chromeウェブブラウザはタブの数を増やすとタブの横幅がどんどんと縮みますがスクロール表示はされません。 なお Ctrl +T や Ctrl + W キーを押し続けた場合にキーリピートで複数のタブを開いたり閉じたりする操作を行うかどうかは、FirefoxはキーリピートになりますがChromeはキーリピートになりません。 ここらへんの差異は思想の違いでしょうかね。 |
コードを見返してみたんですが、タブコントロール上には一覧ボタンやタブを閉じるボタンは描画していないようです。親であるタブバーウィンドウ( という事で「タブじゃない領域」の判定もやろうと思えば出来そうですね。ただし本来は左右端にドラッグ時にスクロールが出来れば良いですがそのやり方は分からないので諦めて後回しにします。標準コントロールに頼らずに全部自前で描画する方式にした方が良いんじゃないか?と思ったりしますが、実装が大変なので先延ばしで…。 |
ドラッグ操作でタブの並び替え、最後のタブより右の位置にドラッグした場合に最後のタブの位置にする
PR の目的
マウスを使ったドラッグ操作によるタブの並び替えでドラッグしてるタブを一番右端に並び替える際の操作性を改善するのが目的です。
現在の実装ではマウスカーソルがタブの上を通るようにドラッグすれば問題なく一番右端に移動できます。
しかしマウスカーソルがずっとタブの上を通るのではなくエディタ領域上を通過して右端のタブを飛び越えた位置にマウスカーソルをドラッグ操作すると並び替えが行われません。
このPRでは上記の操作を行った場合にもドラッグしたタブが右端に並び替えられるようにします。
カテゴリ