Trilium Notes jako platforma pro mini-aplikace

3.2.2018 20:28 | Přečteno: 1522× | | poslední úprava: 3.2.2018 20:33

Tento zápisek navazuje na můj předchozí blogpost, který představuje projekt Trilium Notes. Dnes bych chtěl ukázat novou fíčuru - podpora pro psaní a běh mini aplikací. Ukážu dva skripty, které spolu úzce souvisí.

Poznámka dne

Svoje poznámky strukturuji převážně dvěma způsoby - buď podle obecné taxonomie (pracovní poznámky, technologie, plánování atp.) a podle data - udržuju si strom poznámek rok -> měsíc -> den, do které pak vytvářím nové poznámky, pomocí klonování pak poznámky zařadím i taxonomicky. Dalo by se říct, že tato "poznámka dne" je můj hlavní workspace / inbox. Pro představu to vypadá zhruba takto:

• 2018
  • 01 - January
  • 02 - February
    • 01 - Thursday
    • 02 - Friday
      • Něco co právě řeším
      • Další podpoznámka

Tento systém / pattern byl původně čistě manuální - prostě jsem každý den vytvořil poznámku dne a v ní pracoval. Postupem času se ale ukázalo, že se tento koncept dá znovu použít na věci, které vyžadují určitou automatizaci - kromě příkladu níže (sledování váhy) jej používá třeba i reddit plugin, který automaticky importuje mé komentáře z redditu pod poznámku dne.

Systém tedy potřebuje "rozumnět" této struktuře a popř. ji i vytvářet - je to řešeno tak, že poznámky dne jsou "otagovány" speciálním atributem, který udává, který den reprezentují. Je to trochu vidět na demu níže.

Jak jsem už uvedl výše, poznámka dne je pro mě něco jako hlavní workspace a proto se k ní během práce často vracím. Trilium má dost možností navigace mezí poznámkami, ale tady bych chtěl něco ještě pohodlnějšího - tlačítko v UI, popř. klávesovou zkratku, která mě přesměruje na poznámku dne. Tato funkce nativně v Triliu není, ale je to ideální "hello world" příklad skriptování (gif začíná zobrazením uvodní "Trilium Demo" poznámky):

Jako první bych rád zdůraznil, že všechny tady diskutované "skripty" jsou vytvořené v Triliu, jsou uloženy jako poznámky a pracují s poznámkami. Skripty nejsou ani nepracují s žádnými soubory. Trilium zde vystupuje v roli vývojového prostředí i runtime platformy.

Vysvětlím jednotlivé kroky v demu:

1. Zobrazím si poznámku "Today script", která obsahuje zdrojový kód skriptu. Poznámka má typ "JavaScript", takže Trilium ví, že se dá spustit. Co tento kód obsahuje:
   1. Přidá tlačítko "Today" do toolbaru
   2. Registruje globální funkci (volaná po kliknutí na tlačítko), která voláním serveru zjistí poznámku dne pro dnešní datum a pak zavolá funkci, která přejde na danou poznámku
2. Zobrazím si atributy poznámky "Today script" - obsahuje jeden atribut "run_on_startup". Při startu Trilium najde všechny poznámky s tímto atributem a spustí je - pro nás to znamená, že se tlačítko "Today" přidá do toolbaru hned po startu Trilia.
3. Klikám na "Today" tlačítko, které mě správně veme na "poznámku dne".
   1. Aby bylo jasno, toto tlačítko je dostupné globálně - fakt, že v demu na něj klikám z poznámky se zdrojovým kódem tohoto skriptu je jen shoda okolností
4. Na poznámce dne ještě zobrazím atributy - a vidím "date_note" atribut s hodnotou "2018-02-03" - tohle označuje poznámku jako "poznámku dne"

Celý skript je k dispozici tady.

Sledování váhy

Vedu si denní záznamy o své váze a řeším, kam ty data dát. Chtěl bych je vizualizovat v krátkém časovém údobí (abych viděl  progres), v dlouhodobém období, vidět nějaké korelace s jinými daty (např. by bylo zajímavé srovnání s počtem vypitých piv ). Mám samozřejmě spoustu možností - Libre Office Calc, Google Spreadsheets, nějaká speciální aplikace na mobil, online služby, ale všechny mají nějakou kombinaci těchto nevýhod:

1. Data nejsou synchronizané
2. Data nejsou k dispozici offline
3. Data jsou v nějakém proprietárním formátu
4. K datům má přístup někdo jiný než já
5. Musím otvírat (težkou/pomalou) aplikaci, kterou jinak nepoužívám, na zadání jednoho údaje

Proto zkusím tuto mini aplikaci naskriptovat v Triliu (gif začíná zobrazením uvodní "Trilium Demo" poznámky):

Opět vysvětlím demo:

1. Klikám na "Weight tracker" tlačítko v toolbaru a dostanu se na poznámku se stejným jménem "Weight tracker" (jméno není podstatné)
   1. Tato poznámka má typ "Render HTML note", která neumožňuje editaci, namísto toho vyrenderuje všechny pod-poznámky typu HTML
2. Zadám datum a váhu a klikám na tlačítko Add, což uloží hodnotu váhy do nové JSON poznámky pod poznámku dne.
   1. Ignorujte prosím fakt, že demo data ukazují váhu z budoucnosti
   2. Komponenta date-picker je z jQuery UI (není nutné speciálně importovat, protože je součástí Trilia)
