X Fönsterval

Val , klippa buffertar och dra-och-släpp är de mekanismer som används i X Window System för att tillåta en användare att överföra data från ett fönster till ett annat. Urval och klippbuffert används vanligtvis när en användare väljer text eller annan data i ett fönster och klistrar in i ett annat. Dra-och-släpp används när en användare väljer något i ett fönster, sedan klickar på markeringen och drar den till ett annat fönster.

Eftersom de två fönstren kan hanteras av två olika applikationer kräver dessa mekanismer två olika klienter som är anslutna till samma X-server för att utbyta data. X Window Systems kärnprotokoll innehåller några förfrågningar och händelser som är specifika för urvalsutbyte, men överföringen görs huvudsakligen med hjälp av händelsesändning och fönsteregenskaper, som inte är specifika för urvalsöverföring.

Olika typer av data kan överföras: det är vanligtvis text, men kan också vara en bild, ett nummer, en lista med objekt etc. I det följande behandlas endast fallet med text.

Aktiva och passiva val

Metoderna för att överföra data kan delas in i aktiva och passiva, beroende på om klienten som hanterar de valda uppgifterna måste aktivt delta i överföringen till en klient som begär det:

Passiv: När vissa data väljs överför klienten som hanterar fönstret där detta val görs det någonstans och behöver inte längre bry sig om det;
Aktiv: överföring av data till en klient kräver att klienten "håller" urvalet för att aktivt delta i utbytet.

Val och dra-och-släpp är aktiva mekanismer: efter att viss text har markerats i ett fönster måste klienten som hanterar fönstret aktivt stödja ett protokoll för att överföra data till applikationen som begär det. Däremot är klippbuffertar en passiv mekanism: efter att viss text har valts överförs den till en klippbuffert och förblir där även om programmet som hanterar fönstret avslutas och fönstret förstörs. X-klippbordet är en passiv mekanism som uppfattas av klienten som håller i valet, men kräver att xclipboard -klienten aktivt stöder eventuell efterföljande dataöverföring.

En fördel med aktiva mekanismer är att data kan konverteras till ett annat format innan överföringen. Speciellt kan klienten som tar emot data begära att urvalsdata konverteras till en lämplig form. Om den sändande klienten vägrar att göra det kan mottagaren begära ett annat format. Till exempel kan ett stycke text som återger HTML- kod överföras som text till en begärande som bara kan hantera text, men kan också överföras som HTML-kod om begäranden kan hantera det. Sådan förhandling av format kan inte göras genom passiva mekanismer, där klienten som håller urvalet (och ger det semantik) överför urvalet och inte är involverat i den vidare överföringen till en klient som begär det.

En annan fördel med de aktiva mekanismerna är att stora bitar av data kan överföras i en sekvens av överföringar snarare än en enda. Passiva mekanismer kräver istället att all data överförs någonstans från urvalsägaren och sedan överförs igen till klienten som begär det.

Fördelen med de passiva mekanismerna är att överföringen kan göras även efter att klienten som innehar data avslutas. Detta är inte möjligt i de aktiva mekanismerna, som kräver att klienten som innehar data aktivt deltar i överföringen.

Urval

X Window System stöder ett godtyckligt antal val; varje urval identifieras av en sträng (mer exakt, en atom ). Det mest använda valet är det PRIMÄRA valet.

Följande förfrågningar är specifika för urvalsöverföring, även om överföring också innefattar andra förfrågningar:

begära att få veta vilket fönster som äger urvalet
begära att ställa in fönstret som äger urvalet
begära att konvertera urvalet

Ägaren till markeringen är vanligtvis fönstret där den markerade texten finns, om någon. När användaren väljer text i ett fönster måste klienten som hanterar fönstret tala om för servern att fönstret är ägaren till markeringen.

