Estas specoj de programaro, sen kiuj iuj homoj ne povas vivi, dum aliaj eĉ ne povas imagi, ke tia afero ekzistas aŭ ke iu ajn bezonas ĝin. Por mi dum multaj jaroj ĉi tiu programo estis , kiu permesis al vi konservi, legi kaj organizi interretajn paĝojn en specon de eksterreta biblioteko. Mi certas, ke multaj el niaj legantoj bone sukcesas kun kolekto de ligiloj aŭ kombinaĵo de retumilo kaj dosierujo kun aro da konservitaj dokumentoj. Mi ŝatus povi almenaŭ marki dokumentojn kiel "legitaj" aŭ "favorataj", rapide moviĝi de unu teksto al alia kaj ne dependi de la havebleco de la Interreto aŭ de specifa retejo. Okazas, ke estas tempo por legi ĝuste kiam mankas Interreto (ekzemple survoje), kaj ligiloj, bedaŭrinde, ofte rezultas mallongdaŭraj.
Ŝajne, la aŭtoroj de WebResearch kalkulis je proksimume ĉi tiuj homoj. Ĉi tiu programo estis plenplena de diversaj funkcioj: katalogado per sekcioj kaj etikedoj, redaktado de notoj, ĉiaj eksporto/importado, ktp. Tamen, ĉirkaŭ 2013, la projekto ĉesis esti ĝisdatigita, kaj tiam la retejo de la programisto ĉesis ekzisti. Dum kelkaj pliaj jaroj mi sukcesis rajdi ĉi tiun ĉevalon, sed unue la foliumilaj kromprogramoj defalis (disponeblaj nur por la tiamaj versioj de IE kaj FireFox), kaj tiam modernaj retejoj ĉesis montriĝi normale en spektilo bazita sur la malnova IE-motoro.
Ĉeffenestro de WebResearch,
Vojo de Seniluziiĝo
Tuj kiam evidentiĝis, ke anstataŭaĵo ne povas esti evitita, en la fono mi komencis serĉi decan analogon. Ŝajnis al mi, ke ĉi tie ne estos specialaj malfacilaĵoj, ĉar miaj deziroj estas ege modestaj. Mi estis preta kontentiĝi kun nur malgranda subaro de WebResearch-iloj, inkluzive de:
- konservante HTML-paĝon de la retumilo uzante etendon;
- almenaŭ minimumaj katalogaj iloj (alinomado, organizado de katalogoj, etikedoj);
- (prefere) subteno por PDF-dokumentoj;
- ajnan decan manieron sinkronigi vian kolekton kun aliaj aparatoj.
Je mia surprizo, mi ne povis trovi ion similan, kvankam mi honeste traserĉis la Interreton malproksimen kaj zorge studis dekon da programoj, kiuj kongruis kun la komentarioj (escepte de Evernote, kie funkcieco simila priskribo estas disponebla nur per abono). Hodiaŭ, la solaj aferoj, kiuj almenaŭ iel kontentigas miajn dezirojn, estas projektoj и . Ilia studo, ĝenerale, estas de certa kultura intereso.
TagSpaces estas tia "stile-moda-junulara" organizanto sur Electron kun bela retejo, adapta aranĝo kaj, kompreneble, malhela temo, kie ni estus sen ĝi. Samtempe, la fatala enhavtabelo de la kolekto kun modaj rondetaj ikonoj okupas duonon de la ekrano, dum ĝi akceptas proksimume dudek elementojn maksimume, kaj bazaj aferoj kiel subteno por varmaj klavoj aŭ bildigo de la spektata dokumento estas skribitaj. laŭ la resta principo. Kiel rezulto, dokumentoj estas montrataj malrekte, kaj labori kun la kolekto fariĝas enuiga kaj tempopostula aro de ekzercoj per la muso.
Ĝia antipodo myBase venas de la fino de la naŭdekaj: ĉi tie, krom pure funkcia interfaco ni havas ekstreme riĉan aron da agordoj kaj funkcioj. Tamen, la rigarda fenestro ĉi tie estas la sama retumilo bazita sur la malnova IE (kiu jam malfaciligas legadon), kaj ĉiuj dokumentoj estas konservitaj en monolita datumbazo. Se vi metas ĝin en la dosierujon de Dropbox, ekzemple (ankoraŭ ne ekzistas aliaj manieroj sinkronigi kun aliaj aparatoj), tiam kun la plej eta ŝanĝo en la kolekto vi devas atendi ĝis centoj da megabajtoj da informoj estas alŝutitaj al la servilo.
Turno-punkto
Verŝajne, la plua enhavo de la noto ŝajnas evidenta al la leganto: nun oni proponos al ni nian propran biciklon, kiu, kompreneble, estos kapo kaj ŝultroj super ĉiu ekzistanta analogo. Ia jes, sed ne tute. Mi vere ne povis elteni la suferadon kun myBase kaj TagSpaces kaj skizis mian propran dokumentmanaĝeron, la ligon al kiu mi provizos proksime de la fino. Tamen, tiu ĉi eta persona projekto mem ne meritus propran artikolon; Mi skribas plejparte ĉar mi pensis, ke estus interese kunhavigi la sperton, kiun mi akiris dum mia laboro, kaj kelkajn malagrablajn surprizojn, kiujn mi neniam atendis.
Celoj kaj celoj
Mi komencu per tio, ke mi nun havas sufiĉe okupatan vivon, kaj mi simple ne havas tempon por plenrajtaj hobiaj projektoj. Tial, ekde la komenco, mi decidis, ke mi estas preta skulpti mian instrumenton el iuj komponantoj, kiuj venis al la mano, se tio plirapidigos la aferojn. Krome, nuntempe mi entreprenas efektivigi nur la absolutan minimumon de funkcieco, pri kiu estas absolute neeble malhavi.
Datuma Formato kaj Paĝa Konservado
En kia formo retpaĝoj estu konservitaj sur disko? Konsiderante la antaŭe formulitajn postulojn, ŝajnis al mi, ke la elekto estas malgranda: aŭ la "tuta retpaĝo" konserva formato, tio estas la ĉefa HTML-dosiero kaj dosierujo kun rilataj rimedoj, aŭ la MHTML-formato. La unua opcio tuj ŝajnis al mi malpli preferinda: estas malmulte da ĝojo havi rubamason da dosieroj sur via disko, el kiu vi devos ĉerpi signifajn dokumentojn, filtri la nenecesajn dum serĉado kaj kontroli la integrecon dum kopiado. Kiam mi provis labori kun TagSpaces, mi devis rekonservi ĉiujn miajn dokumentojn, por ke la nomo de la rimeda dosierujo komenciĝu per punkto: tiam la sistemo rekonis ilin kiel "kaŝitajn" kaj ne montris ilin.
Ĉi tiu problemo estas kaŝita de vido en myBase, ĉar ĉio estas konservita en la datumbazo, sed en mia kazo regis la principo de simpleco: mi vere volis konservi ĉion kiel regulajn dosierojn sur disko, por ke mi ne devus trakti la efektivigon de rutinaj operacioj kiel kopii, renomi, forigi kaj sinkronigi .
La MHTML-formato trairas malfacilajn tempojn. Facila maniero konservi MHTML , kaj mi eĉ ne scias kie la paĝoj devas esti konservitaj nun? Estas klare, ke la ŝanco ankoraŭ ne malaperis, ekzistas triaj etendoj, sed ĝenerale ĉi tio estas ia malbona signo. Aldone, konservante en MHTML-formato , kiu ankaŭ ne aldonas optimismon.
Samtempe mi komencis serĉi simplan manieron konservi paĝojn de la retumilo al specifa dosierujo. Kiel rezulto, ambaŭ problemoj estis solvitaj kun malmulte da perdo: mi renkontis mirindan projekton , kapabla konservi la enhavon de retpaĝo en aparta sendependa HTML-dosiero. Ĉi tio estas farita konvertante ĉiujn rilatajn rimedojn al formato base64 kaj enigante ilin rekte en HTML. Kompreneble, la dosiergrandeco kreskas, kaj la enhavo aspektas iom malorda, sed entute la aliro ŝajnis al mi fidinda kaj simpla, kaj mi decidis por ĝi.
SingleFile venas kiel retumila etendo kaj komandlinia aplikaĵo. Nun mi nur uzas la etendon: ĝi estas sufiĉe oportuna, krom la fakto, ke vi devas permane elekti la celan dosierujon por konservi. Estonte, mi verŝajne provos plibonigi la aplikaĵon por simpligi ĉi tiun procezon. Por voki triapartan aplikaĵon de Chrome, vi povas uzi la etendon - jen alia utila eltrovo mia. Cetere, la aplikaĵo jam estis utila: per ĝia helpo mi konvertis kolekton da dosierujoj kaj dosieroj el TagSpaces en aron da sendependaj HTML-dokumentoj.
Problemo kun GUI kaj retumilo
Mi trovis, ke Python estas bona por ĉiaj simplaj dosieroj kaj ĉenaj operacioj, kaj ĉar unu el miaj laborprojektoj uzas , elekto ŝajnis logika kiel ĉefa kadro.
Plue, vidinte sufiĉe da problemoj pri montrado de paĝoj en aliaj programoj, mi alvenis al la konkludo, ke la sola fidinda maniero trakti ilin estas enkonduki vidigilon en la programon bazitan sur moderna retumilo, tio estas, Chrome aŭ Firefox.
Mi devas konfesi, ke la lastan fojon, kiam mi devis fari ion tian, estis antaŭ ĉirkaŭ 15 jaroj, kaj mi ne atendis iujn ajn kaptilojn. Montriĝis, ke estas neeble "nur vangofrapi la retumilon sur la formo": iel la homaro ne povis fidinde kaj universale trakti ĉi tiun taskon. Ia listkesto aŭ butono sur formularo povas esti metita en ajna GUI-kadro, kaj eĉ generi transplatforman kodon, kaj ŝajnis al mi, ke en 2019, HTML-montrado ankaŭ devus esti universale solvita problemo.
Montriĝis, ke en wxWidgets, ekzemple, la norma "retumilo" komponanto estas transplatforma envolvaĵo super la sistem-dependa "retumilo", kio en la kazo de Vindozo, ekzemple, signifas. , kaj la situacio en Windows Forms ne estas pli bona, kaj versioj pli novaj ol IE9 estas disponeblaj nur uzante ne-trivialaj . Kiel vi povas vidi, mi ne estas la sola, kiu faras aliajn aferojn dum la lastaj 15 jaroj—ankaŭ nenio ŝanĝiĝis ĉi tie.
Tiam mi alfrontis elekton: ŝanĝi la kadron aŭ serĉi alternativan komponanton por la retumilo. Hezite, mi decidis unue provi la duan vojon kaj rapide renkontis la projekton , dizajnita specife por la tasko de enkonstruado de Chromium en Python-aplikojn.
Taksi la situacion: Python estas unu el la plej popularaj programlingvoj en la mondo, Chrome estas esence monopolisto en la retumila merkato. Samtempe, CEF Python efektive estas subtenata de energio , forton kaj sanon al li. Ĉu iu vere ne plu bezonas ĉi tion?...
Tamen, CEF Python fine ne helpis min: kvankam eĉ la baza ekzemplo de integriĝo kun wxWidgets el la projekta deponejo estas sincere fuŝa, mi provis pli tuŝi ĝin, sed ne povis solvi ĉiujn estiĝintajn problemojn. Mi eĉ ne pli profundigos la temon; ĝi apenaŭ meritas ĝin.
Mi rigardis komponantojn bazitajn sur la Chromium Embedded Framework pli detale kaj finfine decidis provi ĝin. . Ĉar mi laboras preskaŭ la tutan tempon kun Vindozo, la perspektivo rezigni pri plurplatforma funkcieco, ĝenerale, ne precipe ĝenis min.
Post iu neevitebla tumulto ĉe la komenco, aferoj iris multe pli rapide: la kombinaĵo de CefSharp kaj Windows Forms rezultis venkinto, kaj mi povis solvi la plej multajn teknikajn problemojn senprobleme.
Pri la neprovita
Vi ankaŭ povas provi efektivigi FireFox en C#-aplikaĵon uzante la komponanton , sed mi povas nenion diri pri li. Norma retumila komponanto de la kadro Qt vokis bazita , do ĝi verŝajne funkcios same kiel CefSharp.
Fanoj de Qt povas esti tentataj komenti: se ili nur estus preninta Qt, ili ne havus problemojn. Ĉi tio povas esti vera, sed wxWidgets povas esti konsiderata, se ne la unua, tiam la dua opcio kiam vi elektas GUI-kadron por aplikoj en Python aŭ C++. Kaj laŭ mia humila opinio, tia afero kiel retumilo devus esti enkonstruita en iu ajn pli-malpli evoluinta GUI-kadro sen dancado per tamburino.
Reteja Biblioteko
Ni revenu tamen al mia kandidatiĝo kun la labortitolo . Hodiaŭ ĝi aspektas (tamburrulo) tiel:
krom pura kaj konciza interfaco Nur la plej bazaj funkcioj estas efektivigitaj ĉi tie:
- Montru ajnan specifitan dosierujon en la sistemo kiel dokumentbibliotekon.
- Vidu dokumentojn en retumila fenestro. Navigu tra la listo laŭ la kutima maniero (kursaj klavoj, PgUp, PgDn, Hejmo, Fino), movu tra la retumilo per la Spaco kaj Shift+Spaco klavoj.
- Renomi dokumentojn.
- Marku dokumentojn kiel legitajn aŭ ŝatatajn uzante klavojn.
- Ordigi dokumentojn laŭ iu ajn kampo.
- Refreŝigas la aplikaĵfenestron kiam estas ŝanĝoj en la biblioteka dosierujo.
- Konservu fenestrajn agordojn elirante.
Ĉio ĉi povas ŝajni banala funkcieco, sed, ekzemple, konservi kolumngrandojn en TagSpaces ankoraŭ ne estas subtenata - ŝajne, la aŭtoroj havas aliajn prioritatojn.
La stato (legita/favorato) estas simple konservita en la dosiernomo (legu dosieron doc.html renomita al doc{R,S}.html). Ne ekzistas sinkronigo kiel tia, sed mi simple konservas la bibliotekon en Dropbox - finfine ĝi estas nur dosierujo kun dosieroj.
Ankoraŭ estas planoj plibonigi simplajn aferojn kiel movi kaj forigi dosierojn, kaj ankaŭ efektivigi etikedadon per arbitraj etikedoj. Se iu volas helpi, mi nur ĝojos.
trovoj
Vario. Kiel mi diris dekomence, estas mirinde kiom malsama la ilaro de unu persono povas esti de alia. Uzado de ilo kiel WebResearch venas nature al mi, kaj mi sentis preskaŭ fizikan malkomforton pro ĝia foresto. Samtempe, ŝajne, mi havas malmultajn samideanojn, alie ne estus problemoj por trovi analogojn. Aliflanke, similaj kazoj okazas kun multe pli ĝenerala programaro: ekzemple, Microsoft ne ĝisdatigos la labortablan version de OneNote, do mi estas devigita uzi la 2016-an version, kaj pli aŭ malpli frue mi ankaŭ devos moviĝi de ĝi ie.
Kio ankaŭ estas surpriza estas kiom malfacile estas navigi la nunan pejzaĝon de bibliotekoj kaj kadroj. En mia laborlinio, mi malofte devas verki labortablajn aplikaĵojn de komenco ĝis fino, kaj mi supozis, ke laŭvorte ajna ilo por iu ajn programlingvo taŭgus por mia tasko (unu fenestro, tri komponantoj, bagatelaj interagoj). Do ni simple prenas ion ajn kaj faras ĝin ene de kelkaj tagoj.
Montriĝis, ke la realo estas multe malpli bonvola, kaj oni povas simple renkonti problemon senprokraste. Ni diru, ke mi havas du splitiloj, kiuj povas esti uzataj por etendi la retumilon fenestro. Do, restarigi iliajn poziciojn post ŝarĝo en wxWidgets estas ege malfacila, ĉar la sistemo metas ilin en la defaŭltajn poziciojn post preskaŭ ĉiuj eventoj disponeblaj al mi, kaj mi devas fari ĉiajn piratajn por atingi tion, kion mi bezonas. Kiu estus diveninta?
Aliflanke, estas klare, ke en Windows Forms ĉio estas desegnita por "komercaj interfacoj". Preskaŭ ĉio, kio estis bezonata, estis disponebla el la skatolo: konservado/restarigo de aplikaĵaj agordoj, oportuna interfaco de la komponantoj (ekzemple, mi ne atendis, ke la TreeView-komponento povas esti petita pri la plena vojo de la radiko al iu infana elemento. en la formo de ŝnuro), kaj ne-trivialaj iloj kiel dosierujo enhavo ŝanĝspurilo.
Ĉiukaze, la tempo ne estis malŝparita, kaj la rezulto povas esti konsiderata kontentiga, do kion pli vi povus deziri de la vivo, ĉu ne?
fonto: www.habr.com