Trilium Notes - představení hobby projektu

27.12.2017 19:02 | Přečteno: 2429× |

Před pár měsíci se tu diskutovalo o osobních wiki (např. Zrcadla - proč používat osobní wiki), tak jsem se rozhodl zveřejnit svůj projekt zde s nadějí, že dostanu nějaký zajímavý feedback.

Projekt se jmenuje Trilium Notes a sídlí na GitHubu - https://github.com/zadam/trilium

Cílem projektu je poskytnout aplikaci, která umožňuje efektivní práci s tisíci až desítkami tisíc poznámek ve kterých je možné si zorganizovat život. Efektivní práce znamená snadou editaci, třídění, vyhledávání, odkazování atp.

Vlastnosti

Stromová struktura poznámek

Trilium umožňuje neomezené zanoření poznámek - idea je taková, že člověk si udělá vlastní strukturu tak, jak mu bude vyhovovat bez nějakých umělých omezení.

Trochu možná zvláštnost (pro mě dost důležitá) je, že Trilium nedělá rozdíl mezi poznámkou a složkou - tzn. poznámka může mít textový obsah i pod-poznámky. Je tak velmi snadné přidat nové dodatečné informace k existující poznámce vytvořením pod-poznámky.

Další zvláštní věcí je, že poznámky můžou mít více rodičů ve stromu - tzn. jedna poznámka (a celý její podstrom) může být zařazen do více různých míst ve stromě. Některé poznámky jde totiž zařadit do více kategorií - příklad, který používám je, že "Bash" může být řazen jak pod "Programování", tak pod "Linux". Obě reference jsou si naprosto rovnocené. Funguje to podobně jako hardlinky ve filesystému, s tím rozdílem, že tady to funguje na celé podstromy poznámek (hardlinky nefungují pro adresáře). Dá se to chápat jako sjednocení klasického hierarchické kategorizace (strom, každá položka může patřit jen na jedno místo) a tagů (více míst, ale jen plochá struktura). Více informací zde: https://github.com/zadam/trilium/wiki/Cloning-notes

WYSIWYG editace

Poznámky se editují ve WYSIWYG editoru. Použití nějakého markupu pro poznámky mně přijde jako zbytečný overhead. Taky se chci vyhnout tomu, abych měl jedno editační okno a druhé pro preview.

CKEditor (editační komponenta) jde nastavit, aby na výstupu produkoval Markdown místo HTML, ale zatím v tom nevidím nějaký benefit.

Navigace mezi poznámkami

Základem jsou přecházení dopředu a zpět v historii, "skočit na poznámku" a "nedávné poznámky". Tady jsem se docela inspiroval v IDE nástrojích.

Nějaké GIF dema jsou k dispozici zde: https://github.com/zadam/trilium/wiki/Note-navigation

Všechny featury podporují klávesové zkratky.

Historie / verzování poznámek

Trilium nemá speciální editační a zobrazovací režim - tzn. uživatel nikdy nemusí klikat na "uložit" - poznámky jsou vždy v editačních režimu a jdou měnit okamžitě, změny jsou pak uloženy automaticky.

Verzování funguje tak, že každých deset minut se uloží snapshot právě editované poznámky.

Šifrování poznámek

Některé poznámky mohou být citlivé a chcete je extra chránit. Trilium má koncept "chráněných" (protected) poznámek, které jsou šifrované klíčem odvozeným od hesla. Pro zobrazení poznámek je tedy potřeba zadat heslo, k dispozici jsou ale jen po omezenou dobu (defaultně 10 minut) po které se uvolní z paměti a pro jejich zobrazení je potřeba heslo zadat znovu.

Více informací zde: https://github.com/zadam/trilium/wiki/Protected-notes

Webová a desktopová verze

Z historických důvodů projekt původně vznikl jako čistě webová aplikace - tzn. JavaScript, HTML, CSS na frontendu, backend původně Python. Později se objevila potřeba vytvořit desktopovou variantu (především kvůli offline přístupu), což vyústilo v konverzi backendu do node.js a obalení celé aplikace do Electronu.

Webová verze podporuje poslední Chrome a Firefox, mohla by fungovat i v jiných moderních prohlížečích.

Synchronizace

Hlavně z historických důvodů se poznámky ukládájí do jedné SQLite databáze (sídlící v jediném souboru). Synchronizace databáze přes více instancí pomocí klasických cloudových nástrojů jako Dropbox pak není možná.

Trilium proto implementuje vlastní synchronizaci přes self-hosted synchronizační server, což je vlastně jen webová verze Trilia.

Více informací zde: https://github.com/zadam/trilium/wiki/Synchronization

Aktuální stav

