"Jag läser det senare": det svåra ödet för en offlinesamling av internetsidor

Det finns typer av mjukvara som vissa människor inte kan leva utan, medan andra inte ens kan föreställa sig att något sådant existerar eller att någon behöver det överhuvudtaget. För mig under många år var detta program Macropool WebResearch, som gjorde att du kunde spara, läsa och organisera internetsidor i ett slags offlinebibliotek. Jag är säker på att många av våra läsare klarar sig bra med en samling länkar eller en kombination av en webbläsare och en mapp med en uppsättning sparade dokument. Jag skulle vilja åtminstone kunna markera dokument som "lästa" eller "favoriter", snabbt flytta från en text till en annan och inte vara beroende av tillgängligheten på Internet eller en specifik webbplats. Det händer att det finns tid att läsa exakt när det inte finns något internet (till exempel på vägen), och länkar visar sig tyvärr ofta vara kortlivade.

Tydligen räknade författarna till WebResearch med ungefär dessa personer. Detta program var packat med en mängd olika funktioner: katalogisering efter sektioner och taggar, redigering av anteckningar, alla typer av export/import och så vidare. Men runt 2013 slutade projektet att uppdateras, och sedan upphörde utvecklarens webbplats att existera. I flera år till lyckades jag rida den här hästen, men först föll webbläsarpluginerna (endast tillgängliga för dåvarande versioner av IE och FireFox), och sedan slutade moderna sajter att visas normalt i en viewer baserad på den gamla IE-motorn.

"Jag läser det senare": det svåra ödet för en offlinesamling av internetsidor
WebResearch huvudfönster, PC Week/RE nr. 17 (575)

Besvikelsens väg

Så snart det stod klart att en ersättare inte kunde undvikas började jag i bakgrunden leta efter en anständig analog. Det föreföll mig som om det inte skulle finnas några speciella svårigheter här, eftersom mina önskningar är extremt blygsamma. Jag var redo att nöja mig med endast en liten delmängd av WebResearch-verktyg, inklusive:

  • spara en HTML-sida från webbläsaren med ett tillägg;
  • åtminstone minimala katalogiseringsverktyg (döpa om, organisera kataloger, etiketter);
  • (helst) stöd för PDF-dokument;
  • något anständigt sätt att synkronisera din samling med andra enheter.

Till min förvåning kunde jag inte hitta något liknande, även om jag ärligt talat letade runt på Internet och noggrant studerade ett dussin program som matchade kommentarerna (med undantag för Evernote, där funktionalitet som liknar beskrivningen endast är tillgänglig genom prenumeration). Idag är det enda som åtminstone på något sätt tillfredsställer mina önskemål projekt TagSpaces и myBase. Deras studie är generellt sett av ett visst kulturellt intresse.

TagSpaces är en sådan "snygg-fashionabel-ungdom"-arrangör på Electron med en vacker webbplats, adaptiv layout och, naturligtvis, ett mörkt tema, var skulle vi vara utan det. Samtidigt tar samlingens olyckliga innehållsförteckning med fashionabla rundade ikoner upp halva skärmen, samtidigt som den rymmer ett tjugotal element som mest, och grundläggande saker som stöd för snabbtangenter eller rendering av dokumentet som visas skrivs enligt restprincipen. Som ett resultat visas dokument snett och arbetet med samlingen förvandlas till en tråkig och tidskrävande uppsättning övningar med musen.

Dess antipod myBase kommer från slutet av nittiotalet: här, förutom rent funktionellt gränssnitt vi har en extremt rik uppsättning inställningar och funktioner. Visningsfönstret här är dock samma webbläsare baserad på den gamla IE (som redan gör läsningen svår), och alla dokument lagras i en monolitisk databas. Om du till exempel lägger den i Dropbox-mappen (det finns fortfarande inga andra sätt att synkronisera med andra enheter), måste du med den minsta förändringen i samlingen vänta tills hundratals megabyte med information laddas upp till servern.

