GNOME Bugzilla – Bug 680327
Make GTK+ PRIMARY selection handling match freedesktop specification (pretty please)
Last modified: 2018-02-10 03:32:16 UTC
Bug 333514 says: Make GTK+ PRIMARY selection handling match freedesktop specification But there is such a mangle of issues in a series of reports that nothing gets fixed. So let's try again. One and only one issue please. Basic issue : X11 cut and paste mechanism is being perverted by GTK+ , let's fix this bug once and for all and make it work as defined , rather than playing the Microsoft game of redefining standards. http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt >> Application authors should follow the following guidelines to get correct behavior: - selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD - middle mouse button should paste PRIMARY, never CLIPBOARD ... Apps that follow these guidelines give users a simple mental model to understand what's going on. PRIMARY is the current selection. Middle button pastes the current selection. CLIPBOARD is just like on Mac/Windows. You don't have to know about PRIMARY if you're a newbie. >> The whole point of the X11 (PRIMARY) cut and paste mechanism is to have consistent system wide (X11-wide) FAST cut and paste. This is a beautiful feature that is several orders of magnitude faster that farting around with context menus or dropping the mouse to use the keyboard, It is distinct from the usual Windozian cut and paste mechanism and should remain so. Having two independent mechanisms can be useful and means Mac/Windoze users get no surprises and X11 users get the speed this separate mechanism was designed to provide. I am submitting this via firefox and find myself restrained to using windozian cut and paste since GTK+ has borked this feature. Please can we have some attempt to adhere to standards rather than break them and fix this simple and highly ergonomic feature?
if you call it 'Windoze' it makes it *very* hard to take any of your grievances correctly. you're also assuming that Firefox is a GTK+ application - which is incorrect. finally, you seem to be under the impression that the PRIMARY/CLIPBOARD selection split in X11 is a good idea; it's not. you've also file 631195 already - opening multiple bugs is not a good idea. *** This bug has been marked as a duplicate of bug 631195 ***
NO ! This is not a duplicate of that bug. The other bug specifically referred to the cursor position not being affected by a PRIMARY paste. If fact the problems I reported there no longer seem to happen, despite the fact that not one comment was posted in the intervening two years, it seems to be fixed. I will check that situation more thoroughly before marking the other one as fixed. >> if you call it 'Windoze' it makes it *very* hard to take any of your grievances correctly. >> That has *nothing* whatsoever to do with whether there is a bug or not, but if you are looking for an excuse, you'll find one. I do not have a "grievance" , I am reporting a spec violation bug. >> finally, you seem to be under the impression that the PRIMARY/CLIPBOARD selection split in X11 is a good idea; it's not. >> Perhaps that should be your first comment , not your finally. Is there some bug report where that is dealt with (other than the previous mangle of mixed issues that did not get addressed either)? This was precisely my point about redefining standards, so if this is dealt with elsewhere I'll be happy to dupe this one to something that it is a dupe of.
Emmanuele Bassi >> you're also assuming that Firefox is a GTK+ application - which is incorrect. >> Oh yeah? https://bugzilla.gnome.org/show_bug.cgi?id=629878#c25 André Klapper [developer] 2012-07-21 09:31:00 UTC (In reply to comment #23) > I'm using gtk+-3.2.4 and have been chasing this firefox icon issue for some > time. Firefox uses GTK 2: https://bugzilla.mozilla.org/show_bug.cgi?id=627699
(In reply to comment #3) > Emmanuele Bassi > >> > you're also assuming that Firefox is a GTK+ application - which is incorrect. > >> > > Oh yeah? yeah. Firefox uses GDK code for creating drawing surfaces, and renders GTK widgets offscreen in order to get native-looking controls - but it's not a GTK+ application, in the same way LibreOffice is not a GTK+ application.
So are you saying that the way FF uses PRIMARY is independent from the way GTK+ uses PRIMARY?
(In reply to comment #5) > So are you saying that the way FF uses PRIMARY is independent from the way GTK+ > uses PRIMARY? Yes. And it's been a source of issues for a while. There isn't much that gtk can do, at this point.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.