Attachment clipboard_speaking.patch added by aleksey_s on 2008-10-11 06:23
Description:
original patch

Comment 1 by jteh on 2008-10-11 12:10
I'm not sure we want to implement this from a principle standpoint.

• The main reason is that the clipboard is not visible to any other user without pasting it first. I don't think it is the job of a screen reader to act as a clipboard reader. There might certainly be a case for an accessible clipboard viewer, but I think this is outside the scope of a screen reader.
• This may encourage screen reader users to become dependent on this command, which is defies the standard Windows concept of the clipboard.
• If there is a large amount of text on the clipboard, this could cause problems.
  As always, I'm open to discussion on this, but those are my thoughts.

Comment 2 by aleksey_s (in reply to comment 1) on 2008-10-11 15:25
Replying to jteh:

• The main reason is that the clipboard is not visible to any other user without pasting it first. I don't think it is the job of a screen reader to act as a clipboard reader. There might certainly be a case for an accessible clipboard viewer, but I think this is outside the scope of a screen reader.

okay, sighted user can viev it by pressing one keystroke (paste), and with screen reader it will be minimum two (paste/speakline). also i don't think that blind user must not has functions, that sighted usually does not. sighted user have eyes, and their ever are big advantage :)

• This may encourage screen reader users to become dependent on this command, which is defies the standard Windows concept of the clipboard.

it isn't really an argument, but jaws 10.0 has this, so users will come dependent on it whatever nvda has such or not.

• If there is a large amount of text on the clipboard, this could cause problems.

if you have revieved my patch, you could see, that script determines size of the text, and send it to the synth only if it is less than 1024 characters long.
and in that case lag can not be at all, becouse windows returns only address of stored text, without copying it.

Comment 3 by pvagner on 2008-10-11 19:24
Guys, I my-self like this feature. Although it really is not something screen-reader really needs following the idea we can quickly implement and test various cool features I am woting for its inclusion.
I have also got some ideas by private email:
The problem is screen-reader users can't really be assured whether a text or some other content is selected prior to the actual copying. As far as I know there is no way of monitoring windows clipboard for changes or detecting when something is copyed or cut etc. So this is just a workaround or we might call it an alternative a lot of users might like.

Comment 4 by jteh (in reply to comment 2) on 2008-10-12 00:18
Replying to aleksey_s:

okay, sighted user can viev it by pressing one keystroke (paste), and with screen reader it will be minimum two (paste/speakline). also i don't think that blind user must not has functions, that sighted usually does not. sighted user have eyes, and their ever are big advantage :)

Granted, and I do agree that we should include a feature which is useful to access something that is otherwise difficult to access using the standard method. However, the standard method is not difficult to use. As I say, I don't have a problem with an accessible clipboard viewer, but in that case, it should be implemented in a separate application.

• This may encourage screen reader users to become dependent on this command, which is defies the standard Windows concept of the clipboard.

it isn't really an argument, but jaws 10.0 has this, so users will come dependent on it whatever nvda has such or not.

This isn't a reason to implement it, though. JAWS also has commands to append text to the existing clipboard and I think this is a really bad idea.

if you have revieved my patch, you could see, that script determines size of the text, and send it to the synth only if it is less than 1024 characters long.

Ok. I suspected you may have considered this

Comment 5 by jteh (in reply to comment 3) on 2008-10-12 00:23
Replying to pvagner:

Guys, I my-self like this feature. Although it really is not something screen-reader really needs following the idea we can quickly implement and test various cool features I really don't believe a screen reader should be doing anything clipboard related. As I noted, this introduces functionality which works contrary to the standard Windows clipboard concept. Another example is the introduction of special scripts to append text to the clipboard or to warn when copying over the top of data already on the clipboard. These functions are non-standard, and furthermore, they have caused me problems in the past in applications which use those keystrokes differently in some way.