Vändpunkt

Förmodligen verkar det ytterligare innehållet i anteckningen uppenbart för läsaren: nu kommer vi att erbjudas vår egen cykel, som naturligtvis kommer att vara huvud och axlar över alla befintliga analoger. Typ ja, men inte riktigt. Jag kunde verkligen inte stå ut med prövningen med myBase och TagSpaces och skissade på min egen dokumenthanterare, länken till vilken jag kommer att ge mot slutet. Detta lilla personliga projekt skulle dock inte förtjäna en egen artikel på egen hand; Jag skriver till stor del för att jag tyckte att det skulle vara intressant att dela med mig av den erfarenhet jag fick under mitt arbete och ett antal obehagliga överraskningar som jag aldrig förväntat mig.

Mål och mål

Låt mig börja med det faktum att jag har ett ganska hektiskt liv nu, och jag har helt enkelt inte tid för fullfjädrade hobbyprojekt. Därför bestämde jag mig redan från början att jag var redo att skulptera mitt instrument från alla komponenter som kom till hands, om detta skulle påskynda saker och ting. Dessutom åtar jag mig för närvarande att endast implementera det absoluta minimum av funktionalitet, vilket är absolut omöjligt att vara utan.

Dataformat och sidsparande

I vilken form ska webbsidor lagras på disk? Med hänsyn till de tidigare formulerade kraven föreföll det mig som om valet var litet: antingen sparformatet "hela webbsidan", det vill säga huvud-HTML-filen och en mapp med tillhörande resurser, eller MHTML-formatet. Det första alternativet verkade genast mindre att föredra för mig: det finns liten glädje i att ha en pappershög med filer på din disk, från vilken du kommer att behöva extrahera betydande dokument, filtrera bort det som är onödigt när du söker och övervaka integriteten när du kopierar. När jag försökte arbeta med TagSpaces var jag tvungen att spara om alla mina dokument så att namnet på resursmappen började med en prick: sedan kände systemet igen dem som "dolda" och visade dem inte.

Detta problem är dolt i myBase, eftersom allt är lagrat i databasen, men i mitt fall rådde principen om enkelhet: jag ville verkligen lagra allt som vanliga filer på disk så att jag inte skulle behöva ta itu med implementeringen av rutinoperationer som kopiering, byta namn, radering och synkronisering.

MHTML-formatet går igenom svåra tider. Ett enkelt sätt att spara MHTML sparkades ut från Chrome i somras, och jag vet inte ens var sidorna ska lagras nu? Det är klart att möjligheten inte har försvunnit än, det finns tredjepartstillägg, men generellt sett är detta något slags dåligt tecken. Dessutom sparas i MHTML-format stöds inte i Chromium Embedded Framework, vilket inte heller tillför optimism.

Samtidigt började jag leta efter ett enkelt sätt att spara sidor från webbläsaren till en angiven mapp. Som ett resultat löstes båda problemen med liten förlust: jag kom över ett underbart projekt Ensam fil, kan spara innehållet på en webbsida i en separat oberoende HTML-fil. Detta görs genom att konvertera alla associerade resurser till base64-format och bädda in dem direkt i HTML. Naturligtvis växer filstorleken, och innehållet ser lite rörigt ut, men överlag verkade tillvägagångssättet pålitligt och enkelt för mig, och jag bestämde mig för det.

SingleFile kommer som både en webbläsartillägg och en kommandoradsapplikation. Nu använder jag bara tillägget: det är ganska bekvämt, förutom det faktum att du manuellt måste välja målmappen för att spara. I framtiden kommer jag förmodligen att försöka förbättra applikationen för att förenkla denna process. Du kan använda tillägget för att ringa upp en tredjepartsprogram från Chrome Extern applikationsknapp - Det här är ännu en användbar upptäckt av mig. Förresten, applikationen har redan varit användbar: med dess hjälp konverterade jag en samling mappar och filer från TagSpaces till en uppsättning oberoende HTML-dokument.

