Haai Habr!
Vir my is hierdie frase soortgelyk aan hallo wêreld, aangesien ek uiteindelik by my eerste publikasie uitgekom het. Ek het hierdie wonderlike oomblik lank uitgestel, aangesien daar niks was om oor te skryf nie, en ek wou ook nie aan iets suig wat al 'n klomp kere gesuig is nie. Oor die algemeen wou ek vir my eerste publikasie iets oorspronkliks hê, nuttig vir ander en wat 'n soort uitdaging en probleemoplossing bevat. En nou kan ek dit deel. Kom ons praat nou oor alles in orde.
Entry
Dit het alles begin toe ek 'n tyd gelede Linux Mint op my werkrekenaar afgelaai het. Baie mense weet waarskynlik dat Pidgin met die Sipe-inprop 'n heeltemal geskikte plaasvervanger vir Microsoft Lync (nou Skype vir besigheid genoem) vir Linux-stelsels is. As gevolg van die besonderhede van my werk, moet ek dikwels aan SIP-konferensies deelneem, en toe ek 'n Windows-werker was, was die inskrywing van konferensies elementêr: ons ontvang 'n uitnodiging per pos, klik op die aanmeldskakel, en ons is gereed om te gaan .
Wanneer jy na die donker kant van Linux oorgeskakel het, het alles ietwat meer ingewikkeld geraak: jy kan natuurlik ook by konferensies in Pidgin aanmeld, maar om dit te doen moet jy die sluit aan by konferensie-opsie in die kieslys in die eienskappe van jou SIP-rekening kies en in die venster wat oopmaak, voeg 'n skakel na die konferensie in of voer die naam van die organiseerder en conf id in. En na 'n rukkie het ek begin dink: "is dit moontlik om dit op een of ander manier te vereenvoudig?" Ja, jy kan dalk sê, hoekom de hel het jy dit nodig? Ek sal eerder op Windows sit en nie my gedagtes blaas nie.
Stap 1: Navorsing
"As jy 'n gril in jou kop kry, kan jy dit nie met 'n stok uitslaan nie," het Nekrasov gesê in sy werk "Who Lives Well in Rus'."
So, sodra die gedagte in my kop opgekom het, het na 'n ruk die eerste idee vir implementering ontstaan. Alles het eenvoudig gelyk - jy moet toegang tot skakels onderskep - installeer 'n plaaslike webtoepassingsproses op jou motor by 127.0.0.1 en voeg in /etc/hosts 'n statiese inskrywing by vir die maatskappydomein waardeur jy die konferensie betree, wat na localhost wys. Vervolgens moet hierdie webbediener die skakel verwerk wat daarheen gekom het en dit op een of ander manier binne Pidgin oordra (ek sal dadelik sê dat ek op hierdie stadium nog geen idee gehad het hoe om dit enigsins daaraan te gee nie). Die oplossing ruik natuurlik na krukke, maar ons is programmeerders, krukke maak ons nie bang nie (shit).
Toe het ek toevallig op een of ander manier die uitnodigingskakel in Google Chrome oopgemaak (en gewoonlik gebruik ek altyd Mozilla Firefox). En tot my verbasing het die webblad heeltemal anders gelyk - daar was geen vorm vir die invoer van gebruikersdata nie en onmiddellik nadat die bladsy betree is was daar 'n versoek om iets deur oop te maak XDG-ope. Net vir die pret klik ek “ja” en 'n foutboodskap verskyn - die skakel lync15:confjoin?url=https://meet.company.com/user/confid kan nie oopgemaak word nie. Hmm. Watter soort xdg-open is dit en wat het dit nodig om sulke skakels oop te maak? 'n Nadoodse lesing van die dokumentasie het aan die lig gebring dat dit 'n GUI-hanteerder is wat gepaardgaande toepassings help laat loop hetsy met protokolle vir die uri-skema of met spesifieke lêertipes. Assosiasies word gekonfigureer via mimiektipe kartering. Ons sien dus dat ons besig is met 'n soektog na 'n ooreenstemmende toepassing vir 'n uri-skema genaamd lync15 en die skakel word deurgegee na xdg-open, wat dit dan, in teorie, moet deurgee na een of ander toepassing wat verantwoordelik is vir hierdie tipe skakel. Wat ons natuurlik nie in ons stelsel het nie. Indien nie, wat doen hulle dan in die oopbronwêreld? Dis reg, ons sal dit self skryf.
Verdere onderdompeling in die wêreld van Linux en veral in die bestudering van hoe die grafiese dop (desktop-omgewing, DE) werk, terloops, ek het Xfce in Linux Mint, het gewys dat toepassings en die mime-tipe wat daarmee geassosieer word, gewoonlik direk geskryf word in kortpadlêers met die uitbreiding .desktop. Wel, hoekom nie, ek skep 'n eenvoudige toepassing-kortpad, wat eenvoudig 'n bash-skrif moet begin en die argument wat daarna aan die konsole oorgedra is, moet uitvoer, ek verskaf slegs die kortpadlêer self:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Ek begin xdg-open vanaf die konsole, gee dieselfde skakel deur wat van die blaaier af kom en ... bummer. Weereens sê dit dat dit nie die skakel kan verwerk nie.
Soos dit blyk, het ek nie die gids van geassosieerde mime-tipes met my toepassing opgedateer nie. Dit word gedoen met 'n eenvoudige opdrag:
xdg-mime default lync.desktop x-scheme-handler/lync15
wat bloot die lêer wysig ~/.config/mimeapps.list.
Poging nommer 2 met die xdg-open oproep - en weer mislukking. Niks, probleme maak ons nie bang nie, maar stook net ons belangstelling. En gewapen met al die krag van bash (d.w.s. opsporing), duik ons kop eerste in ontfouting. Dit is belangrik om hier op te let dat xdg-open net 'n dopskrif is.
bash -x xdg-open $url
Deur die uitset te ontleed nadat dit opgespoor is, word dit 'n bietjie duidelik dat beheer dan oorgedra word na ekso-oop. En dit is reeds 'n binêre lêer en dit is moeiliker om te verstaan hoekom dit 'n onsuksesvolle terugkeerkode terugstuur wanneer 'n skakel daarna in 'n argument deurgee.
Nadat ek deur die internals van xdg-open gekyk het, het ek uitgevind dat dit verskeie omgewingsparameters ontleed en beheer verder deurgee na óf na sommige instrumente om lêerskakels spesifiek vir 'n spesifieke DE oop te maak, óf dit het 'n terugvalfunksie oop_generies
open_xfce()
{
if exo-open --help 2>/dev/null 1>&2; then
exo-open "$1"
elif gio help open 2>/dev/null 1>&2; then
gio open "$1"
elif gvfs-open --help 2>/dev/null 1>&2; then
gvfs-open "$1"
else
open_generic "$1"
fi
if [ $? -eq 0 ]; then
exit_success
else
exit_failure_operation_failed
fi
}
Ek sal vinnig 'n klein hack hier insluit met ontleding van die geslaagde argument en of ons spesifieke substring daar geleë is lync15:, dan dra ons dadelik beheer oor na die funksie oop_generies.
Poging nommer 3 en dink jy dit het gewerk? Ja, nou, natuurlik. Maar die foutboodskap het reeds verander, dit is reeds vordering - nou het hy vir my gesê dat die lêer nie gevind is nie en in die vorm van 'n lêer het hy vir my dieselfde skakel geskryf wat as 'n argument deurgegee is.
Hierdie keer het dit geblyk 'n funksie te wees is_lêer_url_of_pad, wat die lêerskakel wat na die invoer: file:// of die pad na die lêer of iets anders oorgedra word, ontleed. En die tjek het nie reg gewerk nie as gevolg van die feit dat ons voorvoegsel (url-skema) nommers het, en die gewone uitdrukking kontroleer net die karakterstel wat bestaan uit :alpha: kolletjies en strepies. Na raadpleging van die rfc3986-standaard vir eenvormige hulpbronidentifiseerder Dit het duidelik geword dat Microsoft hierdie keer niks skend nie (hoewel ek so 'n weergawe gehad het). Net die karakterklas :alpha: bevat slegs letters van die Latynse alfabet. Ek verander vinnig die gewone tjek na alfanumeries. Klaar, jy is ongelooflik, alles begin uiteindelik, beheer nadat alle tjeks aan ons skriftoepassing gegee is, ons skakel word op die konsole vertoon, alles is soos dit moet wees. Hierna begin ek vermoed dat al die probleme met ekso-oop ook te wyte is aan die validering van die skakelformaat as gevolg van die nommers in die skema. Om die hipotese te toets, verander ek die mime-tipe registrasie van die toepassing na net 'n skema lync en voila - alles werk sonder om die open_xfce-funksie te ignoreer. Maar dit sal ons op geen manier help nie, want die webblad om die konferensie in te gaan skep 'n skakel met lync15.
So, die eerste deel van die reis is voltooi. Ons weet hoe om 'n skakeloproep te onderskep en dan moet dit op een of ander manier verwerk word en binne Pidgin deurgegee word. Om te verstaan hoe dit intern werk wanneer data via 'n skakel in die "join a conference"-kieslys ingevoer word, het ek die Git-bewaarplek van die Sipe-projek gekloon en gereed gemaak om weer in die kode te duik. Maar toe is ek gelukkig aangetrokke deur die skrifte in die katalogus bydrae/dbus/:
- sipe-join-konferensie-met-uri.pl
- sipe-join-konferensie-met-organiseerder-en-id.pl
- sipe-oproep-foonnommer.pl
- SipeHelper.pm
Dit blyk dat die Sipe-inprop beskikbaar is vir interaksie via dbus (desktop bus) en binne die skrifte is daar voorbeelde van aansluiting by 'n konferensie via 'n skakel, hetsy deur die organiseerder se naam en conf-id, of jy kan 'n oproep via sip inisieer . Dit is presies wat ons gemis het.
Stap 2. Implementering van 'n outoaansluiting-hanteerder
Aangesien daar klaargemaakte voorbeelde in Pearl is, het ek besluit om net te gebruik sipe-join-konferensie-met-uri.pl en pas dit 'n bietjie aan om by jouself te pas. Ek kan in Pearl skryf, so dit het geen besondere probleme veroorsaak nie.
Nadat ek die skrif afsonderlik getoets het, het ek sy oproep in die lêer geskryf lync.desktop. En dit was 'n oorwinning! Wanneer die konferensieaansluitbladsy binnegegaan word en xdg-open toelaat om te loop, sal die konferensie-opspringvenster van Pidgin outomaties oopmaak. Hoe bly ek was.
Aangemoedig deur die sukses, het ek besluit om dieselfde te doen vir my hoofblaaier, Mozilla Firefox. Wanneer jy deur die jakkals aanmeld, maak 'n bladsy vir magtiging oop en heel onder is daar 'n knoppie sluit aan met behulp van kantoorkommunikator. Sy was die een wat my aandag getrek het. Wanneer jy in die blaaier daarop klik, gaan dit na die adres:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
waarop hy vriendelik vir my sê dat hy nie weet hoe om dit oop te maak nie en miskien het ek nie 'n gepaardgaande aansoek vir so 'n protokol nie. Wel, ons is al hierdeur.
Ek registreer vinnig my skrif aansoek ook vir die uri skema conf en... niks gebeur nie. Die blaaier bly kla dat daar geen toepassing is wat my skakels hanteer nie. In hierdie geval werk die oproep van xdg-open vanaf die konsole met parameters perfek.
"Stel pasgemaakte protokol-hanteerder in firefox" - Ek het aanlyn gegaan met hierdie vraag. Nadat ons deur verskeie besprekings oor stackoverflow gegaan het (en waar sou ons daarsonder wees), lyk dit of die antwoord gevind is. Jy moet 'n spesiale parameter skep in about: config (natuurlik vervang foo met conf):
network.protocol-handler.expose.foo = false
Ons skep dit, maak die skakel oop en... geen geluk nie. Die blaaier, asof niks gebeur het nie, sê dat dit nie ons toepassing ken nie.
Ek lees die amptelike dokumentasie oor die registrasie van 'n protokol van Mozilla, daar is 'n opsie om assosiasies in die gnome lessenaar self te registreer (foo vervang natuurlik met conf):
gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true
Ek registreer, maak die blaaier oop... en weer die baard.
Hier vang 'n reël uit die dokumentasie my oog:
Volgende keer as jy op 'n skakel van protokol-tipe foo klik, sal jy gevra word met watter toepassing om dit oop te maak.
— Semyon Semenych
- Ahh
Ons klik nie op die skakel nie, maar die webblad verander bloot venster.ligging via javascript. Ek skryf 'n eenvoudige html-lêer met 'n skakel na die conf-protokol, maak dit oop in die blaaier, klik op die skakel - Yos! 'n Venster maak oop wat vra in watter toepassing ons ons skakel moet oopmaak, en daar het ons reeds ons Lync-toepassing in die lys - ons het dit eerlik op alle moontlike maniere geregistreer. Daar in die venster is daar 'n merkblokkie "onthou die keuse en maak altyd skakels oop in ons toepassing", merk dit, klik ok. En dit is die tweede oorwinning – die konferensievenster maak oop. Terselfdertyd werk die opening van konferensies nie net wanneer jy op 'n skakel klik nie, maar ook wanneer jy van die aansluitingsbladsy wat ons benodig na die konferensie beweeg.
Toe het ek nagegaan en parameters uitgevee netwerk.protokol-hanteerder.expose.conf het geensins die werking van die protokol in Fox beïnvloed nie. Die skakels het aanhou werk.
Gevolgtrekking
Ek het al my werk opgelaai na die GitHub-bewaarplek; skakels na alle bronne sal aan die einde van die artikel wees.
Ek sal belangstel om terugvoer te ontvang van diegene wat my werk wil gebruik. Ek moet dadelik daarop let dat ek al die ontwikkeling net vir my Linux Mint-stelsel gedoen het, so sommige ander verspreidings of rekenaars werk dalk nie in daardie weergawe nie. Of eerder, ek is selfs amper seker hiervan, want ek het net 1 funksie in xdg-open gepatch wat net met my DE verband hou. As jy ondersteuning vir ander stelsels of rekenaars wil byvoeg, skryf vir my trekversoeke op Github.
Die hele projek het 1 aand geneem om te voltooi.
verwysings:
Bron: will.com