Auto Copy

Auto Copy

hi, Opera is really nice and good browser, but i missing here one for me important feature:
Auto Copy - https://addons.mozilla.org/en-US/firefox/addon/383
I'm using it daily, and embedded Note program is not useful.

Opera is really nice and good browser

Auto Copy plain text on text selection --- UserJS

If data uris were supported in flash, then it'd be better than polling an external server everytime for it.

Originally posted by shoust:

If data uris were supported in flash, then it'd be better than polling an external server everytime for it.

-1. I highlight text when I read to help my eye follow the words. Default installation of this would not only reduce Opera's efficieny, but screw up my clipboard, as well as introduce a bunch of bugs/regressions in future versions if it were implemented within the Opera code. Keep it at the UserJS code, please.

+1 as long as its not enabled by default im still fighting myself not to punch the screen out in Linux when I try to use paste and go in the address bar.

Originally posted by IceArdor:

-1. I highlight text when I read to help my eye follow the words. Default installation of this would not only reduce Opera's efficieny, but screw up my clipboard, as well as introduce a bunch of bugs/regressions in future versions if it were implemented within the Opera code. Keep it at the UserJS code, please.

This is a standard function of X11 in Linux the easiest way to handle this feature eating selections is to just use a clipboard manager, which one probably wants to do anyway if one does any significant work on a computer. The feature itself is so simple that I really doubt it would cause problems with respect to bugs all it really is, is a function that gabs text on a mouse drag event and deposits it in the clipboard. It is really no more complicated than "conventional methods of copying text." The impact on system performance is going to be so negligable that it would only become a problem if someone actually screwed up the code for this functionality.

Note: there is a command "Paste mouse selection" could be used as Auto-copy in Opera only.

Originally posted by shadow skill:

This is a standard function of X11 in Linux

Not quite, the selection buffer in *nix is independent from the clipboard buffer (traditional copy/paste) and therefore it doesn't override the clipboard content (something that it would do in Windows).

How the text is actually handled by the system is not really germane to my point that X11 copies text selected with the mouse automatically; besides the windows behavior is actually more sane since there are not effectively two clipboard buffers. I need to stop being lazy and write a clipboard manager that isn't Klipper.

Originally posted by shadow skill:

How the text is actually handled by the system is not really germane to my point that X11 copies text selected with the mouse automatically

It is actually relevant considering that the application (Opera in this case) would not be following the standard behaviour in the platform. There are two independent buffers in *nix, one in Windows; selected text in *nix doesn't override the clipboard buffer, it would do it in Windows: this is not the standard behaviour in the Windows OS nor what a Windows user expects. This was the whole point of the post you replied to.

The same problem that he was talking about exists in X11 because that buffer gets overwritten with every selection, again it was never important that X11 has what amounts to two clipboards because the solution to the problem ends up being the same in the end. The only real difference as far as the end user is concerned between X11 and Windows behavior is that there is only one buffer to override in windows as opposed to two in X11.

Originally posted by shadow skill:

The same problem that he was talking about exists in X11 because that buffer gets overwritten with every selection

But that's the whole point of the selection buffer in *nix as opposed to the clipboard buffer; if the user wants to keep something then the clipboard is used (highlight text and select "copy") otherwise it is assumed that all selected text will override the selection buffer (but not touching the clipboard one) since this is the standard behaviour in the *nix world.

In *nix each action (selected text and selected text&copy) is linked to one specific buffer but in Windows you would have two different actions (selected text and selected text&copy) linked to only one buffer (which is not a standard behaviour in Windows) so everytime a text is highlighted (in order to be read, use hotclick popup menu, etc) the user would end up with a result that is not usually linked to the action and is not expected in Windows. However, the fact that the selection buffer is overriden in *nix everytime a text is selected is an expected result. This is what makes both situations completely different.

Originally posted by shadow skill:

again it was never important that X11 has what amounts to two clipboards because the solution to the problem ends up being the same in the end.The only real difference as far as the end user is concerned between X11 and Windows behavior is that there is only one buffer to override in windows as opposed to two in X11.

