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

opinions on new UI #4

Open
hdeeken opened this issue Jan 13, 2015 · 4 comments
Open

opinions on new UI #4

hdeeken opened this issue Jan 13, 2015 · 4 comments

Comments

@hdeeken
Copy link
Member

hdeeken commented Jan 13, 2015

hi guys,

would you mind testing the new version of the tool and give me some feedback?

in the old version the FPSMotion viewcontroller needed to be set manually. now the tool chooses this one automatically if activated (by pressing 'q'). if one exits the tool (by pressing 'e') the viewmanager is triggered to load a fallback view (Orbit by default or any other by using the ToolProperty). during this exit a fallback tool is also activated (Interact by default, or property).

this exit on 'e' is somewhat strange because one should switch the tool off by pressing 'q' agian but that seems to result in deactivating and directly activating the tool again... will check that again tomorrow, maybe rviz is behaving strange here...

then there's a property for an arrowbased left-hand mode. i derived that one from the original problem, that pressing 's' in the 'wasd' setup activated the 'Select' tool. but since using the arrow-keys is not really ergonomically, i decided to tackle this problem this way: if 'Select' is active when the FPS tool is activate, i delete the Select tool and readd it if the FPS tool is deactivated. since this does NOT effect the Selections in the Selection Panel, if find this a proper workaround. the only drawback is, that the Select tool changes it position in the ToolBar. what do you think about this?

further one to change the stepsize via the tool properties as well. the same hold for the fly mode, which can still be toggled by pressing 'f'

i feel like this version has pretty easy workflow (at least in the right handed version), only the deactivation part bothers me a little.

any ideas for further improvement?

do you have any ideas on how to improve the tool further?

@WanliJiang
Copy link

I tried and I think it works nice (I don't have idea for working around Tool/Select either...)!

About minor things:

  • compilation fails with this commit: fps_motion_config_widget.h was removed but was still referenced in the fps_motion_tool.h.
  • in Move mode, besides left/right/forward/backward, how about up/down with "q", "z"? (then "q" is used both for activating the tool and moving up when the tool is already activated; or maybe use "f" for activating "FPS Motion" tool?)
  • about fallback viewcontroller: would it be easier if the fallback is just the viewcontroller the user uses before switching to FPSMotion viewcontroller? similar case with fallback tool.

@mintar
Copy link
Member

mintar commented Jan 14, 2015

Can't test right now because compilation fails, just as @WanliJiang noticed. Some more thoughts:

  • Why not use q and e to yaw, like in most shooters? And some other keys for up/down?
  • Holding shift to run would be cool (if it's feasible).
  • If the "select" tool is active, pressing s switches to the select tool instead of moving backwards. I can't think of a good way to solve this, so maybe this should just be mentioned in the documentation. Also, look out for more of those key binding conflicts when selecting new keys.
  • Speaking of documentation: README.md could be improved (doesn't have to be long, but some simple step-by-step instructions on how to start the thing from an empty rviz config would help).
  • I've submitted a rosdistro pull request, so in a couple of days the doc indexer should parse the documentation and update the wiki page, which I've created here. Feel free to add information to it.

@mintar
Copy link
Member

mintar commented Jan 14, 2015

Oh, just noticed that you already mentioned the select tool conflict. I'm not really happy with either solution (deactivating and reactivating it / mentioning the problem in the docu / using different key bindings). Any thoughts, @jspricke?

mintar added a commit that referenced this issue Jan 15, 2015
Fixes the compilation problem on Indigo mentioned in #4.
@hdeeken
Copy link
Member Author

hdeeken commented Jan 15, 2015

Thanks, for the great feedback so far!

Compilation: Sorry about that! Don't know what happend there. Seems like I missed that line during while "commit -p"ing the changes together. :-/ @mintar Thanks for fixing it already!

Shift-Boost / Yaw / Up Down: These are all easy. I implemented your requests. Please pull the new indigo branch. Having the yaw and up and down movementes, makes the right-hand vs. left-hand setup fairly intuitive as well. By default, its now WASD for movement and the arrows for up/down and yawing, and vice versa for the left-hand mode.

ROS Distro / Doc / Wiki / Hydro: That's great! Thanks again @mintar! I will see that I update the Readme asap and write some proper docs soon.

Fallback Tool and View: Yeah I was considering using fallbacks to the previous tool / view as well, but RViz doesn't agree here. Since the ToolManager only offers "getCurrentTool" and "getDefaultTool", its not possible to get information on the previous tool from inside the tool. Regarding the ViewController, one can access the current VC, before setting the "FPSMotion" VC. However I would really like to have the option to set a fixed fallback at least in some use cases. So one can have a fixed change between moving and doing something else (e.g. labeling objects) that allows to be interrupted by another action once in a while and seamingly entering the workflow again by simply moving again. So ideally the EnumProperty of the tool is set to "Previous" by default, but allows to choose all other Tools as well. But since that's not at hand right now, let's do it this way: The tool will keep the fallback enum properties for now and I will try to come up with a patch that allows more sophisticated fallback strategies within RViz' ToolManager.

Shortkey Bindings: RViz' behavior regarding shortkeys is really a little annoying as well. An active tool simply can't overlay shortcuts of other tools, because they are filtered in advance. Which is in my opinion a bad idea because, one we have enough tools at hand the entire keyboard will be setup with hotkeys and no tool is able to have shortkeys off it's own. I fooled around with the RViz' sources yesterday and figured out a way to give tools the opportunity to get all key events if desired. I will setup a pullrequest and issue for that tonight. So I guess we have to live with removing the select tool for now, but hopefully find a more elegant way sooner or later. ;D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants