On Fri, Jul 26, 2013 at 05:58:25AM -0000, Alberto Mardegan wrote:
> > Why did you stop using getopt in favour of custom option parsing? I quite
> > liked the use of a proper API there.
>
> The "proper API" in Qt is QCoreApplication::arguments(); using getops doesn't buy us much, and would need converting all the params to QString.
It's not really an API though. The QApplication page even talks about
using argv so they clearly do recognise that you might want to do this.
Using getopt buys us the fact that it's a standard interface for parsing
which is robust and well-tested. In this case it also means that
--option foo=bar and --option=foo-bar work.
I don't insist though, so if you do insist on your solution then fine.
If you do, there's a segfault if you don't have an = in the option
argument though, so please fix that.
On Fri, Jul 26, 2013 at 05:58:25AM -0000, Alberto Mardegan wrote: n::arguments( ); using getops doesn't buy us much, and would need converting all the params to QString.
> > Why did you stop using getopt in favour of custom option parsing? I quite
> > liked the use of a proper API there.
>
> The "proper API" in Qt is QCoreApplicatio
It's not really an API though. The QApplication page even talks about
using argv so they clearly do recognise that you might want to do this.
Using getopt buys us the fact that it's a standard interface for parsing
which is robust and well-tested. In this case it also means that
--option foo=bar and --option=foo-bar work.
I pushed a branch which uses getopt_long() to
lp:~laney/ubuntu-system-settings/plugin-invocation-getopt-long.
I don't insist though, so if you do insist on your solution then fine.
If you do, there's a segfault if you don't have an = in the option
argument though, so please fix that.
--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]