Re: [PATCH v2 3/3] softmmu/vl: Deprecate the -sdl and -curses option

[Thomas Huth <thuth@redhat.com>]

On 02/09/2021 12.58, Daniel P. Berrangé wrote:
> On Thu, Sep 02, 2021 at 12:51:02PM +0200, Thomas Huth wrote:
>> On 31/08/2021 15.53, Paolo Bonzini wrote:
>>> As an alternative, you may want to turn it into "-display sdl" rather
>>> than poke at dpy. This isn't much more code, but it keeps the shortcut
>>> isolated within a single "case". This follows a lot of recently cleaned
>>> up command line parsing code such as -no-hpet, -enable-kvm, -smp etc.
>>>
>>> In the end (spoiler alert for my upcoming KVM Forum presentation—slides
>>> are already on sched.com <http://sched.com> :)) what really produces
>>> complexity is the lack of isolation/modularity. As long as UI code
>>> doesn't care about command line parsing, and command line parsing
>>> doesn't care about global variables from all over the place, the cost of
>>> shortcuts is so small that it may tilt in favor of keeping them.
>>
>> Honestly, I'd rather like to see them removed in the end. Our user interface
>> is so terribly inconsistent here that I think that these options are rather
>> confusing for the users than helpful. For example, why do we have -sdl and
>> -curses, but no -gtk ? And as a normal user, I'd also always wonder what's
>> the difference between "-display sdl" and "-sdl", since the difference in
>> the amount of characters that you have to type here is not that much that it
>> justifies the shortcut option. So IMHO let's rather clean this up completely
>> than dragging the shortcut options along forever.
> 
> There's also the elephant in the room "-vnc" which has never been mapped
> into -display, but which is also one of the most widely used options for
> display backends :-(

Yeah, for -vnc, it likely makes sense to keep the shortcut since it's in 
wide use and also takes additional parameters ... but -sdl and -curses? They 
are IMHO rather niche, and don't take additional parameters, so it should be 
ok to mark them as deprecated. We can still reconsider in case anybody 
complains about the deprecation later.

  Thomas