Bug 4275 - tlclient and vncviewer should start on correct screen even in multi screen configurations
Summary: tlclient and vncviewer should start on correct screen even in multi screen co...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: 3.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.0.0
Assignee: Pierre Ossman
URL:
Keywords: hean01_tester
: 4337 4363 (view as bug list)
Depends on:
Blocks: 4372
  Show dependency tree / graph
 
Reported: 2012-04-30 14:38 CEST by Peter Åstrand
Modified: 2012-11-28 12:27 CET (History)
2 users (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Peter Åstrand cendio 2012-04-30 14:38:38 CEST 
Dual monitor setup, Fedora 14. Second monitor "active", ie using terminal there, mouse is there. If I then run "tlclient" from the terminal, the GUI starts up on that second screen. However, If I run "tlclient demo.thinlinc.com", the GUI pops up on the primary monitor instead. If I add "-a", then it works correctly, so clearly this is a problem with the "simple mode".
Comment 1 Peter Åstrand cendio 2012-06-14 11:32:32 CEST 
It has to do with the window size. This crazy patch "fixes" the problem:

--- tlclient_mainwindow.cc	(revision 25311)
+++ tlclient_mainwindow.cc	(arbetskopia)
@@ -1538,7 +1538,9 @@
     output->position(0, y);
 
     /* Adjust window size */
-    size(w(), output->y() + output->h());
+    int height = output->y() + output->h();
+    if (height < 207) height = 207;
+    size(w(), height);

See also http://www.fltk.org/str.php?L2773 .
Comment 2 Peter Åstrand cendio 2012-06-20 12:29:44 CEST 
*** Bug 4337 has been marked as a duplicate of this bug. ***
Comment 3 Peter Åstrand cendio 2012-06-20 12:31:52 CEST 
Generalized bug; tlclient should start on the correct screen on all platforms, even with multiple monitors. This includes different versions of OS X, Windows and X11 desktops.
Comment 4 Peter Åstrand cendio 2012-06-20 13:44:55 CEST 
Windows part fixed in 25345, other platforms remains.
Comment 5 Peter Åstrand cendio 2012-06-20 14:13:03 CEST 
Note: The tester needs to test --loop as well.
Comment 6 Peter Åstrand cendio 2012-06-21 15:41:34 CEST 
Extending this bug to cover the start of vncviewer as well. It should start on the screen where the login window (tlclient) is *currently* located.
Comment 7 Peter Åstrand cendio 2012-06-21 16:10:08 CEST 
(In reply to comment #6)
> Extending this bug to cover the start of vncviewer as well. It should start on
> the screen where the login window (tlclient) is *currently* located.

Fixed for Windows in 25382, other platforms remains.
Comment 8 Peter Åstrand cendio 2012-06-26 14:06:44 CEST 
Although we are not currently using the "mouse" functions of screen_xywh, this is a reminder that they are currently broken. See:

http://www.fltk.org/str.php?L2857
Comment 9 Peter Åstrand cendio 2012-06-26 14:40:38 CEST 
tlclient centering on X11 fixed in 25391.
Comment 10 Peter Åstrand cendio 2012-06-27 09:05:06 CEST 
Also, tlclient must use the correct screen when determining the session size ("Current" and "Near"). We cannot assume that all monitors have the same resolution.
Comment 11 Peter Åstrand cendio 2012-06-27 09:21:54 CEST 
(In reply to comment #10)
> Also, tlclient must use the correct screen when determining the session size
> ("Current" and "Near"). We cannot assume that all monitors have the same
> resolution.

Fixed in 25394. The tester should try moving the tlclient main window between monitors during the login process.
Comment 12 Pierre Ossman cendio 2012-07-19 13:10:30 CEST 
*** Bug 4363 has been marked as a duplicate of this bug. ***
Comment 13 Peter Åstrand cendio 2012-08-02 13:27:07 CEST 
With X11, the behaviour is quite nice now. As far as I can tell, there are only two bugs left:

1) The vncviewer window will open up on the monitor where you have the mouse pointer (Fedora 14, XFCE), rather on the one where the tlclient GUI is located. Normally, this is not a problem, but it might be if you have moved the mouse to another screen while tlclient is logging in. I think this can be solved by telling vncviewer which position on the (combined) screen it should use. The only problem with that is that by specifying a requested position, the window manager (which times "knows best") cannot decide on it's own. As far as I know, there's no mechanism to indicate that you want the window to appear on a certain screen, without specifying the position. After all, the idea with Xinerama is to combine all screens into one surface. The only things I can think if would be to use either ICCCM "window groups" (
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.11), or WM_TRANSIENT_FOR, but I have no idea if this works. Also, I'm not sure this is such a big problem after all. 

2) The vncviewer window will open up on the virtual desktop which is currently active. I believe this can be solved by setting/changing _NET_WM_DESKTOP.
Comment 14 Peter Åstrand cendio 2012-08-02 14:17:32 CEST 
We don't know much about OS X yet, but it seems to have a virtual desktop implementation (called Spaces earlier, called Desktops in 10.7 / Mission Control). It is possible to assign applications to a certain Space using the dock, see: http://mattgemmell.com/2011/07/27/using-spaces-on-os-x-lion/. I haven't found any API for this, though. NSWindow has a "setCollectionBehavior", but it can only select between all/one desktop; not a particular one.
Comment 15 Peter Åstrand cendio 2012-08-02 14:33:21 CEST 
(In reply to comment #14)
> We don't know much about OS X yet, but it seems to have a virtual desktop
> implementation (called Spaces earlier, called Desktops in 10.7 / Mission
> Control). It is possible to assign applications to a certain Space using the
> dock, see: http://mattgemmell.com/2011/07/27/using-spaces-on-os-x-lion/. I
> haven't found any API for this, though. NSWindow has a "setCollectionBehavior",
> but it can only select between all/one desktop; not a particular one.

http://stackoverflow.com/questions/7458353/cocoa-programmatically-adding-an-application-to-all-spaces has some information. This one looks nice:

http://stackoverflow.com/questions/2305491/applescript-opening-an-app-in-space-number-n

...if it wouldn't be for this comment:

Note that in OS X 10.7 the "spaces preferences" object is gone again – Robin Dec 31 '11 at 12:05

Aha! There's an undocumented function called CGSMoveWorkspaceWindowList which does what we want. See: 
http://stackoverflow.com/questions/2308820/how-can-i-programatically-move-one-terminal-app-window-to-another-space

I guess if we want to implement support for this, and _NET_WM_DESKTOP, we would need another vncviewer command line option, similar to -Maximize.
Comment 16 Peter Åstrand cendio 2012-08-14 12:34:15 CEST 
We have decided that we should try to make vncviewer appear on the correct monitor. However, caring about virtual desktops will have to wait. Will be handled on separate bug.
Comment 17 Peter Åstrand cendio 2012-08-14 12:35:53 CEST 
(In reply to comment #16)
> However, caring about virtual desktops will have to wait. Will be
> handled on separate bug.

Bug 4372.
Comment 18 Peter Åstrand cendio 2012-08-27 11:43:54 CEST 
(In reply to comment #16)
> We have decided that we should try to make vncviewer appear on the correct
> monitor.

Fixed in r25652. However, Pierre reports that there's an issue with the fullscreen mode, thus we are keeping this bug open. Will also test more on X11 and Mac.
Comment 20 Peter Åstrand cendio 2012-09-04 11:45:44 CEST 
When it comes to testing, there's a lot of combinations that needs to be tested. Here's an idea of how this could be structured:

Test with starting client on non-primary screen, switch pointer+focus
to primary screen during login. Make sure client starts on non-primary
screen. FS=Fullscreen, AM=All monitors. 

                       800x600    Current    NearCurrent    	
Windows		       
Windows/FS	       
Windows/AM		       
Windows/FS/AM
Mac OS X
Mac OS X/FS
Mac OS X/AM
Mac OS X/FS/AM
X11/Metacity	       
X11/Metacity/FS	       
X11/Metacity/AM
X11/Metacity/FS/AM
X11/Ubuntu	       
X11/Ubuntu/FS
X11/Ubuntu/AM	       
X11/Ubuntu/FS/AM
X11/XFCE	       	
X11/XFCE/FS
X11/XFCE/AM	       	
X11/XFCE/FS/AM
Comment 23 Pierre Ossman cendio 2012-09-12 13:17:37 CEST 
We'd like a windowed vncviewer to show up on a single monitor, regardless of the size of the session. This means we need to adjust the size and not just the position.

One related issue is making sure that the title bar falls outside the monitor, making it difficult to move the window. The behaviour of this varies:

 - Windows: Will make sure a window is fully inside a single monitor. Will however not compensate for any panel, which can result in the title bar being obscured.

 - OS X: Will make sure a window is fully inside a single, and make sure it is not covered by the panel.

 - X11: Varies depending on window manager. Metacity (and derivatives) have a lot of rules to make sure nothing obscures the window. Other ones will simply place it where requested.


A safe approach should be to use the same logic as when we compute a "work area" sized session.
Comment 24 Pierre Ossman cendio 2012-09-12 13:47:27 CEST 
Fixed in r25793.
Comment 25 Peter Åstrand cendio 2012-09-25 16:10:05 CEST 
I believe this bug is finished now. Note: I'm reporting all my multi monitor hours on this bug.
Comment 26 Henrik Andersson cendio 2012-10-02 12:57:29 CEST 
(In reply to comment #20)
> When it comes to testing, there's a lot of combinations that needs to be
> tested. Here's an idea of how this could be structured:
> 
> Test with starting client on non-primary screen, switch pointer+focus
> to primary screen during login. Make sure client starts on non-primary
> screen. FS=Fullscreen, AM=All monitors. 
> 
>                        800x600    Current    NearCurrent        
> Windows               
> Windows/FS           
> Windows/AM               
> Windows/FS/AM
> Mac OS X
> Mac OS X/FS
> Mac OS X/AM
> Mac OS X/FS/AM
> X11/Metacity           
> X11/Metacity/FS           
> X11/Metacity/AM
> X11/Metacity/FS/AM
> X11/Ubuntu           
> X11/Ubuntu/FS
> X11/Ubuntu/AM           
> X11/Ubuntu/FS/AM
> X11/XFCE               
> X11/XFCE/FS
> X11/XFCE/AM               
> X11/XFCE/FS/AM

All tests are performed by starting the tlclient on the secondary monitor
and while logon focus of windows on the primary monitor is performed,
x means the test passed, number references the problem description below
the table.

           FS  AM   800x600  Current  Work area
Windows                x        x         x
            x          1        1         1
            x   x      x        x         1
Mac OSX 2)             x        x         x
            x          x        x         x
            x   x      x        x         3
Linux XFCE             x        x         x
            x          1        1         1
            x   x      x        x         x
Metacity               x        x         x
            x          x        x         x
            x   x      x        x         x

1) Fullscreen started on primary monitor (only)

2) tlclient main window is always opened on primary monitor
   eg. screen with dock even if started from desktop shortcut
   on the other screen.

3) Uses both monitors but, the primary monitor is black and
   is not accessible as a desktop from session nor from the 
   local host.
Comment 27 Peter Åstrand cendio 2012-10-03 10:42:58 CEST 
> 1) Fullscreen started on primary monitor (only)

