All I know for certain, is that I'm using Gnome 2.6, and I don't have any problems with any of my Gnome or GTK+ applications in regards to the clipboard buffers. Yet, when I used applications not based on a particular toolkit or set of libraries this wasn't the case.
Well, Konqueror is definitely based on a particular toolkit (Qt) and set of libraries (the KDE libraries), so it'd be in a different category from the applications you describe as having problems with GTK+ applications, and other KDE applications fall into the same category as Konqueror, so the next question is "did you see clipboard problems with KDE applications?" It might be that the "applications not based on a particular toolkit or set of libraries" are those based on lesser-known toolkits or those whose developers have written their own toolkits (or equivalents - if, for example, you have more than one scrollbar in your application, you might have routines to draw scrollbars and respond to input in scrollbars, even if you don't call them part of a toolkit), and those toolkits might not implement the X PRIMARY and CLIPBOARD selections the same way Qt 3.0 and later, for example, do.
However, I have noticed that some applications don't seem to use the 2 X clipboard buffers in the same way.
They might, as noted, be based on toolkits that don't (or don't yet) implement PRIMARY and CLIPBOARD as per the X clipboard explanation.
So it seems that using applications based on the same libraries and toolkit work better together.
Applications based on the same libraries and toolkit are more likely to implement PRIMARY and CLIPBOARD compatibly with each other than are applications based on arbitrary different libraries and toolkits; however, there may be specific pairs of toolkits that implement them in the same way, and a pair of applications, one using toolkit A from that pair and one using toolkit B from that pair, are probably nearly as likely, and perhaps as likely, to work together as well as applications using the same toolkit, so from "it seems that using applications based on the same libraries and toolkit work better together" one cannot necessarily conclude that applications not based on the same libraries and toolkits won't work well together - there might be cases where that's true, but it's probably unwise to generalize from those cases, especially if one of the toolkits isn't one of the major ones.
For me it just disappeared the moment I installed KDE 3.0. Maybe Debian packages somehow magically did the trick for me, I don't know.
What did the trick for you was switching to a version of KDE that used Qt 3.0, that being the first version of Qt that implemented the arguably-better way of managing the X11 PRIMARY and CLIPBOARD selections.
But since then only Konsole copies on selection, and it copies to its own internal buffer rather than the global KDE one,
Or maybe it just sets the PRIMARY selection to the selected text - as X11 applications should.
In windows it's just cntl-c, select,cntl-v,select,cntl-v,... repeat.
In many X11 applications it's just cntl-c, select, cntl-v, select, cntl-v,... repeat. In others, it's not, but that's arguably a misfeature or a bug, at least for GUI applications (if you're running a terminal-based application, it's not so easy - but the same problem exists on Windows with applications running inside a Command Prompt window).
If you're using Gnome as your desktop, and Konq as your browser, ya, you might have an issue.
If you're using GNOME as your desktop and Konqueror as your browser, and ^C/^X/^V don't work in Konqi or between Konqi and other applications, whether they're GTK+-based or Qt-based (regardless of whether they're full-blown GNOME or KDE applications), either Qt or GTK+ has an issue, and you should report that issue in the hopes that it gets fixed. Those toolkits should be using the PRIMARY and CLIPBOARD selections in ways that should make ^C/^X/^V cut/copy/paste and mouse-based "paste current selection" Just Work. If they're not, or if an application is screwing up, that's a bug (or, at best, a misfeature).
Unless you have an alternative mouse on mouse laptops there is no middle click, hence no decent way to copy + paste in linux applications.
^C and ^V have worked for me in that case, for at least some applications.
(That's on FreeBSD, not Linux, but that's not what makes the difference, as they're X11 applications in both cases.)
Konsole doesn't support ^C/^X/^V, at least not by default, for the same reason why the Windows Command prompt window doesn't - but they both have menu items to let you do copies and pastes.
Gnome, KDE, and WindowMaker all have clipboard managers that integrate & abstract the various toolkit clipboards.
GTK+ and Qt all have clipboard managers that, at least in current versions, use the same clipboard - the X11 CLIPBOARD selection, as has been present in X11 for, I think, close to 20 years, dating back to reasonably early versions of the ICCCM - and that's why you can copy from Qt apps and paste into GTK+ apps. See the X clipboard explanation.
If you need some "clipboard manager" application to make that work, that's either a screwup in GTK+ or Qt or, more likely, a screwup in a GTK+-based or Qt-based application.
A simple, high-level, question: why can't the Window Manager (Gnome, KDE, etc.) be made to handle both schemes, and allow the user to switch between them, but not let both scheme be active at once?
Because that would suck for people who use both ^C/^X/^V and middle-mouse-button paste-current-selection?
Things would probably be much improved if
all applications where ^C/^X/^V could be made to work for cut/copy/paste made them work (I say "could" because ^C wouldn't work well in terminal emulators - and wouldn't work well in a Windows command prompt window, either, which is why it's not used for ^C in those windows - and, at least on UNIXes, ^X and ^V probably can't be conveniently grabbed by a terminal emulator, either), and applications such as terminal emulators offer some other way to cut to the CLIPBOARD selection/copy to the CLIPBOARD selection/paste the CLIPBOARD selection;
any application where selecting text copies it to the CLIPBOARD selection (as opposed to just making it the PRIMARY selection) is fixed not to do so by default (so that selecting stuff doesn't copy it to the CLIPBOARD selection used by ^C/^X/^V).
UNIX-under-Windows might be impossible to make perfect for everybody, but making the X CLIPBOARD selection and the Windows clipboard mirror each other (which would make Windows and X11 applications that support ^C/^X/^V work together as expected) would help; I think that's what Hummingbird's X11 does.
A problem is that there's no "paste current selection", like the UNIX+X11 middle-mouse-button operation, in Windows, so, for example, Hummingbird's X11 lets you configure it to automatically copy the X11 PRIMARY selection (i.e., the stuff you select with the mouse in an X11 application that supports the PRIMARY selection) to the Windows clipboard when, I think, the focus leaves the X11 window (always doing that could screw up cut/copy/paste between X11 applications).
In konsole windows you have to use the right-click menu.
...just like {MS-DOS,Command} Prompt windows in Windows, where you can't use ^C to copy (although there is some keyboard accelerator for it, just not ^C), for the same reason - it's the "interrupt" character, for historical reasons dating back to various OSes from Digital Equipment Corporation.
Ctrl-C is bound to interrupt on any modern terminal
...including the Windows MS-DOS Prompt window (or, as it's called in the Shiny New World of NT 5.x, the Command Prompt window), which is why ^C isn't "copy" in those windows, either.
The Mac has the "command" key, and Command+{X,C,V} are used for cut/copy/paste, so ^C can be used for "interrupt" in Terminal and Command+C can be used for "copy".
You know, the "in 64-bit mode" also applies to IA64, as while IA64 can hardly be described has having evolved from a 32-bit architecture (resemblence to PA-RISC notwithstanding),
...said resemblance not being a huge surprise, given that I think it started out as an HP project.
it supports a 32-bit userland (for example, running HP-UX with HP tools).
...although the 32-bit userlands that IA-64 supports are 32-bit PA-RISC (via, I think, binary-to-binary translation) and x86 (via hardware and, I think, either a current or planned binary-to-binary translation mechanism), not any 32-bit flavor of IA-64. It might also support 64-bit PA-RISC (again, via translation), and it might be amusing to see binary-to-binary translation for x86-64.:-)
HP are porting OpenVMS to IA-64, with Alpha->IA-64 translation (they might be doing VAX->IA-64 by VAX->Alpha->IA-64, using the existing VAX->Alpha translator).
ou can map anything like you ever want in x-windows(and heck, in linux too).
Even on ADB keyboards? I.e., the Linux keyboard driver on Macs and/or the XFree86 keyboard handling code on Macs deals with the "sticky" caps lock key (as mentioned on the Web site for uControl:
Technical Question: I thought caps lock key event behavior was wired into the hardware; hence, there's no key up for caps lock. How did you do it?
After playing with iJect, I started to believe the same thing. When caps lock on was turned on, you got a key down event. When caps lock was turned off, you got a key up event. At that point I thought I was sunk. No one wants a sticky control key. Fortunately, in between those two events are "special" events which can be directly correlated with the regular key up, key down events. So by looking at both the regular and special events, you can make the caps lock simulate a standard key up/down sequence.
The uControl page thanks "the Linux PPC folks" for information on how to do "ADB muckery" to eliminate the need to hold down the "fn" key to get function keys, so perhaps information on how to deal with the Caps Lock key was also passed by the LinuxPPC people to the uControl people or by the uControl people to the LinuxPPC people (or independently discovered by both, or passed on to both by some third source, or...).
And, although "a program to do it only exists in Mac OS X" is (probably) erroneous", "modern keyboards are USB, use one you like" (the statement to which I was responding) isn't necessarily the right answer, either (as somebody might have a laptop and want to swap Caps Lock and Control on its built-in keyboard, or might want a cheaper fix for their Caps Lock/Control problem than a replacement keyboard - although I have managed to get used to the standard "ctrl" key placement even when using {Micro}EMACS).
On: Alpha, HPPA64, PPC64, IA64, x86-64 (in 64bit mode), MIPS (in 64bit mode), you get the "Hooray".
And on SPARC V9 (in 64-bit mode) and zArchitecture (in 64-bit mode).
The "in 64-bit mode" also applies to PA-RISC 2.0 ("HPPA64") and PPC64, as those evolved from 32-bit architectures and support 32-bit as well as 64-bit binaries, just as x86-64, SPARC V9, and MIPS - or, rather, the 64-bit version of MIPS - evolved from 32-bit architectures and support 32-bit binaries. Most OSes for them that support 64-bit mode probably also support 32-bit mode.
On OSes such as OS X and older versions of some other OSes, only 32-bit mode is supported.
If they bring the CLR and.NET to Xbox 2, then any application targeting the CLR and.NET (and/or Windows.Forms bindings) will work on Xbox 2.
That was one thought I had. That doesn't necessarily help with existing games, but perhaps something based on Virtual PC for Mac (similar host CPU, different host OS) would be used for that.
For an example, look at IBM's AS/400 line, I forget what the hell they're called now
eServer iSeries.
but they've been running the same bytecode since day one, but the platform underneath has been several different POWER processors and even a PowerPC I believe.
And a non-POWER-family line of CPUs before that (running an instruction set called IMPI, which has been claimed to be a System/3x0-ish instruction set).
While they're not very different from one another, the same executables run on any AS/400 system and they actually work.
Yes, the executables are in machine code for a pseudo-machine, and are translated into native code for the machine on which they're being run; see the book Inside The AS/400.
I.e., the machine won't automatically wake up when you try to ssh into it; you need to send it a Magic Packet(TM) to wake it up. A packet-matching wakeup might be able to match incoming unicast packets to the machine, broadcast ARP requests asking for the MAC address corresponding to the machine's IP address, and other packets that it would need to respond to, so that attempting to ssh into it would wake it up, without making it respond to various random broadcasts and multicasts for which it wouldn't have to wake up (e.g., a broadcast ARP request for somebody else's MAC address, assuming it doesn't have to reply to that for e.g. proxy ARP purposes).
However, wake-on-Magic-Packet(TM) might be sufficient for the purposes of the person to whom you responded; I think one purpose for which it was intended was to allow administrators to wake up sleeping machines in order to do various remote administrative operations - including the remote software updates that they wanted to do.
In the event, it turned out to impossible to write an OS for it due to many reasons: virtually-addressed caches, imprecise interrupts, multiple instruction decode modes, etc.
I assume "impossible" is a rhetorical term here meaning "more difficult", as
Sun had a number of machines with virtually-indexed, virtually-tagged caches, and an already-written OS (SunOS) was ported to machines with that cache without too much pain;
I have the impression that other machines with imprecise interrupts have run UN*Xes;
this article says that the Oki 7300 workstations used the i860 (I seem to remember there was an i860-based workstation at one point), probably using some UN*X-flavored OS.
Actually, there might be people at Apple familiar with that format, given that, as far as I know, it was invented by NeXT, not Sun, and adopted by Sun later.
Possibly you and I can get together somewhere at a stoplight and see if your 04 Prius is faster than 04 Accord EX.
You might have misread what the original poster was probably saying.
He said:
And go ahead and buy one of those shiny new priuses. The 2004 model is bigger (about as big as a 2004 Accord), faster, more efficient, and has the added trunk space of a hatchback.
The only mention of an 04 Accord is when discussing the size; "bigger", "faster", and "more efficient" probably refer to an '04 Prius compared with the previous version of the Prius - according to this review, relative to the original Prius the '04 is 6.9 inches longer in wheelbase, 6.3 inches longer overall, and taller and wider (and heavier) as well, has a bit more horsepower (and I've seen claims that it's faster 0-60mph), and has higher EPA fuel economy.
The V6 EX does accelerate much faster - according to an edmunds.com comparison site, it's 7.5s 0-60mph vs. 10.37 for the Prius. The site doesn't give the acceleration for the 4-cylinder EX. The interior sizes are a mixed bag - the Prius wins on front and rear headroom, rear leg room, and luggage capacity, and the Accord wins on front and rear shoulder and hip room and front leg room. (The Prius, not surprisingly, wins on fuel economy.)
Is this going to be like the LIE-Nuks Lee-nooks, thing?
Hopefully not. For one thing, "Ethereal" wasn't named after somebody whose name is pronounced in a way different from the way the same name is pronounced when it's then name of a character in "Peanuts".:-)
Slashdot Mirror
Well, Konqueror is definitely based on a particular toolkit (Qt) and set of libraries (the KDE libraries), so it'd be in a different category from the applications you describe as having problems with GTK+ applications, and other KDE applications fall into the same category as Konqueror, so the next question is "did you see clipboard problems with KDE applications?" It might be that the "applications not based on a particular toolkit or set of libraries" are those based on lesser-known toolkits or those whose developers have written their own toolkits (or equivalents - if, for example, you have more than one scrollbar in your application, you might have routines to draw scrollbars and respond to input in scrollbars, even if you don't call them part of a toolkit), and those toolkits might not implement the X PRIMARY and CLIPBOARD selections the same way Qt 3.0 and later, for example, do.
They might, as noted, be based on toolkits that don't (or don't yet) implement PRIMARY and CLIPBOARD as per the X clipboard explanation.
Applications based on the same libraries and toolkit are more likely to implement PRIMARY and CLIPBOARD compatibly with each other than are applications based on arbitrary different libraries and toolkits; however, there may be specific pairs of toolkits that implement them in the same way, and a pair of applications, one using toolkit A from that pair and one using toolkit B from that pair, are probably nearly as likely, and perhaps as likely, to work together as well as applications using the same toolkit, so from "it seems that using applications based on the same libraries and toolkit work better together" one cannot necessarily conclude that applications not based on the same libraries and toolkits won't work well together - there might be cases where that's true, but it's probably unwise to generalize from those cases, especially if one of the toolkits isn't one of the major ones.
What did the trick for you was switching to a version of KDE that used Qt 3.0, that being the first version of Qt that implemented the arguably-better way of managing the X11 PRIMARY and CLIPBOARD selections.
Or maybe it just sets the PRIMARY selection to the selected text - as X11 applications should.
In many X11 applications it's just cntl-c, select, cntl-v, select, cntl-v, ... repeat. In others, it's not, but that's arguably a misfeature or a bug, at least for GUI applications (if you're running a terminal-based application, it's not so easy - but the same problem exists on Windows with applications running inside a Command Prompt window).
If you're using GNOME as your desktop and Konqueror as your browser, and ^C/^X/^V don't work in Konqi or between Konqi and other applications, whether they're GTK+-based or Qt-based (regardless of whether they're full-blown GNOME or KDE applications), either Qt or GTK+ has an issue, and you should report that issue in the hopes that it gets fixed. Those toolkits should be using the PRIMARY and CLIPBOARD selections in ways that should make ^C/^X/^V cut/copy/paste and mouse-based "paste current selection" Just Work. If they're not, or if an application is screwing up, that's a bug (or, at best, a misfeature).
^C and ^V have worked for me in that case, for at least some applications.
(That's on FreeBSD, not Linux, but that's not what makes the difference, as they're X11 applications in both cases.)
Konsole doesn't support ^C/^X/^V, at least not by default, for the same reason why the Windows Command prompt window doesn't - but they both have menu items to let you do copies and pastes.
GTK+ and Qt all have clipboard managers that, at least in current versions, use the same clipboard - the X11 CLIPBOARD selection, as has been present in X11 for, I think, close to 20 years, dating back to reasonably early versions of the ICCCM - and that's why you can copy from Qt apps and paste into GTK+ apps. See the X clipboard explanation.
If you need some "clipboard manager" application to make that work, that's either a screwup in GTK+ or Qt or, more likely, a screwup in a GTK+-based or Qt-based application.
Because that would suck for people who use both ^C/^X/^V and middle-mouse-button paste-current-selection?
Things would probably be much improved if
UNIX-under-Windows might be impossible to make perfect for everybody, but making the X CLIPBOARD selection and the Windows clipboard mirror each other (which would make Windows and X11 applications that support ^C/^X/^V work together as expected) would help; I think that's what Hummingbird's X11 does.
A problem is that there's no "paste current selection", like the UNIX+X11 middle-mouse-button operation, in Windows, so, for example, Hummingbird's X11 lets you configure it to automatically copy the X11 PRIMARY selection (i.e., the stuff you select with the mouse in an X11 application that supports the PRIMARY selection) to the Windows clipboard when, I think, the focus leaves the X11 window (always doing that could screw up cut/copy/paste between X11 applications).
...just like {MS-DOS,Command} Prompt windows in Windows, where you can't use ^C to copy (although there is some keyboard accelerator for it, just not ^C), for the same reason - it's the "interrupt" character, for historical reasons dating back to various OSes from Digital Equipment Corporation.
...including the Windows MS-DOS Prompt window (or, as it's called in the Shiny New World of NT 5.x, the Command Prompt window), which is why ^C isn't "copy" in those windows, either.
The Mac has the "command" key, and Command+{X,C,V} are used for cut/copy/paste, so ^C can be used for "interrupt" in Terminal and Command+C can be used for "copy".
...said resemblance not being a huge surprise, given that I think it started out as an HP project.
...although the 32-bit userlands that IA-64 supports are 32-bit PA-RISC (via, I think, binary-to-binary translation) and x86 (via hardware and, I think, either a current or planned binary-to-binary translation mechanism), not any 32-bit flavor of IA-64. It might also support 64-bit PA-RISC (again, via translation), and it might be amusing to see binary-to-binary translation for x86-64. :-)
HP are porting OpenVMS to IA-64, with Alpha->IA-64 translation (they might be doing VAX->IA-64 by VAX->Alpha->IA-64, using the existing VAX->Alpha translator).
Even on ADB keyboards? I.e., the Linux keyboard driver on Macs and/or the XFree86 keyboard handling code on Macs deals with the "sticky" caps lock key (as mentioned on the Web site for uControl:
The uControl page thanks "the Linux PPC folks" for information on how to do "ADB muckery" to eliminate the need to hold down the "fn" key to get function keys, so perhaps information on how to deal with the Caps Lock key was also passed by the LinuxPPC people to the uControl people or by the uControl people to the LinuxPPC people (or independently discovered by both, or passed on to both by some third source, or...).
And, although "a program to do it only exists in Mac OS X" is (probably) erroneous", "modern keyboards are USB, use one you like" (the statement to which I was responding) isn't necessarily the right answer, either (as somebody might have a laptop and want to swap Caps Lock and Control on its built-in keyboard, or might want a cheaper fix for their Caps Lock/Control problem than a replacement keyboard - although I have managed to get used to the standard "ctrl" key placement even when using {Micro}EMACS).
Even the ones on iBooks and PowerBooks? (No, those aren't 64-bit, but this particular thread isn't particularly 64-bit oriented....)
And on SPARC V9 (in 64-bit mode) and zArchitecture (in 64-bit mode).
The "in 64-bit mode" also applies to PA-RISC 2.0 ("HPPA64") and PPC64, as those evolved from 32-bit architectures and support 32-bit as well as 64-bit binaries, just as x86-64, SPARC V9, and MIPS - or, rather, the 64-bit version of MIPS - evolved from 32-bit architectures and support 32-bit binaries. Most OSes for them that support 64-bit mode probably also support 32-bit mode.
On OSes such as OS X and older versions of some other OSes, only 32-bit mode is supported.
They're PowerPC-based, so of course they have EIEIO (Enforce In-Order Execution of I/O) - see PowerPC(TM) Microprocessor Family - The Programming Environment for 32-Bit Microprocessors.
That was one thought I had. That doesn't necessarily help with existing games, but perhaps something based on Virtual PC for Mac (similar host CPU, different host OS) would be used for that.
eServer iSeries.
And a non-POWER-family line of CPUs before that (running an instruction set called IMPI, which has been claimed to be a System/3x0-ish instruction set).
Yes, the executables are in machine code for a pseudo-machine, and are translated into native code for the machine on which they're being run; see the book Inside The AS/400.
Shouldn't that be
(Thank you, Slashdot, for complaining that my comment has too few characters per line. Hopefully this will make you happy.)
There's also
It is - see, for example, a knowledgebase article on it - but that's "wake on magic packet" (or Magic Packet(TM)) wake-on-LAN, not the more general packet matching wakeup that some network interfaces support.
I.e., the machine won't automatically wake up when you try to ssh into it; you need to send it a Magic Packet(TM) to wake it up. A packet-matching wakeup might be able to match incoming unicast packets to the machine, broadcast ARP requests asking for the MAC address corresponding to the machine's IP address, and other packets that it would need to respond to, so that attempting to ssh into it would wake it up, without making it respond to various random broadcasts and multicasts for which it wouldn't have to wake up (e.g., a broadcast ARP request for somebody else's MAC address, assuming it doesn't have to reply to that for e.g. proxy ARP purposes).
However, wake-on-Magic-Packet(TM) might be sufficient for the purposes of the person to whom you responded; I think one purpose for which it was intended was to allow administrators to wake up sleeping machines in order to do various remote administrative operations - including the remote software updates that they wanted to do.
The KDE Free Qt Foundation?
I assume "impossible" is a rhetorical term here meaning "more difficult", as
Actually, there might be people at Apple familiar with that format, given that, as far as I know, it was invented by NeXT, not Sun, and adopted by Sun later.
Yeah, but what about this is scunthorpe?
You might have misread what the original poster was probably saying.
He said:
The only mention of an 04 Accord is when discussing the size; "bigger", "faster", and "more efficient" probably refer to an '04 Prius compared with the previous version of the Prius - according to this review, relative to the original Prius the '04 is 6.9 inches longer in wheelbase, 6.3 inches longer overall, and taller and wider (and heavier) as well, has a bit more horsepower (and I've seen claims that it's faster 0-60mph), and has higher EPA fuel economy.
The V6 EX does accelerate much faster - according to an edmunds.com comparison site, it's 7.5s 0-60mph vs. 10.37 for the Prius. The site doesn't give the acceleration for the 4-cylinder EX. The interior sizes are a mixed bag - the Prius wins on front and rear headroom, rear leg room, and luggage capacity, and the Accord wins on front and rear shoulder and hip room and front leg room. (The Prius, not surprisingly, wins on fuel economy.)
Hopefully not. For one thing, "Ethereal" wasn't named after somebody whose name is pronounced in a way different from the way the same name is pronounced when it's then name of a character in "Peanuts". :-)
See the Ethereal FAQ item on the pronunciation; you're right, they're wrong.
No, it doesn't. See the SOSP paper on Xen (and the Xen Web site).