The problem is screen-reader users can't really be assured whether a text or some other content is selected prior to the actual copying. As far as I know there is no way of monitoring windows clipboard for changes or detecting when something is copyed or cut etc.

As far as I know, no one can really detect when this has been done properly; this is not specific to screen reader users. I would consider it a deficiency in the Windows clipboard implementation.

Comment 6 by aleksey_s on 2008-10-12 07:23
i can not take in mind, why screen reader cann't have some features, which are not implemented in windows it self, and which are (imho) really usefull. when i am using jaws (it is version 4.51), when programming, often i need to repeat in memory, what i have in clipboard, becouse i was away from keyboard etc. and i would not install some external program for this. now, i can use power of nvda and python for this.
so: are you opposite to this functionality without chances? if such, further discussion hasn't sense. if not, let's ask users on nvda user list or how you prefer ask people's thoughts, becouse many of them don't read trac, i guess.

Comment 7 by jteh (in reply to comment 6) on 2008-10-12 15:24
Replying to aleksey_s:

i can not take in mind, why screen reader cann't have some features, which are not implemented in windows it self, and which are (imho) really usefull.

I do concede that it could be useful, even despite my objections. However, a screen reader's job is to make the operating system and software accessible in speech or braille. Sometimes, this might require additional features where the equivalent feature is too difficult to work with in speech or braille. However, in this case, there is no equivalent feature. Convenience features like this seem trivial enough, but where does one draw the line? Should a screen reader start providing global shortcut keys to start applications or change the system volume just because it is convenient? I would argue that they should install a separate, general purpose keyboard shortcut application for this purpose. Should we have global shortcut keys to read messages from every instant messaging program we support? Once we go down the path of implementing convenience features, it becomes very difficult to draw the line later on. Furthermore, users start to have difficulty in separating their understanding of the operating system and its applications from their screen reader.

when i am using jaws (it is version 4.51), when programming, often i need to repeat in memory, what i have in clipboard, becouse i was away from keyboard etc. and i would not install some external program for this.

Any other user has the same issue. They would need to install a clipboard viewer to view the clipboard. It could even have a shortcut key to pop up the text in a message box.

so: are you opposite to this functionality without chances? if such, further discussion hasn't sense. if not, let's ask users on nvda user list or how you prefer ask people's thoughts, becouse many of them don't read trac, i guess.

I have discussed this with Mick and we are both opposed to it for the reasons I have given. However, I recognise that this is one script which will not affect users unless they choose to use it. There are now two users that desire it and code has been provided, so feel free to email the users list and request opinions on this, providing a link to this ticket so people can read the discussion.

On another note, my objections aside, I really do very much appreciate your contributions to NVDA. I mean no offence by any of this; I just disagree in this case. :)

Comment 8 by aleksey_s (in reply to comment 7) on 2008-10-12 19:45
Replying to jteh:

I do concede that it could be useful, even despite my objections. However, a screen reader's job is to make the operating system and software accessible in speech or braille. Sometimes, this might require additional features where the equivalent feature is too difficult to work with in speech or braille. However, in this case, there is no equivalent feature.

inside my point of view, screenreader is a tool, which helps blind user to work on the computer. and this tool can provide most useful features for user. one of advantages of nvda is that it is open source and if you have skills you can extend it with functions you want at the moment, so it must quickly reflect on users request and needs.

Convenience features like this seem trivial enough, but where does one draw the line? community will draw :-)

Should a screen reader start providing global shortcut keys to start applications or change the system volume just because it is convenient? I would argue that they should install a separate, general purpose keyboard shortcut application for this purpose.

i agree with this.

Should we have global shortcut keys to read messages from every instant messaging program we support?

why not? we might implement for example simple miranda plugin, which will send to nvda last message (and might be called with miranda global keys) :) not included in oficial nvda distribution, i suspect.

Once we go down the path of implementing convenience features, it becomes very difficult to draw the line later on. Furthermore, users start to have difficulty in separating their understanding of the operating system and its applications from their screen reader.

