‘Ik lees het later’: het moeilijke lot van een offline verzameling internetpagina’s

Er zijn soorten software waar sommige mensen niet zonder kunnen, terwijl anderen zich niet eens kunnen voorstellen dat zoiets bestaat of dat iemand het überhaupt nodig heeft. Voor mij was dit programma jarenlang een Macropool WebResearch, waarmee u internetpagina's kon opslaan, lezen en ordenen in een soort offline bibliotheek. Ik weet zeker dat veel van onze lezers prima rondkomen met een verzameling links of een combinatie van een browser en een map met een reeks opgeslagen documenten. Ik zou graag documenten in ieder geval willen kunnen markeren als “gelezen” of “favorieten”, snel van de ene tekst naar de andere kunnen gaan en niet afhankelijk zijn van de beschikbaarheid van internet of een specifieke site. Het komt voor dat er tijd is om precies te lezen als er geen internet is (bijvoorbeeld onderweg), en links blijken helaas vaak van korte duur te zijn.

Kennelijk hadden de auteurs van WebResearch op ongeveer deze mensen gerekend. Dit programma zat vol met een grote verscheidenheid aan functies: catalogiseren op secties en tags, notities bewerken, allerlei soorten export/import, enzovoort. Rond 2013 werd het project echter niet meer bijgewerkt en hield de website van de ontwikkelaar op te bestaan. Nog een aantal jaren slaagde ik erin om op dit paard te rijden, maar eerst vielen de browserplug-ins weg (alleen beschikbaar voor de toenmalige versies van IE en FireFox), en daarna werden moderne sites niet meer normaal weergegeven in een viewer op basis van de oude IE-engine.

‘Ik lees het later’: het moeilijke lot van een offline verzameling internetpagina’s
WebResearch-hoofdvenster, PC Week/RE nr. 17 (575)

Weg van teleurstelling

Zodra duidelijk werd dat een vervanger niet te vermijden was, ging ik op de achtergrond op zoek naar een fatsoenlijke analoog. Het leek mij dat er hier geen speciale moeilijkheden zouden zijn, aangezien mijn verlangens uiterst bescheiden zijn. Ik was bereid genoegen te nemen met slechts een kleine subset van WebResearch-tools, waaronder:

  • een HTML-pagina vanuit de browser opslaan met behulp van een extensie;
  • op zijn minst minimale catalogiseringstools (hernoemen, catalogiseren, labels organiseren);
  • (bij voorkeur) ondersteuning voor PDF-documenten;
  • elke fatsoenlijke manier om uw verzameling met andere apparaten te synchroniseren.

Tot mijn verbazing kon ik niets soortgelijks vinden, hoewel ik eerlijk het internet afspeurde en zorgvuldig een tiental programma's bestudeerde die overeenkwamen met de annotaties (met uitzondering van Evernote, waar een vergelijkbare functionaliteit alleen beschikbaar is via een abonnement). Tegenwoordig zijn de enige dingen die op zijn minst op de een of andere manier aan mijn wensen voldoen, projecten TagSpace и mijnBase. Hun studie is over het algemeen van een zeker cultureel belang.

TagSpaces is zo’n ‘stijlvol-modieuze-jeugd’-organizer op Electron met een prachtige website, adaptieve lay-out en uiteraard een donker thema, waar zouden we zijn zonder. Tegelijkertijd neemt de noodlottige inhoudsopgave van de collectie met modieuze ronde iconen de helft van het scherm in beslag, terwijl er maximaal twintig elementen in passen, en worden basiszaken zoals ondersteuning voor sneltoetsen of weergave van het bekeken document geschreven. volgens het restprincipe. Hierdoor worden documenten scheef weergegeven en wordt het werken met de collectie een saai en tijdrovend geheel van muisoefeningen.

Zijn tegenpool myBase stamt uit eind jaren negentig: hier naast puur functionele interface we hebben een extreem rijke reeks instellingen en functies. Het weergavevenster hier is echter dezelfde browser gebaseerd op de oude IE (wat het lezen al moeilijk maakt), en alle documenten worden opgeslagen in een monolithische database. Zet je het bijvoorbeeld in de Dropbox-map (er zijn nog steeds geen andere manieren om te synchroniseren met andere apparaten), dan moet je bij de kleinste verandering in de verzameling wachten tot er honderden megabytes aan informatie naar de server zijn geüpload.

