Remove use of the visibleOffset, this completely breaks the display of all windows except for the main application window. Instead,
just maintain a local offset correction of the windowOffset.
Apply workaround to determining the workArea for remote app mode.
1. Linked Window Manager Maximize/Minimize and Restore operations to those from the Server Rail Window so that they are in sync
2. Enable things like "CTRL-ALT-DELETE" and "WindowsKey-L" to show the full desktop window again since the desktop is not actively monitored since
this was still trying to draw to the rail window without updating the size of the window to accomodate the full workspace area.
3. Changed local window coordinates to be based on the visibileOffsetX/Y- while moving server window based on WindowOffsetX/Y. I have seen various issues regarding this when trying to use a maximized window where this is a disconnect between local window coordinates and remote window coordinates. This change clears these things up.
4. Commented the XShapeCombineRectangles calls - this can cause issues where the entire window is not visible and it does not currently play well with the changes from #3. The gain here is greater than the loss.
5. Draw the initial workspace correctly when running across multiple monitors. The correct size was always used, but the window was only starting on the current monitor and thus could draw the window off of the viewable area.
Known Issues:
Although the changes for #2 worked well in the stable branch that I developed from - the desktop window shown once the rail windows are destroyed does not respond to input unless I minimize/restore the window. Once the window starts responding to input - you can hit cancel to close the desktop window and return to your rail windows again(or launch task manager, etc.). This is still a big step in the right direction as xfreerdp is now correctly acting when the rail server stops Actively Monitoring the desktop.
XShapeCombineRectangles needs to be revisited, most windows applications will give you a rectangular window anyways.
Currently in Remote App mode we have no option to interact with the
remote desktop host before the first RAIL window is created.
In many situations this interaction possibility is absolutely required.
One example is that screen which gets displayed if another user is logged on.
It requires clicking a button in pre-RAIL mode so that the currently logged
on user gets notified to confirm or deny the connection.
Another example is the option to log on graphically (e.g. for hosts that
don't support NLA) without predefined credentials.
Also if the administrator sets the "User must change password at next logon"
option there is currently no way to do this in TS Remote App mode.
This change basically lets xfreerdp create the main window in Remote App mode
like in a normal session and xfi->remote_app is not set to true initially.
As soon as the rail exec result event or the first rail window creation
request is received (whatever comes first) the main window gets destroyed and
xfi->remote_app is set to true.
The second change is to disconnect immediately if the rail exec result event
reports an error, e.g. if the specified app cannot be found or if it is not
in the list of allowed applications.
This fixes FreeRDP github issue #143 and issue #308.
I'm aware that this is not the most elegant solution but it is definitely an
improvement and probably good enough for 1.0.
A nicer solution would be hiding the main window and only displaying it if
no rail exec result or rail window creation event is received after a certain
timeout ...
