Re: [Qemu-block] interactive qemu-img
> On Jul 30, 2018, at 6:14 PM, Nir Soffer wrote: > > On Mon, Jul 30, 2018 at 11:09 PM Eric Blake wrote: > On 07/30/2018 02:54 PM, Nir Soffer wrote: > > >>> $ qemu-img > >>> qemu-img: Not enough arguments > >>> Try 'qemu-img --help' for more information > > > > > > This is not user friendly, but unfortunately very common. > > It can be improved by treating no arguments as --help, like git. > > I somewhat disagree that git is a good example. If '--help' occupies > more than about 25 lines (a screenful on some default terminal sizes), > the mere fact that you have to scroll to read it makes it less helpful > than a 2-liner statement that lets you know "I couldn't do anything > useful with your botched command line, please read the documentation and > try again". 'git' behaving as 'git --help' outputs 42 lines, which > fails my 'one screenful' test; and 'qemu-img --help' at 104 lines is > definitely too verbose to be the default behavior when --help is not given. > > /me Wow - I can't believe I'm actually about to use this as an example, but: > > 'cvs' and 'cvs --help' is just 13 lines (except to stderr, when it > should have been stdout), and gives enough hints on how to get more > specific help on a particular topic. Great for the plain 'cvs' case; a > bit more debatable on 'cvs --help' (the fact that you have to ask for > help twice: once for the summary, again for the specific help, gets > tedious). > > At any rate, getting command-line tools to have user-friendly behavior > when insufficient arguments are supplied is an artform, and you'll find > lots of bikeshed colors out there. > > And regardless of any opinions I've expressed above, this thread does > point out that 104 lines for 'qemu-img --help' is long, and anything we > can do to make that easier to digest may still be worthwhile. > > I agree that git help is too long, and falling back to --help without > improving > qemu-img help is not very useful. > > What we need is something like: > > $ qemu-img > > Commands: > amend description... > bench description... > check description... > commit description... > compare description... > convert description... > create description... > dd description... > infodescription... > map description... > measure description... > snapshotdescription... > rebase description... > resize description... > > This fits in a terminal, and we have space for additional tips or common > command line options. This looks actually readable. I like the idea.
Re: [Qemu-block] interactive qemu-img
On Mon, Jul 30, 2018 at 11:09 PM Eric Blake wrote: > On 07/30/2018 02:54 PM, Nir Soffer wrote: > > >>> $ qemu-img > >>> qemu-img: Not enough arguments > >>> Try 'qemu-img --help' for more information > > > > > > This is not user friendly, but unfortunately very common. > > It can be improved by treating no arguments as --help, like git. > > I somewhat disagree that git is a good example. If '--help' occupies > more than about 25 lines (a screenful on some default terminal sizes), > the mere fact that you have to scroll to read it makes it less helpful > than a 2-liner statement that lets you know "I couldn't do anything > useful with your botched command line, please read the documentation and > try again". 'git' behaving as 'git --help' outputs 42 lines, which > fails my 'one screenful' test; and 'qemu-img --help' at 104 lines is > definitely too verbose to be the default behavior when --help is not given. > > /me Wow - I can't believe I'm actually about to use this as an example, > but: > > 'cvs' and 'cvs --help' is just 13 lines (except to stderr, when it > should have been stdout), and gives enough hints on how to get more > specific help on a particular topic. Great for the plain 'cvs' case; a > bit more debatable on 'cvs --help' (the fact that you have to ask for > help twice: once for the summary, again for the specific help, gets > tedious). > > At any rate, getting command-line tools to have user-friendly behavior > when insufficient arguments are supplied is an artform, and you'll find > lots of bikeshed colors out there. > > And regardless of any opinions I've expressed above, this thread does > point out that 104 lines for 'qemu-img --help' is long, and anything we > can do to make that easier to digest may still be worthwhile. > I agree that git help is too long, and falling back to --help without improving qemu-img help is not very useful. What we need is something like: $ qemu-img Commands: amend description... bench description... check description... commit description... compare description... convert description... create description... dd description... infodescription... map description... measure description... snapshotdescription... rebase description... resize description... This fits in a terminal, and we have space for additional tips or common command line options. Note that this is not "botched command line", so we don't need to complain about missing arguments. qemu-img create --help Should show only help for create. virsh works in a similar way, but it has too many commands in the main help. Of course this may break some management systems calling qemu-img --help and parsing the output. We used to do this in oVirt in the past :-) Nir
Re: [Qemu-block] interactive qemu-img
On Mon, Jul 30, 2018 at 04:57:54PM -0400, Programmingkid wrote: > > > On Jul 30, 2018, at 3:55 PM, Jeff Cody wrote: > > > > On Mon, Jul 30, 2018 at 12:30:01PM -0400, Programmingkid wrote: > >> > >>> On Jul 30, 2018, at 11:09 AM, Eric Blake wrote: > >>> > >>> On 07/28/2018 08:22 PM, Programmingkid wrote: > I thought of a way to make qemu-img much more user-friendly. When the > user opens qemu-img without any arguments, we could present a prompt > that guides the user on making an image file. > This illustrates what I think should happen. > > Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): > qcow2 > Please enter a size (e.g. 100M, 10G): > 4G > Please enter a name: > WinXP.qcow2 > Creating image file...done > The interactive prompt would contain enough options to make a usable > image file. If the user wants to use some of the more advanced features > of qemu-img he or she would still need to use the command-line. > Would such a patch be welcomed? > >>> > >>> qemu-img is a command line tool, not a gui. Bloating it with a gui > >>> dialog box is probably not a wise idea. > >> There would be no gui dialog box. Qemu-img would still be a command-line > >> tool. The patch would be done in printf/scanf calls. > >> > > > > Even without a GUI, this would still add a not insignificant bloat and > > unnecessary complexity to qemu-img, that doesn't add to the core > > purpose of the tool. > > > > It is not that the idea of such a dialog-driven tool (command-line or > > otherwise) is without merit; it is that it would be better served as a > > wrapper around qemu-img rather than built into qemu-img. And it probably > > wouldn't belong as part of the QEMU codebase, either, but more like other > > management tools (e.g. libvirt) that wrap QEMU and add higher-level features > > like that. > > > > (One example of sorts, albeit of a GUI, is virt-manager. If you explore the > > storage management, you can create qemu images of various types). > > A wrapper around qemu-img might actually be a better idea than making > qemu-img interactive. I'm currently not sure which route to travel. Maybe > just improving the help of qemu-img might be good enough. > Even as a standalone wrapper around qemu-img, there is still the question of whether this is something to include in the QEMU git tree. The biggest reason against it (IMO) is that it becomes another installed tool that now has to be maintained from here on out (and not to mention, essentially a management tool, at that). I don't see why QEMU would start shipping a management tool for qemu-img, when we don't ship any other management tools that are user-facing. I think an interactive wrapper could be nice, but it should be a separate project outside of QEMU. I also don't think this should discourage you from making such a tool, if it is something you'd find useful. Many a useful project started from people creating tools for their own consumption! -Jeff
Re: [Qemu-block] interactive qemu-img
> On Jul 30, 2018, at 3:55 PM, Jeff Cody wrote: > > On Mon, Jul 30, 2018 at 12:30:01PM -0400, Programmingkid wrote: >> >>> On Jul 30, 2018, at 11:09 AM, Eric Blake wrote: >>> >>> On 07/28/2018 08:22 PM, Programmingkid wrote: I thought of a way to make qemu-img much more user-friendly. When the user opens qemu-img without any arguments, we could present a prompt that guides the user on making an image file. This illustrates what I think should happen. Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): qcow2 Please enter a size (e.g. 100M, 10G): 4G Please enter a name: WinXP.qcow2 Creating image file...done The interactive prompt would contain enough options to make a usable image file. If the user wants to use some of the more advanced features of qemu-img he or she would still need to use the command-line. Would such a patch be welcomed? >>> >>> qemu-img is a command line tool, not a gui. Bloating it with a gui dialog >>> box is probably not a wise idea. >> There would be no gui dialog box. Qemu-img would still be a command-line >> tool. The patch would be done in printf/scanf calls. >> > > Even without a GUI, this would still add a not insignificant bloat and > unnecessary complexity to qemu-img, that doesn't add to the core > purpose of the tool. > > It is not that the idea of such a dialog-driven tool (command-line or > otherwise) is without merit; it is that it would be better served as a > wrapper around qemu-img rather than built into qemu-img. And it probably > wouldn't belong as part of the QEMU codebase, either, but more like other > management tools (e.g. libvirt) that wrap QEMU and add higher-level features > like that. > > (One example of sorts, albeit of a GUI, is virt-manager. If you explore the > storage management, you can create qemu images of various types). A wrapper around qemu-img might actually be a better idea than making qemu-img interactive. I'm currently not sure which route to travel. Maybe just improving the help of qemu-img might be good enough. > >>> Personally, I'm just fine with the current command line behavior: >>> >>> $ qemu-img >>> qemu-img: Not enough arguments >>> Try 'qemu-img --help' for more information >>> >>> as 'qemu-img --help' tells you how to properly use the command, without >>> having to hand-hold you through the process. >> Hand holding feels way better than the coldness of the --help option.
Re: [Qemu-block] interactive qemu-img
> On Jul 30, 2018, at 3:54 PM, Nir Soffer wrote: > > On Mon, Jul 30, 2018 at 8:00 PM Programmingkid > wrote: > > > On Jul 30, 2018, at 11:09 AM, Eric Blake wrote: > > > > On 07/28/2018 08:22 PM, Programmingkid wrote: > >> I thought of a way to make qemu-img much more user-friendly. When the user > >> opens qemu-img without any arguments, we could present a prompt that > >> guides the user on making an image file. > >> This illustrates what I think should happen. > >> > >> Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): > >> qcow2 > >> Please enter a size (e.g. 100M, 10G): > >> 4G > >> Please enter a name: > >> WinXP.qcow2 > >> Creating image file...done > >> The interactive prompt would contain enough options to make a usable image > >> file. If the user wants to use some of the more advanced features of > >> qemu-img he or she would still need to use the command-line. > >> Would such a patch be welcomed? > > > > qemu-img is a command line tool, not a gui. Bloating it with a gui dialog > > box is probably not a wise idea. > There would be no gui dialog box. Qemu-img would still be a command-line > tool. The patch would be done in printf/scanf calls. > > > Personally, I'm just fine with the current command line behavior: > > > > $ qemu-img > > qemu-img: Not enough arguments > > Try 'qemu-img --help' for more information > > This is not user friendly, but unfortunately very common. > It can be improved by treating no arguments as --help, like git. This would save the user a step. > > > > as 'qemu-img --help' tells you how to properly use the command, without > > having to hand-hold you through the process. > Hand holding feels way better than the coldness of the --help option. > > User feeling that --help is too cold will be better served by management > system > like virt-manager or oVirt. Did you try one of these? I haven't but it is definitely an option. > > Nir Thank you.
Re: [Qemu-block] interactive qemu-img
On 07/30/2018 02:54 PM, Nir Soffer wrote: $ qemu-img qemu-img: Not enough arguments Try 'qemu-img --help' for more information This is not user friendly, but unfortunately very common. It can be improved by treating no arguments as --help, like git. I somewhat disagree that git is a good example. If '--help' occupies more than about 25 lines (a screenful on some default terminal sizes), the mere fact that you have to scroll to read it makes it less helpful than a 2-liner statement that lets you know "I couldn't do anything useful with your botched command line, please read the documentation and try again". 'git' behaving as 'git --help' outputs 42 lines, which fails my 'one screenful' test; and 'qemu-img --help' at 104 lines is definitely too verbose to be the default behavior when --help is not given. /me Wow - I can't believe I'm actually about to use this as an example, but: 'cvs' and 'cvs --help' is just 13 lines (except to stderr, when it should have been stdout), and gives enough hints on how to get more specific help on a particular topic. Great for the plain 'cvs' case; a bit more debatable on 'cvs --help' (the fact that you have to ask for help twice: once for the summary, again for the specific help, gets tedious). At any rate, getting command-line tools to have user-friendly behavior when insufficient arguments are supplied is an artform, and you'll find lots of bikeshed colors out there. And regardless of any opinions I've expressed above, this thread does point out that 104 lines for 'qemu-img --help' is long, and anything we can do to make that easier to digest may still be worthwhile. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-block] interactive qemu-img
On Mon, Jul 30, 2018 at 12:30:01PM -0400, Programmingkid wrote: > > > On Jul 30, 2018, at 11:09 AM, Eric Blake wrote: > > > > On 07/28/2018 08:22 PM, Programmingkid wrote: > >> I thought of a way to make qemu-img much more user-friendly. When the user > >> opens qemu-img without any arguments, we could present a prompt that > >> guides the user on making an image file. > >> This illustrates what I think should happen. > >> > >> Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): > >> qcow2 > >> Please enter a size (e.g. 100M, 10G): > >> 4G > >> Please enter a name: > >> WinXP.qcow2 > >> Creating image file...done > >> The interactive prompt would contain enough options to make a usable image > >> file. If the user wants to use some of the more advanced features of > >> qemu-img he or she would still need to use the command-line. > >> Would such a patch be welcomed? > > > > qemu-img is a command line tool, not a gui. Bloating it with a gui dialog > > box is probably not a wise idea. > There would be no gui dialog box. Qemu-img would still be a command-line > tool. The patch would be done in printf/scanf calls. > Even without a GUI, this would still add a not insignificant bloat and unnecessary complexity to qemu-img, that doesn't add to the core purpose of the tool. It is not that the idea of such a dialog-driven tool (command-line or otherwise) is without merit; it is that it would be better served as a wrapper around qemu-img rather than built into qemu-img. And it probably wouldn't belong as part of the QEMU codebase, either, but more like other management tools (e.g. libvirt) that wrap QEMU and add higher-level features like that. (One example of sorts, albeit of a GUI, is virt-manager. If you explore the storage management, you can create qemu images of various types). > > Personally, I'm just fine with the current command line behavior: > > > > $ qemu-img > > qemu-img: Not enough arguments > > Try 'qemu-img --help' for more information > > > > as 'qemu-img --help' tells you how to properly use the command, without > > having to hand-hold you through the process. > Hand holding feels way better than the coldness of the --help option.
Re: [Qemu-block] interactive qemu-img
On Mon, Jul 30, 2018 at 8:00 PM Programmingkid wrote: > > > On Jul 30, 2018, at 11:09 AM, Eric Blake wrote: > > > > On 07/28/2018 08:22 PM, Programmingkid wrote: > >> I thought of a way to make qemu-img much more user-friendly. When the > user opens qemu-img without any arguments, we could present a prompt that > guides the user on making an image file. > >> This illustrates what I think should happen. > >> > >> Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): > >> qcow2 > >> Please enter a size (e.g. 100M, 10G): > >> 4G > >> Please enter a name: > >> WinXP.qcow2 > >> Creating image file...done > >> The interactive prompt would contain enough options to make a usable > image file. If the user wants to use some of the more advanced features of > qemu-img he or she would still need to use the command-line. > >> Would such a patch be welcomed? > > > > qemu-img is a command line tool, not a gui. Bloating it with a gui > dialog box is probably not a wise idea. > There would be no gui dialog box. Qemu-img would still be a command-line > tool. The patch would be done in printf/scanf calls. > > > Personally, I'm just fine with the current command line behavior: > > > > $ qemu-img > > qemu-img: Not enough arguments > > Try 'qemu-img --help' for more information This is not user friendly, but unfortunately very common. It can be improved by treating no arguments as --help, like git. > > > > as 'qemu-img --help' tells you how to properly use the command, without > having to hand-hold you through the process. > Hand holding feels way better than the coldness of the --help option. > User feeling that --help is too cold will be better served by management system like virt-manager or oVirt. Did you try one of these? Nir
Re: [Qemu-block] interactive qemu-img
> On Jul 30, 2018, at 11:09 AM, Eric Blake wrote: > > On 07/28/2018 08:22 PM, Programmingkid wrote: >> I thought of a way to make qemu-img much more user-friendly. When the user >> opens qemu-img without any arguments, we could present a prompt that guides >> the user on making an image file. >> This illustrates what I think should happen. >> >> Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): >> qcow2 >> Please enter a size (e.g. 100M, 10G): >> 4G >> Please enter a name: >> WinXP.qcow2 >> Creating image file...done >> The interactive prompt would contain enough options to make a usable image >> file. If the user wants to use some of the more advanced features of >> qemu-img he or she would still need to use the command-line. >> Would such a patch be welcomed? > > qemu-img is a command line tool, not a gui. Bloating it with a gui dialog > box is probably not a wise idea. There would be no gui dialog box. Qemu-img would still be a command-line tool. The patch would be done in printf/scanf calls. > Personally, I'm just fine with the current command line behavior: > > $ qemu-img > qemu-img: Not enough arguments > Try 'qemu-img --help' for more information > > as 'qemu-img --help' tells you how to properly use the command, without > having to hand-hold you through the process. Hand holding feels way better than the coldness of the --help option.
Re: [Qemu-block] interactive qemu-img
On 07/28/2018 08:22 PM, Programmingkid wrote: I thought of a way to make qemu-img much more user-friendly. When the user opens qemu-img without any arguments, we could present a prompt that guides the user on making an image file. This illustrates what I think should happen. Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): qcow2 Please enter a size (e.g. 100M, 10G): 4G Please enter a name: WinXP.qcow2 Creating image file...done The interactive prompt would contain enough options to make a usable image file. If the user wants to use some of the more advanced features of qemu-img he or she would still need to use the command-line. Would such a patch be welcomed? qemu-img is a command line tool, not a gui. Bloating it with a gui dialog box is probably not a wise idea. Personally, I'm just fine with the current command line behavior: $ qemu-img qemu-img: Not enough arguments Try 'qemu-img --help' for more information as 'qemu-img --help' tells you how to properly use the command, without having to hand-hold you through the process. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
[Qemu-block] interactive qemu-img
I thought of a way to make qemu-img much more user-friendly. When the user opens qemu-img without any arguments, we could present a prompt that guides the user on making an image file. This illustrates what I think should happen. Please select a format (qcow, qcow2, raw, vdi, vhdx, vmdk, vpc, vvfat): qcow2 Please enter a size (e.g. 100M, 10G): 4G Please enter a name: WinXP.qcow2 Creating image file...done The interactive prompt would contain enough options to make a usable image file. If the user wants to use some of the more advanced features of qemu-img he or she would still need to use the command-line. Would such a patch be welcomed?
