Trilium jako platforma pro mini-aplikace (diskuse)

[Dirka]

Pekny, od minule velkej posun (sem tam appku zkusim, ale mas pravdu, pro kazdodenni nasazeni (mozna zatim) ne).

[ehm]

+1! Fakt pěkné myšlenky.

[ehm]

Zejména ten nápad s tím, že skript je prostě node, který je typu JavaScript a otagovaný run_on_startup, mě dostalo.

[Dirka]

Mozna sem to pochopil spatne, zkusil sem si udelat strukturu a pak poznamkam priradit attributy treba "stock - yes" a "stock - no" ... muzu nak hledat co ma tento attribut na yes a na no (pripadne kombinace vic attributu)? Zaroven pokud je to zamysleny, aby melo vic poznamek/nodu stejnej atrribut, tak by mozna bylo dobry mit dropdown s jiz existujicima.

[Cal]

Myslim, ze jsi to pochopil spravne - filtrovat podle atributu jde - je to i pouzite v prikladu s vahou, hledej this.getNoteWithAttribute - funkce hleda poznamku, ktera ma atribut "date_data" s hodnotou napr. "2018-02-03".

Logicky tento atribut s touto hodnotou by mel byt jen jeden, proto volam "getNoteWithAttribute", tato unikatnost ale neni vynucovana (napr. unikatnim klicem). Jsou pak atributy ktere unikatni nejsou a muzou byt klidne na vice poznamkach, pro ne existuje komplementarni funkce getNotesWithAttribute().

Filtrovat podle vice atributu zatim nejde (resp. to mozne je, ale musel bys pouzit interni API, ktere se muze v budoucnu zmenit). Principialne ale neni problem takove API pridat. Obecne API zatim pokryva jen dva uvedene priklady, takze jsou to spis jen zacatky.

S tim dropdownem mas pravdu - premyslim, jak atributum udelat lepsi UX - nejspis dropdown s 1) standardnima/builtin atributama (napr. "run_on_startup") a 2) jak pises atributy, ktere jiz byly nekdy pouzite.

[Cal]

Ted me napada, ze jsi to mozna myslel tak, jestli nejde uzivatelsky (v UI) hledat atributy a jejich hodnoty (resp. poznamky s takovymi atributy). Tenhle use case me ani nenapadl ... Obecne atributy jsem povazoval za napul interni vec, kterou pouzivaji spis skripty a uzivatel do nich zavita jen obcas resit spis jen nejake corner casy a speciality ...

Hadam, ze zkousis pouzit atributy v podobne roli jako jsme resili labely v diskusi pod minulym clankem ... Kdyz nad tim tak premyslim, tak by to asi takto pouzit slo - jen by to chtelo nejake pekne vyhledavaci rozhrani (nejake klikani + zjednoduseny query language [neco jako ma treba JIRA]).

[Dirka]

jj, presne tak jsem to zkousel ala JQL ve vyhledavani :)

[Cal]

Zalozil jsem na to https://github.com/zadam/trilium/issues/26 s prvnim navrhem syntaxe.

Jinak jsem nad tim premyslel a neco takoveho bych tak jako tak potreboval. Urcite me totiz bude napr. zajimat, ktere skripty se spousteji po startu (= otagovane "run_on_startup").

[Cal]

Implementoval jsem nektere tve napady, tak jestli se ti bude chtit, budu rad za otestovani: https://github.com/zadam/trilium/releases

Stale tam jsou ale nektere problemy, ktere souvisi s tim, ze na toto pouziti to nebylo uplne navrzeno - napr. je otravne, ze nejde atributy radit a mazat.

[Dirka]

Zkusil sem na rychlo par kombinaci hledani etc a super :) pokud narazim na problem, lognu bug.

[Vantomas]

Jak budeš řešit tu Android aplikaci? Zase nějaký JS framework?

[Cal]

Nn, JavaScriptu mam po krk

Vidim to na Kotlin + Android SDK, zadne tezke abstrakce. V Androidu uz jsem nejake aplikace delal a prijde mi to jako docela podes (aktivity, fragmenty, UI thread), i proto mam ze zacatku dost minimalni ambice. Treba se to ale od minula zlepsilo.

