screen number and modal dialogs

[high_flyer]

Hi,

I have the following problem:
I am developing a GUI system that will be used on a multi head system (4 screens) (oh, SUSE 10.1)
The problem I have is, that I have a modal dialog that I have to show, and it needs to be shown above the main widget.
The thing is, that if I start the main widget on screen 1 for example, the dialog will pop up on screen 0.
It will always popup on screen 0.
In order to see if I can do something about it, I started by retrieving the screen number of the main widget.
And no matter on which screen I start it, it returns that its on screen 0.:eek:
numScreens() returns 2 however (at the moment I am working on a dual head system)....

I thought that it will be enough to have the dialog child of the main widget, but its not.

Any ideas how can I force my modal dialog to popup on the same screen as my main widget?

Thanks.

[wysota]

This indeed is strange, as by default the window system should open all windows from the same application on the same screen. Do you use Xinerama? Do other applications behave the same way?

[high_flyer]

yes I must use Xinerama - if I want the desktop to span on all my screens.
I can't really say if other applications behave the same way - or let me put it this way - I haven't notices other applications to open windows not on the same screen...

Oh well... I'll find a work around...:rolleyes:

[wysota]

yes I must use Xinerama - if I want the desktop to span on all my screens.
I think you could have two separate screens (not combined into one).


I can't really say if other applications behave the same way - or let me put it this way - I haven't notices other applications to open windows not on the same screen...

Try running gimp, move it to the second screen and open some dialog from it. This will be one test. But then make another test - move the child dialog to the first screen and open a child dialog from the child dialog. Of course you'll need to find a proper set of dialogs to do that ;)

[high_flyer]

I think you could have two separate screens (not combined into one).
As far as I understand it - Xinerama will allow you to span your desktop on all the creens - no Xinerama = all creens are clones of one screen.
But if I am wrong - please let me know! :)

I will try the thing with gimp - good idea.
But that wont be before eveninig...

Thanks.

[wysota]

As far as I understand it - Xinerama will allow you to span your desktop on all the creens - no Xinerama = all creens are clones of one screen.
But if I am wrong - please let me know! :)


I have no idea. I never managed to have more than one screen be it with or without Xinerama. I just think that if there is a way of configuring more than one screen and that Xinerama is an option, then it should be able to use multiple screens without that option.

[high_flyer]

hmm - I looked around a bit, and it might be that you are right - that it is possible to have multiple not cloned screens - each as "stand alone" with out xinerama.
I need to read more though.
Thanks.

[high_flyer]

Hmm - at least from Qt docs, this should not have been a problem to start with:


int QX11Info::appCells ( int screen = -1 ) [static]

Returns the number of cells used by the application on the given screen.

The screen argument is an X screen number. Be aware that if the user's system uses Xinerama (as opposed to traditional X11 multiscreen), there is only one X screen. Use QDesktopWidget to query for information about Xinerama screens.

Which I did as posted before - and screenNumber() returns 0 on both screens,whereas numScreens() returns correctly 2.
Maybe a Qt bug?

[wysota]

According to the docs "correctly" should be "1", not "2", so if there is a bug, it's in numScreens(). The "gimp test" should shed some light on the case. If child windows are opened on the same screen as their parents, then something indeed may be wrong, but if they are opened "randomly", then I guess it's the way it should work. Besides, Qt should have nothing to do with choosing the screen to open the window on (at least not "by default").

[high_flyer]

According to the docs "correctly" should be "1", not "2", so if there is a bug, it's in numScreens().
Why is that?


int QDesktopWidget::numScreens () const

Returns the number of available screens.

See also primaryScreen().

And I have 2...


Besides, Qt should have nothing to do with choosing the screen to open the window on (at least not "by default").
Well not with choosing the screens, but delivering the right information about the location of the widget - and allowing to choose the screen on which it should live.
And (specially) under KDE I would expect this to work - since KDE is built on Qt.
But I will read some more and look around.

[high_flyer]

Ok, for the benefit of others who might run in to issues of that sort:
The reason I thought that its either Xinerama or clone mode is because under SUSE (which I am using) SaX2 gives only these two options.
So if you are under SUSE (currently I am on 10.1) you will have to edit your xorg.conf manually, so that the you have a "Device","Screen" and "Monitor" scetion for each screen you have.
At least with NVidia, which I use, there is an option "TwinView" which you have to comment out - and Xinerama ofcourse as well.

So now I have an X server running for each screen.
Obviously the above problem is gone but I still have to see how I will do this on the QuadView machine I am coding this for.
Its a Matrox Quad View card - not NVidia, and obviously it has no "TwinView" option.
But that is something that will have to wait for now.
At least I know what I will be looking for :)

Hope this is of use to someone.

[wysota]

So it was Xinerama causing it or a yet unknown reason?

[high_flyer]

Xinerama makes the whole desktop as one screen.
I think thats the reason why the screen number always returned 0, on both screens.
But the way I understand the docs, the screen number should return correctly even in xiberana mode.
Either I got it wrong, or Qt has a problem with this issue.

[wysota]

I'd say it's a good candidate for a bug report. Either way something is incorrect here.

[high_flyer]

Oh by the way - xinerama confuses gimp as well.
If I start gimp on screen 1 - all the other dialogs it wil open on screen 0.

[wysota]

So it looks like the natural behaviour and the problem seems to be that Qt returns an incorrect number of screens or sth like that.

[high_flyer]

Well, yes and no.
As far as I understand the docs, Qt should return the number of physical screens, regardles if this is a viratual desktop (xinerama) or two desktops, as you can see in the illustration in the DesktopWidget docs.
Besides, the docs text it self makes no conditions on when numScreens() should return one screen (for xinerama) and N screens when not using xinerama (or virtual desktop).


All windows opened in the context of the application should be constrained to the boundaries of the primary screen; for example, it would be inconvenient if a dialog box popped up on a different screen, or split over two screens.

The text in the quote is talking from the exact problem I have (popping dialog box on another screen than parent).
So Qt is supposed to allow control over this situation, and allow the user to target physical screens on a virtual desktop - but it doesn't - not in the case I posed in this thread at least.

[hvengel]

Having done some work that involved knowing what physical screen my dialog was on I have learned something about how this works. There are also some misconceptions in this thread that I might be able to address.

First if you make a call to QDesktopWidget::screenNumber(..) in an objects constructor it will always return 0 even if the object is not on screen 0; at least with Qt3. I have not tested this with Qt4. You must make this call only after the dialog is initialized to get a correct result on a multi-screen system.

Second this does work on an Xinerama machine in that numScreens will return 2 on a dual screen setup and screenNumber() will return the correct result if it is not called in the constructor for the object (IE. you will get a 1 if you are on the second display).

And lastly Qt is xinerama aware if it is configured correctly when it is built. If you look in the Qt code that implements the QDesktopWidget functionality , I looked at this code when figuring out how QDesktopWidget::screenNumber() worked, you will see that it has conditional compilation setup to do things differently for a xinerama aware build. So perhaps the systems in question do not have a correctly configured Qt installation?

[high_flyer]

Thanks for the input!
I will look this up at next opportunity and will report.