Draaimoment

Waarschijnlijk lijkt de verdere inhoud van het briefje voor de lezer duidelijk: nu krijgen we onze eigen fiets aangeboden, die uiteraard met kop en schouders boven elke bestaande analoog uitsteekt. Een beetje ja, maar niet helemaal. Ik kon de beproeving met myBase en TagSpaces echt niet verdragen en schetste mijn eigen documentmanager, waarvan ik de link aan het einde zal geven. Dit kleine persoonlijke project zou op zichzelf echter geen eigen artikel verdienen; Ik schrijf grotendeels omdat ik het interessant vond om de ervaring die ik tijdens mijn werk heb opgedaan en een aantal onaangename verrassingen te delen die ik nooit had verwacht.

Doelen en doelstellingen

Laat ik beginnen met het feit dat ik nu een behoorlijk druk leven heb en simpelweg geen tijd heb voor volwaardige hobbyprojecten. Daarom besloot ik vanaf het allereerste begin dat ik er klaar voor was om mijn instrument te beeldhouwen uit alle componenten die voorhanden waren, als dit de zaken zou versnellen. Bovendien verbind ik mij er voorlopig toe om alleen het absolute minimum aan functionaliteit te implementeren, wat absoluut onmogelijk is om zonder te doen.

Gegevensformaat en paginabesparing

In welke vorm moeten webpagina's op schijf worden opgeslagen? Rekening houdend met de eerder geformuleerde eisen, leek het mij dat de keuze klein was: óf het opslagformaat ‘gehele webpagina’, dat wil zeggen het hoofd-HTML-bestand en een map met bijbehorende bronnen, óf het MHTML-formaat. De eerste optie leek mij meteen minder de voorkeur te hebben: het is weinig prettig om een ​​hoop bestanden op je schijf te hebben, waaruit je belangrijke documenten moet extraheren, de onnodige eruit moet filteren bij het zoeken en de integriteit moet controleren bij het kopiëren. Toen ik met TagSpaces probeerde te werken, moest ik al mijn documenten opnieuw opslaan, zodat de naam van de bronmap met een punt begon: het systeem herkende ze vervolgens als “verborgen” en gaf ze niet weer.

Dit probleem is in myBase aan het zicht onttrokken, omdat alles in de database wordt opgeslagen, maar in mijn geval overheerste het principe van eenvoud: ik wilde echt alles als gewone bestanden op schijf opslaan, zodat ik me niet bezig zou hoeven te houden met de implementatie van routinematige handelingen zoals kopiëren, hernoemen, verwijderen en synchroniseren.

Het MHTML-formaat maakt moeilijke tijden door. Een gemakkelijke manier om MHTML op te slaan werd deze zomer uit Chrome gezet, en ik weet niet eens waar de pagina's nu moeten worden opgeslagen? Het is duidelijk dat de kans nog niet is verdwenen, er zijn extensies van derden, maar over het algemeen is dit een slecht teken. Bovendien opslaan in MHTML-indeling niet ondersteund in Chromium Embedded Framework, wat ook geen optimisme toevoegt.

Tegelijkertijd begon ik te zoeken naar een eenvoudige manier om pagina's van de browser in een bepaalde map op te slaan. Het resultaat was dat beide problemen met weinig verlies werden opgelost: ik kwam een ​​prachtig project tegen Enkel bestand, in staat om de inhoud van een webpagina op te slaan in een afzonderlijk, onafhankelijk HTML-bestand. Dit wordt gedaan door alle bijbehorende bronnen naar het base64-formaat te converteren en ze rechtstreeks in HTML in te sluiten. Natuurlijk wordt de bestandsgrootte groter en ziet de inhoud er een beetje rommelig uit, maar over het algemeen leek de aanpak mij betrouwbaar en eenvoudig, en ik heb ervoor gekozen.

SingleFile wordt geleverd als zowel een browserextensie als een opdrachtregeltoepassing. Nu gebruik ik gewoon de extensie: het is best handig, behalve dat je handmatig de doelmap moet selecteren om op te slaan. In de toekomst zal ik waarschijnlijk proberen de applicatie te verbeteren om dit proces te vereenvoudigen. Om vanuit Chrome een applicatie van derden te bellen, kun je de extensie gebruiken Externe applicatieknop - dit is weer een nuttige ontdekking van mij. De applicatie is trouwens al nuttig geweest: met zijn hulp heb ik een verzameling mappen en bestanden van TagSpaces omgezet in een reeks onafhankelijke HTML-documenten.