3. Zobrazí se mi aktualizovaný graf vývoje váhy
4. Rozklikávám Weight tracker k nahlédnutí na implementaci - začneme skriptem "add toolbar button", který je otagovaný atributem "run_on_startup", takže se spustí hned po startu Trilia a přidá tlačítko do toolbaru.
5. Zobrazuju poznámku "implementation", která obsahuje hlavní implementaci jak HTML tak JavaScriptu.
   1. Zdroják tohoto skriptu je na githubu: https://github.com/zadam/trilium/blob/stable/src/scripts/weight.html
6. Zobrazuju pod-poznámku "chart.js", která obsahuje minifikovanou verzi knihovny chart.js
   1. Pokud má JS poznámka pod-poznámky, tak se tyto podpoznámky automaticky chápají jako závislosti. Při spuštění "implementation" se tedy automaticky předřadí spustitelná poznámka chart.js
   2. Tato knihovna by se dala použít na více podobných použití - pomocí klonování je možné stejnou knihovnu zařadit pod více podstromů v různých mini-aplikacích, aniž by se samotná knihovna duplikovala
7. Klikám na "Today" a zobrazuji "data" pod-poznámku, která obsahuje JSON s váhou pro dnešní den.
   1. Důvod proč vytvářím novou "data" poznámku pro každý den je ten, že plánuju přidat nějaká další "denní" data, které pak budu mít společně v této jedné poznámce. Jinak by se daly například ukládat data o váze do jedné poznámky na měsíc.

Výhody takového řešení jsou vlastně jen standardní vlastnosti Trilia přenesené na skripty/data:

• Aplikace i data jsou automaticky synchronizované na všechny zařízení
• Aplikace i data jsou plně dostupné a funkční i offline
• K datům mám přístup jen já. Extra citlivé data můžu klidně šifrovat.
• Data můžu libovolně vizualizovat, korelovat s jinými daty atp. Mám maximální flexibilitu.

Technické detaily

Skriptování frontendu / backendu

Zkusím vypíchnout jednu vlastnost tohoto skriptování, pro někoho možná zřejmou a triviální, pro jiné možná zajímavou. Trilium je principiálně webová aplikace (volitelně obalená Electronem), což znamená že má frontend komponentu a backend komponentu. Pro většinu zajímavých věcí potřebuje skript pracovat s frontendem i backendem.

Místo klasického způsobu jak toto řešit (definováním např. REST API na backendu pro všechny povolené akce) je toto v Triliu řešeno tím, že umožňujeme frontendu injectnout kód do backendu, kde je pak spuštěn. Příklad funkce z Weight Trackeru:

async function saveWeight() {
    await server.exec([dateEl.val(), weightEl.val()], async (date, weight) => {
        const dataNote = await this.getNoteWithAttribute('date_data', date);

        if (dataNote) {
            dataNote.jsonContent.weight = weight;

            await this.updateEntity(dataNote);
        }
        else {
            const parentNoteId = await this.getDateNoteId(date);
            const jsonContent = { weight: weight };

            await this.createNote(parentNoteId, 'data', jsonContent, {
                json: true,
                attributes: {
                    date_data: date
                }
            });
        }
    });

    showMessage("Weight has been saved");

    drawChart();
}

Přechod mezi kódem spuštěným na frontendu a backendu je skoro nezřetelný - server.exec() akceptuje funkci a pole argumentů pro tuto funkci - toto všechno je pak serializované a odeslané na server, kde se vše deserializuje a spustí. Kód není nijak sandboxovaný a může udělat cokoli (i přesto, že existuje speciální API pro skripty, které by mělo být stabilní a snadno použitelné). Vzhledem k základním constraintům (hlavně, že Trilium je čistě single-user) je toto v pořádku i z hlediska bezpečnosti.

Definice závislostí mezi skripty

Jako poměrně zajímavé mně přijde použití vztahu "parent-child" ze stromu pro definici závislostí / kompozici mezi poznámkami. Není tedy potřeba žádný speciální příkaz uvnitř skriptů (něco jako include()), přesuny, přejmenování a podobné operace jsou automaticky refaktorovány. Takové reference mezi skripty je možné přidávat pomocí standardních nástrojů Trilia jako copy & paste klonování, "add link" dialog atp.

Příklad jak to funguje ve weight trackeru. Struktura je tato:

• Weight tracker (typ: Render HTML note)
  • Implementation (typ: HTML)
    • chart.js (typ: JavaScript)

Weight tracker nemá žádný svůj obsah, jen automaticky vloží a vyrenderuje všechny své pod-poznámky. Poznámka Implementation se spustí, ale opět se první vloží všechny spustitelné pod-poznámky (chart.js), které jsou chápané jako závislosti předka.

Mám vizi, že v budoucnosti budu mít nějakou sadu utility funkcí pro (např. něco jako renderGraph()), které budou centralizované v nějaké hierarchii poznámek a když budu některou z nich potřebovat ve svém aktuálním skriptu, tak jen aktivuju "add link" dialog, kterým danou funkci naklonuji do podstromu svého skriptu a můžu ji hned používat - je to trochu jako mít IDE-like vychytávky bez IDE.

Závěr

Momentálně je podpora skriptování dostupná v posledních beta verzích. Je to ale zatím spíš technologické demo - chybí dost API, u některých věcí váhám, kterou cestu zvolit.

Jakmile přivedu tuto podporu skriptování do použitelného / stabilního stavu, tak bych chtěl začít pracovat na Android aplikaci (write-only - jen posílat poznámky a obrázky do "poznámky dne") a možná se začít trochu věnovat propagaci - co vím, tak Trilium kromě mě nikdo nepoužívá.

       

Komentáře

[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í.