[Vantomas]

A jak budeš řešit ty miniaplikace na telefonu? Tohle totiž začíná být jako dobrá killer feature celého projektu a na telefonu si dokážu představit využití s polohou, historií hovorů nebo s kým je aktuálně navázaný hovor.

[Cal]

Mini aplikace na telefonu v dohledne dobe nebudou - jsou prilis provazane jak s frontend JS runtime i backend node.js runtime.

Prvotni cil pro Android aplikaci je velmi skromny - snazim se pokryt usecase, ze si potrebuju neco poznamenat bez pocitace (poznamka nebo fotka). Idea je takova, ze vyfotim fotku (napr. tabule nebo vyfocena stranka sesitu) klasickym Android fotakem, nasdilim do aplikace a ta ji odesle do Trilia a vytvori poznamku s fotkou v "poznamce dne". To same s textem. Na cokoliv dalsiho budu potrebovat pocitac.

Takze v prvni verzi nebude ani moznost existujici poznamky prochazet/cist/upravovat. Mozna pozdeji.

Co je daleko realistictejsi je, ze bych vytvoril mobilni verzi webove aplikace Trilia - tzn. jen mobile friendly CSS atp. Nevyhoda je pak samozrejme, ze nic neni dostupne offline.

[ehm]

Není důležitějším use-casem spíš read-only čtení? (To se neptám ani tak tebe osobně, ale do pléna.)

Přijde mi to jako hlavní problém/nevýhoda CherryTree. Dopadlo to tak, že si část poznámek (jmenovitě se jedná především o nákupní seznam) vedu na mobilu v nějaké předinstalované aplikaci Poznámka, která je ale překvapivě schopná a umí vytvářet i check-listy. Původně jsem zvažoval nějaký export z CherryTree do HTML a následně upload do Dropboxu (a vygenerovaný share-link hodit do záložek do browseru), ale tohle nakonec bylo jednodušší. Stojí to ale na tom, že toho píšu málo a není zásadní překážkou mít to jen na jednom zařízení, tj. obejdu se bez synchronizace (ta aplikace umí export do *.txt, ale neumí import; možná by to šlo nějak dohackovat manipulací se soubory v úložišti, ale nezkoumal jsem to a ani to nemám v plánu – není to tak dobré, aby se mi tím chtělo trávit čas).

[Cal]

Tak ono to asi zalezi na individualnim pouziti - pro me je momentalne dulezitejsi mit moznost poznamky v telefonu psat, ale samozrejme chapu, ze pro jine use casy by se hodilo spis to cteni ...

Krome tohoto kratkodobeho cile ale nemam uplne rozmyslene jak tu Android aplikaci dal rozvijet.

Jedna ze zakladnich otazek je, jestli ma byt offline nebo online. Offline znamena napsani celeho (nebo velke casti) backendu znovu do cehoz se mi moc nechce a i tak je jasne, ze funkcionalitou to bude docela omezene oproti desktopove/webove verzi.

Pokud to bude ale jen klient k backendu, ktery bezi na serveru, tak nevidim zasadni benefit oproti mobilnimu webovemu UI, ktere bezi rovnou ze serveru - to by melo zase vyhodu v tom, ze je to jen skin bezici na stejne code base a navic to bude rovnou "full-featured".

[ehm]

Nevím, jak vypadá komunikace mezi frontendem a backendem, ale prostě bych to zkusil cachovat. Mobilní aplikace si vyžádá veškerá data a schová si je do úložiště. Obsah, který uživatel změní, se ponechá lokálně a následně se po připojení zpropaguje na server. Obnáší to samozřejmě nějaké diffování, rozhodování kdy/co lze pullnout či pushnout a řešení konfliktů (to bude třeba nechat na uživateli).

A teď je otázka, jak moc je klient provázaný s logikou serveru. Tuším, že to bude dost, takže teď je podstatné, jestli je reálné ten server nějak „embeddnout“ do klienta (a síťovou komunikaci nahradit něčím vhodnějším, ideálně přímo voláním funkcí) a synchronizaci následně řešit až na tom backendu. Takže lokální backend by si – při dostupnosti konektivity – vyměňoval informace se vzdáleným backendem a synchronizovaly si tak vzájemně obsah. Pokud je v backendu nějaká logika, bez které by klient nemohl fungovat (např. vyhledávání apod.), tak toto je řešením.