It cannot be the same solution since there's no problem in *nix in the first place: both buffers are independent (that is, they do not override each other's content) and serve different purposes, the user knows it and uses them accordingly. However, in Windows there's only one that only works via copy/paste in all applications but this behaviour would not be followed by Opera so the content of the clipboard would be changing every time a text is highlighted.

The problem is that in the case of *nix the buffer used for mouse selection gets overwritten every time you select some text with the mouse, this is no different than what happens in Windows when a program allows for the same type of functionality so yes it is exactly the same problem. His problem is that he does not want the buffer overwritten by the text selection, the samething will happen in *nix unless he uses a clipboard manager to do two things

• preserve the previous buffer information.
• Sync the two buffers information to effectively merge the two into one.

if we are talking about X11 in the case of windows all that needs to be taken care of is that first item of preserving the clipboard data; and how dows one do this on either system? You guessed it use a clipboard manager.



For the record Trillian, Mirc and Hydrairc all have autocopy functionality by default and it does not create any of the problems he said this would create for Opera save for the "problem" of the clipboard contents being overwritten every time test is selected with the mouse.

Yep, Tracio has the point.

I know that Trillian has auto copy implemented, and it doesn't bother me there. However, there is one big difference between Opera and Trillian. In the Trillian message box, I never click around unless for selecting and copying text. In Opera, on the other hand, clicking and dragging somewhere in the page is a frequent action, as html pages are usually full of interactive elements (hyperlinks, buttons etc). With auto copy, this could easily kill my clipboard.

As a conclusion, I really don't like the idea of autocopy for Opera. The clipboard is sacred, and so are reliable defaults (the expected system behavior).

It's really enough to have an autocopy userjs available.

Originally posted by shadow skill:

His problem is that he does not want the buffer overwritten by the text selection, the samething will happen in *nix unless he uses a clipboard manager to do two things

No, it doesn't happen the same thing in *nix: my clipboard is not overwritten when I select some text; in Windows it would.

I won't repeat everything again, it's clear that for whatever reason you ignore the simple fact that:

*nix:

selected text => Selection buffer
selected text + "copy" => Clipboard buffer

Windows:

selected text => Nothing
selected text + "copy" => Clipboard

The proposal is:

Windows:

selected text => Clipboard
selected text + "copy" => Clipboard

If the above looks similar to you great, but these are clearly two different behaviours and in no way the Windows problem exists in *nix since users expect this behaviour and Windows users don't.

Originally posted by shadow skill:

For the record Trillian, Mirc and Hydrairc all have autocopy functionality by default and it does not create any of the problems he said this would create for Opera save for the "problem" of the clipboard contents being overwritten every time test is selected with the mouse.

How come is this not a problem when an application is doing something that 1) is not the standard behaviour in the platform 2) the user didn't expect because it is not the standard behaviour of applications in Windows?.

Expected defaults for whom you or the hundreds of thousands if not millions of people using those three programs (and probably others) on windows alone not to mention the other hundreds of thousands if not millions of people who make use of Klipper (which can sync the two buffers into one.) on *nix. There is no real problem here just turn the damn thing off if you do not want it, though I recommend that you simply use something like Ditto. (windows clipboard manager.)

Tracio pleasue quote me properly or don't bother at all

The problem is that in the case of *nix the buffer used for mouse selection gets overwritten every time you select some text with the mouse

, this is no different than what happens in Windows when a program allows for the same type of functionality so yes it is exactly the same problem. His problem is that he does not want the buffer overwritten by the text selection, the samething will happen in *nix unless he uses a clipboard manager to do two things...Please explain to me how having the buffer used by mouse selection being overwritten is a different problem from the windows buffer being overwritten? Actually read what he said please, forget about the fact that there are two buffers in X11 and imagine that there is only one like there is in Windows and tell me how the problem is actually different.

Originally posted by shadow skill:

Tracio pleasue quote me properly or don't bother at all

