Bug 564 – QApplication constructor should throw exception when X server connection fails

PySide Bugzilla Closed for New Bugs

PySide is now a Qt Add-on and uses the Qt Project's JIRA Bug Tracker instead of this Bugzilla instance. This Bugzilla is left for reference purposes.

Bug 564 - QApplication constructor should throw exception when X server connection fails

Summary:

QApplication constructor should throw exception when X server connection fails

Status:	CLOSED WONTFIX

Product:	PySide
Classification:	Unclassified
Component:	QtGui
Version:	HEAD
Platform:	All All

Importance:	P3 enhancement
Assigned To:	renato filho

URL:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2010-12-22 13:48 EET by Thomas Perl
Modified:	2011-01-06 16:25 EET (History)
CC List:	8 users (show)

See Also:

Attachments
Qt calling abort after a qFatal call (493 bytes, text/plain) 2010-12-22 15:35 EET, Hugo Parente Lima	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Thomas Perl 2010-12-22 13:48:23 EET

From the mailing list discussion:

Another situation where that happens is when you construct a
QApplication without $DISPLAY set:

$ export DISPLAY=
$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.

            from PySide.QtGui import QApplication
            app = QApplication([])

PySideApp: cannot connect to X server
$ echo $?
1

In this case, I think it would be good to have an exception at the
Python level, as this error is something that only happens when
$DISPLAY is not set, so catching the exception and dealing with it
(i.e. by printing a nice error message like "You do not have $DISPLAY
set.") makes more sense.

Some apps might even have two interfaces (one GUI and CLI) and the Python code
could determine which one to use by trying to construct a QApplication and
(failing that) starting the CLI interface instead.

It's not really a bug, but a "nice to have" feature, so I'm filing this as an
enhancement.

Comment 1 Hugo Parente Lima 2010-12-22 14:49:48 EET

And what to do if the DISPLAY is set but QApplication can't connect to the X
server?

Comment 2 Thomas Perl 2010-12-22 15:11:02 EET

(In reply to comment #1)
> And what to do if the DISPLAY is set but QApplication can't connect to the X
> server?

As the bug title says "when X server connection fails". Not setting DISPLAY is
just a convenient way of making sure that the X server connection fails. So if
DISPLAY is set, but the connection fails, there should be an error as well
(otherwise one could just say "if 'DISPLAY' in os.environ").

Comment 3 Hugo Parente Lima 2010-12-22 15:35:46 EET

Created attachment 202 [details]
Qt calling abort after a qFatal call

Because the only way of checking if the DISPLAY variable is valid is connecting
to it before calling QApplication and IMO it's a unnedded big overhead that
will affect startup time of all applications usign PySide.

We could install a message handler to throw a python exception every time a
qFatal() is called, but this is impossible because as show in the attached
example Qt always call abort() when qFatal is called, no matter what your
message handler do.

My vote is for WONTFIX due to technical issues

Comment 4 Matti Airas 2010-12-23 06:15:35 EET

(In reply to comment #3)
> Created an attachment (id=202) [details]
> Qt calling abort after a qFatal call
> 
> Because the only way of checking if the DISPLAY variable is valid is connecting
> to it before calling QApplication and IMO it's a unnedded big overhead that
> will affect startup time of all applications usign PySide.

Yes, I don't think a separte connection just for testing purposes would make
sense either, so I'm also voting for WONTFIX in this case.

How about the case of empty $DISPLAY then? Maybe that's nowadays a marginal
issue as well: average users won't be ssh'ing into machines and starting remote
X apps any longer, and those who do, can probably interpret the error messages
spat out by the C++ code.

I'm resolving this WONTFIX, after all. Thomas, my apologies for encouraging you
to file a bug only to have it close this way immediately afterwards. :-(

Comment 5 renato filho 2011-01-06 16:25:24 EET

released on beta3