-
Notifications
You must be signed in to change notification settings - Fork 39
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
[rwt_app_chooser] support app args #117
[rwt_app_chooser] support app args #117
Conversation
319b736
to
c5d9491
Compare
I am generally against increasing the number of prompts. I believe that one of the main strengths of the rwt_app_chooser is its ability to be used on mobile devices, and I don't think that emulating a text-heavy CLI interface is doing any good for that. Besides that, this implementation also has several points that need to be more thoroughly discussed:
Normally, I would suggest to implement different app instances with different argument values. |
It is impractical to implement different app instances for different args because some app can take args with variable length. The number of applications will be a number of combinations. Main reason of "text-heavy CLI interfaces" for app args is that args field of StartApp service is already extensive and there is still no interface for app_manager apps to tell app_args list to clients of app_manager. So client interface of app_args to a user have to be implemented to express a dictionary which has strings as values and has strings as keys. (I know my implementation is more ambiguous than this.) |
I do think that this is a good pretext for reconsidering the app_args interface (adding fields to list_apps message, or adding another channel of communication?) |
@sktometometo please fix test |
fc9c763
to
acce4fc
Compare
@k-okada CI passed |
Support args when start an app.