screen number and modal dialogs

**high_flyer** · 19th April 2007, 20:42

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.

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** · 19th April 2007, 21:47

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** · 19th April 2007, 21:59

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...

**wysota** · 19th April 2007, 23:17

Originally Posted by high_flyer

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** · 20th April 2007, 10:21

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** · 20th April 2007, 10:26

Originally Posted by high_flyer

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** · 20th April 2007, 10:32

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** · 20th April 2007, 10:41

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** · 20th April 2007, 10:59

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** · 20th April 2007, 11:14

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** · 20th April 2007, 20:06

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.