users use a tool to interact with their PCs. why they must do not use a special features, offered by their tool?

Any other user has the same issue. They would need to install a clipboard viewer to view the clipboard. It could even have a shortcut key to pop up the text in a message box.

do you know such a program? or why users do not install a program what will popup a messagebox with current time/date, battery status?.. okay, windows provides the vidgets/icons for this info. but does not provide clipboard reminder, so let's be bound.

I have discussed this with Mick and we are both opposed to it for the reasons I have given. However, I recognise that this is one script which will not affect users unless they choose to use it.

exactly that! i prefer a lot of functionality, but all must be customizable, it is a real freedom.

There are now two users that desire it and code has been provided, so feel free to email the users list and request opinions on this, providing a link to this ticket so people can read the discussion.

as i am not subscribed to that list, i asked Peter to do it.

On another note, my objections aside, I really do very much appreciate your contributions to NVDA. I mean no offence by any of this; I just disagree in this case. :)

thanks.

p.s. sorry for my poor english

Comment 9 by jteh (in reply to comment 8) on 2008-10-13 01:11
Replying to aleksey_s:

inside my point of view, screenreader is a tool, which helps blind user to work on the computer. and this tool can provide most useful features for user. one of advantages of nvda is that it is open source and if you have skills you can extend it with functions you want at the moment, so it must quickly reflect on users request and needs.

Even open source tools driven by the community try to limit the scope of what they will implement. What is different about the example of global keyboard shortcuts to launch applications? A user might request this, but imo, this should never be added to NVDA.

Convenience features like this seem trivial enough, but where does one draw the line?

community will draw :-)
While we try to follow the community as much as possible, there are some cases where I believe we need to make a judgement based on our own experience and the goals and philosophy of the NVDA project.

Should we have global shortcut keys to read messages from every instant messaging program we support?

why not? we might implement for example simple miranda plugin, which will send to nvda last message (and might be called with miranda global keys) :) not included in oficial nvda distribution, i suspect.

Where does it stop, though? This means you could end up with hundreds of global keys for all sorts of applications. Not only does this cause key clashes, but it turns the software into bloatware.

users use a tool to interact with their PCs. why they must do not use a special features, offered by their tool?

Why does a media player not act as a word processor? Why does a web browser not act as a spreadsheet? These are exaggerated examples, but there must always be a limit on the scope of an application. Otherwise, it becomes too confusing and eventually becomes bloatware.

do you know such a program? or why users do not install a program what will popup a messagebox with current time/date, battery status?.. okay, windows provides the vidgets/icons for this info. but does not provide clipboard reminder, so let's be bound.

There actually was a clipboard viewer in Windows some time ago. I'm not sure if it is still available now. Also, items such as time and battery status are always visible, whereas the clipboard viewer would not be. IF there was a widget to view the clipboard, then yes, we should try to make this accessible.

Anyway, let's see what the community has to say on this one. Truthfully, I suspect Mick and I will be alone in our objections. :)

Comment 10 by Bernd on 2008-10-31 11:08
Hello Guys, I myself like this feature, too. Sometimes it might be really useful.

Comment 11 by jteh on 2008-11-04 01:07
Grudgingly committed in r2466 with several modifications. :)

Modifications (and code review):

• Fixed some messages slightly.
• Catch exceptions from api.getClipData(), which will fail if there is non-text data on the clipboard.
• nit: To avoid unnecessary levels of indentation, return when an error condition is encountered.
• When a script reports information which is not for speech only, name it report_, rather than speak_; i.e. reportClipboardText.
• Similarly, use ui.message() instead of speech.speakMessage() unless the message is for speech only.
• Please include an entry in user_docs\whats new.txt when doing something significant to the code that will be noticed by users.
  Changes:
  State: closed

Comment 12 by jteh on 2008-11-04 01:09
Changes:
Changed title from "Speaking of the windows clipboard text" to "Reporting of the windows clipboard text"