first pan/zoom doesn't get recognized when window isn't active #99269

New Issue

Matthias · 2022-06-29T14:31:40+02:00

Matthias commented

2022-06-29 14:31:40 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.59

Blender Version
Broken: version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: cc66d1020c
Worked: never?

Short description of error
When working with blender and multiple floating windows / other programs, blender doesn't recognize the modifier keys on the first interaction with the non active window, so it defaults to the middle mouse button without modifiers (e.g. orbit in 3d viewport).

Exact steps for others to reproduce the error

Start blender
open floating window (graph editor for example)
interact with graph editor
hover mouse over 3d viewport, shift+mmb to pan or ctrl+mmb to zoom
blender will rotate the viewport instead of paning/zooming

This is kind of a duplicate of a feature request I did a few years ago on RCS:

https://blender.community/c/rightclickselect/lZcbbc/?sorting=hot

but I think it really qualifies as a bug (since it's possible in linux and pretty much any other 3d program) and is REALLY annoying and happens dozens of times each day.

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.59 **Blender Version** Broken: version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: `cc66d1020c` Worked: never? **Short description of error** When working with blender and multiple floating windows / other programs, blender doesn't recognize the modifier keys on the first interaction with the non active window, so it defaults to the middle mouse button without modifiers (e.g. orbit in 3d viewport). **Exact steps for others to reproduce the error** - Start blender - open floating window (graph editor for example) - interact with graph editor - hover mouse over 3d viewport, shift+mmb to pan or ctrl+mmb to zoom blender will rotate the viewport instead of paning/zooming This is kind of a duplicate of a feature request I did a few years ago on RCS: https://blender.community/c/rightclickselect/lZcbbc/?sorting=hot but I think it really qualifies as a bug (since it's possible in linux and pretty much any other 3d program) and is REALLY annoying and happens dozens of times each day.

Matthias commented

2022-06-29 14:31:40 +02:00

Added subscriber: @Mots

blender-admin commented

2022-06-29 14:31:40 +02:00

#103249 was marked as duplicate of this issue

blender-admin commented

2022-06-29 14:31:40 +02:00

#100621 was marked as duplicate of this issue

Germano Cavalcante commented

2022-06-30 21:17:42 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-06-30 21:17:42 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2022-06-30 21:17:42 +02:00

This is because events like Shift are only sent to the active window.
So you need to activate the window with the 3D view first to then pan it.

This is common for most windowed applications.
Chrome for example, you can't select a text without activating the window first.

Did I misunderstand the problem?

This is because events like Shift are only sent to the active window. So you need to activate the window with the 3D view first to then pan it. This is common for most windowed applications. Chrome for example, you can't select a text without activating the window first. Did I misunderstand the problem?

Matthias commented

2022-06-30 21:46:17 +02:00

Hello Germano,

thanks for the reply.

No, you understood correctly. And I know that many applications work that way.

The thing is, most applications don't need multiple windows at the same time, or modifier keys to navigate.

3D applications on the other hand do have many different editors which often times are floating windows.

As I said, other 3D applications don't have the need to always activate the windows first, but rather only hover over that specific window. (C4D and Modo I can say for certain, and I'm pretty sure Maya behaved the same way, back when I was using it).

So, I don't know how complicated it would be to implement this, but it would certainly be a welcome quality of life change.