Problemen met GUI en browser

Ik ontdekte dat Python goed is voor allerlei eenvoudige bestands- en tekenreeksbewerkingen, en sinds een van mijn werkprojecten wordt wxWidgets, keuze wxPython leek logisch als hoofdkader.

Verder kwam ik, nadat ik genoeg problemen had gezien met het weergeven van pagina's in andere programma's, tot de conclusie dat de enige betrouwbare manier om hiermee om te gaan, is door een visualisatieprogramma in het programma te introduceren op basis van een moderne browser, dat wil zeggen Chrome of Firefox.

Ik moet toegeven dat de laatste keer dat ik zoiets moest doen ongeveer 15 jaar geleden was, en ik had geen valkuilen verwacht. Het bleek dat het onmogelijk is om "gewoon de browser op het formulier te zetten": op de een of andere manier is de mensheid niet in staat geweest om deze taak betrouwbaar en universeel aan te pakken. Een soort keuzelijst of knop op een formulier kan in elk GUI-framework worden geplaatst en zelfs platformonafhankelijke code genereren, en het leek mij dat HTML-weergave in 2019 ook een universeel opgelost probleem had moeten zijn.

Het bleek bijvoorbeeld dat in wxWidgets de standaard ‘browser’-component een platformonafhankelijke wrapper is over de systeemafhankelijke ‘browser’, wat in het geval van Windows bijvoorbeeld betekent Internet Explorer 7, en de situatie in Windows Forms is niet beter, en versies nieuwer dan IE9 zijn alleen beschikbaar met niet-triviale manipulatie van het register. Zoals je ziet ben ik niet de enige die de afgelopen vijftien jaar andere dingen heeft gedaan; ook hier is er niets van de grond gekomen.

Toen stond ik voor de keuze: verander het raamwerk of zoek een alternatief onderdeel voor de browser. Na aarzeling besloot ik eerst het tweede pad te proberen en kwam al snel het project tegen CEF Python: Python-bindingen voor Chromium Embedded Framework, speciaal ontworpen voor de taak om Chromium in Python-applicaties in te sluiten.

Beoordeel de situatie: Python is een van de populairste programmeertalen ter wereld, Chrome is in wezen een monopolist op de browsermarkt. Tegelijkertijd wordt CEF Python feitelijk ondersteund door energie een man, kracht en gezondheid voor hem. Heeft niemand dit echt meer nodig?

CEF Python heeft me uiteindelijk echter niet geholpen: hoewel zelfs het basisvoorbeeld van integratie met wxWidgets uit de projectrepository eerlijk gezegd fouten bevat, probeerde ik er meer aan te sleutelen, maar ik kon niet alle problemen oplossen die zich voordeden. Ik zal niet eens dieper op het onderwerp ingaan; het verdient het nauwelijks.

Ik heb de componenten gebaseerd op het Chromium Embedded Framework gedetailleerder onderzocht en uiteindelijk besloten om het eens te proberen versie voor C#. Omdat ik bijna de hele tijd met Windows werk, stoorde het vooruitzicht om de platformonafhankelijke functionaliteit op te geven me over het algemeen niet bijzonder.

Na wat onvermijdelijk gedoe in het begin ging het veel sneller: de combinatie van CefSharp en Windows Forms bleek een winnaar en ik kon de meeste technische problemen probleemloos oplossen.

Over het onbeproefde

U kunt ook proberen FireFox met behulp van de component in een C#-toepassing te implementeren Geckofx, maar ik kan niets over hem zeggen. Een standaard browsercomponent van het Qt-framework genaamd QWebEngineView gebaseerd op chroom, dus het zal waarschijnlijk net zo goed werken als CefSharp.

Fans van Qt kunnen in de verleiding komen om te zeggen: als ze Qt hadden gebruikt, zouden ze geen problemen hebben gehad. Dit kan waar zijn, maar wxWidgets kunnen worden overwogen, zo niet de eerste, dan de tweede optie bij het kiezen van een GUI-framework voor toepassingen in Python of C++. En naar mijn bescheiden mening zou zoiets als een browser in elk min of meer ontwikkeld GUI-framework moeten worden ingebouwd zonder te dansen met een tamboerijn.

