Diskuzní fórum železničních modelářů

Patri do plku, spis povzdech. Vcera jsem po delsi dobe pouzil JMRI, tentokrat Decoder Pro. Zcela chapu ze 'java ma hnusne GUI' po te, co jsem videl. Pritom to jde i jinak.

Panove, FAKT nekdo JMRI pouziva k realnemu rizeni kolejiste ? Opravdu ? Je to uspokojive fungujici ? Ptam se proto, ze to uzivatelske rozhrani je tak straslive "zprasene", nepohodlne, nedodrzuje skoro zadne principy "navrhu UI a ergonomie" co do mne poslednich 20 let vtloukali - a to nemluvim o programu samotnem - se systemy kolejiste se bezne "hovori" v UI vlakne, takze ruzne "zamrzava" GUI, spatne reaguje ... Ja bych i spoustu veci dokazal prepsat ... jenze ono je to zmastene uplne od zakladu az nahoru; ani v tom GUI si nezaridili pro aplikaci "jednotne" rizeni a vzhled dialogu, skupin tlacitek, odezvy pri chybach a validace vstupu. Vsude je to napsane zvlast a znova (nekde lip, nekde vubec).

OPRAVDU stoji za to to prekousnout a prekonat - stoji vysledek (= automatizovane rizeni provozu v kolejisti) za to ?

Prosim ozvete se vy kteri uz JMRI mate nasazene, ze to neni slepa ulicka. Diky za nadeji... po vcerejsku mam pocit, ze bych se mel radsi naucit C++, a nasadit RocRail

-----
Edit: zrovna ten DecoderPro. Proboha, ktery - s prominutim - pablb (jasne, udelal to programator, protoze nikdo jiny nedokaze udelat tak "strojove" rozhrani pro uzivatele) dokaze NAVRHNOUT GUI, kde je dialog s 20 zalozkami ? Zaprve, usporadani neni "logicke" podle dulezitosti. Lide se orientuji rychleji barvami - ikonky nikde. Mnozstvi zalozek je obrovske (ano, vim ze se jedna o panely ktere ma kazde zarizeni specialni, tim hur, protoze jejich pocet neni omezeny) - nez clovek vyhleda tu spravnou mezi 3 radky stejneho textu ... Pritom existuji jine bezne techniky:
- postranni navigacni seznam, klik na polozku zmeni panel. Vyhoda je, ze ma scrollbar a neroste tak nade vsechny meze, jedna polozka na radek se lepe cte
- misto seznamu strom, usporadany hiearchicky: Obecne, Zvuky, Svetla, Funkce, ZIMO, ....
I pouhe rozdeleni tech 20 veci na 2 urovne by zretelne zjedodusilo praci. A to nemluvim o tom, ze nefunguji poradne navigacni klavesy (tab, enter, ctrl+navigace), vsechno je mysoidni, pri zobrazeni zalozky je input focus Buh vi kde, jen ne na nejvyznamnejsim ovladacim prvku

Autodetekce dekoderu: zmrzle UI (komunikuje se s kolejistem). Obrazovka blbe rozdelena, nerespektuje roztahovani (ovladaci tlacitka mizi za okrajem dialogu).

Toto je názorný příklad, kdy kutilství překoná všechny rozumné meze a nerespektují se ani základní zažité principy. Taky už je tento skvost u tebe na blacklistu?

Brejla píše:Toto je názorný příklad, kdy kutilství překoná všechny rozumné meze a nerespektují se ani základní zažité principy. Taky už je tento skvost u tebe na blacklistu?

Jak se to veme. Prijde mi, ze ma nejlepsi podporu pro ruzne druhy dekoderu - kdyz si odmyslim to uplne "kutilske" zpracovani UI. Na blacklistu je predevsim do znacne miry Freiwald (cena licence, pristup Mr. Freiwalda k zakaznikum).
Muzes mi doporucit jiny, rozumneji udelany SW - dle tvych zkusenosti pouzitelny ? Potrebuji v prvni fazi ovladat kolejiste rozumne dotykacem. V dalsi fazi automatizovat provoz.