Nedíval jsem se do kódu, tak sorry, že střílim od boku. Teoreticky by to mělo být proveditelné, ale nevím, jak moc prakticky.

[Cal]

Zda se mi, ze to co navrhujes je soucasna architektura

Tzn. kazda instance ma vlastni backend a ty si pak mezi sebou vymenuji zmeny ve chvili, kdy je dostupna konektivita.

Rad bych to takto udelal i na Androidu, jen je problem v tom, ze stavajici backend na Androidu nerozjedu kvuli nedostupnosti node.js runtime. Takze bych ten backend musel naprgat znovu v Jave/Kotlinu a do toho se mi moc nechce

Bohuzel jsem nenasel zadny rozumny zpusob, jak psat aplikace pro web & desktop & mobile s jednim codebase. Tak jsem si vybral web & desktop s tim, ze mobile proste ostrouha ...

[Vantomas]

Na telefonu používám aplikaci Tripcase. Dřív jsem to používal na Androidu, dnes to používám na iOS. Ta aplikace vypadá i se chová naprosto identicky napříč platformami, protože mě to zaujalo, tak jsem si to hodil do Googlu a ta aplikace je postavená na PhoneGap. Podle toho co je o tom napsáno na webu, tak je to vlastně single page application, se všemi HTML, CSS a JS. Aplikace funguje i offline a prakticky jsem na ní nepoznal, že je to jen obalená HTML aplikace.

Pokud tedy máš webpage aplikaci, která prostě funguje v browseru, asi by nebyl takový problém to prostě zabalit do tohoto frameworku a provozovat to na telefonu, vč. offline režimu, synchronizace a třeba i těch miniaplikací. S tím, že ten framework pak nabídne i nějaký přístup do systému, jako je třeba ta poloha nebo možnost přidat aplikaci do menu "Sdílet" a tak do toho posílat výstupy z jiných aplikací.

[Josef Kufner]

Můžeš zkusit použít Android NDK a sestavit si cokoliv linuxového nativního pro Android.

[Filip Jirsák]

Apache Cordova umožňuje psát mobilní aplikace pomocí web technologií. Kolem toho jsou pak postavené další frameworky. Ale nevím, jak moc je ten váš kód závislý na node.js runtime a kolik by dalo práce, aby fungoval i v prohlížeči.

[Dirka]

My sme meli s Cordovou naky problemy, kdyz sme chteli zpracovavat napr barkod pres ctecku a ne jako obrazek, ale jasny, je to jedna z cest. Co me na techto web vecech vadi - a vicemene je to i duvod proc trilium nepouzivam misto cherrytree je stovky megabajtu, otazka je, jak dlouho vydrzim, ne jestli vubec.

[Cal]

Jj, na Cordovu jsem se dival, ale nemam jeste uplnou predstavu, co by obnaselo aplikaci Cordovou obalit.

S tim node.js - pouzivam samozrejme nejaky HTTP framework (express) a ten by v prohlizeci asi nefungoval. Bylo by samozrejme mozne funkcionalitu abstrahovat od HTTP (neco podobnehu uz pouzivam pro electron). Existuje nejaky nodejs plugin pro Cordovu ... A pak jeste zbyva sqlite a jine nativni node moduly (scrypt, mozjpeg ...). No budu muset tomu venovat vic casu a vic se do toho ponorit.

[chrono]

Nebolo by rozumné, aby mohol atribút run_on_startup prípadne obsahovať niečo (napr. číslo), pomocou čoho si bude možné vynútiť konkrétne poradie spúšťania skriptov? (aby sa napr. pridané tlačidlá zobrazovali stále v rovnakom poradí)

[Cal]

Obecne je lepsi pokud je spis jedno v jakem poradi skripty bezi, ale s tema tlacitkama mas pravdu - chtelo by to konzistentni a predvidatelne poradi.