WebBibliotheek

Laten we echter terugkeren naar mijn toepassing met de werktitel WebBibliotheek. Vandaag ziet het er (tromgeroffel) zo uit:

‘Ik lees het later’: het moeilijke lot van een offline verzameling internetpagina’s

Behalve schone en beknopte interface Alleen de meest elementaire functies zijn hier geïmplementeerd:

  • Geef elke opgegeven map in het systeem weer als documentbibliotheek.
  • Bekijk documenten in een browservenster. Navigeer op de gebruikelijke manier door de lijst (cursortoetsen, PgUp, PgDn, Home, End), blader door de browser met behulp van de toetsen Spatie en Shift+Spatie.
  • Documenten hernoemen.
  • Markeer documenten als gelezen of als favoriet met behulp van sneltoetsen.
  • Documenten sorteren op elk veld.
  • Vernieuwt het toepassingsvenster wanneer er wijzigingen zijn in de bibliotheekmap.
  • Sla vensterinstellingen op bij het afsluiten.

Dit alles lijkt misschien triviale functionaliteit, maar bijvoorbeeld het opslaan van kolomgroottes in TagSpaces wordt nog steeds niet ondersteund - blijkbaar hebben de auteurs andere prioriteiten.

De status (lezen/favoriet) wordt eenvoudigweg opgeslagen in de bestandsnaam (read file doc.html hernoemd naar doc{R,S}.html). Er is op zich geen synchronisatie, maar ik bewaar de bibliotheek gewoon in Dropbox - het is tenslotte maar een map met bestanden.

Er zijn nog steeds plannen om eenvoudige zaken als het verplaatsen en verwijderen van bestanden te verbeteren, en om tagging met willekeurige tags te implementeren. Als iemand wil helpen, zal ik alleen maar blij zijn.

Bevindingen

Verscheidenheid. Zoals ik vanaf het begin al zei: het is verbazingwekkend hoe verschillend de gereedschapskist van de een kan zijn van die van de ander. Het gebruik van een tool als WebResearch is voor mij vanzelfsprekend en ik voelde bijna fysiek ongemak door de afwezigheid ervan. Tegelijkertijd heb ik blijkbaar weinig gelijkgestemde mensen, anders zouden er geen problemen zijn met het vinden van analogen. Aan de andere kant doen zich soortgelijke gevallen voor bij veel meer reguliere software: Microsoft gaat bijvoorbeeld de desktopversie van OneNote niet updaten, dus ben ik genoodzaakt de versie van 2016 te gebruiken, en vroeg of laat zal ik ook moeten overstappen van het ergens.

Wat ook verrassend is, is hoe moeilijk het is om door het huidige landschap van bibliotheken en raamwerken te navigeren. In mijn werk hoef ik zelden desktopapplicaties van begin tot eind te schrijven, en ik ging ervan uit dat letterlijk elk hulpmiddel voor elke programmeertaal geschikt zou zijn voor mijn taak (één venster, drie componenten, triviale interacties). Dus we nemen gewoon alles en doen het binnen een paar dagen.

Het bleek dat de realiteit veel minder welwillend is en dat je zomaar uit het niets tegen een probleem kunt aanlopen. Laten we zeggen dat ik twee splitters heb die kunnen worden gebruikt om het browservenster uit te rekken. Het herstellen van hun posities na het laden in wxWidgets is dus buitengewoon moeilijk, omdat het systeem ze in de standaardpositie zet na bijna alle gebeurtenissen die voor mij beschikbaar zijn, en ik allerlei soorten hacking moet uitvoeren om te bereiken wat ik nodig heb. Wie had dat kunnen raden?

Aan de andere kant is het duidelijk dat in Windows Forms alles is ontworpen voor “business interfaces”. Bijna alles wat nodig was, was out-of-the-box beschikbaar: applicatie-instellingen opslaan/herstellen, een handige interface van de componenten (ik had bijvoorbeeld niet verwacht dat de TreeView-component om het volledige pad van de root naar elk kindelement kan worden gevraagd in de vorm van een string) en niet-triviale tools zoals een tracker voor het wijzigen van mapinhoud.

Hoe dan ook, de tijd is niet verspild en het resultaat kan als bevredigend worden beschouwd, dus wat wil je nog meer van het leven, toch?

Bron: www.habr.com

Voeg een reactie