Hi; I read the textual description, mostly because after 20 years of using X11 I've never even seen an implementation of the SECONDARY selection protocol outside of Motif applications. GTK+ itself does not implement anything with the 'SECONDARY' atom, unlike the 'PRIMARY' one — unfortunately, if I may add.
The GTK+ team is pretty much following the behaviour set out by the freedesktop.org clipboard specification: https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt which was written down in 2000-ish and has been the de facto standard for the free software desktop since then. Again: I think it's perfectly fine to let applications take care of this, especially on X11. The whole PRIMARY/SECONDARY shenanigans are pretty much the definition of unportable X11 behaviour anyway — i.e. the Windows and macOS backends do not have any support for PRIMARY/SECONDARY selections, even if they are part of the available atoms in GDK, and Wayland had to get an additional protocol extension to implement PRIMARY behaviour — again, unfortunately. Ciao, Emmanuele. On 21 August 2016 at 12:07, Paul Davis <p...@linuxaudiosystems.com> wrote: > Emmanuele, > > did you watch his video? > > On Sun, Aug 21, 2016 at 3:07 AM, Emmanuele Bassi <eba...@gmail.com> wrote: >> >> Hi; >> >> thanks for your email. >> >> GTK+, as a project, tracks bugs and enhancements in Bugzilla - >> https://Bugzilla.gnome.org/enter_bug.cgi?product=gtk%2b - instead of the >> mailing list, which is only meant for discussion. >> >> Additionally, the latest stable version of GTK+ is 3.20, and we plan to >> release GTK+ 3.22 by next month. >> >> We still (optionally) support the PRIMARY selection on the X11 backend, >> and some compatibility layer for it on Wayland, but we have no plans on >> adding support for the SECONDARY selection, as it's both barely specified >> and, like the PRIMARY, highly confusing for anybody who is not well-versed >> in 20+ years of use of textual interfaces on the X Windows System. >> Personally, I would have jettisoned the PRIMARY selection a long time ago as >> well, but apparently a very vocal minority is still holding tight to that >> particular Easter egg. Adding support for the even more esoteric SECONDARY >> selection on the X11 backend when we're trying to move the Linux world >> towards the more modern and less legacy-ridden Wayland display system would >> be problematic to say the least, and an ill fit for the majority of >> graphical user experiences in use these days. >> >> It should be entirely possible to add support for the SECONDARY selection >> inside specific applications, like text editors; or in specific libraries, >> like VTE for terminal emulators. It would definitely make more sense than >> trying to apply it to all text entry widgets in GTK+. >> >> Ciao, >> Emmanuele. >> >> >> On Saturday, 20 August 2016, Charles Lindsey <c...@clerew.man.ac.uk> wrote: >>> >>> For over 20 years, I have been using the secondary-selection (a standard >>> feature of the X-Windows system) when editing texts, using the Solaris >>> operating system on Sun Hardware. Recently, I have switched to Linux on i86 >>> hardware, and have been horrified to find that this valuable feature is not >>> supported by modern toolkits and editors. The world seems to have forgotten >>> what it was meant for, and yet I believe it is the best thing since sliced >>> bread. >>> >>> This is not the place to explain what the secondary-selection does, and >>> why it should be used more widely. To see that, I invite you to visit my >>> website at >>> http://www.cs.man.ac.uk/~chl/secondary-selection.html >>> which I hope will persuade you that something needs to be done about it. >>> >>> Furthermore, to illustrate how it is used, I have implemented an >>> Experimental Extension to GTK-3 so that people can try it out for themselves >>> and to see how useful it can be for constructing texts (and particularly >>> program texts, where there is a common requirement to grab existing bits of >>> code - perhaps even just identifiers - from other places, whether in the >>> same document or from outside). >>> >>> My implementation is based on gtk+-3.10.8, because I am using Ubuntu >>> 14.04LTS "Trusty Tahr", though it may well work on other Linux versions. Yes >>> I know 3.10.8 is ancient, but I don't expect my code, which is pretty hairy, >>> to be fit for immediate incorporation in current versions of gtk. But it now >>> works well enough for it to be tested more widely, and if people like it, >>> then I would be happy to join the Developer Team and to do the job properly. >>> >>> So I invite you guys to look at my website, download my code and give it >>> a try. I am also making this known on various other lists, because unless >>> people try it out (and hopefully like it), there can be no pressure to take >>> it further. >>> >>> Share and Enjoy! >>> >>> -- >>> Charles H. Lindsey ---------At Home, doing my own >>> thing------------------------ >>> Tel: +44 161 436 6131 Web: >>> http://www.cs.man.ac.uk/~chl >>> Email: c...@clerew.man.ac.uk Snail: 5 SK8 3JU, U.K. >>> PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 >>> AB A5 >>> _______________________________________________ >>> gtk-devel-list mailing list >>> gtk-devel-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> >> >> >> -- >> https://www.bassi.io >> [@] ebassi [@gmail.com] >> >> _______________________________________________ >> gtk-devel-list mailing list >> gtk-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> > -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