A jinak ... kdyby to nebyla uplna uchylarna, spravny postup by asi byl udelat fork, vrazit tam Netbeans (sic!) aplikacni platformu kvuli zakladnimu GUI - a zacit predelavat. Napriklad takovy DecoderPro, kde kazda lokotka je vlastne soubor, roster je vlastne takovy adresar, a cele kolejiste je defakto projekt ... lokomotiva ma tolik nastaveni, ze to vyda na pekny editor (ne dialog !), a NB umi celkem pracovat s workspacy - hlavni okno, sidebary a tak. Muze to vypadat fakt o DOST lepe. Ale je to taky DOST prace.

Nebo nejaky inkrementalni pristup ... napriklad v serializacich ti geniove dokolecka kopiruji a upravuji kod, pritom by stacilo par anotaci a procesor, ktery ten vicemene standardizovany kod (ktery se i MA z definice chovat jednotne) vygenerujou, nebo strojek rizeny runtime anotacemi v kodu. Kdyz jsem na to koukal tak asi 80% save/load kodu z/do XML by mohlo uplne pryc.

Sorry, ale nechápu, proč je to zde. Je to přece Software, a v tom je také vlákno JMRI.

mpinta píše:Sorry, ale nechápu, proč je to zde. Je to přece Software, a v tom je také vlákno JMRI.

@mpinta: protoze jsou to - pro vetsinu modelaru - skutecne plky. Nechci tim znecistit tema, kde se resi realne provozni problemy s JMRI. Teda to, ze JMRI blbe pracuje s asynchronnimi odpovedmi z kolejiste je bohuzel TAKY provozni problem (ktery panove "vyresili" vlozenym cekanim ) ale trochu abstraktnejsi nez to co bezny modelar resi. Myslim.

belgarat píše:

mpinta píše:Sorry, ale nechápu, proč je to zde. Je to přece Software, a v tom je také vlákno JMRI.

@mpinta: protoze jsou to - pro vetsinu modelaru - skutecne plky. Nechci tim znecistit tema, kde se resi realne provozni problemy s JMRI. Teda to, ze JMRI blbe pracuje s asynchronnimi odpovedmi z kolejiste je bohuzel TAKY provozni problem (ktery panove "vyresili" vlozenym cekanim ) ale trochu abstraktnejsi nez to co bezny modelar resi. Myslim.

Já v tom vidím spíš recenzi, poznatky, zkušenosti ...
A že je to více či méně odborné ... to by každé téma muselo být rozděleno na Začátečníci, Mírně pokročilí, Pokročilí ... atd., což je blbost. Ať si každý vybere to svoje.
"Znečišťování" vypadá jinak a je, bohužel, v každém druhém vlákně.

Tak já nějaký ten plk přidám. Když jsem volil sw já, nejdříve jsem zjistil, jaký SW lze využít. Přednost jsem dal pro začátek těm co lze použít zdarma. Zkoušel jsem tedy JMRI a RocRail. Řekl jsem si, že si postupně nainstaluji oba programy a že zkusím s každým programem pracovat 2 hodiny a uvidím, kam se dostanu. Vše jsem testoval na kousku kolejí s výhybkou. U RocRail jsem se dostal k ovládání výhybky i lokomotiv. V JMRI jsem zpočátku strávil hodně času tím, že jsem nechápal, který nástroj ze dvou mám použít pro tvorbu plánu kolejiště. Navíc u obou mi unikal princip ovládání. Nakonec jsem JMRI věnoval asi čtyři hodiny a prvotními problémy jsem se prokousal, ale mohu říct, že mně rozhraní odradilo natolik, že jsem se vrátil k RocRail. V pozdější době jsem opět zauvažoval o tom, že znovu zkusím JMRI. To bylo v době, kdy Sidlo začal vydávat zde na fóru seriál o používání JMRI. Ten seriál je skvělý. Když jsem si ale představil, co vše jsem nastavil v RocRail a co bych musel zadat znovu a jinak, tak jsem to vzdal. Navíc jsem si nebyl jist, že v JMRI dokáži nastavit nějaký automatický provoz jako v RocRail.

