- This topic has 6 replies, 4 voices, and was last updated 9 years, 1 month ago by
.
-
Posts
-
Desktop Sharing/Shadowing has great potential in NX, but the feature is horribly documented, and with its current implementation, requires users to be trained. The ConnectPolicy with new runtime session type selection, can render session sharing impossible. Specifically the default ConnectPolicy autocreate=1,autoconnect=1,automigrate=1,desktop=0,dialog=0 renders this impossible, since you cannot select session type.
When creating a connection, you should definitely be able to specify session type like it was in NX 3.5 – or at least do so for shadowing. Perhaps this can be fixed in the session file, and its just not documented – and if so, please share.
But in general, it should be easy for end-users to share sessions.. ideally an invite/respond function, but even a method that you can use from within an already connected session, ie. “show running sessions”.
Or better still.. command line.. nxplayer –shadow user@host
It was a design choice that most of the session configuration happens at runtime based on information provided by the server after authentication to the server has taken place. Rather than put everything in the hands of the user who with v3 had to know a priori what to configure and what was available (or not), it’s now the server which tells the client what the user can do or not. So really, there is less training for new users of the latest version.
Specifically, all connections to a physical desktop happen in “shadow” mode, so that no choice by the user is necessary.
Also all connections to a virtual desktop owned by a different user can only happen in shadow mode.
So I assume that your problem is with connecting to a virtual desktop owned by yourself. By default the session is “migrated” to the new client and probably you want instead that the previously connected client is not disconnected. This can be achieved by changing the ‘automigrate’ option to ‘0’ in the ConnectPolicy key. To hide this complication to the user was a precise design choice. The main reason is that session sharing makes sense between different users. Allowing the user to connect to its own session in shadow mode would mean more or less to “share the session with yourself”.But in general, it should be easy for end-users to share sessions..ideally an invite/respond function, but even a method that you can use from within an already connected session, ie. “show running sessions”.
A system based on invitions will be part of the new NoMachine Network Service (or NoMachine Anywhere, we are still debating what name is the best), currently in its final stages of implementation.
Your reply triggered me to test something. I’m in an all virtual desktop environment across two servers.
I decided to try nxplayer from within my NX session, connecting to the same host as my NX session. It listed only my session, but I was able to change the filter “My Desktop” to “All Desktops”, and all active sessions were displayed.. exactly what I wanted (since I don’t want to change automigrate option).
I then tried the same thing, but connecting to a different host – and I discovered the following:
If the “My Desktops” filter is set, and I connect to a different host, it will open a new NX session (or reconnect existing session) on that server, which is what I don’t want.
If the “All Desktops” filter is set, and I connect to a different host, it will display me all user connections, which is what I want.
So it appears that option/filter will drive whether it launches session or displays desktops for me to shadow.
In player.cfg:option key=”Remote session list owner filter” value=”all sessions”
Bug is that when set to “my sessions”, you cannot change it to “all sessions” easily (i had to try something impossible – connect to my session from within my session – in order for filter to be changed).
Hi blabj.
The connection configuration flow has gone through a lot of design changes based on feedbacks and usability tests, so what you see now is what the majority of users asked for. This doesn’t mean it is perfect, so new use cases are always helpful to evaluate how to make that flow more flexible.
First of all, how it works. The client skips configuration steps each time there is only one choice. When the connecting user has no sessions running on the server and the filter is on “My desktops”, the configuration moves on virtual desktop type selection. From this dialog you may go back and select ‘All desktops”, unless the type is stored in the configuration file or the server only offers one virtual desktop type, because in such conditions the virtual session starts right away. While this workflow is ideal for administrators wishing to make life easier for users, it might be a problem for you.
If you wish to use the same connection to do both virtual desktop and desktop sharing, then I’d suggest to not save the desktop type in the configuration (by checking the box “Save this setting in the connection file” in the type selection dialog).
Interesting, if I connect to remote host with “All desktops”, I can connect/shadow a session fine.
If I connect to the local host (same host running virtual desktop), with “All desktops”, if I try to shadow another virtual desktop session, it disconnects my session.
I do limit the per user virtual desktops to 1 – so perhaps this is causing the issue.
This topic was marked as solved, you can't post.