S tim cislem by to urcite slo, zalozil jsem pro to GitHub issue: https://github.com/zadam/trilium/issues/27

Docela elegantni reseni co me ted napadlo je opet pouzit "parent-child" vztah:

• Startup scripts (ma atribut run_on_startup)
  • Today startup script (bez atributu)
  • Weight Tracker startup script (bez atributu)

Tzn. existuje jen jedna poznamka otagovana ke spusteni - ta ma ale pod poznamky, ktere se chapaji jako zavislosti - tzn. spusti se jako prvni a spusti se v tom poradi v jakem jsou razene ve strome. Takze "Today startup script" se vzdy spusti pred "Weight Tracker startup script".

[Ivorne]

Přijde mi, že pořadí tlačítek by mělo být najěkým parametrem přidání toho tlačítka. Jestli se tlačítka vytváří explicitně v kódu, tak nejlepší by bylo to udělat na styl AddButton( "RunThatScript", /*ui_order*/15 );. Pokud se tlačítka vytvářejí samy (jedno tlačítko pro každý script), tak bych se nebál to nastavovat volitelně explicitně v kódu: SetMyUiPriority( 15 );.

[ehm]

Jak si upravíš pořadí tlačítek v případě, že použiješ skripty třetích stran? Budeš to konfigurovat v kódu? A mezi čísly záměrně budeš nechávat mezery a číslovat to třeba 0, 10, 20, ..., abys mohl tlačítko vložit někam doprostřed bez nutnosti přečíslovávat to ve všech ostatních skriptech? A stejně si budeš muset projít všechny skripty, zjistit ta čísla, seřadit si je, ... meh. Mám pokračovat?

Ten nápad se řazením nodů se mi zamlouval mnohem víc.

[Josef Kufner]

Takovéto číslování není vůbec špatné. Párkrát jsem to použil a odezva uživatelů byla přívětivá.

Spíš než těžko uchopitelnou prioritu doporučuju používat označení "váha" a k políčku přihodit prostou poučku od Archiméda: "Lehké nahoře/vlevo."

[ehm]

Asi moc nerozumím. Jakému políčku, když byla řeč o argumentu funkce?

[Josef Kufner]

Tam, kde se to číslo potká s člověkem. Možná to nebude políčko, ale řádek v nějakém konfiguračním souboru či zdrojáku/dokumentaci. V mém případě to tehdy bylo políčko v nastavení.

[ehm]

A to mi právě smysl moc nedává, viz argument výše. Si představ procházet tu hierarchii, kde jsou náhodně a na různých úrovních rozmístěny nody se skripty, studovat v nich nějaké magické konstanty, řadit je / přečíslovávat je... To je hrozný opruz. Mít všechny skripty pod jedním nodem a spouštět je v tom daném pořadí, je mnohem elegantnější a přehlednější. Uživateli to pak umožňuje pořadí tlačítek změnit vizuálně třeba přetažením myší.

[Dirka]

A neprijde ti logicky, ze pokud takto nekdo tuni rozhrani aplikace, tak si to da do jednoho nodu? Nebo ocekavas, ze ti posle babicka urgentni zpravu pres dnes-zrovna-hype-mesendzr, ze ma jiny poradi tlacitek?

[Dirka]

Sorac, zaradilo se to jinam, nez sem myslel, s tebou kamo samo souhlasim :)

[Josef Kufner]

V zásadě máš tři možnosti, jak pořadí určovat:

1. Definovat závislosti a tím určit (částečné) uspořádání. – Je to nutnost u složitých věcí a/nebo pokud je opravdu kritické, aby pořadí bylo správné. Hodí se mít nějaké well-known meta-závislosti, na které se dají věšet běžné případy (viz systemd targets).
2. Použít magické konstanty doplněné nemagickou konvencí, aby se v tom dalo vyznat. – Je to velmi snadné na implementaci a mnohdy to stačí. Ta konvence dělá z opruzu použitelnou věc (vyzkoušeno).
3. Udělat drag&drop GUI, které to nějak očísluje. – Lehká nadstavba předchozího řešení.

[lizbee]

this is awesome! fresno laser hair removal