[Development] possible change in behavior: QGuiApplication::primaryScreen() can return null
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