I thought I was doing so...

Originally posted by shadow skill:

His problem is that he does not want the buffer overwritten by the text selection, the samething will happen in *nix unless he uses a clipboard manager to do two things...

Again, he doesn't want the clipboard content to get overwritten when selecting text, this would happen with the "auto-copy" feature; however, this doesn't happen at all in *nix, you don't need a clipboard manager in order to avoid it since it doesn't happen in the first place, it is the standard behaviour in *nix and thus what the user expects as opposed to the Windows standard behaviour.

Originally posted by shadow skill:

Please explain to me how having the buffer used by mouse selection being overwritten is a different problem from the windows buffer being overwritten?

I have done it many times (see the example I posted in my previous post); take the time to read it properly and you will see how the behaviour is completely different. If you want a simple example, here it goes:

*nix:

1. -Select some text ("This is the Opera Forum")and copy it. => the content goes to the clipboard buffer.
   
2. -Select other piece of text ("I'm an Opera user"). => the content goes to the selection buffer.
   
3. -Middleclick. => the content of the selection buffer is pasted ("I'm an Opera user").
   
4. -Use "Paste" => the content of the Clipboard buffer is pasted ("This is the Opera Forum").
   

This is the standard behaviour in *nix, no need to use a clipboard manager to achieve it.

Windows with "auto-copy":

1. -Select some text ("This is the Opera Forum")and copy it. => the content goes to the clipboard buffer.
   
2. -Select other piece of text ("I'm an Opera user"). => the content goes to the clipboard buffer.
   
3. -Use "Paste" => the content of the Clipboard buffer is pasted ("I'm an Opera user")
   

It's quite clear...the clipboard content is overwritten by the selected text in Windows while in *nix the clipboard content is not touched at all. Simply put, I lose my clipboard content in Windows when I select text for reading, hotclick popup menu, etc; my clipboard content is still there in *nix after I select text for the same purposes.

Originally posted by shadow skill:

Actually read what he said please, forget about the fact that there are two buffers in X11 and imagine that there is only one like there is in Windows and tell me how the problem is actually different.

I'm a bit puzzled reading this long controversy.

Imagine you use the clipboard as a backup for text. I do that frequently, when I'm afraid a message will be lost due to script-generated forms.

Doing that in Linux, you can still use the select-autocopy without killing your back-upped text. You can't use the actual clipboard for that time, but you expected that, and it's not a problem. Nothing unexpected or destructive happens.

In Windows, as long as you want to keep the back-upped text in your clipboard, you can't copy and paste anything else. That's a limitation, but it's not destructive, and it doesn't break your expectations. With autocopy, however, it can easily happen that you flush the buffer by accidant - either as a motion error (stubby fingers), or as a result of false expectations - which is clearly destructive.

Now would you tell me what I got wrong?

The X11 method does break user expectations because the behavior goes to a second buffer and not to the same buffer as an explicit copy command from an X11 client application. When you select text you pretty much can't use the keyboard to paste that selected text because all of the shortcuts (save maybe one) paste from the buffer that collects explicit copy commands (ctrl-c,edit>copy,etc) as opossed to the buffer that handles the implicit copy command. The mouse selection event, Both buffers are in effect clipboards that respond to two totally different control interfaces. That is counter-intuitive not the other way around, no one should be thinking of how they copied a piece of information and then try to remember which control interface Mouse or Keyboard to use to get access to the right set of data. The X11 situation is an example of how to incorrectly do a clipboard it just so happens that as a side-effect there is some very useful functionality available despite the mechanics of the system itself being broken.

Back to the question of overwritting a buffer, remember that both buffers are clipboards, the problem of overwriting the buffer on mouse selection is present no matter how many buffers exist or which buffer the text goes to when grabbed on mouse selection; therefore the problem is still present, and has not changed in nature. That is what makes the solution to the problem the same regardless.

If you are afraid o a script dying on and losing a post use something like Ditto it will hold your post even if your box crashes on you.

The point is, you want at least one buffer that is protected from accidental flushing.