Problem med GUI och webbläsare

Jag tyckte att Python var bra för alla möjliga enkla fil- och strängoperationer, och eftersom ett av mina arbetsprojekt använder wxWidgets, val wxPython verkade logiskt som huvudram.

Efter att ha sett tillräckligt med problem med att visa sidor i andra program, kom jag till slutsatsen att det enda pålitliga sättet att hantera dem är att introducera en visualizer i programmet baserad på en modern webbläsare, det vill säga Chrome eller Firefox.

Jag måste erkänna att senast jag var tvungen att göra något sådant här var för cirka 15 år sedan, och jag förväntade mig inga fallgropar. Det visade sig att det är omöjligt att "bara slå webbläsaren på formuläret": på något sätt har mänskligheten inte kunnat på ett tillförlitligt och universellt sätt klara av denna uppgift. Någon form av listbox eller knapp på ett formulär kan placeras i vilket GUI-ramverk som helst, och till och med generera plattformsoberoende kod, och det verkade för mig att 2019 borde HTML-visning också ha varit ett universellt löst problem.

Det visade sig att i till exempel wxWidgets är standardkomponenten "webbläsare" ett plattformsoberoende omslag över den systemberoende "webbläsaren", vilket i fallet med Windows, till exempel, betyder Internet Explorer 7, och situationen i Windows Forms är inte bättre, och versioner nyare än IE9 är endast tillgängliga med icke-triviala registermanipulation. Som du kan se är jag inte den enda som har gjort andra saker de senaste 15 åren – inget har visats här heller.

Sedan stod jag inför ett val: ändra ramverket eller leta efter en alternativ komponent för webbläsaren. Efter att ha tvekat bestämde jag mig för att prova den andra vägen först och kom snabbt över projektet CEF Python: Python-bindningar för Chromium Embedded Framework, designad speciellt för uppgiften att bädda in Chromium i Python-applikationer.

Bedöm situationen: Python är ett av de mest populära programmeringsspråken i världen, Chrome är i grunden en monopolist på webbläsarmarknaden. Samtidigt stöds CEF Python faktiskt av energi en snubbe, styrka och hälsa till honom. Är det ingen som verkligen behöver detta längre?..

Men CEF Python hjälpte mig inte till slut: även om till och med det grundläggande exemplet på integration med wxWidgets från projektförrådet är uppriktigt sagt buggigt, försökte jag mixtra med det mer, men kunde inte lösa alla problem som uppstod. Jag ska inte ens gå djupare in på ämnet, det förtjänar det knappast.

Jag undersökte komponenter baserade på Chromium Embedded Framework mer i detalj och bestämde mig till slut för att prova det version för C#. Eftersom jag arbetar nästan hela tiden med Windows, störde inte utsikten att ge upp plattformsoberoende funktionalitet mig särskilt mycket.

Efter lite oundvikligt tjafs i början gick det mycket snabbare: kombinationen av CefSharp och Windows Forms visade sig vara en vinnare, och jag kunde lösa de flesta tekniska problem utan problem.

Om det oprövade

Du kan också försöka implementera FireFox i en C#-applikation med hjälp av komponenten Geckofxmen jag kan inte säga något om honom. En standard webbläsarkomponent i Qt-ramverket kallas QWebEngineView grundad på Chromium, så det kommer förmodligen att fungera lika bra som CefSharp.

Fans av Qt kan frestas att kommentera: om de bara hade tagit Qt hade de inte haft några problem. Detta kan vara sant, men wxWidgets kan övervägas, om inte det första, så det andra alternativet när du väljer ett GUI-ramverk för applikationer i Python eller C++. Och enligt min ödmjuka åsikt bör en sådan sak som en webbläsare byggas in i vilket mer eller mindre utvecklat GUI-ramverk som helst utan att dansa med en tamburin.