P.S: Ještě jeden důvod pro použití RocRail jsem na začátku měl. Na obrázcích se totiž principy použité v RocRail jevily podobné těm v TC, který jsem si chtěl původně pořídit. Ale to by asi lépe řekl Matrin.

@mpinta: se vsi uctou (nechci se hadat) - recenze vypada jinak. Tohle je jen zpoved ze srazky z jednou z mnoha casti JMRI. Jestli se dokopu k tomu, ze udelam seriozni analyzu (napr.) toho DecoderPro, co tam povazuji za problem (dost velky aby se zmenil) a proc + treba srovnani s TC (inspirace jak na to) -- slibuji ze tu uzivatelskou cast dam do nePLKu.

belgarat píše:...Muzes mi doporucit jiny, rozumneji udelany SW - dle tvych zkusenosti pouzitelny ? Potrebuji v prvni fazi ovladat kolejiste rozumne dotykacem. V dalsi fazi automatizovat provoz...

V tom ti neporadím. My jsme kompletně přešli na prvky průmyslové automatizace. Možnosti jsou obrovské, ceny bohužel taky.

@trixt: JMRI ma moznost automatickeho provozu - viz "Warrants". Ale jako se vsim se obavam ze to je dost "syrove". Na rozdil od RocRail umoznuji KOMPLETNI pristup pomoci Jython scriptu. Ale maji dost spatne definovany model spousteni vlaken / synchronizace s back-endovou casti, takze je otazka jak spolehlive ty scripty vlastne mohou byt.
Nezkoumal jsem az tak detailne; ale samotny fakt, ze jde aplikacni jadro skriptovat dava moznosti automatizace v podstate neomezene.

Plky

V jednom Šumavském penzionu, kde mají čtyři postele a dva měsíce v létě a dva v zimě mají pár turistů, používají účetní systém Pohoda. Jsou s ním velmi spokojeni. Má barevné ikonky, je jednoduchý a jednou za rok podat daňové přiznání zvládne.

Mezinárodní síť hotelů používá informační systém SAP. To proto, že v každé zemi kde působí se mluví jiným jazykem, platí jiné účetní zákony a na konci finančního roku se musí sestavovat konsolidované finanční výkazy. V hotelovém resortu někde na Havaii si místní ajťák všimne, že kód SAPu není optimální. Že agendy objednávání praní prádla, objednávání potravin do restauračních kuchyní a objednávání údržby výtahů jsou podobné, že by tedy bylo vhodné provést refaktoring kódu. Byl by kratší a lépe by se udržoval. Do toho se vmísila místní uklízečka, která prohlásila, že celý SAP je špatný a že její sysnovec na Šumavě používá systém Pohoda. Naštěstí ji nikdo nebral vážně.

Konec plků

Každé úsilí, které povede ke zlepšení funkčnosti nebo vylepšení kódu JMRI je vítáno. Držím palce belgarat, aby se mu jeho návrhy podařilo překlopit z úrovně plky do úrovně konkrétního kódu.

Plky.

Analogie SAP vs. Pohoda trochu kulha protoze mame protipriklady - kdyz se podivas na Eclipse, nebo (au!) NetBeans, nebo IntelliJ, zjistis, ze resi nepomerne slozitejsi ukoly, nad podstatne rozsahlejsimi a vice komplexnimi daty (koukni se treba na vizualizaci zavislosti maven POM.xml); presto dokazi dodrzovat obecne principy navrhu GUI - a v pripade IntelliJ se jedna o velmi efektivni zpusob ovladani.
Jenom panove z JMRI udelali opravdu mnoho chyb. Ani tak trivialni konvenci jako Bean Patterns (tusim z roku 1997) nedokazali dodrzet - a vyuzit (interface pouzito, ale blbe), ackoliv prave v rozsiritelnem systemu je to velka vyhoda. Prestoze se dodnes - a prave proto, ze umozuje integraci ruznych funkci - bezne pouziva.

Edit: kdyz jsem psal o XML, tak jsem se nahodne podival do jednoho load/store. Veril bys tomu, ze automaticka alokace portu se do XML zapisuje pomoci _jazykove zavisleho_ textu ? A pri cteni ... no jasne, vyplazne se varovani, ze se neda precist cislo portu (neb to neni cislo). I studenta by mozna trklo, ze kdyz zapisuje data, konfiguraci, nemuze do ni cpat prelozene retezce. Co kdyby nekdo - treba - chtel nacist konfiguraci z Cech na anglickych Windows ?

