[PyKDE] Qt shutting down the process/Python interpreter - necessary?

[Ingo Krabbe]

It is quite reasonable for Qt to break down when fatal error occure due
to an errorneous initializing of the whole system.  It's like pressing
the gas pedal of a car without ever turning the key first.  Since Qt has
quite complex initializing mechnisms which optimize the work during a
running program this behaviour increases debuggability and consistency.

It is no parameter of compiled programs that they should break down on
program errors, its just a reasonable parameter of Qt not to start in
wrong environments.  It is left to you to check for a server BEFORE
creating a QApplication as a client.

I also don't know where you want to put your "-qws" argument inside your
application.  Though this is possible this should in neither case be
acceptable style.  The QApplication class provides a constructor for
this operation and you should use that:

if QwsIsStarted():	# QwsIsStarted() is an own function that tests
			# for a server, see below.
	app = QApplication( argc, argv, QApplication::GuiClient )
else
	app = QApplication( argc, argv, QApplication::GuiServer )

As documented in the Qt Documentation:
-----------
QApplication::QApplication ( int & argc, char ** argv, Type type )
Constructs an application object with argc command line arguments in argv.

For Qt/Embedded, passing QApplication::GuiServer for type makes this application the server (equivalent to running with the -qws option). 
-----------

On the other hand if you want to use "-qws" as an option, why don't you
start a script that restarts your application with "-qws" if the
operation fails.

There are many solutions to the problem which all rely on your knowledge
of a server running.  You should think about a test function that I
called QwsIsStarted() as an example here.

BYE INGO

On Fri, Nov 08, 2002 at 12:26:54PM +0100, Michael Lauer wrote:
> Hi,
> 
> in Qt there are certain places, where exit() is called, for instance,
> if you construct a QPaintDevice before a QApplication, the process ends.
> 
> This behaviour - while perhaps being reasonable in a compiled language -
> seems truly inappropriate in the context of an interpretated interactive
> and dynamic environment such as the Python interpreter.
> 
> It would be much more useful if this would raise an exception, like,
> PyQtException, which we could catch and react appropriate - for
> instance, generating the application object and trying again.
> 
> It's especially bugging me in Qt/Embedded, where the offending exit()
> call is triggered, when you create a QApplication in client mode but
> no QWS server is running. It would be sufficient to just recreate the
> QApplication with the appropriate parameter (-qws), but I can't because
> my interpreter is being shutdown [see below] :(
> 
> ========================================================
> 
> mickey at gandalf:~/work/elan$ python
> Python 2.2.2 (#1, Oct 27 2002, 17:30:06) 
> [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import qtpe
> >>> try:                           
> ...  a=qtpe.QApplication([])
> ... except:
> ...  pass
> ... 
> QSocket::writeBlock: Socket is not open
> QSocket::writeBlock: Socket is not open
> QSocket::writeBlock: Socket is not open
> No Qt/Embedded server appears to be running.
> If you want to run this program as a server,
> add the "-qws" command-line option.
> mickey at gandalf:~/work/elan$ 
> 
> ========================================================
> 
> This behaviour is due to the following code:
> 
> ========================================================
> 
> void QWSDisplayData::waitForConnection()
> {
> #ifndef QT_NO_QWS_MULTIPROCESS
>     for ( int i = 0; i < 5; i++ ) {
> 	if ( csocket ) {
> 	    csocket->flush();
> 	    csocket->waitForMore(2000);
> 	}
> 	fillQueue();
> 	if ( connected_event )
> 	    return;
> 	usleep( 50000 );
>     }
> #else
>     if ( connected_event )
> 	return;
> #endif
>     qWarning("No Qt/Embedded server appears to be running.");
>     qWarning("If you want to run this program as a server,");
>     qWarning("add the \"-qws\" command-line option.");
>     exit(1);
> }
> 
> ========================================================
> 
> Now, my question... is there something I can do at python level
> or is there something we can do at PyQt level to change this behaviour?
> 
> Yours,
> 
> -- 
> :M:
> --------------------------------------------------------------------------
> Dipl.-Inf. Michael 'Mickey' Lauer  
> mickey at tm.informatik.uni-frankfurt.de 
>   Raum 10b - ++49 69 798 28358       Fachbereich Informatik und Biologie
> --------------------------------------------------------------------------
> 
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.gmd.de
> http://mats.gmd.de/mailman/listinfo/pykde
>