So it was Xinerama causing it or a yet unknown reason?
So it was Xinerama causing it or a yet unknown reason?
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.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
I'd say it's a good candidate for a bug report. Either way something is incorrect here.
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.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
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.
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).
The text in the quote is talking from the exact problem I have (popping dialog box on another screen than parent).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.
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.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
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?
Thanks for the input!
I will look this up at next opportunity and will report.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
Bookmarks