Off topic - nazor obskurniho IT jedince, co ~25 let dela web a desktop aplikace.
TrainController je (bez posuzovani vlastnich moznosti rizeni) software orientovany na uzivatele, pohodli ovladani, vizualizaci jednotlivych procesu. Je profesionalni ve smyslu maleho poctu chyb, dodrzovani uzivatelskych postupu a principu z dalsich Windows aplikaci. Jinak receno, CTRL-C, CTRL-V, mysi tlacitka a dalsi gesta funguji 'jak je uzivatel zvykly'. Take obsah menu, alternativy context menu - hlavni menu - toolbar jsou konzistentni a funguji "jako obvykle", takze uzivatel zbytecne netape. V tomto smyslu je INTUITIVNI pro kazdeho pouceneho laika.
Uzivatelske prizpusobeni je vsak omezene jednak zvolenou vizualizaci a vizualnimi konfiguratory, jednak obchodne - nektere funkce jsou az v Gold verzich, ktere jsou patricne drahe.
---
JMRI je navrzeny technokraty pro technokraty. Svou uzivatelskou zakladnu si jiste najde, ale nedodrzuje prakticky ZADNE principy uzivatelskych rozhrani, at uz se podivam na doporucovanou praxi Windows nebo MacOS. Kazdy pes jina ves, nastroje NEJSOU integrovane, ale spis 'poslepovane' - pohromade je drzi vlastne jen infrastruktura komunikace s kolejistem. Z toho plyne, ze kazdy nastroj je nutne se naucit pouzivat a pamatovat si presne detaily; navrh dvou podobnych "obrazovek" ve dvou nastrojich je obvykle zcela jiny - nejlepsi je ridit se presne navodem (viz perfektni tutorialy Sidla); intuitivni pristup naprosto selhava. Mimo 'hlavni scenare' obsahuje JMRI obrovske mnozstvi chyb, ktere muze vyustit i v zablokovani komunikace s kolejistem (bezny stav u pouziti DecoderPro).
Namisto dusledne vizualizace a omezovani uzivatele se naopak sazi na skriptovani a AKTIVNI zapojeni uzivatele ve forme drobnych programku v Pythonu - ty mohou jak reagovat na 'kolejistni udalosti', tak generovat udalosti pro jiz pritomne standardni mechanismy (napr. aktivovat interni senzor); moznosti prizpusobeni jsou prakticky neomezene (umi-li uzivatel programovat).
JMRI neni vyvijen profesionalne (to neni na zavadu) - je zdarma; nepisi jej zhusta profesionalove (to uz ma vliv na kvalitu vysledku)- uz samotny navrh UI nedodrzuje zadne doporucene uzivatelske standardy. Provedeni kodu (je otevreny, a nekolik mesicu jsem si hral s ruznym pretvarenim) rovnez nerespektuje doporucene postupy do te miry, ze se da dokazat, ze je JMRI z principu (a neopravitelne) nespolehlive. Me zkusenosti ukazuji, ze hlavni vyvojari nechapou nektere klicove principy uziti implementacniho jazyka - z toho pak plynou dalsi navrhove chyby. Uzivatel se vubec nemusi s anomalnim chovanim setkat, pokud vsak nastane je na dane kombinaci hardware (zejmena konfigurace PC, ale tez centrale) pomerne pravdepodobne. To se jeste umocnuje v pripade uzivatelskych skriptu, ktere pouzivaji (chybne navrzene, sesynchronizovane) programove rozhrani.
---
Kdybych mel cas se tomu venovat ... kvalifikovany odhad je, ze 80% kodu JMRI je spatne udelane neco, co behem dlouhych let, kdy se autori JMRI opajeli ovacemi vlastni komunity vzniklo jako aplikacni infrastruktura v dalsich projektech (z meho oboru JetBrains, Eclipse, NetBeans -- vsechny obsahuji oddelitelnou knihovnu pro 'aplikacni zaklad', ktera je na rozdil od JMRI desitky let profesionalne udrzovana); nepochybuji, ze TrainController pouziva take profi aplikacni knihovnu - napr. nejakou formu MFC nebo co dnes v C++/Windows leti
. Tuhle cast ma JMRI beznadejne zaostalou a spatnou. Tech zbylych 20% je to, co JMRI dela 'vlackovym software'; a zatez prastarych a zastaralych postupu a udrzba 'unikatniho' kodu (ktery je jiz aplikacnimi knihovnami davno prekonany) brani soustredeni se na to podstatne: funkce a uzivatelske pohodli.
Pro Sidla: JMRI nedodrzuje ani principy ktere se pouzivaji od roku 1993, kdy jsem zacal (tehdy) s TurboVision v Borland Pascalu a byly davno zname (nebo spis prekonane) v dobe zacatku JMRI. O modernejsich postupech nemluve.