Windows part fixed in cenbuild 25947, should work in next build. 


> 2) tlclient main window is always opened on primary monitor
>    eg. screen with dock even if started from desktop shortcut
>    on the other screen.

We have no support for this, I'm not even sure it's possible. 


> 3) Uses both monitors but, the primary monitor is black and
>    is not accessible as a desktop from session nor from the 
>    local host.

According to Ossman, this was fixed on bug 4229. 

Checking out problem 1 with XFCE remains.
Comment 28 Peter Åstrand cendio 2012-10-03 10:47:41 CEST 
>1) Fullscreen started on primary monitor (only)
... 
> Checking out problem 1 with XFCE remains.

Cannot reproduce with XFCE xfwm4-4.8.3-1.el6.x86_64 on CentOS 6. Which platform did you use?
Comment 29 Henrik Andersson cendio 2012-10-03 10:52:37 CEST 
(In reply to comment #28)
> >1) Fullscreen started on primary monitor (only)
> ... 
> > Checking out problem 1 with XFCE remains.
> 
> Cannot reproduce with XFCE xfwm4-4.8.3-1.el6.x86_64 on CentOS 6. Which platform
> did you use?

I tested this on my Fedora 16 machine with xfce session and wm
xfwm4-4.8.3-1.fc16.i686
Comment 30 Peter Åstrand cendio 2012-10-04 09:04:17 CEST 
(In reply to comment #29)

> I tested this on my Fedora 16 machine with xfce session and wm
> xfwm4-4.8.3-1.fc16.i686

After some more testing, the conclusion is that XFCE is broken. The client will always open up on the *opposite* monitor, since XFCE apparently is confused about the screen numbering. I've created https://bugzilla.xfce.org/show_bug.cgi?id=9351 for this; not much more we can do at this point.
Comment 31 Henrik Andersson cendio 2012-10-08 12:54:40 CEST 
Redid the test using build 3675

          FS SM   800x600  Current  Workarea  Allmon
Windows   
                     x        1         x        x
           x         x        x         x        x
           xx        x        x         2        x
            x        x        x         x        x
Mac OSX   
                     x        x         x        x
           x         x        x         3        x
           xx        x        x         x        x
            x        x        x         x        x
XFCE   
                     x        x         x        x
           x         4        4         4        4
           xx        x        x         x        x
            x        x        x         x        x

Metacity   
                     x        x         x        x
           x         x        x         x        x
           xx        x        x         x        x
            x        x        x         x        x

1) Window not maximized eg titlebar lays outside screen, on Mac on the other hand it looks maximized, should probably be maximized due to the position outside of screen feels strange.

2) Starts fullscreen on primary monitor, this is a regression since the previous test.

3) dead space over/under when started on secondary monitor which does not have anything on desktop to consider, looks like the hight is titlebar height/2.

4) Starts fullscreen on primary monitor
Comment 32 Peter Åstrand cendio 2012-10-08 16:15:26 CEST 
(In reply to comment #31)

> 1) Window not maximized eg titlebar lays outside screen, on Mac on the other
> hand it looks maximized, should probably be maximized due to the position
> outside of screen feels strange.

Pierre is checking this. 


> 2) Starts fullscreen on primary monitor, this is a regression since the
> previous test.

The reason seems to be the -Maximize argument. When used, fullscreen only covers primary monitor, even though -fullscreenallmonitors=1. I'm surprised this worked before. To me, it seems very difficult (impossible) to support this case. I think either vncviewer should ignore -maximize in this case, or tlclient should avoid passing this combination. Hmm, I could try moving the call to maximizeWindow/SetWindowPlacement so that that happens before the geometry/fullscreen stuff. 



> 3) dead space over/under when started on secondary monitor which does not have
> anything on desktop to consider, looks like the hight is titlebar height/2.

Could be a variant if 1). 


> 4) Starts fullscreen on primary monitor

XFCE bug as pointed out on comment #30. Wont fix.
Comment 33 Pierre Ossman cendio 2012-10-10 15:01:30 CEST 
(In reply to comment #31)
> 
> 1) Window not maximized eg titlebar lays outside screen, on Mac on the other
> hand it looks maximized, should probably be maximized due to the position
> outside of screen feels strange.
> 

r25973.
Comment 34 Pierre Ossman cendio 2012-10-11 12:23:48 CEST 
(In reply to comment #31)
> 
> 2) Starts fullscreen on primary monitor, this is a regression since the
> previous test.
> 

Fixed in 25984.
Comment 35 Pierre Ossman cendio 2012-10-11 14:31:41 CEST 
(In reply to comment #31)
> 
> 3) dead space over/under when started on secondary monitor which does not have
> anything on desktop to consider, looks like the hight is titlebar height/2.
> 

NOTABUG. Workspace is the useful area in maximized mode, meaning it needs to compensate for the title bar.
Comment 36 Henrik Andersson cendio 2012-10-15 09:45:13 CEST 
I have verified the last changes

1) Still a problem on Windows platoform, window+deco is bigger then monitor
   and the windows has offset outside of screen (top-left), this kind of look
   strange.

   On Mac OSX which also the codechange should affect all looks ok, window
   is nicly fitted into screen.

2) Fixed
Comment 37 Pierre Ossman cendio 2012-10-15 14:31:28 CEST 
(In reply to comment #36)
> I have verified the last changes
> 
> 1) Still a problem on Windows platoform, window+deco is bigger then monitor
>    and the windows has offset outside of screen (top-left), this kind of look
>    strange.
> 

r26002.
Comment 38 Henrik Andersson cendio 2012-10-16 10:49:56 CEST 
Just tried the latest build 3686 and finally the last issue is fixed,
lets do a full retest once again :)
Comment 39 Henrik Andersson cendio 2012-10-17 12:55:07 CEST 
Started to retest but, failed using build 3688, a regression in last commit
makes the Workarea test on gnome fail and scrollbars are added.
Comment 40 Pierre Ossman cendio 2012-10-17 16:18:35 CEST 
(In reply to comment #39)
> Started to retest but, failed using build 3688, a regression in last commit
> makes the Workarea test on gnome fail and scrollbars are added.

r26021.
Comment 41 Henrik Andersson cendio 2012-10-18 09:13:40 CEST 
I stumble upon a new oddity testing latest linux client/server build 3689,
this might not be a regression just a miss in expected behavior.

When starting a session using FS AM and "All monitors" session size, the
server side is initiated with 2 displays reflecting client displays, 
however if one starts with same settings except with FS flag the serverside
will only have one VNC-0 display active with a size of "All monitors" and
going into fullscreen using F8 menu will not activate VNC-1 and change display
sizes to reflect client monitors.
Comment 42 Henrik Andersson cendio 2012-10-18 09:46:51 CEST 
(In reply to comment #41)
> I stumble upon a new oddity testing latest linux client/server build 3689,
> this might not be a regression just a miss in expected behavior.
> 
> When starting a session using FS AM and "All monitors" session size, the
> server side is initiated with 2 displays reflecting client displays, 
> however if one starts with same settings except with FS flag the serverside
> will only have one VNC-0 display active with a size of "All monitors" and
> going into fullscreen using F8 menu will not activate VNC-1 and change display
> sizes to reflect client monitors.

Update, this works if i enable dynamic resize, then i get two active screens serverside...
Comment 43 Pierre Ossman cendio 2012-10-18 12:45:01 CEST 
Intended behaviour. We don't mess with the server layout unless dynamic resize is active.
Comment 44 Henrik Andersson cendio 2012-10-23 09:02:23 CEST 
Redid the test using build 3694/95

          FS SM   800x600  Current  Workarea  Allmon
Windows   
                     x        x         x        x
           x         x        x         x        x
           xx        x        x         x        x
            x        x        x         x        x
Mac OSX   
                     x        x         x        1
           x         x        x         x        2
           xx        x        x         x        2
            x        x        x         x        2
XFCE   
                     3        3         3        3
           x         3        3         3        3
           xx        3        3         3        x
            x        3        3         3        x

Metacity   
                     x        x         x        x
           x         x        x         x        x
           xx        x        x         x        x
            x        x        x         x        x

1) Going fullscreen shows scrollbars, going back to windowed
   hides the scroolbars.

2) Going from fullscreen to windowed hides scrollbars

3) Goes fullscreen on wrong monitor, this is a aknowledged xfvm
   issue and is to be ignored but shows that most of the combinations
   does not work as intended.
Comment 45 Henrik Andersson cendio 2012-10-23 09:17:42 CEST 
(In reply to comment #44)
> 1) Going fullscreen shows scrollbars, going back to windowed
>    hides the scroolbars.
> 
> 2) Going from fullscreen to windowed hides scrollbars

This seems to be a redraw issue, scrollbars are there if you just
use it.. but now shown at first..
Comment 46 Pierre Ossman cendio 2012-10-24 15:01:31 CEST 
(In reply to comment #45)
> (In reply to comment #44)
> > 1) Going fullscreen shows scrollbars, going back to windowed
> >    hides the scroolbars.
> > 
> > 2) Going from fullscreen to windowed hides scrollbars
> 
> This seems to be a redraw issue, scrollbars are there if you just
> use it.. but now shown at first..

r26066.
Comment 47 Henrik Andersson cendio 2012-10-29 12:13:18 CET 
(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > 1) Going fullscreen shows scrollbars, going back to windowed
> > >    hides the scroolbars.
> > > 
> > > 2) Going from fullscreen to windowed hides scrollbars
> > 
> > This seems to be a redraw issue, scrollbars are there if you just
> > use it.. but now shown at first..
> 
> r26066.

Tested using client build 3702 and verified that this is no longer and
issue on Mac OS X.
Comment 48 Henrik Andersson cendio 2012-10-29 12:13:19 CET 
(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > 1) Going fullscreen shows scrollbars, going back to windowed
> > >    hides the scroolbars.
> > > 
> > > 2) Going from fullscreen to windowed hides scrollbars
> > 
> > This seems to be a redraw issue, scrollbars are there if you just
> > use it.. but now shown at first..
> 
> r26066.

Tested using client build 3702 and verified that this is no longer and
issue on Mac OS X.
Comment 49 Henrik Andersson cendio 2012-10-29 12:21:47 CET 
Considering this bug as closed due to latest redraw fix is a minimal
isolated change and does not require a full test to be performed...
Note You need to log in before you can comment on or make changes to this bug.