När användaren försöker klistra in markeringen i ett annat fönster, initierar det fönstrets hanterare ett protokoll för att hämta den markerade texten från den andra klienten. Detta protokoll omfattar den andra och tredje begäran i listan ovan och specificeras inte av X-protokollet utan som en konvention i Inter-Client Communication Convention Manual (ICCCM).

I synnerhet börjar destinationsklienten med att fråga servern vilket fönster som äger urvalet. Sedan överför de två klienterna valet via servern. Detta utbyte involverar en egenskap hos ett fönster och en godtycklig databit kopplad till fönstret. Om innehållet i urvalet anses tillräckligt litet för att kunna överföras på en gång, är stegen som sker:

mottagaren av urvalet begär att markeringen ska konverteras, och specificerar en egenskap för ett fönster (detta kan vara fönstret där texten måste klistras in)
som svar skickar servern en SelectionRequest- händelse till den nuvarande ägaren av urvalet;
ägaren placerar den markerade texten i egenskapen för fönstret som beställaren har angett genom att skicka en ChangeProperty ; begäran till servern
ägaren skickar en förfrågan till servern om att skicka en SelectionNotify till begäran till en SelectionNotify för att meddela att urvalet har överförts
begäranden kan nu läsa urvalet i egenskapen för fönstret genom att skicka en eller flera GetProperty- förfrågningar till servern;
beställaren förstör egendomen; om ägaren har begärt att få besked om detta skickas det ett PropertyNotify- event.

Om innehållet är stort ska det överföras i bitar. I det här fallet uttrycker båda klienterna intresse för PropertyNotify- händelser: på detta sätt vet urvalsägaren när urvalet har lästs och begäranden vet när en annan del har placerats i egenskapen.

XFixes - tillägget tillåter klienter att lyssna efter valändringar.

Urklipp

Det mest använda valet är det PRIMÄRA valet och används när användaren väljer vissa data. Urklippsvalet används när användaren väljer vissa data och uttryckligen begär att de ska "kopieras" till urklippet, till exempel genom att anropa "Kopiera" under "Redigera"-menyn i en applikation . En associerad begäran om "Klistra in" resulterar i att data från valet URSLAG används.

På nivån för kärnprotokollet skiljer sig inte valen PRIMÄR och URLIPP . Men xclipboard- klienten får dem att bete sig annorlunda. Speciellt när en annan klient hävdar äganderätten till URLIPPORVALet, begär detta program och visar det i ett fönster. Ytterligare begäran om detta val hanteras av xclipboard . På så sätt överlever innehållet i urvalet att klienten har kopierat det.

Skär buffertar

Klippningsbuffertar är en annan mekanism för att överföra data, särskilt vald text. De är fönsteregenskaper för rotfönstret , som heter CUT_BUFFER1 , etc. Till skillnad från urval involverar inte klippbuffertar en direkt interaktion mellan klienter. Snarare, när text väljs i ett fönster, kopierar fönsterägaren denna text till egenskapen för rotfönstret som heter CUT_BUFFER1 . När användaren klistrar in texten i ett annat fönster läser fönsterägaren denna egenskap för rotfönstret.

Xcutsel - programmet överför data mellan urval och klippbuffertar, och xcb -programmet tillåter olika typer av åtkomst till klippbuffertarna.

Skärbuffertar anses vara föråldrade.

XDND

Dra-och-släpp i X Window System regleras av Xdnd-konventionen. När användaren drar den markerade texten till ett fönster och släpper musknappen sker utbytet av data som för det primära valet. Dra-och-släpp kompliceras av vad som händer under dragningen. När användaren drar markeringen till olika delar av skrivbordet eller ett fönster, förväntar sig användaren att kunna avgöra om text kan släppas eller inte. I synnerhet bör målet visa visuell feedback om huruvida det kommer att acceptera släppet eller inte, och markören bör ändras för att indikera åtgärden som kommer att vidtas; t.ex. kopiera eller flytta.

