Thesis STUDIS prep (#411)

* Proofreading

* PDF format

* PDFs signed

Author: davidhozic

docs/thesis/IzjavaOAvtorstvu.pdf

@@ -13,7 +13,7 @@
 
 
 Nezamenljivi žetoni (angl. *Non fungible tokens*) so edinstvena digitalna sredstva, ki živijo na verigi blokov brez možnosti replikacije.
-Obstaj več pristopov za njihovo oglaševanje, kjer je eden izmed teh oglaševanje po socialnem omrežju Discord s pristopom agresivnega oglaševanja.
+Obstaja več pristopov za njihovo oglaševanje, kjer je eden izmed teh oglaševanje po socialnem omrežju Discord s pristopom agresivnega oglaševanja.
 Diplomsko delo se fokusira na proces oglaševanja in se navezuje na projekt Ogrodje za oglaševanje po Discordu (angl. Discord Advertisement Framework),
 ki je implementirano v programskem jeziku Python.
 

docs/thesis/NaslovnaStranDiplome.pdf

@@ -58,32 +58,6 @@ Pošiljanje s fiksno periodo dveh ur in avtomatično odkrivanje pridruženih ceh
     :caption: Avtomatsko odkrivanje cehov in kanalov - |SCHEMA_EXAMPLE|
 
 
-
-Sledenje cehovskih (pridružnih) povezav
-----------------------------------------------
-Sledenje trem cehovskim povezavam.
-
-.. literalinclude:: ./DEP/Examples/example-invites-tracking.py
-    :caption: Sledenje cehovskih povezav - |PY_EXAMPLE|
-
-.. literalinclude:: ./DEP/Examples/example-invites-tracking.json
-    :caption: Sledenje cehovskih povezav - |SCHEMA_EXAMPLE|
-
-
-
-Pridružitev novim cehom
-----------------------------------------
-Pridruževanje največ 15 novim cehom, na podlagi izraza "NFT", ker imajo cehi med 100 in 1000 uporabnikov.
-
-
-.. literalinclude:: ./DEP/Examples/example-new-guild-join.py
-    :caption: Pridružitev novim cehom - |PY_EXAMPLE|
-
-.. literalinclude:: ./DEP/Examples/example-new-guild-join.json
-    :caption: Pridružitev novim cehom - |SCHEMA_EXAMPLE|
-
-
-
 Oddaljen dostop
 ----------------------------------------
 HTTP strežnik, in GUI shema za povezovanje na ta strežnik.

docs/thesis/daf-thesis.pdf

@@ -24,9 +24,9 @@ da se to datoteko generira iz grafičnega vmesnika (:ref:`Zasnova in razvoj graf
 
 AsyncIO
 ===============
-Jedro ogrodja je zasnovano za konkurenčno (angl. *concurrent*) delovanje, kar pomeni da se lahko na videz več opravil izvaja na enkrat, v
-resnici pa se zelo hitro preklaplja med njimi. To je omogočeno s knjižnico :mod:`asyncio`.
-AsyncIO omogoča ustvarjanje ``async`` funkcij, ki vrnejo korutine. Te korutine lahko potem zaženemo v opravilih,
+Jedro ogrodja je zasnovano za sočasno (angl. *concurrent*) večopravilnost, kar pomeni da se lahko na videz več opravil izvaja na enkrat, v
+resnici pa se med njimi zelo hitro preklaplja. To je omogočeno s knjižnico :mod:`asyncio`.
+AsyncIO omogoča ustvarjanje ``async`` funkcij, ki vrnejo korutine (angl. coroutine). Te korutine lahko potem zaženemo v opravilih,
 med katerimi bo program preklopil vsakič, ko v trenutnem opravilu z ``await`` besedo na primer čakamo:
 
 - na konec neke asinhrone komunikacije (angl. *Async I/O*)
@@ -38,6 +38,7 @@ med katerimi bo program preklopil vsakič, ko v trenutnem opravilu z ``await`` b
    dela kode oz. skupne surovine. https://docs.python.org/3/library/asyncio-sync.html.
 
 
+
 .. raw:: latex
 
     \newpage
@@ -83,7 +84,7 @@ Ogrodje samo po sebi deluje tako, da ima vse objekte (račune, cehe, sporočila,
 ob taki definiciji neproblematično, problem pa je nastopil, ko je bilo dodano dinamično dodajanje in brisanje objektov, kar
 dejansko uporabnikom omogoča, da ogrodje dinamično uporabljajo in v tem primeru je bilo potrebno dodati neke vrste permanentno shrambo.
 Razmišljalo se je o več alternativah, ena izmed njih je bila da bi se vse objekte shranjevalo v neko bazo podatkov, ki bi omogočala
-mapiranje podatkov v bazi, kar bi z vidika robustnosti bila zelo dobra izbira, a to bi zahtevalo veliko prenovo
+preslikavo bazičnih podatkov v objekte, kar bi z vidika robustnosti bila zelo dobra izbira, a to bi zahtevalo veliko prenovo
 vseh sektorjev, zato se je na koncu izbrala preprosta opcija shranjevanja objektov, ki preko :mod:`pickle` modula shrani vse račune
 ob vsakem normalnem izklopu ogrodja, ali pa v vsakem primeru na dve minuti periodično. V prihodnosti so
 še vedno načrti za izboljšanje tega mehanizma in ne izključuje se uporaba prej omenjene podatkovne baze.
@@ -162,7 +163,7 @@ v primeru beleženja sporočil (vsaj v primeru JSON datotek), kjer je vse razdel
 
 Sporočilni sektor
 -----------------
-Sporočilni sektor je zadolžen za pošiljanje dejanskih sporočil v posamezne kanale na Discordu.
+Sporočilni sektor je zadolžen za pošiljanje dejanskih sporočil v posamezne kanale.
 V tem sektorju so na voljo trije glavni razredi za ustvarjanje različnih vrst sporočil:
 
 1. |TextMESSAGE| - pošiljanje tekstovnih sporočil v cehovske kanale
@@ -185,9 +186,9 @@ To je še posebno pomembno v primeru, da imamo definiranih veliko sporočil v en
 poslalo točno ob določenem času. Ker se čas prišteva od prejšnjega predvidenega časa pošiljanja, to pomeni, da bo v primeru
 zamude sporočila razmak med tem in naslednjim sporočilom manjši točno za to časovno napako (če privzamemo da ne bo ponovne zakasnitve).
 
-Pred tem algoritmom, je za določanje časa pošiljanja bil v rabi preprost časovnik, ki se je ponastavil po vsakem pošiljanju, a se je zaradi Discordove
-omejitve API zahtevkov in tudi drugih Discord API zakasnitev, čas pošiljanja vedno pomikal malo naprej, kar je pomenilo, da če je uporabnik
-ogrodje konfiguriral da se neko sporočilo pošlje vsak dan in definiral čas začetka naslednje jutro ob 10ih (torej pošiljanje vsak dan ob tej uri),
+Pred tem algoritmom je bil za določanje časa pošiljanja v rabi preprost časovnik, ki se je ponastavil po vsakem pošiljanju, a se je zaradi Discordove
+omejitve API zahtevkov in tudi drugih Discord API zakasnitev čas pošiljanja vedno pomikal malo naprej, kar je pomenilo, da če je uporabnik
+ogrodje konfiguriral, da se neko sporočilo pošlje vsak dan in definiral čas začetka naslednje jutro ob 10ih (torej pošiljanje vsak dan ob tej uri),
 potem je po (sicer veliko) pošiljanjih namesto ob 10ih uporabnik opazil, da se sporočilo pošlje ob 10.01, 10.02, itd.
 Primer računanja časa in odprave časovne napake je prikazan na spodnji sliki.
 
@@ -262,7 +263,7 @@ datoteko.
 
 CSV beleženje
 ~~~~~~~~~~~~~~~~~~
-CSV beleženje deluje na enak način kot JSON beleženje. Edina razlika je v formatu, kjer je format tu CSV.
+CSV beleženje deluje na enak način kot JSON beleženje. Edina razlika je v formatu, kjer je ta v tem primeru CSV.
 Lokacija datotek je enaka kot pri JSON beleženje. Za shranjevanje je uporabljen vgrajen Python modul :mod:`csv`.
 
 Za sam pregled poslanih sporočil to ni najbolj primeren format, saj se vse shrani v eni datoteki, kjer za razliko od JSON
@@ -276,18 +277,19 @@ formata, tu ni več-slojnih strukture.
 
 SQL beleženje
 ~~~~~~~~~~~~~~~~~~
-SQL beleženje pa deluje precej drugače, kot delujeta JSON beleženje in CSV beleženje, saj se podatki shranjujejo
+SQL beleženje deluje precej drugače, kot delujeta JSON beleženje in CSV beleženje, saj se podatki shranjujejo
 v podatkovno bazo, ki je v primeru uporabe SQLite dialekta lahko tudi datoteka.
 
 Beleženje je omogočeno v štirih SQL dialektih:
 
 1. SQLite
-2. Microsoft SQL Server
+2. Microsoft SQL Server (T-SQL)
 3. PostgreSQL
 4. MySQL / MariaDB
 
 Za čim bolj univerzalno implementacijo na vseh dialektih, je bila pri razvoju uporabljena knjižnica :mod:`SQLAlchemy`.
-Celoten sistem SQL beleženja je implementiran s pomočjo ORM, kar med drugim omogoča tudi
+
+Celoten sistem SQL beleženja je implementiran s pomočjo ORM, kar med drugim omogoča,
 da SQL tabele predstavimo z Python razredi, posamezne vnose v bazo podatkov oz. vrstice pa predstavimo z instancami
 teh razredov. Z ORM lahko skoraj v celoti skrijemo SQL in delamo neposredno z Python objekti, ki so lahko tudi gnezdene
 strukture, npr. vnosa dveh ločenih tabel lahko predstavimo z dvema ločenima instancama, kjer je ena instanca 
@@ -344,5 +346,5 @@ PyCord je odprtokodno ogrodje, ki je nastalo iz kode starejšega `discord.py <ht
 Ogrodje PyCord skoraj popolnoma zakrije Discord API z raznimi objekti, ki jih ogrodje interno uporablja.
 
 Če bi si ogledali izvorno kodo (angl. *source code*) ogrodja, bi opazili da je poleg ``daf`` paketa zraven tudi paket z imenom ``_discord``.
-To ni nič drugega kot PyCord ogrodje, le da je modificirano za možnost rabe na osebnih uporabniških računih.
+To ni nič drugega kot PyCord ogrodje, le da je modificirano za možnost rabe na uporabniških računih (poleg avtomatiziranih robotskih računov).
 

docs/thesis/images/daf-high-level-log.svg

@@ -16,7 +16,7 @@ na spletni strani [#daf_web_page]_.
 .. [#daf_web_page] Na voljo na: https://daf.davidhozic.com/en/v2.9.x/.
 
 Na voljo je v spletni obliki (HTML), kot tudi lokalni obliki (PDF), ki se jo lahko prenese tako, da se na spletni strani dokumentacije
-kurzor premakne levo spodaj strani nad verzijo dokumentacije in zatem klikne *PDF*.
+kurzor premakne na levi spodnji del strani nad verzijo dokumentacije in zatem klikne *PDF*.
 
 
 .. figure:: ./DEP/doc-pdf-download.png
@@ -27,7 +27,7 @@ kurzor premakne levo spodaj strani nad verzijo dokumentacije in zatem klikne *PD
 
 Sphinx
 ----------------
-Sistem, uporabljen za grajenje dokumentacije projekta, se imenuje :ref:`Sphinx`.
+Sistem, uporabljen za grajenje dokumentacije projekta, se imenuje Sphinx.
 Sphinx je popularno orodje med Python razvijalci za generiranje dokumentacije v več formatih.
 Razvijalcem omogoča ustvarjanje profesionalne dokumentacije za lastne projekte, kar je nuja pri javnih projektih.
 

docs/thesis/sl/abstract.rst

@@ -23,7 +23,7 @@ Tkinter knjižnica je v osnovi vmesnik na Tcl/Tk orodja za izdelavo grafičnih v
 ki še dodatno razširijo delovanje knjižnice.
 Omogoča definicijo različnih pripomočkov (angl. *widgets*), ki se jih da dodatno razširiti in shraniti pod nove
 pripomočke, katere lahko večkrat uporabimo. Ti pripomočki so na primer :class:`~tkinter.ttk.Combobox`, ki je neke vrste 
-(angl.) "drop-down" meni, :class:`~tkinter.ttk.Spinbox` za vnašanje številskih vrednosti, gumbi :class:`~tkinter.ttk.Button`, itd.
+(angl.) "drop-down" meni, :class:`~tkinter.ttk.Spinbox` za vnašanje številskih vrednosti, :class:`~tkinter.ttk.Button` za gumbe, ipd.
 Posamezne pripomočke se da tudi znatno konfigurirati, kjer lahko spreminjamo stile, velikost, pisavo, ipd :ref:`tkinter_py_docs`.
 
 Pred izbiro Tkinter knjižnice je bila ena izmed možnosti tudi knjižnica PySide (QT), a na koncu se je vseeno obnesla Tkinter
@@ -40,8 +40,8 @@ Grafični vmesnik ogrodja je razdeljen na več zavihkov, kjer je vsak namenjen l
 
 *Optional modules* zavihek
 -----------------------------
-*Optional modules* zavihek omogoča namestitev dodatnih modulov, ki v osnovnem paketu ogrodja niso prisotni (zaradi hitrejšega zagona).
-Sestavljen je iz statusnih panelov, ki če so rdeči (modul ni nameščen) vsebuje še gumb za namestitev.
+*Optional modules* zavihek omogoča namestitev dodatnih modulov, ki jih osnovni paket ogrodja pogreša (zaradi hitrejšega zagona).
+Sestavljen je iz statusnih panelov, ki v primeru da so rdeči (modul ni nameščen), vsebujejo še gumb za namestitev.
 Gumb bo namestil potrebne pakete, potem pa bo uporabniku sporočeno, da mora za spremembe ponovno odpreti vmesnik.
 Po ponovnem zagonu bo statusni panel za posamezen modul obarvan zeleno.
 
@@ -54,15 +54,15 @@ Po ponovnem zagonu bo statusni panel za posamezen modul obarvan zeleno.
 -----------------------------
 *Schema definition* omogoča definicijo uporabniških računov (in v njih cehov, sporočil, ipd.), definicijo upravljalnika za beleženje,
 izbiro globine izpisov na konzoli in konfiguracijo povezave do jedra ogrodja.
-Omogoča tudi shrambo teh definicij v JSON datoteko, branje definicij iz JSON datoteke in pa generacijo ekvivalentne
-Python datoteke, ki požene le jedro orodja (brez grafičnega vmesnika).
+Omogoča tudi shrambo teh definicij v JSON datoteko, branje definicij iz JSON datoteke in generacijo ekvivalentne
+Python datoteke (konfiguracijske datoteke jedra), ki požene le jedro orodja (brez grafičnega vmesnika).
 Pravzaprav je ta zavihek namenjen definiciji neke predloge, ki jo lahko potem uvozimo v jedro ogrodja.
 Izgled je prikazan na :numref:`fig-gui-front`.
 
 Omogoča tudi dinamično branje in dodajanje objektov v že zagnanem vmesniku preko gumbov, ki vsebujejo besedo *live*.
 
 Uporabniške račune (in ostale objekte) se lahko definira z klikom na opcijski meni *Object options*, in opcijo *New ACCOUNT*.
-Ob kliku se odpre novo okno, ki je avtomatično in dinamično generirano iz podatkov o podatkovnih tipih (anotacij), ki jih sprejme
+Ob kliku se odpre novo okno, ki je avtomatično in dinamično generirano iz podatkov o podatkovnih tipih, ki jih sprejme
 razred ob definiciji. Za vsak parameter se generirajo oznaka, opcijski meni in opcijski gumb, v katerem lahko urejamo izbrano vrednost
 oz. definiramo novo vrednost.
 
@@ -72,7 +72,7 @@ oz. definiramo novo vrednost.
 
     Definicija uporabiškega računa
 
-Shranjevanje sheme (predloge) v datoteko in nalaganje sheme iz datoteke in generiranje ekvivalentne Python datoteke
+Shranjevanje sheme (predloge) v datoteko, nalaganje sheme iz datoteke in generiranje ekvivalentne Python datoteke
 je možno preko opcijskega menija *Schema*. Datoteka, kamor se shrani shema je datoteka formata JSON in vsebuje
 definirane račune, objekte za beleženje sporočil, objekte za povezovanje z jedrom ipd.
 Vsi objekti znotraj grafičnega vmesnika, pravzaprav niso pravi Python objekti ampak so dodaten nivo abstrakcije, ki je sestavljen
@@ -147,21 +147,21 @@ Za pridobitev statistike se uporabi gumb *Calculate*, ki na podlagi opcijskega m
 Povezava grafičnega vmesnika z jedrom ogrodja
 =====================================================
 Grafični vmesnik lahko s stališča lokacije delovanja deluje na dva načina. Prvi je lokalen način, kjer grafični vmesnik
-jedro ogrodja zažene na istem računalniku, kjer deluje grafični vmesnik. Drugi način pa je oddaljen
-režim delovanja, kjer se grafični vmesnik poveže na HTTP strežnik, kateri deluje znotraj jedra ogrodja in na ta strežnik
-pošilja HTTP ukaze, ki se v jedru mapirajo na programski vmesnik. Koncept je prikazan na :numref:`gui-core-connection`
+jedro ogrodja zažene na istem računalniku. Drugi način je oddaljen režim delovanja,
+kjer se grafični vmesnik poveže na HTTP strežnik, kateri deluje znotraj jedra ogrodja in na ta strežnik
+pošilja zahtevke, ki se v jedru potem preslikajo na programski vmesnik. Koncept je prikazan na :numref:`gui-core-connection`
 
 V primeru oddaljenega dostopa se podatki serializirajo v JSON reprezentacijo, kjer so navadne vrednosti neposredno serializirane v JSON format,
-večina objektov pa v slovar (:class:`dict`), kjer je sta slovarju zapisana pot do podatkovnega tipa (razreda) objekta in njegovi attributi.
+večina objektov pa v slovar (:class:`dict`), kjer je sta slovarju zapisana pot do podatkovnega tipa (razreda) objekta in njegovi atributi.
 Obstaja nekaj izjem pri serializaciji objektov, kjer je ena izmed teh :class:`~datetime.datetime` tip objekta, ki se serializira v besedilo po standardu ISO 8601.
 Pretvorbo v končno JSON reprezentacijo opravlja vgrajena knjižnica :mod:`json`, medtem ko pretvorbo objektov v slovar
 opravlja funkcija :func:`daf.convert.convert_object_to_semi_dict`. Serializacijo in deserializacijo opravljata grafični vmesnik in
-jedro oba enako. Včasih se pri pošiljanju podatkov iz grafičnega vmesnika na jedro sploh ne serializira (kot objekte),
-temveč se pošlje le referenco (identifikator) objekta, kjer se na strežniku (jedru ogrodja) objekt pridobi iz spomina prek reference. 
+jedro oba enako. Včasih se pri pošiljanju podatkov iz grafičnega vmesnika na jedro sploh ne serializira,
+temveč se pošlje le referenco (identifikator) objekta, kjer se na strežniku (jedru) objekt pridobi iz spomina preko reference. 
 
 .. autofunction:: daf.convert.convert_object_to_semi_dict
 
 Za konfiguracijo oddaljenega dostopa je potrebno na vrhu vmesnika izbrati :class:`~daf_gui.connector.RemoteConnectionCLIENT`
 in nastaviti parametre. Prav tako je potrebno ustrezno konfigurirati jedro [#extra_remote_conf]_.
 
-.. [#extra_remote_conf] Več o konfiguraciji je na voljo v :ref:`dokumentaciji ogrodja <Remote control (GUI)>`.
+.. [#extra_remote_conf] Več o konfiguraciji je na voljo v dokumentaciji ogrodja - :ref:`Remote control (core)`.

docs/thesis/sl/appendix.rst

@@ -68,8 +68,8 @@ kot vhod damo primerjavo dveh seznamov.
 
     assert [1, 2, 3] == [1, 2, 3, 4, 5, 6]
 
-Iz zgornjega testa je očitno, da to ne drži in da bo test neuspel, ampak v assertu nimamo nobene
-:func:`print` funkcije, ki bi izpisala kaj je šlo narobe, tako da bi pričakovali da pytest vrne samo informacijo da test ni uspel.
+Iz zgornjega testa je očitno, da to ne drži in da bo test dvignil napako, ampak v assertu nimamo nobenega
+besedila, da bi se izpisalo kaj je šlo narobe, tako da bi pričakovali da pytest vrne samo informacijo da test ni uspel.
 Izkaže se, da nam bo pytest izpisal točno kateri elementi se v seznamu razlikujejo.
 
 .. raw:: latex
@@ -103,6 +103,11 @@ Izkaže se, da nam bo pytest izpisal točno kateri elementi se v seznamu razliku
     test.py:6: AssertionError
 
 
+.. raw:: latex
+
+    \newpage
+
+
 Testiranje ogrodja
 ---------------------
 Testi so v ogrodju razdeljeni po posameznih nivojih in funkcionalnostih. Skoraj vsi testi delujejo sinhrono,