[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage- clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG mov
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not. But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage- clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG mov
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not. But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage- clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG mov
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not. But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage- clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG mov
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not. But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage- clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG mov
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not. But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage- clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG mov
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not. But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: MASTER Copy-Paste doesn't work if the source is closed before the paste
I'm not a programmer, so how was this fixed in firefox? What clipboard manager was it integrated with? Does that limit it to a certain DE then since this wasn't fixed in Xorg? Did they remove anything like the selection clipboard that uses the middle mouse button? -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 106644] Re: MASTER Clipboard gets lost when windows is closed
*** This bug is a duplicate of bug 11334 *** https://bugs.launchpad.net/bugs/11334 The design of the clipboard isn't rocket science here. Implement it according to the way Windows does it. If an application wants to use the selection method of copy and pasting, then it takes over the ctrl+c ctrl+x ctrl+v shortcuts since it's most likely a terminal application. But most other applications are not and the selection method should therefore be disabled in the main clipboard implementation. You may think you save time using the selection method, but it is NOT intuitive. And we wonder why at the beginning of every year someone announces that this year will be the year of the linux desktop and yet it fails to come true. This is why. Users expect stuff to be working properly and this is an example of something not working properly and the developers not caring enough because it works the way they want it to work and that's what matters to them. It doesn't matter to them that to most end users, it is broken and not working. -- MASTER Clipboard gets lost when windows is closed https://bugs.launchpad.net/bugs/106644 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug (via bug 11334). -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
The design of the clipboard isn't rocket science here. Implement it according to the way Windows does it. If an application wants to use the selection method of copy and pasting, then it takes over the ctrl+c ctrl+x ctrl+v shortcuts since it's most likely a terminal application. But most other applications are not and the selection method should therefore be disabled in the main clipboard implementation. You may think you save time using the selection method, but it is NOT intuitive. And we wonder why at the beginning of every year someone announces that this year will be the year of the linux desktop and yet it fails to come true. This is why. Users expect stuff to be working properly and this is an example of something not working properly and the developers not caring enough because it works the way they want it to work and that's what matters to them. It doesn't matter to them that to most end users, it is broken and not working. -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: Copy-Paste doesn't work if the source is closed before the paste
Some day its gonna be fixed? It's been 16 years. I can tell you what prevents me from using Linux is bugs exactly like this where the developer thinks its fine but 99% of users do not think it's fine. it's a bug. Fix it already. I don't care if its gonna take a lot of work, I'd like it fixed. Making excuses doesn't make up for the fact it's a bug, and a major one at that due to a design decision made in 1993. I can tell you I won't be using linux until the developers behind it start taking it seriously by fixing major design problems just like this. Audio and video is another one and just being able to install a driver/module in linux is another one. What good is open source software if it doesn't work correctly? -- Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: MASTER Copy-Paste doesn't work if the source is closed before the paste
I say it should be fixed in the X.org layer. Otherwise you have DE's reinventing the wheel here when they shouldn't have to. Here is how it should be working: 1. Copy or cut something into the clipboard. 2. It copies directly into ram without needing the original app open after it's done. 3. If it is too large, put a message that it is unable to copy that large amount. It can test this by estimating how much memory it is going to take up. 4. When you close that app it stays there. 5. An app can set a flag that checks if its still in memory when exiting, then upon closing the app, the Xorg layer of the clipboard will warn the user that the app is leaving this in memory and asks the user if they want to clear it upon exiting the app. It can pause the exiting of the app to do this. This way we don't have to have a hard coded value. It is up to the app to correctly set this flag such as audio/video/image editing apps. 6. When the user has made up their mind of what they want to do, then the app finishes exiting. The API needs the following features: 1. Estimation of how large the object is going to be in memory so that it doesn't take up all the users memory. A good percentage I think is 90% here. 2. A flag that is set that when the app has exited, X.org is to ask the user if they want to keep the clipboard contents in memory or delete them. When the user has answered this, then the app in question is allowed to continue exiting. 3. Confirmation that the object has been copied into the clipboard or if it hasn't, the reason why which goes to point 1. 4. When you cut an object, only delete the original if you paste the new object. 5. Object type that is copied into the clipboard. This is so that we can identify the object that is in clipboard and possibly identify which app would be appropriate to be able to use it in. To expand on this object type, we can have 5 basic types: 1. Text 2. Raw Audio 3. Raw Video 4. Raw Images 5. A file Just an idea here, what do the rest of you think? -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: MASTER Copy-Paste doesn't work if the source is closed before the paste
Oh yeah and I almost forgot, remove the selection copy method. If an individual app wants to do it fine, but don't make it system wide by default. This way those who use terminal apps who want selection can still keep it. Then it doesn't interfere with any other app. Putty on windows works this way, so it can be done. -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: MASTER Copy-Paste doesn't work if the source is closed before the paste
Well said Patrick. So now it comes down to this: Fix it. We as end users expect this to be working the way windows and OS X have implemented it. If it's not gonna be fixed to that specification, then I won't even think of using it. There's a reason why software companies can sell software and have the public buy it. Because if it is not usable to the end user, the end user isn't gonna use it. And that company will then go out of business. What incentive here does linux have? As for just explaining it to the end user such as me why it doesn't work isn't a fix. If you have to explain how to do something, it's not designed correctly. If you wonder why OS X is the way it is, it is because they look at how you do something in it and they question it, how can we make this easier? This is the way Linux should be headed. Knowing there is a work around is not fixing it, it is avoiding it. -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 264805] Re: clipboard is emptied when closing firefox
*** This bug is a duplicate of bug 11334 *** https://bugs.launchpad.net/bugs/11334 Christoph actually it is a duplicate. Please read the summary of the bug this was set to be a duplicate of and you'll see it is a duplicate. -- clipboard is emptied when closing firefox https://bugs.launchpad.net/bugs/264805 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug (via bug 11334). -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 264805] Re: clipboard is emptied when closing firefox
*** This bug is a duplicate of bug 11334 *** https://bugs.launchpad.net/bugs/11334 Firefox is simply obeying how xorg has the clipboard implemented. Just like it does in Windows and in OS X. Fixing it on a per application basis is not smart and creates more work instead of fixing it at the xorg level. That's the aim of the bug this was made a duplicate of. Please look at that bug instead as it will do more in the end. -- clipboard is emptied when closing firefox https://bugs.launchpad.net/bugs/264805 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug (via bug 11334). -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: MASTER Copy-Paste doesn't work if the source is closed before the paste
I wish this would get fixed in the Xorg layer instead. Fixing it on a per application basis takes more time then it should need to. And fixing it at the DE layer is a mere bandaid solution, meaning when it finally is fixed in the Xorg layer, the fix in the DE layer won't matter. -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 11334] Re: MASTER Copy-Paste doesn't work if the source is closed before the paste
I dont think so. So I submitted a bug report: https://bugs.freedesktop.org/show_bug.cgi?id=25220 Anyone want to add to it, feel free. ** Bug watch added: freedesktop.org Bugzilla #25220 https://bugs.freedesktop.org/show_bug.cgi?id=25220 -- MASTER Copy-Paste doesn't work if the source is closed before the paste https://bugs.launchpad.net/bugs/11334 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a subscriber of a duplicate bug. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