I Xdnd-protokollet kallas fönstret där texten är markerad och dra börjar källan ; fönstret som markören svävar över kallas målet . Kommunikationen mellan källan och målet drivs av källan eftersom källan "griper" markören. Ett utbyte mellan källa och mål är därför nödvändigt för att målet ens ska veta att dra-och-släpp pågår. Eftersom källan bestämmer markörens form måste källan få ett svar från målet för att kunna uppdatera markören. Dessutom, eftersom målet kan behöva rita ett bombsikte för att indikera var fallet kommer att inträffa, och eftersom acceptansen av fallet kan bero på den exakta platsen för markören, måste detta utbyte ske upprepade gånger när markören rör sig. Faktum är att även om markören inte rör sig måste meddelanden utbytas för att tillåta målet att rulla när markören är nära en kant av visningsområdet. Annars kommer användaren bara att kunna släppa på den synliga delen av målet.

Ett program kan ange att ett fönster kan vara målet för ett fall genom att skapa en egenskap som heter XdndAware som innehåller den högsta versionen av protokollet som programmet stöder. På så sätt kan applikationer som stöder nyare versioner falla tillbaka till äldre versioner för att fungera korrekt. Dessutom kommer alla applikationer som är skrivna utan stöd för Xdnd att ignoreras.

När markören går in i målfönstret kontrollerar källan närvaron av XdndAware -egenskapen i det fönstret. Om den här egenskapen finns, börjar ett utbyte:

källan talar om för målet att markören har angett målet medan du drar vissa data genom att skicka en händelse XdndEnter
målet kan ta reda på vilken typ av data som dras (text, bild, etc.) genom att titta på denna händelse och eventuellt genom ytterligare interaktion med källan

Medan markören är inne i målfönstret:

källan skickar XdndPosition -händelser för att tala om för målet var markören för närvarande är
målet svarar med XdndStatus- händelser för att tala om för källan om data kan släppas i den aktuella positionen
källan skickar ett meddelande XdndLeave eller XdndDrop när markören har lämnat fönstret eller knappen har släppts, respektive

Om användaren tappar, begär målet att välja från källan som vanligt. När överföringen av urvalet är avslutad skickar målet en XdndFinish -händelse för att tala om för källan att överföringen har lyckats.

Sammanfattningsvis drivs protokollet av källan, som håller målet informerat om vad som händer med markören. Som svar berättar målet för källan om en droppe skulle accepteras eller inte. Målet måste också informeras när användaren släpper musknappen, eftersom denna händelse startar en vanlig begäran om ett urval, vilket är ett protokoll som drivs av målet.

Ovanstående är beskrivningen av Xdnd-konventionen för dra-och-släpp. Olika konventioner för dra-och-släpp används i Motif, OffiX och Amulet.

XDS

Direct Save Protocol , förkortat XDS (för X Window D irect S ave Protocol), är ett programvaruprotokoll som stöder att spara filer genom att dra dem till filhanterarens fönster . XDS är byggt ovanpå XDND -protokollet.

Program

Följande program arbetar specifikt med dataöverföringsmekanismer:

xcutsel överför data från urval för att klippa buffertar eller vice versa
xclipboard, glipper ( Gnome ), parcellite ( LXDE ) och klipper ( KDE ) är urklippshanterare , kanske wmcliphist också
xcb visar innehållet i de klippta buffertarna och låter användaren manipulera dem
xselection , xclip , xsel och xcopy är kommandoradsprogram som kopierar data till eller från X-valet. xcopy har ett detaljeringsalternativ som hjälper till att felsöka X-valsproblem. parcellite har också förmågan att läsa från och skriva till specifika X-val från kommandoraden.
synergy är ett plattformsoberoende verktyg som låter dig dela ett urklipp mellan flera datorer som kör flera operativsystem
xfce4-clipman-plugin är ett "urklippshistorikplugin för Xfce4-panelen" och även en urklippshanterare
xtranslate slår upp ord i Xselection i en flerspråkig ordbok
autocutsel synkroniserar klippbuffert och urvalsbuffert

Se även

externa länkar