Клипбордът е един от основните елементи на графичния потребителски интерфейс,

Клипбордът е един от главните детайли на графичния потребителски интерфейс, само че е сложен за реализация. Има толкоз доста подводни камъни, че в никакъв случай повече няма да можете да произнесете думата „ copypaste “ с пренебрежително изражение. Съществуват хиляди приложения и формати за данни. Невъзможно е да се обезпечи цялостно конвертиране на всичко във всичко.

В някои случаи данните въобще на никое място не се записват при натискане на Ctrl+C. А Ctrl+V ще върне NULL. Shit happens, както се казва…

В някои стратегии може да се копира единствено текст, в други може да се маркира графика, другаде се поддържат файлове за копиране/вмъкване и така нататък Има доста нюанси. Нека се опитаме да обърнем внимание на главните моменти на клипборда за Windows и Linux.

X11

Графичният стек на Linux е формиран от огромен брой разнообразни детайли, които са обединени в монолитна архитектура и по някакъв чудодеен метод работят взаимно без каквито и да било проблеми.

Така или другояче, клипбордът в X11 работи по по-различен метод, спрямо другите операционни системи. Тук се основава усещане за две самостоятелни клипборда. Единият е посредством бързите клавиши като Ctrl+C/V (или Ctrl/Shift+Ins), а другият – посредством кликване с мишката – маркирането с мишката е изцяло задоволително – кликването с колелцето вмъква текста. Ако копирате данните в буфера с гореща клавишна композиция, можете да ги поставяте единствено с клавиатурата. А в случай че копирате с мишката, можете да ги вмъкнете посредством клик със междинното колело. Но от време на време работят и двата метода, т.е. можете да копирате текста в буфера с мишката и да го поставите с клавишна композиция.

Документацията удостоверява, че X11 в действителност има няколко самостоятелни клипборда (тук те са наречени селекции). Те даже не са два, а могат да бъдат колкото си желаете. Идеята е, че тези селекции по прицип съставляват метода, по който клиентите споделят между тях. Самите клиенти би трябвало да решат между тях кой буфер ще употребяват. Така да вземем за пример, в случай че пишете някакъв клиент за Linux, като притежател на селекция (SelectionOwner) можете да въведете личния си буфер за клипборд и да се надявате, че останалите ще го възприемат.

Тоест, работата с клипборда в общи линии наподобява по следния метод:

Клиентът 1 декларира на Х-сървъра, че има избран клипборд буфер във тип на SelectionOwner В някакъв миг от времето клиентът 2 можа да изиска от сървъра наличието на буфер 1, само че в тъкмо избран формат Х-сървърът получава тази поръчка и я препраща към съответния собственик Притежателят на буфера на клипборда (клиентът) непосредствено изпраща поисканите данни в инструкции формат към клиент 2, само че когато или в случай че въобще може (има и такива случаи) Клиентът 2 връща на клиента 1 удостоверение за получените данни

Всичко наподобява напълно просто и разумно, с минимално взаимоотношение с ядрото на операционната система. Но в реалност може да има несъответствия и усложнения. Най-важното е, че няма безусловно никаква гаранция, че клиент 1 в миналото ще изпрати желаните данни, още по-малко в инструкции формат.

Как по този начин за потребителя цялата тази система наподобява като два изолирани буфера – един за горещите клавиши и един за мишката? Въпросът тук е в идентификацията на буферите. Вътрешно те са случайни номера, а външно (за клиентите) това са три разновидността:

PRIMARY – буферът на междинния бутон на мишката SECONDARY  – съществува, само че през днешния ден на процедура не се използва CLIPBOARD – буферът за Ctrl+C и Ctrl+V

Често стратегиите, работещи в X11, основават невидими програмни прозорци с единствената цел да задържат (прихванат) избран систематичен буфер. По принцип това може да се направи и с забележим прозорец, само че е по-лесно с незабележим.

В реалност наличието на буфера в действителност се трансферира посредством програмни прозорци, а точно посредством запис в свойствата на прозореца (там се слага лимитирано количество данни). В този смисъл работата на буферите е сходна на тази на прозорците – в X11 няма условие тези прозорци да работят на еднакъв хост или посредством еднакъв протокол. Така да вземем за пример на доктрина копирането би трябвало да работи в другите стратегии, даже в случай че клиентите са на разнообразни компютри и са свързани към еднакъв X сървър през интернет. Всъщност, тъкмо по този начин и става.

Така работят нещата в X11: той е единствено медиатор сред клиентите, който има минимално присъединяване в прехвърлянето на данните от клипборда. X11 даже не разполага с вграден управител за тези данни.

Wayland

Както вероятно всички знаят, за замяната на Х11 бе създаден протокола, по-точно прозоречния управител Wayland, където клипбордът работи по малко по-различен метод.

Работата с клипборда в спецификациите на Wayland е разказана със същата характерна терминология (Selection – клипборд, clipboard – един от клипбордовете, неповторим atom идентификатор и т.н.).

Но в случай че се вгледаме, всичко е направено напълно разумно и опростено.

По сходен метод е проведена и собствеността върху буфер от избран вид. Когато натиснете Ctrl+C, програмата просто взема клипборд от избран вид и декларира за съществуването на данни в избран формат (например image/png, text/x-moz-url1 или text/plain). В този миг на никое място не се изпращат или съхраняват данни. Така че, при липса на специфичен управител на клипборда, данните ще бъдат изгубени при затваряне на прозореца на съответното приложение или при изтриването им в него.

