X2Go - everywhere@home

• [all]h1, Mike#1, Mike#2, Mihai, Stefan, Alex

• X2GoServer code updates in preparation of the upcoming release
  • release is scheduled for early December 2017, but the sooner, the better
  • We need a “master bug” for the release, that will/can be blocked by the bugs created for the individual tasks
    • Who will file these bugs, and who will mark them as blockers?
    • Who is working on what?
  • New release will bring changes on server and client side
    • mostly regarding xinerama
    • keyboard handling (“Keyboard cloning” feature)
    • “autograb”/Input-Lock for windowed desktop sessions
  • server-side changes must come first, client-side changes could be delayed into early 2018 if we're low on resources
• Upcoming X2GoClient stable release
  • any questions, vetos, …?
  • What needs to be done?
  • Mike#2 will be available for Q&A
• Move of bugtracker to self-hosted “gogs” instance
  • after the upcoming release?
  • who can do it?
  • how do we migrate bugs?
• Date for Next DevMeeting
  • Regular schedule: Once per quarter
  • Might need to take place more often in the next few months, due to the release schedule

(will be moved to a different Wiki page later)

X2Go Next Major Release

Server-Side:
Phase that allows 3.5 && 3.6
3.6 is in experimental, could co-exist with 3.5
Xinerama is not done
Needs Server-side and Client-Side changes

New Servers need to be able to function with older Clients
and vice versa

Current (old) approach: xinerama.conf is generated on the client
file gets copied to server regularly

Mode 1: NXagent is in fullscreen - xinerama.conf shows geometry of your output device layout

Mode 2: X2Go session is in windowed mode and there is a multi-device layout on the client
->it's possible to move the client window across screens (with overlap)
-> that's why on each resize/move event, xinerama.conf needs to be updated when using the "old" method

Now, with current X2Go-Libs and X2GoClient, xinerama.conf gets pushed to the server -> if file is present, we enable xinerama mode.

When does that happen? Before or after the xgostartagent call?

New Client, New Server:
->Idea: keep creating xinerama.conf, but fill it with "auto" or a similar magic value
-> "X2GOAGENT_RANDRXINERAMA" 
   * present -> xinerama.conf with "auto"
   not present -> xinerama.conf with required values

New Client, Old Server:
-> x2gofeaturelist / x2gofeature <feature_name>
-> "X2GOAGENT_RANDRXINERAMA" 
   present -> xinerama.conf with "auto"
   * not present -> xinerama.conf with required values

Old Client, New Server:
Old clients will generate a xinerama.conf and upload it to the server
New Server should check file
-> If file exists, enable xinerama
-> If not, do not enable xinerama
--> Won't work because xinerama.conf is created too late
--> New Client 

Old Client, Old Server: Unchanged

->Idea: Have New X2Go *Client* report its list of features *to the Server*
--> Empty list = old client
->This info should be stored in a file on the server (in the session directory)
--> x2gosuspend-/-terminate-session should remove this file

--

Keyboard:

(Uli) 
Plan: Change NX so keyboard handling works out of the box.
Unsure if this works.
Future NX-libs should block keyboard changes within sessions.
But: X2Go is currently changing keyboard settings within sessions.

-->New Feature "Keyboard Cloning"

(Mike#1)
Plan: Keep old behavior in the code, but switch the default:
- New way of handling things becomes default
- command line parameter/option allows fallback

--

Auto-Grab:
X2GoClient needs a checkbox to enable/disable auto-grab

Same goes for Input-Lock

--

Focus on Server-Side implementation first
(Timing/Limited Resources-> Ubuntu Freeze, Dec 2017 deadline)


Step-by-step plan, dependencies, (wishlist?) bugs -> Master Bug, blocked by the individual (wishlist) bugs

If we do a "LTS-like" release, it should clearly state the date when it will be removed from the download servers
ESR instead of LTS?
Remove LTS/ESR packages from download servers if there is no support contract

->Mihai will introduce snapshot archives for heuler
-->hopefully increases amount of testers

required Documentation for testers -> Should be as simple as updating sources.list to a heuler+timestamp entry and running update, upgrade, dist-upgrade

...log...