Originally posted by shadow skill:

The X11 method does break user expectations because the behavior goes to a second buffer and not to the same buffer as an explicit copy command from an X11 client application. When you select text you pretty much can't use the keyboard to paste that selected text because all of the shortcuts (save maybe one) paste from the buffer that collects explicit copy commands (ctrl-c,edit>copy,etc) as opossed to the buffer that handles the implicit copy command. The mouse selection event, Both buffers are in effect clipboards that respond to two totally different control interfaces. That is counter-intuitive not the other way around, no one should be thinking of how they copied a piece of information and then try to remember which control interface Mouse or Keyboard to use to get access to the right set of data. The X11 situation is an example of how to incorrectly do a clipboard it just so happens that as a side-effect there is some very useful functionality available despite the mechanics of the system itself being broken.

This is just your opinion and it is completely beside the point; maybe you find it annoying (I do not and it suits my needs just fine) but it doesn't change the fact that that's how *nix works; that is, different from the Windows "auto-copy".

Originally posted by shadow skill:

Back to the question of overwritting a buffer, remember that both buffers are clipboards, the problem of overwriting the buffer on mouse selection is present no matter how many buffers exist or which buffer the text goes to when grabbed on mouse selection; therefore the problem is still present, and has not changed in nature. That is what makes the solution to the problem the same regardless.

I give up, if you are not able to understand the examples I posted above and their consecuences then this discussion goes nowhere and it's a waste of time for both sides.

The point is, you want at least one buffer that is protected from accidental flushing.

What protection does a second buffer provide you, seriously its VERY easy to accidentally flush the explicit buffer by accidentally using one of the keyboard shortcuts in reality its no more difficult than doing so with the mouse. As far as I can tell protecting buffers from accidental flushing was never a consideration with respect to the design of X11. The reason clipboard managers exist is to address the issue of accidentally flushing the buffer(s) and to cut down on repetitive cut/copy commands.

Tracio please don't half quote me, and bring up a bunch of totally irrelevant points about the existance of two buffers in X11 and then cry when you didn't read what the other guy was actually concerned about (accidental buffer flushing) and my response therein and decided to play games with the fact that two buffers exist in X11 to try and deny that the auto-copy functionality exists as a standard feature of X11.

Originally posted by shadow skill:

Tracio please don't half quote me, and bring up a bunch of totally irrelevant points about the existance of two buffers in X11 and then cry when you didn't read what the other guy was actually concerned about (accidental buffer flushing) and my response therein and decided to play games with the fact that two buffers exist in X11 to try and deny that the auto-copy functionality exists as a standard feature of X11.

Don't worry, this is the last time I quote you. You basically avoid and divert so this discussion is a waste of time. I already made my point and the examples are very clear (and they prove you wrong).

PS If someone is interested in a more technical explanation of how *nix buffers work: http://www.jwz.org/doc/x-cut-and-paste.html

Oh I'm diverting the discussion now, come on dude I have said since you started this that his concern has to do with accidental buffer flushing

-1. I highlight text when I read to help my eye follow the words. Default installation of this would not only reduce Opera's efficieny, but screw up my clipboard, as well as introduce a bunch of bugs/regressions in future versions if it were implemented within the Opera code. Keep it at the UserJS code, please.

you have yet to explain anywhere how the presence of a second buffer changes the situation as far as X11 goes, one of the buffers will be flushed period. What if a user wanted to keep what was in the selection buffer? Back to square one are we not, that is why I keep saying if you really want to handle accidental buffer flushing you need to use a clipboard manager no matter how many buffers are available to you. You are the one who turned this into a discussion of how X11's buffers work even though ut has absolutely no bearing on my point to this person. But oh I am the one diverting the discussion..

Do you really not get the point, or are you joking??

Originally posted by shadow skill:

seriously its VERY easy to accidentally flush the explicit buffer by accidentally using one of the keyboard shortcuts in reality its no more difficult than doing so with the mouse.

