[Development] possible change in behavior: QGuiApplication::primaryScreen() can return null

Harri Porten porten at froglogic.com
Fri Mar 6 09:34:49 CET 2015


I see that the first decisive commit is already merged but I'd like to 
comment on it anyway:

On Mon, 2 Mar 2015, Rutledge Shawn wrote:

> It may be a surprise though, for some applications, that 
> QGuiApplication::primaryScreen() can return null in the case where there 
> is really no screen attached.  It’s a rare use case, but it’s possible 
> that some applications could crash if they are using that pointer at the 
> wrong time, without checking.  And there are also some platforms where a 
> dummy screen will normally exist even if no actual monitors are 
> connected.  It’s just that it doesn’t seem to be necessary to have one 
> on xcb, so we are trying to avoid needing to create one artificially. 
> It seems right to have the code modeling the real world: if there is 
> nothing on which you can view the graphical output of your application, 
> then there should not be a QScreen instance.
> Does anyone have any objection?

I would favor an "invalid" QScreen instance to be returned instead. At 
least from the public QGuiApplication API.

A function that "maybe" returns null on "some platforms" puts an onus on a 
diligent developer using this function. Thus work is created for everyone 
to cover a scenario that will happen for a very few in very seldom cases.

Our own software was not prepared for a similar case until last week: we 
relied on the xcb plugin returning an X11 Display pointer when querying it 
for "display". Until the first customer had build Qt without xlib 


PS: The documentation of the (internal) QPlatformWindow::screen() 
implementation would need updating too:


More information about the Development mailing list