Otakza na zacatku vlakna byla: je to hnusne - ale kdyz to NAKONEC bude fungovat, clovek se pres to prenese. BUDE to fungovat ?

Jen tak na okraj - proc JMRI vypada tak jak vypada,

JMRI has historically worked on the “adding a few percent more users is important” approach. The network effects of that have been a _deliberate_ part of JMRI’s growth. That’s why we have hardware support for systems with only a few (in two cases, less than a dozen) users; signal support for somewhat obscure signal systems; (partial) I18N for 15 languages, etc. If people want to add something, “Code wins” and they can. _Many_ of those are additions by non-software developers and their contributed code, by any professional standard, is _terrible_. Yet it adds functionality, delights users, and that’s all good.
[...]
In the last few years, PaulB, RandallW and a couple others ...on’t want to merge PRs that don’t have sufficient tests, will argue about coding style. [...] But they miss the point: JMRI is about _model_railroading_ and 10’s of thousands of users aren’t delighted by the fact that the code test coverage has gone up. So we need to strike a balance so that JMRI can continue to be better for _model_ _railroaders_.
[...]
JMRI’s use of overridden versions of java.awt.Window#dispose() [1] dates back to the earliest versions that used Java 1.1.8.

parafrazovano: psali jsme kod jak to slo a neadaptujeme jej ani po 15 letech, ackoliv se knihovny uz zmenily a nekdejsi techniky jsou zastarale. Nebudeme vyzadovat aby se kod psal lepe, protoze to odradi modelare, kteri slusne psat neumeji, protoze slusne psany kod neni zadna vyhoda pro koncoveho modelare.

A pak se divte ze sem tam neco nefunguje, jako treba ENTER v dialogu, kde vidite tlacitko "OK".

Zaroven prosim neskakejte na spek Jirkovi_US az zase bude tvrdit neco o uzasnem projektu JMRI. A pokud hodnoceni JMRI svedci o schopnosti porozumet a porovnavat, tak bych se duheho protezovaneho systemu, DCC++ nedotkl ani chlorovanym klackem na tyci...

Vše co je výše napsáno je pravda. A teď se v tomto vláknu můžeme pohádat který přístup je lepší. Zdali mít SW, který vypadá a ovládá se podobně jako MS Office a některé zásadní funkce mu chybí, nebo SW který nesplňuje standardy dnešních požadavků na UI a umí splnit i ty nejnáročnější požadavky na provoz, respektive na modelování skutečného provozu.

Mám tu jeden hezký příklad ze života. Chodil jsem na přednášky ze statistiky. Studenti si mohli vybrat ze dvou programů. První byl placený (celkem drahý) s krásným uživatelským UI https://www.sas.com/en_us/software/stat.html. Přednášející nás varoval, co není v programu připraveno někde v menu tak program neumí vyřešit. Druhý byl s hodně spartánským rozhraním https://www.r-project.org/, ale nebyla úloha kterou by nevyřešil.
P.S. sám přednášející používal variantu č. 2. Všichni studenti si na zkoušku vzali program č. 2.

Sidlo: zapominas na to, ze JDE napsat program tak, aby se ovladal "jako word" a pritom se dalo nahlednout pod poklicku. Specialne u Open Source to neni problem ... a neni problem si "neco dopsat". Akorat tady misto "udelame neco co funguje pro 80%, a pak speciality", zvolili opacny postup. A jeste technicky (mnohdy) spatne provedeny.

Specialne kdyby melo JMRI (napriklad) dusledne oddeleny datovy model od UI, tak by se dalo skriptovat mnohem pohodlneji ... ty veci jako ve kterem vlakne se ma kreslit na obrazovku atd by si vyresil "nejak" zakladni JMRI kod. Jenze oni prenaseji i tyto hnusne veci na chudaka uzivatele.

P.S.: fastR programuje kolega v praci o 3 stoly vedle: https://github.com/oracle/fastr