Hej Habr!
Por mi ĉi tiu frazo similas al saluto mondo, ĉar mi finfine alvenis al mia unua eldonaĵo. Mi prokrastis ĉi tiun mirindan momenton dum longa tempo, ĉar estis nenio por skribi, kaj mi ankaŭ ne volis suĉi ion, kio jam estis suĉita amaso da fojoj. Ĝenerale, por mia unua eldonaĵo mi volis ion originalan, utilan al aliaj kaj enhavantan ian defion kaj problemon solvantan. Kaj nun mi povas dividi ĉi tion. Nun ni parolu pri ĉio en ordo.
eniro
Ĉio komenciĝis kiam antaŭ iom da tempo mi elŝutis Linux Mint sur mia laborkomputilo. Multaj homoj verŝajne scias, ke Pidgin kun la kromaĵo Sipe estas tute taŭga anstataŭaĵo por Microsoft Lync (nun nomata Skype por komerco) por Linuksaj sistemoj. Pro la specifaĵoj de mia laboro, mi ofte devas partopreni en SIP-konferencoj, kaj kiam mi estis Windows-laboristo, eniri konferencojn estis elementa: ni ricevas inviton per poŝto, klaku sur la ensaluta ligilo, kaj ni pretas iri. .
Kiam vi ŝanĝas al la malluma flanko de Linukso, ĉio fariĝis iom pli komplika: kompreneble vi ankaŭ povas ensaluti en konferencojn en Pidgin, sed por fari tion vi devas elekti la opcion aliĝi al konferenco en la menuo en la propraĵoj de via SIP-konto kaj en la fenestro kiu malfermiĝas, enigu ligilon al la konferenco aŭ enigu la nomon de la organizanto kaj konfidu. Kaj post iom da tempo mi ekpensis: "ĉu eblas iel simpligi ĉi tion?" Jes, vi povus diri, kial diable vi bezonas ĉi tion? Mi preferas sidi sur Vindozo kaj ne krevigi mian menson.
Paŝo 1: Esploro
"Se vi ricevas iom da kaprico en via kapo, vi ne povas bati ĝin per paliso", diris Nekrasov en sia verko "Kiu bone vivas en Rus'".
Do, kiam la penso venis en mian kapon, post iom da tempo ekestis la unua ideo por efektivigo. Ĉio ŝajnis simpla - vi devas kapti aliron al ligiloj — instalu lokan TTT-aplikprocezon sur via aŭto ĉe 127.0.0.1 kaj en /etc/hosts aldonu senmovan eniron por la kompania domajno per kiu vi eniras la konferencon, montrante al localhost. Poste, ĉi tiu retservilo devas prilabori la ligilon kiu venis al ĝi kaj iel translokigi ĝin ene de Pidgin (mi tuj diros, ke en ĉi tiu etapo mi ankoraŭ tute ne havis ideon kiel doni ĝin al ĝi). La solvo, kompreneble, odoras kiel lambastonoj, sed ni estas programistoj, lambastonoj ne timigas nin (feko).
Poste, hazarde, mi iel malfermis la invitligon en Google Chrome (kaj kutime mi ĉiam uzas Mozilla Firefox). Kaj je mia surprizo, la retpaĝo aspektis tute alie - ne estis formo por enigi uzantajn datumojn kaj tuj post eniro de la paĝo estis peto malfermi ion pere. xdg-open. Nur por amuzo, mi klakas "jes" kaj aperas erarmesaĝo - la ligilo lync15:confjoin?url=https://meet.company.com/user/confid ne povas esti malfermita. Hmm. Kia xdg-open estas ĉi tio kaj kion ĝi bezonas por ke tiaj ligiloj malfermiĝu? Postmorta legado de la dokumentaro rivelis ke ĝi estas GUI-traktilo kiu helpas prizorgi rilatajn aplikojn aŭ kun protokoloj por la uri-skemo aŭ kun specifaj dosiertipoj. Asocioj estas agorditaj per mim-speca mapado. Do ni vidas, ke ni faras serĉon por kongrua aplikaĵo por uri-skemo nomita lync15 kaj la ligo estas pasita al xdg-open, kiu tiam, en teorio, devus pasi ĝin al iu aplikaĵo kiu respondecas pri ĉi tiu tipo de ligo. Kion, kompreneble, ni ne havas en nia sistemo. Se ne, do kion ili faras en la malfermkoda mondo? Ĝuste, ni mem skribos ĝin.
Plia mergo en la mondo de Linukso kaj precipe en studado de kiel funkcias la grafika ŝelo (tabla medio, DE), cetere, mi havas Xfce en Linux Mint, montris, ke aplikaĵoj kaj la mim-speco asociita kun ĝi estas kutime skribitaj rekte en ŝparvojaj dosieroj kun la etendo .desktop. Nu, kial ne, mi kreas simplan aplikaĵan ŝparvojon, kiu simple devus lanĉi bash-skripton kaj eligi la argumenton transdonitan al ĝi al la konzolo, mi provizas nur la ŝparvojan dosieron mem:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Mi lanĉas xdg-open de la konzolo, pasante la saman ligilon kiu venas de la retumilo kaj... mizero. Denove ĝi diras, ke ĝi ne povas prilabori la ligon.
Kiel rezultas, mi ne ĝisdatigis la dosierujon de rilataj mim-tipoj kun mia aplikaĵo. Ĉi tio estas farita per simpla komando:
xdg-mime default lync.desktop x-scheme-handler/lync15
kiu simple redaktas la dosieron ~/.config/mimeapps.list.
Provo numero 2 kun la xdg-open alvoko - kaj denove malsukceso. Nenio, malfacilaĵoj ne timigas nin, sed nur nutras nian intereson. Kaj armitaj per la tuta potenco de bash (t.e. spurado), ni plonĝas kapunue en senararigadon. Gravas rimarki ĉi tie, ke xdg-open estas nur ŝela skripto.
bash -x xdg-open $url
Analizante la produktaĵon post spurado, iĝas iom klare, ke kontrolo tiam estas transdonita al ekso-malfermita. Kaj ĉi tio jam estas binara dosiero kaj estas pli malfacile kompreni kial ĝi resendas malsukcesan revenkodon kiam oni pasas ligon al ĝi en argumento.
Trarigardinte la internon de xdg-open, mi eksciis, ke ĝi analizas diversajn mediajn parametrojn kaj transdonas kontrolon plu aŭ al iuj iloj por malfermi dosierligojn specifajn por aparta DE, aŭ ĝi havas rezervan funkcion. open_generic
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
}
Mi rapide enkonstruos ĉi tie malgrandan hakon kun analizo de la pasita argumento kaj se nia specifa subĉeno troviĝas tie lync15:, tiam ni tuj transdonas kontrolon al la funkcio open_generic.
Provu numeron 3 kaj ĉu vi pensas, ke ĝi funkciis? Jes, nun, kompreneble. Sed la erarmesaĝo jam ŝanĝiĝis, tio jam estas progreso - nun li diris al mi, ke la dosiero ne estas trovita kaj en formo de dosiero li skribis al mi la saman ligilon pasigita kiel argumento.
Ĉi-foje ĝi montriĝis funkcio is_file_url_or_path, kiu analizas la dosierligon pasitan al la enigo: file:// aŭ la vojo al la dosiero aŭ io alia. Kaj la kontrolo ne funkciis ĝuste pro tio, ke nia prefikso (url-skemo) havas nombrojn, kaj la regula esprimo nur kontrolas la signaron konsistantan el :alpha: punktoj kaj streketoj. Post konsultado de la rfc3986-normo por unuforma rimeda identigilo Evidentiĝis, ke ĉi-foje Microsoft nenion malobservas (kvankam mi havis tian version). Nur la signoklaso :alpha: enhavas nur literojn de la latina alfabeto. Mi rapide ŝanĝas la regulan ĉekon al alfanombra. Farita, vi estas mirinda, ĉio finfine komenciĝas, kontrolo post ĉiuj kontroloj estas donita al nia skripto-aplikaĵo, nia ligilo estas montrata sur la konzolo, ĉio estas kiel ĝi devus esti. Post ĉi tio, mi komencas suspekti, ke ĉiuj problemoj kun exo-open ankaŭ ŝuldiĝas al la validigo de la ligoformato pro la nombroj en la skemo. Por testi la hipotezon, mi ŝanĝas la mimspecan registradon de la aplikaĵo al nur skemo lync kaj voila - ĉio funkcias sen superregado de la funkcio open_xfce. Sed ĉi tio neniel helpos nin, ĉar la retpaĝo por eniri la konferencon kreas ligilon kun lync15.
Do, la unua parto de la vojaĝo finiĝis. Ni scias kiel kapti ligan vokon kaj tiam ĝi devas esti iel prilaborita kaj pasita ene de Pidgin. Por kompreni kiel ĝi funkcias interne kiam vi enigas datumojn per ligilo en la menuo "aliĝu al konferenco", mi klonis la Git-deponejon de la projekto Sipe kaj pretiĝis denove plonĝi en la kodon. Sed poste, feliĉe, min allogis la skriptoj en la katalogo kontribui/dbus/:
- sipe-join-konferenco-kun-uri.pl
- sipe-aliĝu-konferenco-kun-organizanto-kaj-id.pl
- sipe-voko-telefonnumero.pl
- SipeHelper.pm
Rezultas, ke la Sipe-kromaĵo disponeblas por interagado per dbus (skribotabla buso) kaj ene de la skriptoj estas ekzemploj de aliĝo al konferenco per ligilo, ĉu per la nomo kaj konf-id de la organizanto, aŭ vi povas iniciati vokon per sip. . Ĝuste ĉi tio mankis al ni.
Paŝo 2. Efektivigo de aŭtojoin-traktilo
Ĉar estas pretaj ekzemploj en Pearl, mi decidis nur uzi sipe-join-konferenco-kun-uri.pl kaj modifu ĝin iomete laŭ vi mem. Mi povas skribi per Perlo, do ĝi ne kaŭzis apartajn malfacilaĵojn.
Post testi la skripton aparte, mi skribis ĝian alvokon en la dosieron lync.desktop. Kaj ĝi estis venko! Enirante la konferencan aliĝpaĝon kaj permesante al xdg-open funkcii, la konferenca ŝprucfenestro de Pidgin malfermus aŭtomate. Kiel mi ĝojis.
Kuraĝigite de la sukceso, mi decidis fari la samon por mia ĉefa retumilo, Mozilla Firefox. Kiam vi ensalutas per la vulpo, paĝo por rajtigo malfermiĝas kaj ĉe la malsupro estas butono aliĝi uzante oficejan komunikilon. Ŝi estis tiu, kiu kaptis mian atenton. Kiam vi alklakas ĝin en la retumilo, ĝi iras al la adreso:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
al kiu li afable diras al mi, ke li ne scias kiel malfermi ĝin kaj, eble, mi ne havas asociitan aplikaĵon por tia protokolo. Nu, ni jam travivis ĉi tion.
Mi rapide registras mian skripto-aplikaĵon ankaŭ por la uri-skemo konf kaj... nenio okazas. La retumilo daŭre plendas, ke ne ekzistas aplikaĵo, kiu pritraktas miajn ligilojn. En ĉi tiu kazo, voki xdg-open de la konzolo kun parametroj funkcias perfekte.
"Agordu laŭmendan protokoltraktilon en Firefox" - Mi interrete kun ĉi tiu demando. Trapasinte plurajn diskutojn pri stackoverflow (kaj kie ni estus sen ĝi), ŝajnas, ke la respondo estis trovita. Vi devas krei specialan parametron en pri: config (kompreneble anstataŭigante foo per conf):
network.protocol-handler.expose.foo = false
Ni kreas ĝin, malfermas la ligilon kaj... ne tia sorto. La retumilo, kvazaŭ nenio estus okazinta, diras, ke ĝi ne konas nian aplikaĵon.
Mi legas la oficialan dokumentaron pri registri protokolon de Mozilo, ekzistas eblo registri asociojn en la gnoma labortablo mem (anstataŭigante foo per conf, kompreneble):
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
Mi registras, malfermas la retumilon... kaj denove la barbon.
Jen linio el la dokumentaro kaptas mian atenton:
La venontan fojon, kiam vi alklakas ligilon de protokolo-tipo foo, oni demandos vin per kiu aplikaĵo malfermi ĝin.
— Semjon Semenych
- Ahh
Ni ne alklakas la ligilon, sed la retpaĝo simple ŝanĝas window.location per javaskripto. Mi skribas simplan html-dosieron kun ligilo al la protokolo conf, malfermas ĝin en la retumilo, alklaku la ligilon - Yos! Fenestro malfermiĝas demandante en kiu aplikaĵo ni devas malfermi nian ligilon, kaj tie ni jam havas nian Lync-aplikaĵon en la listo - ni honeste registris ĝin laŭ ĉiuj eblaj manieroj. Tie en la fenestro estas markobutono "memoru la elekton kaj ĉiam malfermu ligilojn en nia aplikaĵo", marku ĝin, alklaku ok. Kaj jen la dua venko - malfermiĝas la konferenca fenestro. Samtempe, malfermi konferencojn funkcias ne nur kiam vi alklakas ligilon, sed ankaŭ kiam vi moviĝas de la aliĝa paĝo, kiun ni bezonas al la konferenco.
Poste mi kontrolis, forigante parametrojn network.protocol-handler.expose.conf neniel influis la funkciadon de la protokolo en Fox. La ligiloj daŭre funkciis.
konkludo
Mi alŝutis mian tutan laboron al la GitHub-deponejo; ligiloj al ĉiuj rimedoj estos ĉe la fino de la artikolo.
Mi interesiĝos ricevi komentojn de tiuj, kiuj volas uzi mian verkon. Mi tuj rimarku, ke mi faris la tutan evoluon nur por mia sistemo Linux Mint, do iuj aliaj distribuaĵoj aŭ labortabloj eble ne funkcias en tiu versio. Aŭ pli ĝuste, mi eĉ preskaŭ certas pri tio, ĉar mi flikis nur 1 funkcion en xdg-open, kiu rilatas nur al mia DE. Se vi volas aldoni subtenon por aliaj sistemoj aŭ labortabloj, skribu al mi tirpetojn sur Github.
La tuta projekto daŭris 1 vesperon por kompletigi.
Referencoj
fonto: www.habr.com