Open source programator

[Miroslav Mraz]

No berte to jako první nástřel.

Jan Waclawek píše v Pá 26. 09. 2008 v 13:16 +0200:
> Niekolko nie prilis suvislych poznamok ku "koncepcii": Ocividne je tendencia rozdelit samotny "palic" (v modeli GUI-"palic"-firmware-hardware) od GUI (nerozoberajme teraz, ze to nemusi byt silou-mocou graficke rozhranie, vdaka za to co pan kolega Mraz urobil). Na druhej strane si treba uvedomit prave tu takmer nekonecnu variabilitu poziadaviek: len tak z fleku napr. 24C02 nepotrebuje taky velky datovy buffer (a teda to editovacie okno by malo byt obmedzene);
Zobrazení toho buferu je jen nouzovka, nedá se to ani editovat, to by
bylo dost práce. Asi by to chtělo něco s tím udělat (stránkování ?),
protože i tak zobrazení u velkých pamětí trvá dost dlouho (několik sec)
a po tuto dobu je okno mrtvé, takže se ani nedá spustit progress bar.
>  jednocipy (a aj ine obvody, napr. GAL) maju obvykle aj viac programovanych oblasti (napr. FLASH, boot FLASH, data EEPROM, user signature), takze tych okien by bolo mat zahodno viac;
To jsem zatím neřešil
>  EPROM typu 27C512 - co je povodom celeho tohoto threadu - sa neda mazat takze ikona ERASE by mala byt pre ten pripad zasedena. Atd. atd. atd.
> 
ikona Erase je opravu u tt. typu paměti šedivá
> Teraz je otazne, kto by mal byt nositelom informacii o tychto vlastnostiach - GUI? "Palic"? Obaja?
> 
> Pointa toho delenia je - okrem ineho - v rozdeleni prace. Proste kto vie lepsie s okienkami a obrazkami, nech sa netrapi podrobnostami "palenia"; autor "palica" by sa zase nemal venovat ergonomii. Preto si myslim, ze zdrojom informacii specifickych pre obvody by mal byt len a jedine programator "palica" - no a pre jednoduchost a kompaktnost by sa tieto informacie mali dostat ku GUI az v runtime - GUI by sa mal spytat "palica", ake obvody podporuje; pri vybrani obvodu by sa mal spytat, co vsetko ten obvod obnasa - to je u pana kolegu Mraza plnenie struktury typu deviceinfo, a to rozhranie je to co by malo byt definiciou abstractinterface.
> 
XML konfigurační soubor - jeho struktura bude odpovídat struktuře
deviceInfo
> ---
> 
> Este jedna konkretna poznamka, data je potrebne viest jednak oddelene pre programovane oblasti (FLASH, EEPROM atd.), a druhak je potrebne mat pre kazdy byte este aj flag, ci ten byte je programovany alebo nie, resp. ci sa v natahovanom intelhexe skutocne vyskytol.
> 
To je možná dobrý nápad.
> ---
> 
> Tiez je potrebne mysliet na to, ze pre pohodlne pouzitie trebars v opakovanej vyrobe je potrebne nieco ako su projekty u Elnecu, t.j. subor (podla moznosti jediny, aj keby trebars mal byt zipom viacerych suborov) zahrnajuci cely kompletny "stav" programu - vybrany obvod, jeho nastavenia, vsetky suvisiace data, nastavenie a stav serializacie.... ine ma momentalne nenapada... 
> 
> ---
To je na další XML konfigurák
> 
> Este jedna poznamka pre pana kolegu Mraza (a inych co by mali zaujem prispiet - dufam ze vas je vela ;-) ): treba pomerne rigorozne dbat aj na moznost ovladat takmer vsetko z klavesnice - je to rozhodujuce pre buducu pouzitelnost. Ak je moznost uzivatelsky nastavovatelnych klavesovych skratiek prilis pracna, je mozno vhodne sa inspirovat prave tym Elnekacky softom, ktory tu zrejme uz aj tak pomerne dost ludi pozna.
> 
Tvorba klávesových zkratek je legrace - v Designeru vyberu objekt, v
nastavení Shortcut jen zmáčknu příslušnou zkratku a je to. Takže tyto
zkratky si může každý nastavit jak chce.
> wek
> 
> 
> PS. Bolo by fajn zohnat niekoho kto vie spravit tie ikony - nielenze je neslusne ich vykradat z toho FLIPU, ale su aj skarede... ;-)
> 
No jo, ale něco jsem tam dát musel. Nic vám nebrání namalovat obrázky
32x32 pixel a když mi je pošlete, dám je tam. Bylo by dobré, kdyby měly
průhledné pozadí (proto jsou taky ty původní ošklivé).

Mrazík