WebBibliotek

Låt oss dock återgå till min ansökan med arbetstiteln WebBibliotek. Idag ser det ut (trumrulle) så här:

"Jag läser det senare": det svåra ödet för en offlinesamling av internetsidor

förutom rent och kortfattat gränssnitt Endast de mest grundläggande funktionerna implementeras här:

  • Visa valfri specificerad katalog i systemet som ett dokumentbibliotek.
  • Visa dokument i ett webbläsarfönster. Navigera genom listan på vanligt sätt (markörtangenter, PgUp, PgDn, Home, End), bläddra genom webbläsaren med hjälp av mellanslagstangenterna och Skift+Mellanslagstangenterna.
  • Byta namn på dokument.
  • Markera dokument som lästa eller favoriter med snabbtangenter.
  • Sortera dokument efter valfritt fält.
  • Uppdaterar programfönstret när det finns några ändringar i biblioteksmappen.
  • Spara fönsterinställningar när du avslutar.

Allt detta kan verka som trivial funktionalitet, men låt oss säga, att spara kolumnstorlekar i TagSpaces stöds fortfarande inte - tydligen har författarna andra prioriteringar.

Statusen (läs/favorit) lagras helt enkelt i filnamnet (läs fil doc.html bytt namn till doc{R,S}.html). Det finns ingen synkronisering som sådan, utan jag behåller helt enkelt biblioteket i Dropbox – det är trots allt bara en mapp med filer.

Det finns fortfarande planer på att förbättra enkla saker som att flytta och ta bort filer, samt implementera taggning med godtyckliga taggar. Om någon vill hjälpa till så blir jag bara glad.

Resultat

Mängd. Som jag sa från början, det är fantastiskt hur olika en persons verktygslåda kan vara från en annan. Att använda ett verktyg som WebResearch kommer naturligt för mig, och jag kände nästan fysiskt obehag av frånvaron. Samtidigt har jag tydligen få likasinnade, annars skulle det inte vara några problem med att hitta analoger. Å andra sidan förekommer liknande fall med mycket mer mainstream-programvara: till exempel kommer Microsoft inte att uppdatera desktopversionen av OneNote, så jag tvingas använda 2016-versionen, och förr eller senare måste jag också flytta från det någonstans.

Vad som också är förvånande är hur svårt det är att navigera i det nuvarande landskapet av bibliotek och ramverk. I mitt arbete behöver jag sällan skriva skrivbordsapplikationer från början till slut, och jag antog att bokstavligen vilket verktyg som helst för vilket programmeringsspråk som helst skulle vara lämpligt för min uppgift (ett fönster, tre komponenter, triviala interaktioner). Så vi tar bara vad som helst och gör det inom några dagar.

Det visade sig att verkligheten är mycket mindre välvillig, och du kan helt enkelt stöta på ett problem ur det blå. Låt oss säga att jag har två splitter som kan användas för att sträcka ut webbläsarfönstret. Så att återställa deras positioner efter att ha laddats in i wxWidgets är extremt svårt, eftersom systemet sätter dem i standardpositionerna efter nästan alla händelser som är tillgängliga för mig, och jag måste göra alla typer av hackning för att uppnå det jag behöver. Vem skulle ha gissat?

Å andra sidan är det tydligt att i Windows Forms är allt designat för "affärsgränssnitt". Nästan allt som krävdes var tillgängligt direkt: spara/återställa applikationsinställningar, ett bekvämt gränssnitt för komponenterna (till exempel förväntade jag mig inte att TreeView-komponenten kan frågas om hela sökvägen från roten till vilket underordnat element som helst i form av en sträng) och icke-triviala verktyg som en ändringsspårare för mappinnehåll.

Tiden var i alla fall inte bortkastad, och resultatet kan anses vara tillfredsställande, så vad mer kan man önska sig av livet, eller hur?

Källa: will.com

Lägg en kommentar