Bug 54048

What is the exact use case? 
 
I am asking because 
1. krdc is meant as a simple, easy-to-use tool with a minimum feature set. However the 
goal is to provide a backend that can be used for other, more sophisticated and 
specialized application. If your use case is about watching users or students, for 
example, this is just one among many desirable features for these use cases, but way 
out of scope for krdc. 
2. krdc will get some more configurability. If that feature should really be implemented in 
krdc, it would be important to know whether the feature is a feature that needs to be 
done once for each hosts, or before each connection (and whether the setting 
can/should be remembered). 

Often when I'm helping someone with a problem, they want to know how to do it.
Usually I watch their screen and explain to them how to do it themselves.

Tim, could you elaborate a little bit more on your two points?

1. Why is this out of scope? Is it difficult to implement? It already exists as
an option on the host side.
2. Why would that be a setting done for a host? Isn't that a feature purely on
the client side? I don't know anything about how this is actually implemented,
but couldn't one simply not send any information to the host if "view-only" is
enabled?

Its a mainly a UI issue. I dont like complicating the UI with features unless there is a use case within the scope of the app that cannot be solved without it, or at least it would be less comfortable.

In the near future there will be three locations for the options: the main toolbar, the per host config dialog and the command line switches. I asked how it is being used because this decides where to put it. in this case the toolbar would seem to be the right place, but this w=is also why I hesitate. The toolbar is a very visible location for a rather obscure feature.

Subject: Re:  Krdc needs an option to view only         

I see your point. As for myself, I would be happy with the command line 
option. A toolbar option on the other hand would give users more 
flexibility though, i.e. it would add convenience since one wouldn't have 
to restart kdrc in order to change this setting.

I'm in favour of this too.  There is certainly no problem on the host side
because "xvncview -viewonly" works fine with krfb.

I don't think it needs to be a toolbar option however, just a checkbox on the
initial connection dialog to say viewonly.  This doesn't seem out of scope,
there is already a drop down box for specifying connection speed; a checkbox
does not seem an unreasonable addition.

Myself I would be happy with a command line option as Nicholas in comment 5;
however, it looks very like xvncview then and what would be the point of having
krdc?

Command line options are only acceptable for things that very few people need or understand. So far the only thing that is only available via the command line is the exact encoding configuration (-e).  But I wonder why you only want to configure it at startup. Taking luke7jr's use case, 'only watching what people do', it is certainly desirable to be able to take control at a later point when the other person needs more help.   Right now I think the best solution is to add a button with pull down menu (like those in konqueror's toolbar for going up/back/forward) that contains the option, together with one or two other options that will be possible in the future.   

Personally, I think the TightVNC viewer for Windows has very good design while still keeping it 
easy for computer novices to use... What's wrong with an Advanced button? 

IMHO the problem with the TightVNC windows client is that a) unless you know the protocol and its extensions you will not be able to find good settings for different situations (it's better with the auto-adjust stuff from RealVNC though) and b) all functions are hidden in the window menu, so few novices will find them. When you can't see a feature it is not there - at least for the majority of users. Beside that, with KDE it is not possible to put features into the window menu, nor can the 'maximize' button be overloaded like the MS's RDP client does.   There's nothing wrong with a advanced button, that's basically what I proposed with the pull-down menu button. The only problem is that each control element and each option makes the app more difficult to use and increases the complexity of the code.    

Implemented in CVS.  
 
There's still a small GUI problem in the advanced popup (the check mark can't be seen), 
that will be solved later.