> > * All tools are advised to support --verbose and --quite arguments > > (including -v and -q). > > Even if this arguments does not change the behavior of the tool at all at > > this moment, it can be used in the future.. > > Note: almost all qvm- tools already do support those, so probably there was > > a plan so already. > > Same question as above.
Personally,I think it's a mistake to include options like "--verbose" that do nothing. It's confusing and gives bad UX. Non functional options should be removed, not retained as placeholders for work to be done. > > * Each tool should provide some information about arguments without actual > > qubes name being required. > > E.g. `qvm-prefs --help-properties` requires VMNAME and the lists properties > > help only for the qube. There is no way to list all properties for user nor > > get them from scripts, because dom0 has only limited of properties and > > names of other qubes can be different on any Qubes OS instance. I think in > > this case VMNAME should be optional, without it the tool should output all > > possible properties. > > The issue here is that different VM types may not only different allowed > properties, but even different meanings of the same property. See for > example 'template' property for AppVM and DispVM. > We can probably collect them for all classes and then annotate > differences, but I'm not sure how helpful that would be. I find the current system works well, if I forget something while composing a command. Quicker than `man`,which should list all properties. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y9aNZoCiHt4vKvCw%40thirdeyesecurity.org.
