Hey, looks good to me from the design standpoint. I'm saying this only looking at the screenshot and the gif - but it seems that the UX side is ok as well.

Minor comments:

• AFAICS this only works well with continuous grab enabled (unavoidable, just to keep in mind its not useful for tablet users)
• I would prefer click drag performs viewport operations, it feels strange that you have to click, let go, move mouse, then click again.

From the GIF this is looking very good! I'd like to try it out but it is failing to apply against the latest master.

Here's my log:

Created and checked out branch arcpatch-D584.
/private/var/folders/zw/ps4qhh4s17z8xc14p8588gg00000gn/T/abvheoaf468k0kog/33770-HPFn7z:488: trailing whitespace.
        
/private/var/folders/zw/ps4qhh4s17z8xc14p8588gg00000gn/T/abvheoaf468k0kog/33770-HPFn7z:490: trailing whitespace.
        
/private/var/folders/zw/ps4qhh4s17z8xc14p8588gg00000gn/T/abvheoaf468k0kog/33770-HPFn7z:492: trailing whitespace.
        
/private/var/folders/zw/ps4qhh4s17z8xc14p8588gg00000gn/T/abvheoaf468k0kog/33770-HPFn7z:494: trailing whitespace.
        
/private/var/folders/zw/ps4qhh4s17z8xc14p8588gg00000gn/T/abvheoaf468k0kog/33770-HPFn7z:497: trailing whitespace.
        
Checking patch release/datafiles/blender_icons.svg...
Checking patch release/scripts/startup/bl_ui/space_userpref.py...
Checking patch release/scripts/startup/bl_ui/space_view3d.py...
Hunk #1 succeeded at 3242 (offset 3 lines).
Checking patch source/blender/blenkernel/BKE_screen.h...
Checking patch source/blender/editors/include/UI_icons.h...
Checking patch source/blender/editors/include/UI_interface.h...
Hunk #2 succeeded at 863 (offset 2 lines).
Checking patch source/blender/editors/include/UI_interface_icons.h...
Checking patch source/blender/editors/interface/interface_icons.c...
Checking patch source/blender/editors/interface/interface_widgets.c...
Checking patch source/blender/editors/screen/area.c...
Hunk #1 succeeded at 1779 (offset 4 lines).
Checking patch source/blender/editors/space_view3d/space_view3d.c...
Hunk #3 succeeded at 1321 (offset 1 line).
Hunk #4 succeeded at 1330 (offset 1 line).
Checking patch source/blender/editors/space_view3d/view3d_draw.c...
Checking patch source/blender/editors/space_view3d/view3d_edit.c...
Checking patch source/blender/editors/transform/transform.c...
Checking patch source/blender/makesdna/DNA_userdef_types.h...
error: while searching for:
	short tweak_threshold;
	char navigation_mode, pad;

	char author[80];	/* author name for file formats supporting it */

	int compute_device_type;
	int compute_device_id;

error: patch failed: source/blender/makesdna/DNA_userdef_types.h:519
Checking patch source/blender/makesrna/intern/rna_ui_api.c...
Checking patch source/blender/makesrna/intern/rna_userdef.c...
Applied patch release/datafiles/blender_icons.svg cleanly.
Applied patch release/scripts/startup/bl_ui/space_userpref.py cleanly.
Applied patch release/scripts/startup/bl_ui/space_view3d.py cleanly.
Applied patch source/blender/blenkernel/BKE_screen.h cleanly.
Applied patch source/blender/editors/include/UI_icons.h cleanly.
Applied patch source/blender/editors/include/UI_interface.h cleanly.
Applied patch source/blender/editors/include/UI_interface_icons.h cleanly.
Applied patch source/blender/editors/interface/interface_icons.c cleanly.
Applied patch source/blender/editors/interface/interface_widgets.c cleanly.
Applied patch source/blender/editors/screen/area.c cleanly.
Applied patch source/blender/editors/space_view3d/space_view3d.c cleanly.
Applied patch source/blender/editors/space_view3d/view3d_draw.c cleanly.
Applied patch source/blender/editors/space_view3d/view3d_edit.c cleanly.
Applied patch source/blender/editors/transform/transform.c cleanly.
Applying patch source/blender/makesdna/DNA_userdef_types.h with 1 reject...
Rejected hunk #1.
Hunk #2 applied cleanly.
Applied patch source/blender/makesrna/intern/rna_ui_api.c cleanly.
Applied patch source/blender/makesrna/intern/rna_userdef.c cleanly.

 Patch Failed! 
Usage Exception: Unable to apply patch!

@Julian Eisel (Severin), devices such as tablet use absolute positioning, just forcing continuous grab here wont work right. Worth seeing how other apps handle this.

Probably checking if the event is from a tablet or not is the best we can do here. (event->tablet_data == NULL)

Hey @Campbell Barton (campbellbarton),
I had a deeper look into the tablet issues. A possible solution:
When the mouse moves close to the upper window border the moving/rotating/zooming could happen automatically, even if the mouse isn't moving. The closer to the border the faster. This could use if (event->tablet_data) to limit it to tablet events only. I had some tries with this and so far it worked but I'm a bit afraid that this wouldn't integrate nicely with the source code as it had to be implemented to each operator individually.
We could rather think about adding this as a general behaviour for continuous grap when using a tablet.

