Qt-interest Archive, August 2007
Options parsing and GUI/Non-Gui QApplication
Message 1 in thread
Hi,
i seek a workaround for the following problem:
My app is supposed to run either in GUI or non-GUI mode depending on the
commandline options. And as there are more commandline options than this
single one i would like to use an options parser system like getopt_long or
boost::program_options and i want to be able to reject wrong options.
The problem is that i don't see any way to have my options handling completely
automated via an option parsing mechanism _and_ have Qt/X11 specific options
[which are those handled by QApplication].
If i parse options before creating the QApplication object there is the
problem that some Qt/X11 specific options might still be in the arguments and
i would have to manually take care of these [so that they don't get detected
as wrong arguments].
So i tried to think of another way:
- make a copy of the original argc and argv
- create a non-GUI QApplication with original argc/argv
- parse my options [on now modified original argc/argv]
- if GUI app:
- destroy QApplication object
- create new GUI QApplication with copy of original argc/argv
But this doesn't work correctly either because as the first QApplication
object is created as a non-GUI app the Qt/X11 specific options do not get
removed from the original argc/argv :( So then my option parsing still
encounters these options and reports errors.. Back to the start..
Did i miss something obvious?
Regards,
Flo
--
[ signature omitted ]
Message 2 in thread
Am Mittwoch 01 August 2007 01:40:00 schrieb Florian Schmidt:
> Hi,
>
> i seek a workaround for the following problem:
>
> My app is supposed to run either in GUI or non-GUI mode depending on the
> commandline options. And as there are more commandline options than this
> single one i would like to use an options parser system like getopt_long or
> boost::program_options and i want to be able to reject wrong options.
>
> The problem is that i don't see any way to have my options handling
> completely automated via an option parsing mechanism _and_ have Qt/X11
> specific options [which are those handled by QApplication].
>
> If i parse options before creating the QApplication object there is the
> problem that some Qt/X11 specific options might still be in the arguments
> and i would have to manually take care of these [so that they don't get
> detected as wrong arguments].
>
> So i tried to think of another way:
>
> - make a copy of the original argc and argv
> - create a non-GUI QApplication with original argc/argv
> - parse my options [on now modified original argc/argv]
> - if GUI app:
> - destroy QApplication object
> - create new GUI QApplication with copy of original argc/argv
>
> But this doesn't work correctly either because as the first QApplication
> object is created as a non-GUI app the Qt/X11 specific options do not get
> removed from the original argc/argv :( So then my option parsing still
> encounters these options and reports errors.. Back to the start..
>
> Did i miss something obvious?
>
> Regards,
> Flo
Hi Flo.
I ran into this problem some time ago.
I worked around it by a scanning the options for the parameter which switches
between gui-mode and non-gui-mode, this is done in a simple loop.
After that i create the respective QApplication object and let it take its
options. Than i do the getopt parsing, ignoring the parameter handled in the
first step.
HIH
....Volker
--
[ signature omitted ]
Message 3 in thread
Hi all,
> > Did i miss something obvious?
What about the "GUIenabled" parameter of QApplication::QApplication()?
QApplication::QApplication ( int & argc, char ** argv, bool GUIenabled )
Set GUIenabled to false for programs without a graphical user interface
that should be able to run without a window system.
On X11, the window system is initialized if GUIenabled is true. If
GUIenabled is false, the application does not connect to the X server.
On Windows and Macintosh, currently the window system is always
initialized, regardless of the value of GUIenabled.
There is an example on that in the docs...
\Ralf
--
[ signature omitted ]
Message 4 in thread
On Friday 03 August 2007, Ralf Neubersch wrote:
> Hi all,
>
> > > Did i miss something obvious?
>
> What about the "GUIenabled" parameter of QApplication::QApplication()?
>
> QApplication::QApplication ( int & argc, char ** argv, bool GUIenabled )
>
> Set GUIenabled to false for programs without a graphical user interface
> that should be able to run without a window system.
>
> On X11, the window system is initialized if GUIenabled is true. If
> GUIenabled is false, the application does not connect to the X server.
> On Windows and Macintosh, currently the window system is always
> initialized, regardless of the value of GUIenabled.
>
> There is an example on that in the docs...
The problem is that QApplication parses options differently when either
GUIenabled is set or not. Also QApplication has to be created before i can
parse my options because there might still be some Qt-specific options on the
commandline.. [see my original post]
Regards,
Flo
--
[ signature omitted ]
Message 5 in thread
Why bother with step 2 (create a non-GUI QApplication with original
argc/argv)? Why not just create your QApplication (GUI or non-GUI)
depending on what you parsed in step 3?
-----Original Message-----
From: Florian Schmidt [mailto:mista.tapas@xxxxxxx]
Sent: Tuesday, July 31, 2007 16:40
To: qt-interest@xxxxxxxxxxxxx
Subject: Options parsing and GUI/Non-Gui QApplication
Hi,
i seek a workaround for the following problem:
My app is supposed to run either in GUI or non-GUI mode depending on the
commandline options. And as there are more commandline options than this
single one i would like to use an options parser system like getopt_long
or
boost::program_options and i want to be able to reject wrong options.
The problem is that i don't see any way to have my options handling
completely
automated via an option parsing mechanism _and_ have Qt/X11 specific
options
[which are those handled by QApplication].
If i parse options before creating the QApplication object there is the
problem that some Qt/X11 specific options might still be in the
arguments and
i would have to manually take care of these [so that they don't get
detected
as wrong arguments].
So i tried to think of another way:
- make a copy of the original argc and argv
- create a non-GUI QApplication with original argc/argv
- parse my options [on now modified original argc/argv]
- if GUI app:
- destroy QApplication object
- create new GUI QApplication with copy of original argc/argv
But this doesn't work correctly either because as the first QApplication
object is created as a non-GUI app the Qt/X11 specific options do not
get
removed from the original argc/argv :( So then my option parsing still
encounters these options and reports errors.. Back to the start..
Did i miss something obvious?
Regards,
Flo
--
[ signature omitted ]
Message 6 in thread
On Wednesday 01 August 2007, Jones, Torrin A (US SSA) wrote:
> Why bother with step 2 (create a non-GUI QApplication with original
> argc/argv)? Why not just create your QApplication (GUI or non-GUI)
> depending on what you parsed in step 3?
Becauseto decide whether i need a GUI or non-GUI qapp, i need to parse my
options. But i don't want to see Qt/X11-specific options, and as Qt doesn't
offer any way to remove the Qt/X11-specific options without constructing a
QApplication....
So:
- I need to create a QApplication object before parsing my options
- But before parsing my options i don't know what kind of QApplication to use
A fix would be for the QApplication constructor to remove Qt/X11 specific
options even when a non GUI qapp is constructed..
Flo
>
> -----Original Message-----
> From: Florian Schmidt [mailto:mista.tapas@xxxxxxx]
> Sent: Tuesday, July 31, 2007 16:40
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Options parsing and GUI/Non-Gui QApplication
>
>
>
> Hi,
>
> i seek a workaround for the following problem:
>
> My app is supposed to run either in GUI or non-GUI mode depending on the
>
> commandline options. And as there are more commandline options than this
>
> single one i would like to use an options parser system like getopt_long
> or
> boost::program_options and i want to be able to reject wrong options.
>
> The problem is that i don't see any way to have my options handling
> completely
> automated via an option parsing mechanism _and_ have Qt/X11 specific
> options
> [which are those handled by QApplication].
>
> If i parse options before creating the QApplication object there is the
> problem that some Qt/X11 specific options might still be in the
> arguments and
> i would have to manually take care of these [so that they don't get
> detected
> as wrong arguments].
>
> So i tried to think of another way:
>
> - make a copy of the original argc and argv
> - create a non-GUI QApplication with original argc/argv
> - parse my options [on now modified original argc/argv]
> - if GUI app:
> - destroy QApplication object
> - create new GUI QApplication with copy of original argc/argv
>
> But this doesn't work correctly either because as the first QApplication
>
> object is created as a non-GUI app the Qt/X11 specific options do not
> get
> removed from the original argc/argv :( So then my option parsing still
> encounters these options and reports errors.. Back to the start..
>
> Did i miss something obvious?
>
> Regards,
> Flo
--
[ signature omitted ]