Прихващането на буфера е позволено единствено за основния прозорец. Когато някой нов прозорец прихване буфер, той получава известие от предходния притежател на буфера за наличността на данните и техния формат. След това идва стъпката на проникване на данните „ от буфера “ (в кавички, тъй като към този момент разбрахме, че буферът е нереално понятие), т.е. данните, маркирани за прекопирване. И по този начин, вторият клиент прави поръчка (създава файлов дескриптор), като показва формата, в който желае да получи данните. Този формат може да не е тъкмо същият като горния, като в този случай той ще получи единствено част от данните или нищо.

Въпреки дългата си еволюция API за клипборда във Wayland надалеч не е идеален и тази подсистема към момента се нуждае от външен управител или програмна библиотека, с цел да работи вярно.

Windows

Windows ползва същата идея за „ притежател на буфер “. Собственикът е всяко приложение, което е изпратило информация в буфера по общоприетия метод. Поддържат се следните систематични извиквания:

OpenClipboard(hwnd) изпраща информация за прозореца, който би трябвало да стане новият притежател на буфера. EmptyClipboard() изтрива предходното наличие от буфера SetClipboardData() за всяка част от данните, които желаете да поставите в буфера (по исторически аргументи това извикване може да се употребява даже от стратегии, които не разполагат с буфер) CloseClipboard() алармира за края на обработката на данни Честито, вие сте новият притежател на буфера

При опит на прозорец на трета страна да получи достъп до буфера неговият притежател получава няколко известия. Сред тях могат да бъдат WM_RENDERFORMAT (забавено визуализиране на данните за буфера, до момента в който не бъдат непосредствено поискани – прегледано по-долу), WM_RENDERALLFORMATS (част от последователността за заличаване на прозореца, в случай че той към момента има клипборда при унищожаването му) или WM_DESTROYCLIPBOARD (изчистване наличието на буфера).

Схемата за метод а за прочитане на данните от клипборда е почти следната:

Извикването OpenClipboard(hwnd) изпраща информация за прозореца, който прочита данни от клипборда Извикването GetClipboardData() за приемането на данните от клипборда Извикването Close­Clipboard() за индикация, че четенето на данни е завършило

Според Реймънд Чен, чиновник на Microsoft с 25-годишен стаж, в случай че всички употребяват предложената нагоре скица, Windows ще работи както би трябвало. За страдание стратегиите на трети страни постоянно се пробват да нарушат конвенцията, а API разрешава запис в непознат буфер (в случая клипборд). Това води до проблеми.

Това е почти методът, по който работи и клипбордът на macOS (всъщност изобретателите на концепцията за клипборда се считат основателите на компютъра Mac/Lisa, а за Mac има отлични мениджъри с многомесечно търсене в историята като доста положителни образци за това са ClipBuddy, Alfred и Raycast).

Освен това в Оценка за съвместимост Windows 10/11 има Linux-подобен метод за работа с клипборда, при който се употребява забавен метод – данните на никое място не се записват, а единствено се означават като налични, което е направено най-вече за спестовност наизуст. Това е упоменатият нагоре способ за отсрочено рендиране WM_RENDER­FORMAT. И точно това е повода, в случай че в клипборда на Windows бъде заимствуван огромен диапазон от кафези на Excel, а по-късно се направи опит тази информация да бъде вмъкната в текстов тип, то нищо не се получава и всичко завършва неуместно. И още, във Windows 10, през месец юни 2022 година, с едно от обновяванията бе въведено ограничаване от 30 секунди за отсроченото рендиране. Ако в продължение на това време данните не съумеят да се обръщат в новия формат, в който би трябвало да бъдат вмъкнати, то клипбордът връща NULL.

Заключение

По този метод клипбордът е абстракция от високо равнище, която разказва на понятен език механизма за прекачване на данни сред стратегиите ( клиентите, прозорците). В Linux въобще няма буфер, там не се копира нищо, данните единствено се маркират за прекачване. Това е доста образован метод – потреблението наизуст се свежда до нула.

Недостатъкът също е явен – когато пандизите истинския прозорец, информацията от клипборда също ще бъде изгубена и няма да може да бъде вмъкната на никое място другаде (въпреки че специфичните клипборд мениджъри вземат решение този проблем).

В другите операционни системи е решено да се жертва дребна част от продуктивността (и от паметта) в името на удобството на потребителя, защото копирането и вмъкването са едни от най-използваните функционалности от елементарните хора, а загубата на данни е неприемлива.

Интересно е, че създателят на истинската публикация не се стопира на съответните клипборд мениджъри, които неведнъж улесняват работата на потребителите. За Linux дистрибуциите това са CopyQ, Kupfer (просто съвършен за Linux Mint), Diodon, Klipper и други.

За операционната система Windows клипборд мениджърите също са доста, като измежду тях още веднъж е CopyQ, следван от ClipClip, ClipMate и ClipX. Последният ClipX има най-вече позитивни рекомендации и съвсем всички се насочват точно към него. Той запомня цялата история на данните от клипборда, в това число изображения, кафези на електронни таблици и така нататък

Програмите от този жанр мощно форсират въвеждането на текст, и понижават броя на грешките, тъй като огромен брой от въвежданите думи, изключително в случай че са по-големи, се избират от комфортен лист и няма потребност да се вкарват посредством клавиатурата или микрофона. По този метод се обезпечава една доста по-удобна и удобна работа с персоналния компютър.