#1368 closed enhancement (fixed)
more sharing options client side
Reported by: | Antoine Martin | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | minor | Milestone: | 2.2 |
Component: | client | Version: | trunk |
Keywords: | Cc: |
Description
Follow up from #41.
It would be nice if the clients could specify more than sharing on or off.
Maybe add the ability to refuse to let other users steal the session? ("keep"?)
The other user would have to issue an "xpra disconnect" first before being able to connect?
We still need a way to take over stuck sessions, otherwise the only option would be to "xpra stop" it which isn't very user friendly.
Change History (10)
comment:1 Changed 4 years ago by
Status: | new → assigned |
---|
comment:2 Changed 4 years ago by
Milestone: | 2.0 → 2.1 |
---|
comment:4 Changed 4 years ago by
comment:5 Changed 3 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|---|
Status: | assigned → new |
Done in r17268 with the "lock" option, which can be modified at runtime from the system tray.
The semantics of "sharing" has changed somewhat, this is how the server handles the value:
- sharing=no disables all sharing
- sharing=yes now enables sharing for all clients, ignoring what the clients request
- sharing=auto lets the clients decide - this is the default value
"auto" defaults to "no" on the client.
The same logic applies to the new "lock" switch. A locked session cannot be stolen by another user, though it may still be shared if that is enabled.
@maxmylyn: mostly a FYI. Feel free to close.
I may follow up in #1369 and #972.
comment:6 Changed 3 years ago by
comment:7 Changed 3 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Very nice - noted and closing.
comment:9 Changed 17 months ago by
r17804 updates the system tray if the "sharing" or "lock" options have been changed on the server.
comment:10 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1368
See also #1369: the sharing option could be used to define the offset for each client.
Taking this even further: we could even have the option to force the client to map to the same full-screen size (scaling client size display to match whatever is on the server) - somewhat related to #972.