-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
I tried and I think it works nice (I don't have idea for working around Tool/Select either...)! About minor things:
|
Can't test right now because compilation fails, just as @WanliJiang noticed. Some more thoughts:
|
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? |
Fixes the compilation problem on Indigo mentioned in #4.
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 |
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?
The text was updated successfully, but these errors were encountered: