www.cendio.com
Bug 4275 - tlclient and vncviewer should start on correct screen even in multi screen configurations
: tlclient and vncviewer should start on correct screen even in multi screen co...
Status: CLOSED FIXED
: ThinLinc
Client
: 3.2.0
: PC Unknown
: P2 Normal
: 4.0.0
Assigned To:
:
:
:
: 4372
  Show dependency treegraph
 
Reported: 2012-04-30 14:38 by
Modified: 2012-11-28 12:27 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2012-04-30 14:38:38
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 From cendio 2012-06-14 11:32:32 -------
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 From cendio 2012-06-20 12:29:44 -------
*** Bug 4337 has been marked as a duplicate of this bug. ***
------- Comment #3 From cendio 2012-06-20 12:31:52 -------
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 From cendio 2012-06-20 13:44:55 -------
Windows part fixed in 25345, other platforms remains.
------- Comment #5 From cendio 2012-06-20 14:13:03 -------
Note: The tester needs to test --loop as well.
------- Comment #6 From cendio 2012-06-21 15:41:34 -------
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 From cendio 2012-06-21 16:10:08 -------
(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 From cendio 2012-06-26 14:06:44 -------
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 From cendio 2012-06-26 14:40:38 -------
tlclient centering on X11 fixed in 25391.
------- Comment #10 From cendio 2012-06-27 09:05:06 -------
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 From cendio 2012-06-27 09:21:54 -------
(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 From cendio 2012-07-19 13:10:30 -------
*** Bug 4363 has been marked as a duplicate of this bug. ***
------- Comment #13 From cendio 2012-08-02 13:27:07 -------
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 From cendio 2012-08-02 14:17:32 -------
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 From cendio 2012-08-02 14:33:21 -------
(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 From cendio 2012-08-14 12:34:15 -------
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 From cendio 2012-08-14 12:35:53 -------
(In reply to comment #16)
> However, caring about virtual desktops will have to wait. Will be
> handled on separate bug.

Bug 4372.
------- Comment #18 From cendio 2012-08-27 11:43:54 -------
(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 From cendio 2012-09-04 11:45:44 -------
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 From cendio 2012-09-12 13:17:37 -------
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 From cendio 2012-09-12 13:47:27 -------
Fixed in r25793.
------- Comment #25 From cendio 2012-09-25 16:10:05 -------
I believe this bug is finished now. Note: I'm reporting all my multi monitor
hours on this bug.
------- Comment #26 From cendio 2012-10-02 12:57:29 -------
(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 From cendio 2012-10-03 10:42:58 -------
> 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 From cendio 2012-10-03 10:47:41 -------
>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 From cendio 2012-10-03 10:52:37 -------
(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 From cendio 2012-10-04 09:04:17 -------
(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 From cendio 2012-10-08 12:54:40 -------
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 From cendio 2012-10-08 16:15:26 -------
(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 From cendio 2012-10-10 15:01:30 -------
(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 From cendio 2012-10-11 12:23:48 -------
(In reply to comment #31)
> 
> 2) Starts fullscreen on primary monitor, this is a regression since the
> previous test.
> 

Fixed in 25984.
------- Comment #35 From cendio 2012-10-11 14:31:41 -------
(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 From cendio 2012-10-15 09:45:13 -------
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 From cendio 2012-10-15 14:31:28 -------
(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 From cendio 2012-10-16 10:49:56 -------
Just tried the latest build 3686 and finally the last issue is fixed,
lets do a full retest once again :)
------- Comment #39 From cendio 2012-10-17 12:55:07 -------
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 From cendio 2012-10-17 16:18:35 -------
(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 From cendio 2012-10-18 09:13:40 -------
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 From cendio 2012-10-18 09:46:51 -------
(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 From cendio 2012-10-18 12:45:01 -------
Intended behaviour. We don't mess with the server layout unless dynamic resize
is active.
------- Comment #44 From cendio 2012-10-23 09:02:23 -------
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 From cendio 2012-10-23 09:17:42 -------
(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 From cendio 2012-10-24 15:01:31 -------
(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 From cendio 2012-10-29 12:13:18 -------
(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 From cendio 2012-10-29 12:13:19 -------
(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 From cendio 2012-10-29 12:21:47 -------
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...