Removing the icons completely if we have tablet data wouldn't be a solution because when using a pen tablet you still have the option to use relative position.

Having a look at other apps shows that they have the same limitations. E.g. I tried Inkscape with my Bamboo. When I moved the canvas upwards till the tablet border is reached, it just ignores further increasing the y-axis. Well you can't really compare these situations, because when moving the canvas you normally have much more space than we have above the navigation icons.

My personal preference:
Either add the general "close to window border behaviour" for continuous grap when using a tablet or just leave it as it is (you normally still have the pixels from the info header + the window border until the tablet border is reached which should be quite enough)

Thanks for the feedback!

@Julian Eisel (Severin), regarding other apps, did you check other 3D apps which have a pan/orbit/zoom options? (MotionBuilder, Cinema4D have iirc), but there are probably no magic answers here.

Probably best we can do is ensure its not behaving with bugs/glitches when tablets are used.

See similar issue discussed here.
https://developer.blender.org/D606

@Campbell Barton (campbellbarton), I just had a look at the navigation icons of Cinema4D, which are behaving extremely weird with a pen tablet in absolute mode, so no, no magic answers there.
I think it's fine to leave it as it is and start reviewing. Just need someone to do this *cough* ;-). I'm going to throw the patch into the next meeting, so maybe it will do it into 2.72 (if thats okay for @Jonathan Williamson (carter2422)).

As noted in IRC, this patch is still failing to apply for me. Here's the error: http://www.pasteall.org/52586

Do I need to do anything extra to make the icons show? They are enabled in User Preferences and they actually work, I can click onto them to activate. But they don't show.

@Jonathan Williamson (carter2422), sry for the delay was a bit busy the last days... anyway...
I thought the icons would work out of the box but it seems that you have to update the icons. For testing it should be enough to erease blender_icons16.png and blender_icons32.png in /"build_dir"/release/datafiles with these:

If this doesn't work you can update the icons via:

python3 blender_icons_update.py

in /"source_dir"/release/datafiles (afaik you need to have Python3, Inkscape and Blender in your PATH, or you can just edit the .py file).

Sry for making it so hard for you, but i don't know an easier way to do this ;) Feel free to ask me for help

Thanks!

Idea for tablet solution: Would it be possible to register a second finger input?
Ie. You press the icon (if. pan) and if you move the finger it will pan, but if you put another finger on the screen it will use this one instead?
So you could touch the icon/function you want and use another finger to swipe around, doing the movement you want..?

I wonder if FPS walk mode + on-screen instructions and navigation controls would be better. A single small indicator in the right upper corner of the 3d view could start it. Editing and all keyboard shortcuts other than for navigation should be disabled while that operator is running (maybe add *File > Open (View only)* option?)

Benefits:

• 1 instead of 3 icons in the right upper corner
• No new option for the crowded user preferences, which can be disabled and make it pretty inaccessible to newbies again
• Modal operator can show help text and specially designed navigation controls, which work for mouse + tablets (view-centered!)
• No accidental changes to the file, as editing is temporarily disabled

This sounds like a very nice addition, but theres two small UI design elements that caught my eye, and think could do with some tweaks. Firstly, the Zoom icon shading is very strong in comparison to the other two icons, which makes it stick out unnecessarily rather than sitting as an equal to the other two icons.

Also, the dot inside the rotate icon is very close to intersecting the arrow, which I feel make the symbol less 'readable'. I made a few scrappy edits which hopefully illustrate my point (Left One = Old, Right One = New)

Sorry if this is beyond the scope of patch discussion, this is my first time :x

@Paweł Łyczkowski (plyczkowski), would you mind having a look on that? They should indeed get some fine tuning before this is merged (even though we're quite picky here ;D).

BTW, I hope to find a bit of time to go over the patch again, within the next weeks, so I can make it ready for review. I don't want to promise anything, but chances are we can merge this for 2.73.

Hmm, we should keep the shaded style of other icons - your edit makes them more consistent among themselves, but inconsistent with the rest of Blender GUI icons. So the problem is actually that the arrows have no shading at all. I'll see what I can do about it.

The shading itself is okay IMO, I think the problem is in the zoom icon, which seems to be a bit more intense. IIRC, it looked like you used a higher alpha value for it.

In D584#13850, @Paweł Łyczkowski (plyczkowski) wrote:

Hmm, we should keep the shaded style of other icons - your edit makes them more consistent among themselves, but inconsistent with the rest of Blender GUI icons. So the problem is actually that the arrows have no shading at all. I'll see what I can do about it.

There isn't shading on these? I only altered the shading on the Zoom to make it less intense, but at least on inspection theres shading on the three icons, even if subtle. There are icons in Blender's GUI like the Plus and Cross icon get away with a more subtle gradient or no gradient at all in some areas, gradients only seem to get used with more complicated icons.