I disagree. Ctrl-C or "copy" in the context menu usually only happen on conscious purpose. Randomly selecting text is easier - fewer motions necessary, and a much bigger target. Moreover, as a Windows user I am used to the fact that selecting text does nothing permanent. I might even develop the habit of unconsciously selecting text just for the joy of colors, or to support reading. I will never find pleasure in piano-playing Ctrl-C, as I know this is a dedicated shortcut.

Originally posted by shadow skill:

one of the buffers will be flushed period. What if a user wanted to keep what was in the selection buffer?

The user will never use the selection buffer for text backup. He will use the clipboard (or something else), as his mental model clearly identifies the clipboard as the more "permanent" of the two buffers.

You are right in saying that the clipboard is still not a totally safe place. But for sure it's safer than a selection buffer, or a Windows clipboard with autocopy.

No you are used to programs that do not have this functionality there is a difference. The clipboard is just a buffer it does not actually do anything sending things to the clipboard is handled by the graphical server directly or by client applications. Keep in mind that different programs may have keyboard shortcuts that use keys very close to X, C, V increasing the possibility that the user will make a mistake. Even if you use the mouse option menu the user can easily select copy or cut having intended a totally different set of options simply because their hand slips while holding the mouse. (Can't count how many times that happened to me.) While writing this I accidentally hit ctrl+I when I wanted to use shift+I simply because my finger slipped down a bit too far. Pretty much illustrates how useless splitting the buffers is for the purpose that you described because overwriting the buffer is still way too easy.

In a user's mind there is no difference between the two buffers (nor should there be) the user will just end up copying or cutting using one control interface and wonder why pasting with the other interface does not paste the item they wanted. This is the main problem with the X11 spec (Which apparently is not really official)it expects the user to remember whether or not they used the mouse or the keyboard, whether or not they used a menu command or a keyboard shortcut. That is a job for software (Clipboard managers) not the end user who has more important things to concern him or herself with.

Who said that he wanted to use the clipboard buffer?

Originally posted by sgunhouse:

Who said that he wanted to use the clipboard buffer?

I believe it was assumed as he wanted to be able to move the text to another program. If it's just within Opera it's fine.

Personally, I would not like autocopy overwriting my clipboard every time I use open URL, or just highlight text. It would not be disasterous (as I use Clipmate) but I can't imagine many users would expect using the hotclick menu to overwrite the clipboard.

All this said, in some ways, this is an issue because the default clipboard in Windows (and *nix?) are almost useless compared to a real clip manager like Clipmate.

The open URL thing isn't much of a problem because Opera has Paste and Go so you would not even need open URL. Yes the clipboard functionality of Windows and X11 are pretty much useless compared to a real clipboard manager. I find the clipboard mnemonic a bit odd when you consider the fact that normally the buffers called clipboards can only hold one item at a time, yet a clipboard in real life can hold more than just one item at a time, so you would think upon hearing its name and understanding its general purpose that the buffers should be capable of holding more than one item and being manipulated by the user. I would imagine that user expectation would actually be more in line with the functionality provided by nearly all clipboard managers in existence currently. The behavior we actually have with respect to the volatility of the clipboard is what users have learned to expect; this however does not mean that the current functionality is really appropriate since it turns the use of the word clipboard into a gross misnomer at the very least.

Originally posted by jp10558:

All this said, in some ways, this is an issue because the default clipboard in Windows (and *nix?) are almost useless compared to a real clip manager like Clipmate.

KDE comes with "klipper", a clipboard manager. It remembers the last ... seems to be 7 items on the clipboard (the "Copy" clipboard) and has an option where it can merge the clipboard with the selection buffer. (Personally, I disabled that option so that selecting text doesn't pollute my clipboard.)

I don't really use Gnome, can't speak about it in that regard. I recall seeing some sort of clipboard manager in XFCE, but couldn't tell you how it compared to klipper. The one difference ... some Windows clipboard managers can save the current state of the clipboard history as a file, klipper doesn't. But klipper does remember entries after you've logged out and then logged back in, its history is persistent.

In other words ... there is really no one default clipboard in *NIX. If you're using KDE, then by default you have klipper. If you're in some other desktop, you have whatever that desktop uses.

If I remember correctly Qt/KDE and GTK have their own api's that deal with the clipboard; if memory serves me these API's are abstractions of X11's api, X does have a clipboard program though its called Xclipboard if memory serves me. You sure Klipper doesn't retain things in the clipboard if you reboot for example?

Of course it does. I did say that it was persistent ... things will stay in the clipboard until you have too many items there and it needs to drop one - or until you tell it to clear the clipboard. Doesn't matter if you log out or reboot, they will still be there when you come back.

Oh guess I misread what you said.

So it seems this option would only make sense on Windows... Opera can't disable the selection buffer on Linux I wouldn't think. I have no idea what happens on Mac OSX so...

I wonder how much work putting in the Option would take? I just can't see a large number of Windows users jumping on this (that is, finding out how to turn it on, because it would almost certainly have to be off by default), so I wonder if the ROI would be there.

The user.js that does this is VERY short (I think the firefox extension is also implemented with javascript.) the difficulty in implementing the overall functionality is minimal; all you are really doing is telling the program to send text to a buffer when it is selected. You just have to decide which buffer to send it to. I think having an option to send it to the clipnoard or to the note buffer inside opera (which could be a default behavior) is enough to satisfy everyone.

js can replace on the clipboard?

No, js can only work within a given page. If you use js, then you can't autocopy from one tab to another.

Why not -- if I use JS to follow similar code as given on that link above (with clipboard.swf), will it not work within my webpage? Or is it supposed to work only as a UserJs?

I need to implement functionality where a part of my website is automatically copied to clipboard when the user clicks a button or a link. What are my options? I would like this JS to be within my website, instead of cumbersome instructions that require users to install some UserJs etc.

Thanks for any pointers!

That's the point ... it can work within a page where that code is running, but you won't be able to copy something from one tab to a different tab - an action which is trivial in UNIX versions.

Thanks for replying. But I am confused. How can something be copied to the "clipboard" (OS term) and not be available in another tab, and every other application that accesses the keyboard?

By not using the clipboard. All you need is some javascript variable that can act as a "scratchpad", if you're copying inside the same tab. Opera doesn't allow javascript - even userJS - to access the clipboard, so you need to store the selection somewhere else. That "somewhere else" will be something like the "scratchpad" I just mentioned, and therefore only available in the same tab.

In the future, Opera could implement an autocopy that does use the clipboard - that's what threads in this forum are for. To ask for things that are not currently possible.

I'm pretty sure Opera disallows access to the clipboard for security reasons. You'll have to get them to relax their security standards or convince them it's not a vulnerability I think before they'd change the behavior.

Originally posted by AyushJ:

Opera is really nice and good browser

Auto Copy plain text on text selection --- UserJS

Really nice, but has some problems to copy alphabetic characters in german language with "ä", "ö" and "ü" inside, I think.
Maybe you can check that? - Thanks!

((((( Strictly4me )))))

Strictly4me
Use this (unicode is supported)

Thanks this works perfect!

((((( Strictly4me )))))

Hi Lex1. Thanks for this. Can this same code be used to copy from a specific INPUT textbox?

Originally posted by IceArdor:

-1. I highlight text when I read to help my eye follow the words. Default installation of this would not only reduce Opera's efficieny, but screw up my clipboard, as well as introduce a bunch of bugs/regressions in future versions if it were implemented within the Opera code. Keep it at the UserJS code, please.

it is very simple ta make this behaviour optional as everything else in opera so that you can simply turn it off if you don't want it

I vote 110% for having opera od automatic copying to standard clipboard by highlight; it would be very usefull;

worrying about performance is really nonsense;
in case of above reaction, you are probably highlighting few words, a sentence or a line, maybe a paragraff; to copy that over takes probably some nonosecundes; a time shorter then your time to move your hand to and from the mouse ...

does this auto-copy still work ?