Hello Germano, thanks for the reply. No, you understood correctly. And I know that many applications work that way. The thing is, most applications don't need multiple windows at the same time, or modifier keys to navigate. 3D applications on the other hand do have many different editors which often times are floating windows. As I said, other 3D applications don't have the need to always activate the windows first, but rather only hover over that specific window. (C4D and Modo I can say for certain, and I'm pretty sure Maya behaved the same way, back when I was using it). So, I don't know how complicated it would be to implement this, but it would certainly be a welcome quality of life change.

Harley Acheson commented

2022-06-30 22:32:04 +02:00

Added subscriber: @Harley

Harley Acheson commented

2022-06-30 22:32:04 +02:00

You could test the following patch: D13951: Win32: Auto-Raise and -Focus Windows on Hover

You could test the following patch: [D13951: Win32: Auto-Raise and -Focus Windows on Hover](https://archive.blender.org/developer/D13951)

Matthias commented

2022-06-30 22:44:32 +02:00

Thank you very much, Harley,

this seems to be exactly what I was looking for.

I'll have to look into how to make a build and apply a patch tomorrow to test this out.

Don't want to go too much off topic, but is this something that gets added to a future version of blender?

Thank you very much, Harley, this seems to be exactly what I was looking for. I'll have to look into how to make a build and apply a patch tomorrow to test this out. Don't want to go too much off topic, but is this something that gets added to a future version of blender?

Harley Acheson commented

2022-06-30 23:06:20 +02:00

This could get added to blender if enough people try it and give positive feedback. The spoiler here is that it can't be set to raise ALL of Blender's windows just because we have some oddballs like the Render Window that behaves differently from others. So the patch auto-focuses between parent windows and their children and between siblings (same parent). And between main (parentless) windows only if they are not overlapping at all. So this covers the main usages without letting the Render window mess things up.

Matthias commented

2022-07-01 05:38:20 +02:00

Thanks for the explanation.

I'll give it a try when I get the chance and report back to you!

Thanks for the explanation. I'll give it a try when I get the chance and report back to you!

Germano Cavalcante commented

2022-07-04 16:08:56 +02:00

Changed status from 'Needs User Info' to: 'Archived'

Germano Cavalcante closed this issue

2022-07-04 16:08:56 +02:00

Germano Cavalcante commented

2022-07-04 16:08:56 +02:00

As the issue here is not actually about a bug but a design that needs to be discussed, I'm closing the report.

It would be better to create a Design task in this case.

(Note the report can be reopened if the developers approves and edits it).

As the issue here is not actually about a bug but a design that needs to be discussed, I'm closing the report. It would be better to create a `Design` task in this case. (Note the report can be reopened if the developers approves and edits it).

Germano Cavalcante commented

2022-08-25 00:24:35 +02:00

Added subscriber: @manukings

Pratik Borhade commented

2022-12-16 07:58:44 +01:00

Added subscribers: @glencandle-3, @sockseight

Harley Acheson commented

2022-12-16 15:04:47 +01:00

Added subscriber: @PratikPB2123

Harley Acheson commented

2022-12-16 15:04:47 +01:00

@PratikPB2123

You merged this and #103249 but there is a subtle difference. In fact THIS one can actually be closed as resolved. They seem similar and in fact I proposed the same possible solution to both, which is probably why you merged.

With THIS one, there is a mouse activation of the new window, as in he is directly clicking on each window in turn. So he is properly making the new window active. The problem here is that he is doing so while also holding down a modifier key, like shift or ctrl. That is fixed as of Blender 3.4 by Campbell so modifiers are no longer lost if they were part of the first click.

The other one was a complaint that a mouse click is even necessary to activate a window. So like this complaint but instead of shift+mm think of pressing "g" to grab. That wont work unless the window is activated first with a mouse click. This would require my proposed auto-raising patch

@PratikPB2123 You merged this and #103249 but there is a subtle difference. In fact THIS one can actually be closed as resolved. They seem similar and in fact I proposed the same possible solution to both, which is probably why you merged. With THIS one, there is a mouse activation of the new window, as in he is directly clicking on each window in turn. So he is properly making the new window active. The problem here is that he is doing so while also holding down a modifier key, like shift or ctrl. That is fixed as of Blender 3.4 by Campbell so modifiers are no longer lost if they were part of the first click. The other one was a complaint that a mouse click is even necessary to activate a window. So like this complaint but instead of shift+mm think of pressing "g" to grab. That wont work unless the window is activated first with a mouse click. This would require my proposed auto-raising patch

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

first pan/zoom doesn't get recognized when window isn't active #99269