32612 - make gtk nsScreenManager understand multiple monitors

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

Do as the summary says. 

This is really low priority compared to mac/win32 since not many X users have 
multiple monitors.

Comment 1

[Stuart Parmenter]

actually, you'll find WAY more people with multiple monitors on X than you will
on windows I would imagine, but yeah, i'll get to it someday :)

Comment 2

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 3

[Peter Trudelle]

moving to m18

Comment 4

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 5

[Christopher Blizzard (:blizzard)]

-> [e-mail]

Comment 6

[Christopher Blizzard (:blizzard)]

Attachment: first rough patch

Comment 7

[Christopher Blizzard (:blizzard)]

Adding my gtk-reviewing posse.

Comment 8

[Stuart Parmenter]

the first thing I notice is us linking against Xinerama, which a lot of people
probably don't have.  Autoconf goodness required.  i'll continue through this
patch in a few.

Comment 9

[Christopher Blizzard (:blizzard)]

Yeah, that's why I called it a rough patch.

In any case, libXinerama is actually a static library so we won't run into run
time problems on other machines for that reason.  There are a few things that I
need to fix in the code right now:

Add autoconf-fu to detect Xinerama on the system.
Add autoconf-fu to enable/disable Xinerama at build time.
Handle the case where Xinerama isn't running on the current display and fall
back to the standard gdk* calls.

I'll get to it in the next few days.

Comment 10

[Christopher Blizzard (:blizzard)]

Attachment: patch 2

Comment 11

[Christopher Blizzard (:blizzard)]

Attachment: patch that actually compiles

Comment 12

[Christopher Blizzard (:blizzard)]

OK.  This patch compiles with or without xinerama on the system.  It will also
run with or without Xinerama on a display.  I've tested all configurations. 
Looking for reviews!

Comment 13

[Mike Pinkerton (not reading bugmail)]

only thing is that mac/win optimize nsScreenManager::ScreenForRect for the
single monitor case (no need to loop, etc) since that is the 99% case. No big
deal, no one will probably notice, but just to be consistent.

if you fix that, r=pinkerton.

Comment 14

[Alec Flett]

sr=alecf

Comment 15

[Daniel (Leaf) Nunes]

r=leaf for the configure.in addition.

Comment 16

[Christopher Blizzard (:blizzard)]

Attachment: final patch with pink's suggestion

Comment 17

[Christopher Blizzard (:blizzard)]

Checked in.

Comment 18

[Adam D. Moss]

I'm interested; what does this actually GIVE us?  From
browsing the patch it looks like we try to favour the
screen with the greatest surface area.  Shouldn't this
simply be in the domain of the window manager rather than
having to care on a per-application basis?

Comment 19

[Christopher Blizzard (:blizzard)]

It does two things at the moment:

1) When the browser is near the edge of the screen menus that pop up won't hang
over the edge of the screen onto the monitor to the right.  This is most
definitely not the domain of the window manager

2) Dialogs that pop up don't pop up hanging over the edge of half way over two
monitors if you happen to have two.  In this case they always pop up on the left
most monitor which isn't optimal but can be fixed in the future.  At least the
infastructure is place to fix that now for linux, too.

Most window managers respect the location hints of the dialogs and never mess
with menus.  This patch doesn't change the location of standard browser windows
which is still managed by the WM.

Comment 20

[Chris P. Ross]

There is a bug in this patch.  Note bug #74870 for a discussion, and a
patch to fix blizzard's code added here.

Comment 21

[Kyle K.]

Attachment: X config file

I'm not sure if this is related to this bug or if I should open a new one, but I figured I'd start here.  Using the attached xorg.conf file, I run Firefox on the primary desktop (0,0) and Thunderbird on the secondary (0,1).  If I have Firefox running and click a link in Thunderbird, I get the following notice:

"Firefox is already running, but is not responding.  To open a new window, you must first close the existing Firefox process, or restart your system."

If I run both Thunderbird & Firefox on the same monitor, everything is fine.  Is there anyway to tell Thunderbird to look on all desktops for a running Firefox instance to open the URL in?

I'm running:

Firefox: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051202 Fedora/1.5-0.fc4 Firefox/1.5

Thunderbird: version 1.5 (20051201)

Fedora Core 4: Linux myhost.mydomain.com 2.6.14-1.1656_FC4 #1 Thu Jan 5 22:13:22 EST 2006 i686 i686 i386 GNU/Linux