Portál AbcLinuxu, 30. dubna 2025 12:42
27.12.2017 19:02
| Přečteno: 2337×
|
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.
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
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.
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.
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.
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
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.
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
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.
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.
Tiskni
Sdílej:
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é)?
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.
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.
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.
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@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.
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)
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)
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: {}
- 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.
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 ...
pri pouziti global hkeys ctrl+shift+sipka to nefunguje, clovek musi byt opravdu focuslej ve stromuNejsem 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).
Jop a asi to je proste vlastnost. Jinak bys musel zrusit rovnou focus do editacniho okna.pri pouziti global hkeys ctrl+shift+sipka to nefunguje, clovek musi byt opravdu focuslej ve stromuNejsem 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).
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.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.
Jasny.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).
28.12.2017 16:52
Josef Kufner | skóre: 70
28.12.2017 08:56
otasomil | skóre: 39
| blog: puppylinux
29.12.2017 12:42
otasomil | skóre: 39
| blog: puppylinux
28.12.2017 21:50
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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.
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.
30.12.2017 16:49
Josef Kufner | skóre: 70
30.12.2017 18:14
Josef Kufner | skóre: 70
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.
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 ...
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í...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.