Tohle je první veřejný release, takže je to taková těžká alpha. Já sám ji používám měsíce, ale nikdo jiný ji zatím netestoval, takže čekám, že prvním pár lidem nejspíš exploduje hned po spuštění. Budu vděčný, pokud někdo aplikaci zkusí a bude reportovat chyby (do GitHub issues https://github.com/zadam/trilium/issues nebo klidně tady v komentářích).

Aplikace používá jako editační komponentu CKEditor 5 alpha, který má zatím docela dost chyb a nedodělků a chybí pořádné API, které by umožňovalo některé pokročilejší funkce.

Download a instalace

Pro vyzkoušení doporučuji stáhnout Electron build posledního release: https://github.com/zadam/trilium/releases/latest

Stačí rozbalit a spustit binárku "trilium". Aplikace uživatele požádá o zadání uživatelského jména a hesla (použivá se pro přihlášení na webu a šifrování poznámek) a to by mělo být vše.

Budoucnost

• V první řadě bych chtěl projekt stabilizovat, pofixovat UX problémy a vydat první stabilní verzi.
• Přidat podporu obrázků a příloh
• Synchronizační protokol není úplně ideální - zaručuje jen "eventual consistency" a pokud se něco pokazí uprostřed, tak databáze může být dočasně nekonzistentní.
• Přidat možnost přidávat k poznámkám metadata a strukturované informace nad kterými by pak mohly běhat uživatelské skripty (přirozeně JavaScript).
• Vytvořit nějaké API. Chtěl bych totiž mít možnost importovat data z různých zdrojů - např. napíšu docela dost komentářů do Redditu, které jsou pak ale tak nějak ztracené - rád bych si je importoval do Trilia.
• Nejspíš nějaké organizační funkce jako alarm / primitivní kalendář, což by usnadňovalo použití Trilia pro GTD atp.

       

Komentáře

[ehm]

Pěkný projekt. Osobně bych si to představoval trochu jinak (UI i použité technologie), ale sám o tom mluvím roky a ještě jsem nezačal, takže nechci moc prskat a spíš jsem rád, že se v tomhle směru někdo vůbec o něco snaží.

Jen pár drobností:

Poznámky se editují ve WYSIWYG editoru. Použití nějakého markupu pro poznámky mně přijde jako zbytečný overhead. Taky se chci vyhnout tomu, abych měl jedno editační okno a druhé pro preview.

Jde především o to, jestli vzniknou i další implementace (např. mobilní aplikace) a pokud ano, zda generovaný kód bude pokud možno stejný (tj. bude se to chovat konzistentně).

Verzování funguje tak, že každých deset minut se uloží snapshot právě editované poznámky.

Co když uživatel v poznámce udělá změnu a ještě před uplynutím 10 minut se přepne na jinou poznámku? Nemělo by to být spíš tak, že každých 10 minut se uloží všechny poznámky, které se od posledního uložení změnily (namísto pouze aktuální editované)?

[Cal]

Osobně bych si to představoval trochu jinak (UI i použité technologie)

Ze se nebudou libit technologie jsem cekal (ostatne mne se taky nelibi)

Jestli se ti chce o tom rozepsat, co by jsi udelal jinak v UI? (teda jsem si vedom, ze je to skarede )

Jde především o to, jestli vzniknou i další implementace (např. mobilní aplikace) a pokud ano, zda generovaný kód bude pokud možno stejný (tj. bude se to chovat konzistentně).

To jo. Pokud nekdy bude webova verze, tak bude nejspis pouzivat stejnou editacni komponentu. Jinak docela verim, ze ten CKEditor bude produkovat rozumne HTML podle toho, co jsem o nem cetl (maji pomerne dobre vymysleny engine).

Co když uživatel v poznámce udělá změnu a ještě před uplynutím 10 minut se přepne na jinou poznámku? Nemělo by to být spíš tak, že každých 10 minut se uloží všechny poznámky, které se od posledního uložení změnily (namísto pouze aktuální editované)?

V tom pripade se nova verze neulozi do historie (samotna poznamka samozrejme updatovana je).

Tahle implementace je vicemene nejjednodussi mozna a docela pokryva me potreby. Do budoucna se tohle dost mozna zmeni ... je potreba to promyslet a samozrejme feedback (jako ten tvuj) je hodne dulezity.

[ehm]

Jestli se ti chce o tom rozepsat, co by jsi udelal jinak v UI?

Asi ne. Nejde přímo o UI ve smyslu uspořádání/vzhledu ovládacích prvků, ale víc o koncept, nebo ještě lépe řečeno pojetí, toho programu. Popisovat to detailně by bylo nad rámec jednoho komentáře. Ty ostatně taky spěješ k něčemu sofistikovanějšímu, jak jsi naznačil v té sekci o budoucnosti.

Druhá věc je, že moje představa je dost nekonkrétní a nehmotná a lze to označit přinejlepším za vizi, kterou navíc neumím dost dobře oddělit od jiných myšlenek. Dlouho se peru s tím, jestli to oddělit, nebo ne, a pokud ano, jak. Za takových podmínek se to obtízně předává dál.

Zajímavý by mohl být feedback od Bystroushaaka, který napsal ten původní blogpost. Ten se ideově vydal ale ještě šílenějším směrem než já, tak nevím, jestli to nedopadne podobně.

Ale v každém případě držím palce a budu to sledovat.

[ehm]

Za takových podmínek se to obtízně předává dál.

Abych to ještě doplnil... Nerad bych zopakoval to, co se tu už stalo se svobodným CADem a „novým portálem“, kde každý začal teorizovat o tom, co by se mělo udělat, ale ruku k dílu stejně nepřiložil. První se mě netýká, ale do druhé diskuze jsem se zapojil a dost mě to štve.

Výsledkem bývá guláš zcela protichůdných názorových proudů, ve kterém se nelze vyznat. Teoreticky by to mohlo přinést podněty, ze kterých si pak vybereš a realizuješ jen ty zajímavé, ale nemyslím, že by se to stalo. Spíš by se tu rozjela diskuze o stovkách příspěvků, kde by se brzy začalo řešit něco úplně jiného.

Nakonec je lepší se v diskuzích tohoto typu omezit na pár lidí, kteří mají potenciálně nejkompatibilnější názory a snažit se jít k věci a co nejkonkrétnějším návrhům/požadavkům/dotazům. Proto jsem se mj. omezil jen na ně a zbytek přeskočil.

Ono to k tomu nakonec stejně dospěje, jen doufám, že bez mého přispění. A taky je to varování pro tebe, že si toho nemáš moc všímat a raději pokračovat ve směru, který jsi si zvolil sám, než to pohřbít. Je nemožné vyhovět všem.

[snajpa]

Kdyz uz jsi to zminil, na portalu se maka, ale vybral jsem velmi spatneho cloveka na vykopnuti prvotniho kodu, takze odhad, ze do roka melo neco byt hotove, je mimo. Behem ledna bych mel mit jasno, kudy se bude ubirat to, co je napsane, dam vedet.

[Cal]

Asi ne. Nejde přímo o UI ve smyslu uspořádání/vzhledu ovládacích prvků, ale víc o koncept, nebo ještě lépe řečeno pojetí, toho programu.

Jo, jasny, jak ukazala i ta diskuse pod Bystrousakovym blogpostem, o zajimave napady jak mapovat a ukladat informace neni nouze, jen ty napady jsou casto vhodne spis na research projekty.

Ja se spis pragmaticky drzim starych, nudnych, ale overenych konceptu, jen je vlastne preskladavam tak, aby mne osobne vyhovovaly.

[Vantomas]

Jj, bouchlo to při prvním spuštění.

vantomas@vendula ~/Stažené/trilium-linux-x64 $ ./trilium 
Using data dir: /home/vantomas/trilium-data
Generated sourceId=kRV1oMWUgygX
App HTTP server starting up at port 8080
{
  "app_version": "0.1.0",
  "db_version": 60,
  "build_date": "2017-12-26T22:59:46-05:00",
  "build_revision": "ae337e45009c3938dddcbb3452b271f97eb80bce"
}
Connected to db, but schema doesn't exist. Initializing schema ...
Error connecting to DB. { Error: ENOENT: no such file or directory, open 'db/schema.sql'
    at Object.fs.openSync (fs.js:652:18)
    at Object.module.(anonymous function) [as openSync] (ELECTRON_ASAR.js:172:20)
    at Object.fs.readFileSync (fs.js:553:33)
    at Object.fs.readFileSync (ELECTRON_ASAR.js:508:29)
    at dbConnected.then (/home/vantomas/Stažené/trilium-linux-x64/resources/app/services/sql.js:31:31)
    at <anonymous>
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'db/schema.sql' }
vantomas@vendula ~/Stažené/trilium-linux-x64 $ find|grep schema.sql
./resources/app/db/schema.sql
vantomas@vendula ~/Stažené/trilium-linux-x64 $ vim /home/vantomas/Stažené/trilium-linux-x64/resources/app/services/sql.js
vantomas@vendula ~/Stažené/trilium-linux-x64 $ cd resources/app/
vantomas@vendula ~/Stažené/trilium-linux-x64/resources/app $ ../../trilium 
Using data dir: /home/vantomas/trilium-data
Generated sourceId=3bf1BBzlrSJF
App HTTP server starting up at port 8080
{
  "app_version": "0.1.0",
  "db_version": 60,
  "build_date": "2017-12-26T22:59:46-05:00",
  "build_revision": "ae337e45009c3938dddcbb3452b271f97eb80bce"
}
Connected to db, but schema doesn't exist. Initializing schema ...
Creating missing sync record for notes 0xtvjqrcGiRB
Creating missing sync record for notes 1Heh2acXfPNt
Creating missing sync record for notes 1hASbLRDL7oo
Creating missing sync record for notes 21K84UqGhqlt
Creating missing sync record for notes 2WU27ekfy07E
Creating missing sync record for notes 3RkyK9LI18dO
Creating missing sync record for notes 3oldoiMUPOlr
Creating missing sync record for notes 5v5Dx6LMHXIO
Creating missing sync record for notes 62BKAQMVP2KW
Creating missing sync record for notes 6ZuXjCSWgjB4
Creating missing sync record for notes 8nRNDJGyGs2Z
Creating missing sync record for notes 9zSwD89vgzNO
Creating missing sync record for notes C44aq4mkaX67
Creating missing sync record for notes CF2lUIJAr6Ey
Creating missing sync record for notes GpGnjmcAPeWG
Creating missing sync record for notes HJusZTbBU494
Creating missing sync record for notes I6Cw88AirBBl
Creating missing sync record for notes Iha4YwchR413
Creating missing sync record for notes IlULcDiOTI4K
Creating missing sync record for notes L1Ox40M1aEyy
Creating missing sync record for notes MG0wntwILQW6
Creating missing sync record for notes MLQjmREtcnJ3
Creating missing sync record for notes NncfGH8dyNjJ
Creating missing sync record for notes PEGQGg0In3Ar
Creating missing sync record for notes QbL3pTvhgzM8
Creating missing sync record for notes R6pheWjdwmNU
Creating missing sync record for notes TjWEndYCCg7g
Creating missing sync record for notes WdWZFuWNVDZk
Creating missing sync record for notes ZC78NlmdXeC6
Creating missing sync record for notes Zl69uXBSen0w
Creating missing sync record for notes cFK9sGYZaMWs
Creating missing sync record for notes eXHZAKsMYgur
Creating missing sync record for notes eouCLkjbruai
Creating missing sync record for notes h4OfLEAYspud
Creating missing sync record for notes jyqG9GucsMdn
Creating missing sync record for notes mcEwFMSjhlvL
Creating missing sync record for notes moMbTKwN15Ps
Creating missing sync record for notes mw4f2xB4J5fV
Creating missing sync record for notes pOFVzbXLmzhX
Creating missing sync record for notes pTTjrxgnvURB
Creating missing sync record for notes r4BnsmSQeVr1
Creating missing sync record for notes root
Creating missing sync record for notes rz5t0r9Qr2WC
Creating missing sync record for notes u5t1EvWa3CMO
Creating missing sync record for notes vBv6ovBupfTj
Creating missing sync record for notes xkXwueRoDNeN
Creating missing sync record for notes yK4SBJfwD3tY
Creating missing sync record for notes_tree 0fpnraUGs9Kl
Creating missing sync record for notes_tree 2GOsNT5LsvTP
Creating missing sync record for notes_tree 4Tu6vaPdCxCM
Creating missing sync record for notes_tree 5Dt9YCMn59sY
Creating missing sync record for notes_tree 6M7qPlr7at6N
Creating missing sync record for notes_tree 6brdjeWDOB6w
Creating missing sync record for notes_tree 79e4hrHLFmx6
Creating missing sync record for notes_tree 8a3aNxjG0nu7
Creating missing sync record for notes_tree AqKUM2zUVFUF
Creating missing sync record for notes_tree C5ipVqeDWySp
Creating missing sync record for notes_tree CarTrwkGVcPz
Creating missing sync record for notes_tree EjQTcVVHFmmZ
Creating missing sync record for notes_tree Ez7NN2WVzRc4
Creating missing sync record for notes_tree Fstg4tkccO4N
Creating missing sync record for notes_tree GOxcrZrxalFN
Creating missing sync record for notes_tree GZ6aRI8rdSJt
Creating missing sync record for notes_tree HsN4600rQoL9
Creating missing sync record for notes_tree MN8B7qXDUViO
Creating missing sync record for notes_tree NG4gbKOnsM3v
Creating missing sync record for notes_tree O983DHtLpgmr
Creating missing sync record for notes_tree QJAcYJ1gGUh9
Creating missing sync record for notes_tree QLfS835GSfIh
Creating missing sync record for notes_tree RsvL795Mk1bp
Creating missing sync record for notes_tree RxUiraiR655R
Creating missing sync record for notes_tree T2ToYBfyPy0g
Creating missing sync record for notes_tree T4USGzfllu5t
Creating missing sync record for notes_tree abTEhnOsAsSg
Creating missing sync record for notes_tree bMtxCD6cwNR9
Creating missing sync record for notes_tree bSPmEvjLzQKU
Creating missing sync record for notes_tree bryQseMhyzaI
Creating missing sync record for notes_tree c4JgFNIobvQW
Creating missing sync record for notes_tree c4wt27WNjepw
Creating missing sync record for notes_tree ccslPJf3wQV3
Creating missing sync record for notes_tree d8L8zYlLTbym
Creating missing sync record for notes_tree dLgtLUFn3GoN
Creating missing sync record for notes_tree gSRkHpB7Bu3D
Creating missing sync record for notes_tree hbcWTnEnXPwF
Creating missing sync record for notes_tree jvhKcwz4pYTr
Creating missing sync record for notes_tree lBPOmhP12egP
Creating missing sync record for notes_tree mZuSrZ18Zmv0
Creating missing sync record for notes_tree nMRpPWWH8WRk
Creating missing sync record for notes_tree nfWjptAU2ZDg
Creating missing sync record for notes_tree o4ycR7xIi4oI
Creating missing sync record for notes_tree oWO8rctUjf7d
Creating missing sync record for notes_tree t3vVElqMIQVa
Creating missing sync record for notes_tree tQgognnAH9WI
Creating missing sync record for notes_tree uSitzbGcSATJ
Creating missing sync record for notes_tree uipfvAfwWRgx
Creating missing sync record for notes_tree wLTa2l3lYi83
Creating missing sync record for notes_tree xQ3fjRp9yaPq
Creating missing sync record for notes_tree xyAi7MmgvAgR
Creating missing sync record for notes_tree yMhwsE7uvEij
Schema and initial content generated. Waiting for user to enter username/password to finish setup.

[Cal]

Diky za report, fixnu to ASAP. Tohle mi pri testovani uteklo, exploduje to jen pri prvni inicializaci a jen v zabalenem Electron buildu.

Vidim ale, ze sis poradil. Pokud to dobre chapu, tak workaround je zmenit aktualni adresar na cd resources/app/ a spustit trilium z toho adresare pres "../../trilium".

[Vantomas]

Ano, přesně tak. V sql.js jsem nic neměnil, jen jsem se do toho souboru koukal co tam je.

[Dirka]

Klidne to zkusim, nicmene nemam x64 je i x86 verze?

[Cal]

Pridal jsem x86 verzi pro linux do release 0.1.1 - https://github.com/zadam/trilium/releases

Snad to pojede (otestovano na 64bitovem Ubuntu s 32 bitovymi knihovnami).

(32bit verze pro windows neni, to by bylo tezsi)

[Dirka]

Dik, nicmene to vyzaduje GCC 7, ktery neni na gentoo zatim stabilizovany.

Error: /usr/lib/gcc/i686-pc-linux-gnu/6.4.0/libgcc_s.so.1: version `GCC_7.0.0' not found (required by /mnt/usb.down/trilium-linux-ia32-0.1.1/trilium-linux-ia32/resources/app/node_modules/sqlite3/lib/binding/electron-v1.8-linux-ia32/node_sqlite3.node)
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:172:20)
    at Object.Module._extensions..node (module.js:598:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:172:20)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.anonymous (/mnt/usb.down/trilium-linux-ia32-0.1.1/trilium-linux-ia32/resources/app/node_modules/sqlite3/lib/sqlite3.js:4:15)
    at Object.anonymous (/mnt/usb.down/trilium-linux-ia32-0.1.1/trilium-linux-ia32/resources/app/node_modules/sqlite3/lib/sqlite3.js:190:3)

[Dirka]

Tak sem to zkusil na zaloznim notesu s Artixem.

Po par minutach pouzivani mi oproti cherrytree chybi:

- klavesovy zkratky (nepouzivam mys), zejmena pro prochazeni nodu (vetsinou si mapuju na CTRL+sipky), momentalne lze pouze doTABovat do tree a tam sipkama, toto ale musi fungovat at je focus kdekoliv
- stejne Space pro expand/collapse
- labelovani nodu
- vyhledavani pomoci regex a kombinace textu a labelu

Taky jsem moc nepochopil F2 - tree prefix? Pod F2 bych cekal editaci jmena nodu. Prefix ma jakou fci?

Bugy

- ctrl+F dej vyhledat neco a vrati napr (1/2) napis jinej bougs text, kterej nic nevrati, vysledek porad ukazuje (1/2)

[Dirka]

- Expand/Collapse resi teda sipky leva/prava, ok :)
- Nejde me pouzit Enter pro multiline zapisky, nicmene jakmile pastnu viceradkovej text ze schranky, tak uz Enter normalne funguje, i tak po kazde hodi tento error. Zrejme to souvisi s vytvorenim nove nody?

JS Error: Uncaught error: Message: Uncaught TypeError: Cannot read property 'defaultView' of undefined - URL: http://localhost:8080/libraries/ckeditor/ckeditor.js - Line: 5 - Column: 41040 - Error object: {}

[Dirka]

- Pokud je v nazvu polozky spicata zavorka, ve stromu se toto nezobrazi napr "poz<na>mka" se zobrazi jako "pozmka"

[Cal]

Diky moc za feedback, zkusim odpoved na vse tady:

- klavesove zkratky se snazim podporovat, ale jak uvadis, nektere jsou aktivni pouze ve stromu. Napad CTRL+sipky globalne se mi libi, jen tyhle zkratky jsou v editorech pouzivany typicky na skrolovani. Obecne je hodne konfliktu - snazim se napr. vyvarovat konfliktu se standardnima klavesovyma zkratkama prohlizecu (protoze existuje webova verze). Driv nebo pozdejc bude moznost si namapovat klavesove zkratky na akce libovolne, ale chtel bych mit taky "sane defaults". Jinak aktualne by ta globalni navigace sla udelat pres CTRL+. ktere ti vrati focus do stromu a pak sipky. (Zpet do editoru je CTRL+ENTER coz ale jeste neni releasnuto)

- labelovani nodu - myslis jako prejmenovani nebo treba zmena ikonky? Tohle trochu souvisi s tim prefixem. Poznamka ma "title" a "text", ve stromu se zobrazuje logicky title. Pak je tu ale ta vec, ze poznamka muze byt na vice mistech ve stromu a vsude by mela stejny title, coz je nekdy blbe, protoze kontextove ten title nemusi dobre zapadat na dane misto ve strome. Prefix je pak urcity "location-specific" label ktery je predrazen titlu poznamky a poskytuje ten vhodny "kontext". Dost blbe se toto vysvetluje a premyslim jestli tento problem nejde vyresit nejak jinak ...

Nicmene mas pravdu ze pod F2 by clovek cekal editaci jmena (nebo obojiho) - mrknu na to.

- vyhledavani - zatim je to spis minimalni implementace aby tam neco bylo. REGEX casem pribude. Na ten bug s (1/2) se podivam.

- Nejde me pouzit Enter pro multiline zapisky, nicmene jakmile pastnu viceradkovej text ze schranky, tak uz Enter normalne funguje, i tak po kazde hodi tento error. Zrejme to souvisi s vytvorenim nove nody?

Tohle je bohuzel jeden z bugu CKEditoru, ktery doufam brzy opravi. Workaround je prekliknout na jiny note a vratit se zpet (dela to jen pri puvodne prazdne poznamce).

- Pokud je v nazvu polozky spicata zavorka, ve stromu se toto nezobrazi napr "poz<na>mka" se zobrazi jako "pozmka"

Mrknu na to.

[Dirka]

Pod pojmem label si predstav rozsireny vlastnosti dane polozky.

Dejme tomu mam seznam knizek ve stromu Autor 1 --> Kniha 1, Autor 2 --> Kniha 1 etc ... kazde knizce pak priradim treba zanr, rok a stav.

Pote muzu zobrazit napr sci-fi z roku 1999, ktery nema nikdo pujceny. (touto formou pouzivam cherrytree, ale ne zrovna pro knizky :)

Pripadne muzu otagovat nahodne poznamky "urgent" a priradit jim treba jinou barvu nebo podbarvit (toto se muze vztahovat k rozsireni scriptovani).

[Cal]

Aha, jo, chapu. Labely/tagy v Triliu nejsou.

Misto toho se to resi pomoci toho "multi-parent" systemu. Vytvorim si strukturu neco jako

Knihy
    * Podle autora
	     * Neal Stephenson
		     * Diamantovy vek
    * Podle Zanru
	     * Scifi
		     * Diamantovy vek
    * Podle Roku
	     * 1995
		     * Diamantovy vek	 

Jedna kniha muze byt ve vice podstromech. Strom tak funguje podobne jako label/tag.

Moznost si zobrazit scifi z roku 1999, ktere neni pujcene zatim mozna neni, ale v budoucnu to urcite pujde bud pomoci nejakeho mocneho filtru nebo s trochou skriptovani - bude se filtrovat podle zarazeni do urcitych podstromu.

Stejne tak jdou resit veci typu urgent (proste dalsi podstrom pro urgentni veci). Mozna to zni trochu krkolomne, ale tohle "klonovani" je docela rychly proces pres CTRL-L dialog popr. pres schranku.

Chci pridat i podporu nejakych metadat / atributu k poznamkam - tohle by slo teoreticky taky pouzit na podobne veci.

Jinak podbarvovani atp. zatim neni a nevim uplne jak to konceptualizovat. Hadam, ze to ale casem prijde ...

[Cal]

Jeste doplnim, ze tohle "multi-parency" bylo vytvoreno primo jako mocnejsi nahrada labelu/tagu.

Mocnejsi predevsim v tom, ze tyto labely samy tvori hierarchii (a od toho byl jen krok k tomu je sjednotit s normalnim stromem).

Asi jedina vyhoda labelu je pak v tom, ze jsou trochu snadnejsi na pridavani a odebirani. To by slo ale optimalizovat v UI, pri nejhorsim jdou klasicke "ploche" labely emulovat pres multi-parency.

[Dirka]

Zkusim si s tim trosku pohrat a uvidim (uprimne, zatim su celkem skeptickej, prece jen mam nektery poznamky, kde mam treba 5 labelu ... je to proste jinej koncept). Mozna by bylo zajimavy, kdyby se ty nody nak samo vytvarely, tzn reknes pod urovni Knizky udelej automaticky podle data, zanru a stavu. V urovni chilli podle druhu a palivosti etc ... tzn definoval bys parent node, pod kterym by se to vytvarelo (a jsme zpet u labelu :)

[Dirka]

Tak nakej feedback

- pres ctrl+c/ctrl+v to jde celkem rychle
- ALE musi byt nody blizko sebe, jak je struktura slozitejsi je to zdlouhavy
- taky by se hodil multi-select a moznost naklonovat vic polozek naraz
- pri pouziti global hkeys ctrl+shift+sipka to nefunguje, clovek musi byt opravdu focuslej ve stromu

Celkove u polozek, kde mam vic jak dva labely, si toto nedokazu v realu predstavit.

Napadlo me jeste k tomu pristoupit naopak, tzn oznacis vic polozek a v dialogu (podobne jako ctrl+j vyberes clone parent). Otazka je taky filtrovani/vyhledavani, kdyz mam nakou polozku napr ve 4 pod-stromech, tak to pusobi dost zvlastne, videt vsechny instance identicke poznamky.

[Cal]

Diky za feedback.

Multiselect mam v planu pridelat. Taky mi docela chybel (i kdyz spis na jine operace).

pri pouziti global hkeys ctrl+shift+sipka to nefunguje, clovek musi byt opravdu focuslej ve stromu

Nejsem si jisty, co tim myslis - jakoze mimo strom nefunguje ten CTRL-C/CTRL-V? To by ale asi ani neslo, protoze pokud mas focus v editoru, tak to bude CTRL-C/CTRL-V bude kopirovat klasicky text v editoru. Jedine zase definovat nove globalni zkratky (bohuzel CTRL-SHIFT-V uz maji prohlizece obsazene na plain paste).

Celkove u polozek, kde mam vic jak dva labely, si toto nedokazu v realu predstavit.

Asi mas pravdu v tom, ze to pouziti se od labelu prece jen lisi. Pro me byly labely moznost jak "zaradit" poznamku do vice mist/kontextu. Me typicke pouziti tohoto multi-parency je dva nebo tri vyskyty ve stromu, vic jen vyjimecne. Chapu, ze pokud rutinne pouzivas ~5 labelu, tak tohle je dost neprakticke.

Budu o tom jeste premyslet, jestli prece jen ty labely v nejake forme nepridelat ...

Otazka je taky filtrovani/vyhledavani, kdyz mam nakou polozku napr ve 4 pod-stromech, tak to pusobi dost zvlastne, videt vsechny instance identicke poznamky.

Tohle je pro me spis ficura, rad vyhledavam vcetne kontextu cele cesty po stromu. Tzn. treba z prikladu vyse, knihu bych mohl hledat jako "neal diamant". Samozrejme bych i tak mohl v naseptavaci zobrazovat jen jeden vysledek, ale neni jasne ktery, protoze vsechny jsou rovnocene (to by slo popr. vyresit tim, ze by slo urcitou instanci ve strome oznacit za hlavni).

[Dirka]

pri pouziti global hkeys ctrl+shift+sipka to nefunguje, clovek musi byt opravdu focuslej ve stromu

Nejsem si jisty, co tim myslis - jakoze mimo strom nefunguje ten CTRL-C/CTRL-V? To by ale asi ani neslo, protoze pokud mas focus v editoru, tak to bude CTRL-C/CTRL-V bude kopirovat klasicky text v editoru. Jedine zase definovat nove globalni zkratky (bohuzel CTRL-SHIFT-V uz maji prohlizece obsazene na plain paste).

Jop a asi to je proste vlastnost. Jinak bys musel zrusit rovnou focus do editacniho okna.

Celkove u polozek, kde mam vic jak dva labely, si toto nedokazu v realu predstavit.

Asi mas pravdu v tom, ze to pouziti se od labelu prece jen lisi. Pro me byly labely moznost jak "zaradit" poznamku do vice mist/kontextu. Me typicke pouziti tohoto multi-parency je dva nebo tri vyskyty ve stromu, vic jen vyjimecne. Chapu, ze pokud rutinne pouzivas ~5 labelu, tak tohle je dost neprakticke.

Ja prave labely casto vidim i jako ne-hierarchicky, napr si pisu recenze (caj, rum, pivo etc) a jeden z labelu je "stock" tzn mam chut treba na sheng puer '90 tak si pomoci labelu zobrazim, jaky doma mam (pripadne do toho pridam jeste dodavetele etc) no a kdyz piju posledni proste smazu "stock" - a tyhle ruzny kombinace by stromove bylo strasny peklo :) ... zas u pracovnich poznamek mam vetsinou jeden label max, tam jich tolik nepouzivam.

Otazka je taky filtrovani/vyhledavani, kdyz mam nakou polozku napr ve 4 pod-stromech, tak to pusobi dost zvlastne, videt vsechny instance identicke poznamky.

Tohle je pro me spis ficura, rad vyhledavam vcetne kontextu cele cesty po stromu. Tzn. treba z prikladu vyse, knihu bych mohl hledat jako "neal diamant". Samozrejme bych i tak mohl v naseptavaci zobrazovat jen jeden vysledek, ale neni jasne ktery, protoze vsechny jsou rovnocene (to by slo popr. vyresit tim, ze by slo urcitou instanci ve strome oznacit za hlavni).

Jasny.

[Josef Kufner]

Ctrl+šipky jsou snad ve všech konvenčních editorech pro skákání po slovech.

[Cal]

Myslim, ze Dirka spis myslel CTRL-UP a CTRL-DOWN ... (ty jsou typicky na skrolovani).

ALT-UP a ALT-DOWN by asi sly, ale ALT-LEFT a ALT-RIGHT (pro expand/collapse) jsou obsazene prochazenim historie (pouzivaji treba prohlizece).

[Dirka]

jj CTRL+up/down, pokud bude naka globalni zkratka, tak expand muze byt jen pokud je focus ve stromove strukture.

[disorder]

mne uplne staci org-mode, cisty textak a aj tak vacsina poznamok ostane write/append-only

[otasomil]

Zdravim
Fakt pekna prace. to je odvaha a ten potencial pustit se do neceho takovyho.
No taky jsem dlouho zkousel a dumal jakym zpusobem ukladat a organizovat poznamky, navody... az jsem po letech zkouseni dospel k Dokuwiki a Etherpadu. Oboji lze snadno provozovat na vlastnim serveru a projekty jsou stale aktivne vyvijeny.

[Cal]

Diky.

Ja taky dlouho na spravu poznamek pouzival wiki, jen me pak stvalo, ze prace s tim je dost pomala - musim kliknout na edit, udelat zmeny v nejakem markupu, preview, pak save ... A obecne wiki moc neumi offline pristup.

Jinak Etherpad vypada zajimave ...

[OldFrog {Ondra Nemecek}]

Používám Zim Není to ideální, ale použitelné ano. Oproti Trilium Notes to má jen jednoduchou stromovou strukturu a jako úložiště adresářovou strukturu s wiki soubory (čistý text s wiki syntaxí).

[Prd z gatí]

Vypadá to pekne, aspoň sa pri tom niečo naučíš. Ale ja si radšej zaplatím pár € za Evernote a mám v tom všetko čo potrebujem.

[Cal]

Jj, vyzkousel jsem si na tom nektere nektere nove veci jako CSS GRID/Flexbox a nove vlastnosti JavaScriptu (ES2017, async/await atp.) - kdyz si clovek muze dovolit ignorovat IE, tak ten web development neni takova hruza jako driv.

Jinak Evernote jsem taky par let pouzival. Tam mne ale dost vadilo to, ze si nemuzu poznamky strukturovat jak chci - muzu mit poznamku v notebooku a ty jdou nejak radit do stacku, ale to je vse. Nemuzu vic "zanorovat", nemuzu menit poradi poznamek v notebooku atp. Celkove se mi zdalo, ze to nemuze dost dobre fungovat pokud ma clovek vic nez par stovek poznamek.

Na druhou stranu se mi libila synchronizace a ty jejich aplikace pro Windows a Android byly docela fajn.

[Ivorne]

Co to jako má bejt člověče? To se tu na nás jako fakt pokoušíš machrovat tím, že utrácíš za software 30€ za rok? Nevím, jestli bych ti měl akorát tak sarkasticky zatleskat, nebo jestli sis představoval, že z toho vznikne nějaká širší diskuse.

[Prd z gatí]

60€. A prečo by som mal machrovať? Si sa zbláznil? Pre mňa je to jeden z hlavných pracovných nástrojov, teda pomôcok. Pre človeka, ktorý robí v IT oblasti to musí byť úplne zanedbatelná suma.

[otasomil]

No tak ono to neni od toho kolik Vas stoji uzivani nejake aplikace na urcite casove obdobi ale je to o tom jak a s cim jste se naucil spravovat sve poznamky. Zrovnatak jste tu mohl napsat ze si vse znamenate v podobe cisteho textu. Na zadne variante neni nic spatnyho, jen je to o tom co Vam sedi a jste zvykly.

[Bystroushaak]

Cool, dobré vidět, že se trochu rozčeřily vody na poli osobních wiki. Snad se k tomu taky někdy dostanu.

[Leoš Literák]

Fajné. Držím palce.

[ludvik]

Synchronizace ... nejspíš jedna z top vlastností. Chtělo by to pár dodělků: a) jednoduchost nasazení b) multiuser - např. pro firemní/komunitní sítě. b1) s tím související šifrování na straně klienta. b2) sdílení větví mezi uživateli by už byla taková třešnička.

A zbytek? To se doladí časem.

[ludvik]

Synchronizace ... nejspíš jedna z top vlastností. Chtělo by to pár dodělků:

a) jednoduchost nasazení

b) multiuser - např. pro firemní/komunitní sítě.

b1) s tím související šifrování na straně klienta.

b2) sdílení větví mezi uživateli by už byla taková třešnička.

A zbytek? To se doladí časem.

[Cal]

Diky za feedback.

- jednoduchost nasazeni - vyhledove bych chtel publikovat webovou verzi jako flatpack/appimage nebo neco takoveho, aby to bylo vicemene bez zavislosti a instalace. Synchronizace je trochu narocnejsi na setup, tam bych to chtel zjednodusit, vzhledem k tomu, ze je to self-hosted tak to nebude nikdy tak jednoduche jako treba u Evernote, kde staci zadat login a heslo ...

- multiuser - tohle by byla ficura, ktera by Trilium prenesla do jine sfery, jineho zamereni. Pro me je primarni focus na spravu osobnich dat a momentalne neplanuju, ze bych implementoval multi-user v klasickem smyslu.

- sdileni vetvi - tohle je vyhledove velmi zajimava vec - Trilium by stale bylo single user, ale tito uzivatele by si volitelne mohli nasdilet nektere podstromy. Jestli a jak tohle implementovat se ale jeste uvidi ...

- sifrovani na klientovi - zajimave, takto Trilium puvodne data sifrovalo - tzn. sifrovaci klic se z hesla odvodil na klientovi a na server se nikdy nedostal. Byly s tim ale nejake problemy - napr. mam operace jako "zasifruj podstrom" a s timto pristupem je to dost tezke udelat atomicky. Mimoto treba zmena hesla nejde udelat tak, aby se heslo (nebo nejaky odvozeny credential) na server nedostal. Nakonec jsem dospel k tomu, ze sifrovani na klientovi mne vlastne nic realneho neprinasi a presunul to na server.

[Josef Kufner]

Pokud by jsi pro verzování poznámek používal Git, tak by sdílení i synchronizace byla docela snadná. Pokud tedy použití Gitu dává technologicky smysl (nezkoumal jsem, jak poznámky ukládáš).

[Cal]

Poznamky jsou prave ulozeny v databazi, takze git moc pouzit nejde. Takze je to spis o tom rozhodnuti nepouzivat filesystem - napr. struktura poznamek ani nejde poradne namapovat na FS (predevsim kvuli tomu multi-parency).

Ale i jinak by to drhlo - napr. jedna z featur je, ze se poznamky i historie ukladaji automaticky, uzivatel nemusi explicitne ukladat nebo commitovat. Poznamky se pak ukladaji (momentalne) kazdych pet sekund pri psani, coz je pro databazi OK, ale kazdych pet sekund commit do gitu nedava moc smysl ...

[Josef Kufner]

Poznamky jsou prave ulozeny v databazi, takze git moc pouzit nejde. Takze je to spis o tom rozhodnuti nepouzivat filesystem - napr. struktura poznamek ani nejde poradne namapovat na FS (predevsim kvuli tomu multi-parency).

Použití file systému a obecný graf vztahů mezi poznámkami se nijak nevylučuje. Poznámka tak jako tak musí mít nějaké ošklivé ID a podle něj se to na file systému najde. Struktura adresářů nemusí odpovídat struktuře v tom navigačním panelu, co je vidět na screenshotu. Pak se dá také kouzlit se symlinky, kdy primární úložiště poznámek je podle ID a strom symlinků poskytne přívětivý náhled na strukturu (pokud to je žádoucí).

Pěkným příkladem je právě struktura repozitáře Gitu, kde je .git/objects/ obsahuje kopu bordelu, ale uživatel ji nikdy nevidí.

Ale i jinak by to drhlo - napr. jedna z featur je, ze se poznamky i historie ukladaji automaticky, uzivatel nemusi explicitne ukladat nebo commitovat. Poznamky se pak ukladaji (momentalne) kazdych pet sekund pri psani, coz je pro databazi OK, ale kazdych pet sekund commit do gitu nedava moc smysl ...

Nemá smysl, aby uživatel explicitně commitoval. Aplikace může používat Git na pozadí a uživateli to naprosto zatajit. Průběžné ukládání může být implementováno například jako větev, která se při uložení sloučí do jednoho commitu (squash). Zda to bude čudlíkem "Uložit", nebo automaticky při zavření poznámky už je jedno.

[Cal]

Použití file systému a obecný graf vztahů mezi poznámkami se nijak nevylučuje. Poznámka tak jako tak musí mít nějaké ošklivé ID a podle něj se to na file systému najde. Struktura adresářů nemusí odpovídat struktuře v tom navigačním panelu, co je vidět na screenshotu. Pak se dá také kouzlit se symlinky, kdy primární úložiště poznámek je podle ID a strom symlinků poskytne přívětivý náhled na strukturu (pokud to je žádoucí).

Pěkným příkladem je právě struktura repozitáře Gitu, kde je .git/objects/ obsahuje kopu bordelu, ale uživatel ji nikdy nevidí.

Tak jasne, ze v dusledku jde nejakym zpusobem cokoliv namapovat na filesystem. Pro me by melo smysl pouzit filesystem pokud by to mapovani bylo prirozene a jednoduche. Napr. pokud bych v aplikaci pouzival cisty strom (kde slozky nemuzou mit textovy obsah), tak se pouziti FS primo nabizi. Pak mas problemy s povolenymi znaky ve jmenech souboru, muzes se tomu vyhnout proste pouzitim ID jako jmena souboru, ale pak si rikam jaky to ma vlastne smysl? Jinak i ty symlinky nejsou vsemocne, napr. ta (dulezita) moznost, ze poznamka ma zaroven text a podpoznamky by sla mapovat na FS opet jen oklikou. V neposledni rade symlinky na windows (junctions) by default vyzaduji admin prava ...

Nemá smysl, aby uživatel explicitně commitoval. Aplikace může používat Git na pozadí a uživateli to naprosto zatajit. Průběžné ukládání může být implementováno například jako větev, která se při uložení sloučí do jednoho commitu (squash). Zda to bude čudlíkem "Uložit", nebo automaticky při zavření poznámky už je jedno.

Hmm, to by asi slo to ukladani do branche, squash a merge, nasledne by se asi daly ty stare commity smazat z historie. Blbe pak je, ze aktualni stav je reprezentovany nejakou vetvi a ne v masteru. Opet si nemyslim, ze by pouzit git neslo, jen jde o tom, jak by to bylo krkolomne ...

Ve srovnani s tim mam ted jednu tabulku na aktualni stav a druhou tabulku na historii (snapshoty). Jiste, je to omezene - nemuzu si napr. zobrazit celkovy stav vsech notu a jejich relaci v jednom okamziku, ale realisticky YAGNI. Celkova slozitost systemu mi ale prijde daleko nizsi ...

[ehm]

Použitím Gitu si taky nejsem moc jistý – a to zejména s ohledem na to, že uživatel od něj bude zcela izolován a nemůže čerpat žádné výhody. Pokud by struktura na FS kopírovala strukturu v aplikaci a dokumenty byly ukládány v pretty-formatted HTML (nebo raději spíše třeba Markdownu), jako to dělá kupříkladu zde v diskuzi zmiňovaný Zim, mělo by to smysl spíše.

Mimochodem:

Napr. pokud bych v aplikaci pouzival cisty strom (kde slozky nemuzou mit textovy obsah), tak se pouziti FS primo nabizi.

To umí i ten Zim. Řesí to tak, že vedle adresáře existuje i stejně pojmenovaný soubor.

Pak mas problemy s povolenymi znaky ve jmenech souboru, muzes se tomu vyhnout proste pouzitim ID jako jmena souboru, ale pak si rikam jaky to ma vlastne smysl?

To by reálně moc velký problém nebyl, jen by asi bylo fajn v softwaru přidat nějaké omezení na „univerzálně“ bezpečné znaky kvůli kompatibilitě. V krajním případě by se asi dalo vymyslet nějaké kódování, kde většina bezpečných znaků zůstane stejná a zakódují se pouze speciální znaky. Ale to je, řekl bych, trochu zbytečná práce vzhledem k naprosto minimálnímu přínosu, který to má.

Jinak i ty symlinky nejsou vsemocne, napr. ta (dulezita) moznost, ze poznamka ma zaroven text a podpoznamky by sla mapovat na FS opet jen oklikou. V neposledni rade symlinky na windows (junctions) by default vyzaduji admin prava ...

Bál bych se (možná zbytečně?), že se ty symlinky rozbijou. Zrovna přenos na jinou platformu by asi mohl být ten případ.

To už bych si spíš nechal pěkně pojmenované soubory/adresáře, ale do každého souboru (do obsahu) stejně nacpal nějaké unikátní ID. Při spuštění bych prošel celý strom a sestavil si mapu ID => název. Pak stačí mít někde pomocný soubor, který bude obsahovat dodatečné informace k jednotlivým ID (např. labely/tagy/zařazení do další hierarchie). Což je tedy trochu prasárna, ale stále menší než v tom pomocném souboru mít názvy (tj. muset to při přejmenování aktualizovat a řešit konzistenci – např., ale nejenom, v případě, že uživatel ručně přejmenuje přímo zdrojový soubor).

IMO se nevyplatí se tím zabývat, protože by sis sice ušetřil synchronizaci databáze a s poznámkami by se dalo snadněji pracovat i bez použití Trillia, ale zase bys musel řešit hromadu dalších věcí...

[hydrandt]

Super, fandim! Stale hledam, kde se s poznamkami / osobni wiki usadim. CherryTree je fajn, ale casto si zapisuju do telefonu, a tak me absence mobilni aplikace stve. Zkousim ted Joplin, taky ve velmi rane fazi, ale zda se, ze je zivo, a mohlo by to byt brzy pouzitelne. Stve me, ze poznamky nejsou stromove, uvidim, jak se mi s tim bude zit.