Re: [Qemu-block] interactive qemu-img

[Programmingkid]

> On Jul 30, 2018, at 3:55 PM, Jeff Cody <address@hidden> wrote:
> 
> On Mon, Jul 30, 2018 at 12:30:01PM -0400, Programmingkid wrote:
>> 
>>> On Jul 30, 2018, at 11:09 AM, Eric Blake <address@hidden> 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.
>>>> <after user double-clicks on qemu-img...>
>>>> 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.