Cadus – dokonalé GUI a práce s programem 1 - parametry

26.3.2013 22:51 | Přečteno: 1939× | | poslední úprava: 26.3.2013 23:03

Čumákuju, že jsem tu dost možná minulým blogpostem spustil lavinu, což je jedině dobře. Takže k věci: blog bude mít tři díly. V tomto budu řešit parametry, v druhé části ukážu draft gui, jehož potřebu dokonalého vzhledu jsem zmínil minule. V třetím bych rád navrhnul první část uživatelské interakce a princip práce a konstruování v programu.

Předpokládám, že společným cílem je PARAMETRICKÝ cad. To slovo jsem vykřičel, protože je naprosto zásadní a parametry jsou v cadu naprosto dokonalá věc. V zásadě a velmi zjednodušeně v parametrickém cadu nemáme kvádr 50x60x70 milimetrů, ale kvádr, jež je určen parametry AxBxC, jejichž velikost si můžeme určit při vytváření na těch 50x60x70 a poté je neomezeně měnit. Změna parametru má vliv na vše, co je k němu navázáno.

Vezměme si jekl 60x40 z vobrázku. Vše je na něm parametrické. Mohu kliknout na jakoukoliv míru a přepsat ji.

Zatím ty parametry vypadají jako nic moc, ale pokračujme dále. Udělejme si do jeklu díru pro vosmičku šroub. Pozici zvolíme 20 mm zepředu a 10 mm od stěny.

Kvůli tomu, že díra má parametr „hele vole buď 10 mm vod stěny“ se nám díra bude držet 10 mm od stěny. I v případě, že z prvního kroku změníme parametr šířky jeklu třeba na 60 mm. Když do díry vložíme šroub, který bude mít parametr, že bude souose s dírou, tak se po změně šířky jeklu přesune i díra a s ní i šroub.

Tento příklad je sranda srandoucí, ale ve velkých sestavách je to krutopřísně velemocné. Řekněme, že chceme zkonstruovat kadibudku a vystřelit na gumovém lanu. Začneme zvolením hlavních parametrů - půdorysem a výškou. Načrtneme tedy čtvereček 1000x1000 mm. Uděláme jeho kopii a nastavíme jí parametr, aby byla dva metry nad ním. Tím máme stanoveny hlavní rozměry a začneme umísťovat jekly, jejichž délka bude určena parametricky čtverečky. Na jekly plácneme boční plechy, které budou určeny velikostí jeklů. Dále přidáme dřevěnou placku se serdírou a stříšku. A nyní další geniální přínos parametrů: všem dílům nastavíme parametr hustoty. Tím se nám při každé změně přepočítá i těžiště. Nahoru přivaříme jekl, jež v jedné ose nebude umístěn vůbec k současným dílů, ale k celkovému těžišti sestavy. Na stejný jekl přivaříme oko, které bude mít parametr na střed jeklu v jedné ose a těžiště v ose druhé. Takže budeme mít boudu vždy pěkně svisle :) Nyní máme parametrickou sestavu, takže když budeme chtít kadibudku pro dva lidi, tak jen změníme základní čtvereček na 2000x1000 mm a změní se nám vše, od jeklů, bočních stěn, těžiště, polohy horního oka, šířky serdíry....

V dobře udělaném a inteligentně navrženém parametrickém modelu třeba formulky tak jde na jedno kliknutí změnit třeba rozvor a změní se nám kompletně všechno, včetně výrobních výkresů, kusovníků materiálů, naprogramovaných cnc drah atd atd.

Doufám, že parametry byly pochopeny, takže jdu spinkat, pokračování příště.

P.S. Nechoděj emaily z cadus org, po registraci vypisuje drupal chybu.

       

Obrázky

Komentáře

[Pnaky]

Už to nepiš, nikoho to nezajímá

[pavlix]

O tvém komentáři to skutečně platí. Zápisek se mi moc líbí, i když nejsem žádný konstruktér.

[Bystroushaak]

Proč lžeš?

[xkucf03]

Díky

Ten scénář by to chtělo hodit do User's workflows

[JS]

Neni mi uplne jasne, jak se zabrani cyklum mezi temi parametry a tedy nekonzistenci. Co kdybych treba chtel sroub v dire, ale dira by byla 10 mm z jedne strany a sroub 10 mm z druhe? Nebo je tam nejaka hierarchie?

[xxxxxxxxxxx]

k zacykleni parametru dochází docela casto. jinak šroub do díry umistis tak ze reknes cadu ze drik sroubu patří do díry a hlava sroubu na plochu kolem díry.

[pawleeq]

Cyklům a konfliktním vazbám se asi nelze vyhnout, protože je vytváří uživatel. GUI musíme navrhnout tak, aby ho nepustilo dál, dokud nebude součástka usazena korektně tj. že má ve všech třech osách jasnou vazbu na jiné objekty, nebo pevně danou pozici vůči počátku souřadného systému.

[Ondrej 'SanTiago' Zajicek]

V 'parametrickem' 2D grafickem editoru Vrr jsme to resili tim, ze zavislosti tvorily orientovany acyklicky graf. To je pomerne jednoduche, rychle a univerzalni (jdou bez potizi implementovat i ruzne nelinearni zavislosti), na druhou stranu pevne dany smer propagace zmen je zbytecne omezujici pro jednoduche linearni zavislost a dost neintuitivni pro uzivatele.

[JS]

Aha, netusil jsem, ze Vrr je "parametricky". Kazdopadne, me spis napadla alternativa a to ze by ty prvky tvorily strom, tam by pak smer zavislosti nerozhodoval.

Ale kazdopadne to pak zavisi na poradi, v jakem se definuji a tedy na uzivateli.

[pawleeq]

Drupalový web je zatím naprosto holý, ještě není co ukazovat. Sypu si popel na hlavu a brzy tam něco vyrobím. Pravdu už jsem tu za pěknou slibotechnu :)

Registrace má smysl hlavně na tracu, kde lze aktivně kecat do vývoje.

Díky za článek, s parametry samozřejmě počítáme. Klíčové je v GUI, resp. ve 3D pohledu jasně vaznačit, co je s čím provázáno.

[David Jaša]

Máte v komunitě nějaké stavaře?

[pawleeq]

Nikdo se k tomu zatím jmenovitě nepřihlásil, ale máme toto: http://cadus.org/trac/wiki/ArchitecturalEngineering. Pokud se do toho chcete pustit hlouběji, jste jen vítán :)

[David Jaša]

Franta to tam pěkně rozjel. To by baráčky mohlo pokrýt pěkně, chybí mi tam jen zmínka o modulové koordinaci (kroku/násobku pro některé prvky - aby se třeba kvůli oknům nemusely řezat cihly).

Možná bych časem mohl sepsat něco podobného pro liniové stavby.

[Josef Kufner]

Místa je tam dost

http://cadus.org/trac/wiki/UsersWorkflows

[Operator]

a hlavne programatorov, nezabudnut na programatorov!!!

[Sokrat]

no neblbni, programátor, který event. i něco umí, by při tom vymýšlení těch bombastických konceptů jen rušil.

[Dusan]

Ja som stavbár a zaujímam sa o voľný CAD. A rozmýšľam ako prispieť.

Napríklad ja by som mal záujem o ovládanie ako má strednotonážny CAD Microstation s pár skratkami ako je odskok "o", uzavretie smeru úsečky "enter", zlučovanie rozdelovanie objektov, ohrady, používanie podkladov z iných výkresov, pokročilé funkcie s krížikom a x,y,z.

Pre kreslenie v 3D odporúčam ako príklad nadstavbu speedikon 2.5. (kreslenie stien v 3D zo šrafovaním, kreslenie okien s parametrami a označením, generovanie rezov podľa podlaží, dodržovanie pravidiel ČSN, STN pri kreslení,....)

Funkcia ktorú má asi len autocad/bricscad Generovanie detailov podľa rôznych mierok na jednom výkrese ale s tou istou veľkosťou popisných fontov.

Ani funkcie ako má reconcad 2D pre bricscad niesu na zahodenie (tabuľky miestností s automatickou výpočtom plochy, ....).

Z microstationu+ spedikonu by som vedel urobiť video ak by bol záujem.

Nemám problém robiť bugreporting ani skúšanie funkcií.

ps. len chcem upozorniť že v konečnom dôsledku je potrebné mať veľmi kvalitne spracované 2D kreslenie pretože stavbarine je dôležitý výstup v 2D výkresoch (a určite aj pri iných odboroch) a na 3d vizualzáciu sa dá použiť aj blender.

ps2. nieže by 3D nebolo na nič to nie napríklad na generovanie rezov a pohľadov je super.

ps3. nikdy som neprišiel na chuť Archicad-om a podobným komplexným programom pre stavbárov, CAD som používal ako pokročilé kreslenie na výkres

ps4 Tou som napísal len pár funkcií ktoré mi chýbajú v jednoduchých CAD-och (librecad, FreeCAD, BRL-CAD) A to nehovorím o výpočet statiky/dynamiky, tepelnej techniky (viď agros2D), ...

[pawleeq]

Díky za spoustu podnětů.

To video by určitě pomohlo.

Zaregistrujte se na tracu, jakmile se to dostane do použitelné podoby, bude každý tester dobrý. Ale může to ještě hodně dlouho trvat. :)

[Josef Kufner]

Nedával jsi tam přesměrování na Trac?

[pawleeq]

už to funguje

[deda.jabko]

Mozna blba otazka: Zacal uz nekdo neco programovat nebo se jenom predhanite v napadech, jak uzasny CAD to mozna jednou bude?

[Sokrat]

to jsou ale zlé větičky ...

ale teď vážně, jestli si to nepochopil. Slouží to k tomu, aby se mohli ti chytří pobavit na českém webu anglicky o CAD.

[pavlix]

Na druhou stranu si říkám, že ti hate posteři nemají na práci něco lepšího než nadávat na projekt, který je údajně nezajímá. Co je to za druh mindráku?

[pawleeq]

No, this page, or -- to be exact -- these blogs, serves us to discuss CAD and -- as you might have noticed -- we discuss it in czech. The purposse of trac project is even for ill brains pretty obvious: it gathers the information relevant for upcoming code development, there is no discussion. For your further part in this chit-chat, please search Köchels list, no. 231. Thank you.

[pavlix]

Máš namysli to GUI? Taky se těším na nějaké dílčí výsledky, ale teď je na to asi dost brzo.

[pasmen]

Spíš mi přijde, že projekt nikdo neřídí. Mám upřímnou radost z toho, že se přestalo jen kecat, a někdo začal něco dělat Ale pokud to někdo neuchopí a nebude určovat směr, moc nadějí tomu stejně nedávám. Ale možná to někdo řídí a jen já se o to zajímám tak málo, že to nevidím.

[Josef Kufner]

Samozřejmě, že ještě nikdo nenapsal ani řádek kódu. Začít psát teď by bylo značně zbrklé.

Ale už se začaly kreslit nějaké ty obrázky.

[deda.jabko]

Ale už se začaly kreslit nějaké ty obrázky.

Sarkasmus?

[Josef Kufner]

Ne

[xkucf03]

Nejdřív se musí vymyslet, co budeme dělat, posbírat požadavky a pak naplánovat, co dáme do první iterace – pak se teprve může začít programovat.

[deda.jabko]

Nemuzu si pomoct, ale silne mi to pripomina ,,schuzi podvyboru kadernicke sekce pro vyvoj ohne''. Zajimalo by me, jak by vypadal Linux, kdyby byl vyvijen podobnym zpusobem, ...

[pavlix]

Druhá věc ovšem je, jak vypadá linux teďka :).

[xkucf03]

Ale tady přece nikdo nechce dělat klasický vodopád nebo stavět katedrálu. Vždyť píšu o iteracích. Ale tohle je větší systém, ne nějaký skript, kde by člověk prostě sedl a hned začal psát.

[deda.jabko]

Vždyť píšu o iteracích.

Rikej si tomu jak chces, ale pokud neuvedes, co ta iterace ma obsahovat nebo jak dlouho ma trvat, ma to informacni hodnotu nulovou.

Ale tohle je větší systém, ne nějaký skript, kde by člověk prostě sedl a hned začal psát.

Prave ze uz jsem videl spoustu projektu, ktere dojely na tom, ze se vic ,,schuzovalo'' a ,,malovalo'' nez programovalo. Nechci syckovat, ale nejak tu zatim postradam cloveka, ktery by mel jasno v tom, co chce delat, jak to delat a na mesic si sednul a naprogramoval prototyp. Aktualni pristup, kdy se vymysli CAD-pro-vsechno, mi notne pripada jako design by committee, coz moc casto dobre nekonci.

[Josef Kufner]

Zatím to je ve stavu, kdy se sbírají požadavky, lidi a zdroje. Právě proto, že není jasno co se vlastně chce.

Nikdo se tomu nevěnuje naplno, takže to jde relativně pomalu, ale aspoň se něco děje. Zatím se jen kecalo a nic nebylo. Kdyby se tomu naplno někdo věnoval, tak by to vypadalo jinak a prototyp by už byl na cestě.

Já se kolem toho motám hlavně kvůli tomu, aby to vůbec mělo nějakou šanci na úspěch a snažím se to trošku popostrkovat správným směrem. Jenže toho času mám poněkud málo.

V nejbližších dnech dám dohromady roadmap, co je potřeba ještě promyslet, aby se mohl udělat aspoň ten prototyp.

[xkucf03]

Rikej si tomu jak chces, ale pokud neuvedes, co ta iterace ma obsahovat nebo jak dlouho ma trvat, ma to informacni hodnotu nulovou

Viz iterace v RUP/OpenUP metodice, žádné pětiletky

Aktualni pristup, kdy se vymysli CAD-pro-vsechno, mi notne pripada jako design by committee, coz moc casto dobre nekonci.

Nic se nesmí přehánět… ale zase kdyby se začalo hned programovat, tak můžou být v návrhu chyby, které to znemožní použít pro některé účely… mohl by to být příliš jednostranně zaměřený software, který bude vyhovovat tomu, na co si programátor zrovna vzpomněl, ale na spoustu věcí, které uživatelé potřebují, nebude stavěný a bude se to tam muset dobastlit.

[jkb]

ale zase kdyby se začalo hned programovat, tak můžou být v návrhu chyby, které to znemožní použít pro některé účely

ja se priznam, ze jsem spis ten zdrzenlivy typ a proto mam problemy se tak sebejiste k vsemu moznemu vyjadrovat. Ale kdyz to predrecnik nacal, tak se osmelim.

Predne mi neni jasne, jak to ma formalne fungovat. Na tom tracu jsou jakesi podlkady, ktere jsou ted jako nejaky uz hotovy navrh? A nebo se ma k tomu diskutovat. Treba priklad. Pan Kufner tam pise , ze vsechno bude komunikovat pres slot/signal. Ja si myslim, ze to je volovina , ale kde se to ma napsat. Tady? A nebo jsem nikde nenasel , co pana Kufnera k tomu 'velkemuObrazku' vedlo. To si ma ted clovek domejslet, co ho k tomu vedlo a nebo to bude nekde popsano.

Pak je tam velka cast textu, kde jsou utrzkovite popsany jakesi vlastnosti nejakch CAD systemu. Smysl toho mi skutecne unika. Ne ze by to bylo uplne zbytecne, ale postradam takovou zakladni diskuzi o tom, co skutecne delat. Ocekaval bych, ze tam nekdo napise, ze bezne CAD free systemy jsou ve fazi prototypu nejdrive po 7 letech (gcad3d) , vetsinou po 10 letech a to jeste porad nic neumi. Jako prvni bych vedl diskuzi o tom, jake cesty vedou k tomu to urychlit. V cem udelaly vsechny ty projekty chybu, ze to trva tak dlouho. To, ze nejaky MegaCAD ma peknou ficurku v tomhle a onom je irelevantni malickost.

Ja bych proste na zacatku spis potreboval nejake schema toho, jak funguji minimalne 'uvnitr' ty stavajici systemy. A to bych podrobil kritice a na tom stavel.

[xkucf03]

Na tom tracu jsou jakesi podlkady, ktere jsou ted jako nejaky uz hotovy navrh? A nebo se ma k tomu diskutovat.

Je to k diskusi. Koukni na historii v tracu, já jsem tam kreslil trochu jiný obrázek, pořád se to vyvíjí a ujasňuje… Jestli myslíš, že je něco blbost a napadá tě, jak to udělat líp, tak si to nenechávej pro sebe a napiš to do tracu nebo sem.

To si ma ted clovek domejslet, co ho k tomu vedlo a nebo to bude nekde popsano.

To je právě ta analýza a návrh, která teď probíhá – a proto je mj. blbost teď hned začít programovat, než se rozmyslí některé věci.

Pak je tam velka cast textu, kde jsou utrzkovite popsany jakesi vlastnosti nejakch CAD systemu. Smysl toho mi skutecne unika.

Musíme vědět, v jakém prostředí se pohybujeme, mít přehled, co nabízí konkurence, inspirovat se a taky vymyslet, v čem budeme lepší (vyřešit nedostatky stávajících CADů). Zatím je to tam v pár bodech, ale chtělo by to podrobnější rozbor a posbírat víc zkušeností od uživatelů.

Ocekaval bych, ze tam nekdo napise, ze bezne CAD free systemy jsou ve fazi prototypu nejdrive po 7 letech (gcad3d) , vetsinou po 10 letech a to jeste porad nic neumi. Jako prvni bych vedl diskuzi o tom, jake cesty vedou k tomu to urychlit.

Řešení je prosté: pracovat na tom intenzivněji, ne jen sem tam, když má někdo volnou chvíli a nemá nic lepšího na práci. Otázka je, kde na to vzít.

To, ze nejaky MegaCAD ma peknou ficurku v tomhle a onom je irelevantni malickost.

Funkcionalitu, která se bude implementovat, je potřeba vhodně nakombinovat – musíme dát uživatelům to, co nezbytně potřebují k práci + něco navíc, třeba nějakou jednu vybranou vlastnost o řád dražšího CADu, než teď používají, nebo něco úplně nového.

[Josef Kufner]

Pana Kufnera k tomu vedlo to, že ho to prostě napadlo a nebyla to úplná hovadina. Je to jen nástřel toho, jak by to mohlo vypadat a zdaleka není konečný. A zrovna ta centrální část, přes kterou to bude všechno propojené, ještě bude potřeba dobře promyslet a aspoň tak dvakrát přepsat.

Vše, co je na té wiki má do specifikace ještě hodně daleko. Spíš to je hromada keců, ze které se pak ta specifikace postaví, až bude keců nashromážděn dostatek.

Pokud se ti neco nelíbí, tak je to pěkné, pokud víš i proč, tak to tam napiš přímo k tomu. Pokud chceš okolo něčeho otevřít diskusi, založ tu nějaké vlákno. Wiki na diskutování není, ale hodí se na sbírání závěrů z diskusí.

[pavlix]

Ani mě to jako až taková blbost nepřijde, vzhledem k tomu, že součástí návrhu je, že se různé části systému překlopí/přizpůsobí jiným částem podle potřeby. Na to je systém signálů ideální. Popravdě řečeno se něco takového docela osvědčilo v NetworkManageru, kde se to o to víc zdůrazňuje teď, když se snažíme přesněji oddělit jednotlivé vrstvy/komponenty. A to je NM oproti tomu, na co se chystáte vy, velice jednoduchý systém.

[Josef Kufner]

Díky.

[Franta]

A to je NM oproti tomu, na co se chystáte vy, velice jednoduchý systém.

No právě.

[pavlix]

Když se osvědčuje mít jasně oddělení komponent a být schopný plynule reagovat na události v jednodušším systému, určitě to neuškodí v komplikovanějším.

[Franta]

Takhle to zní moc hezky, stejně jako:

vzhledem k tomu, že součástí návrhu je, že se různé části systému překlopí/přizpůsobí jiným částem podle potřeby

Strašně záleží na konkrétní realizaci – jak jsou sdílené společné struktury/třídy/rozhraní, co se např. stane, když na jednom konci systému něco změním – selže kompilace, začne to nečekaně padat při běhu programu, nějak se to s chybou vyrovná a ošetří ji to…

Pokud to chceš udělat pořádně, stejně potřebuješ mít definovaná rozhraní. U rozhraní definovaných jádrem je to celkem jednoduché – každý modul závisí na jádře. Složitější je to u rozhraní, která jsou definovaná v modulech – jeden modul závisí na druhém a musí spolu nějak sdílet část kódu.

[pavlix]

To zde nikdo nerozporoval.

[Franta]

vsechno bude komunikovat pres slot/signal. Ja si myslim, ze to je volovina

Signály/sloty jsou akorát syntaktický cukr (neříkám, že nejsou fajn) a totéž jde obstarat pomocí posluchačů událostí. Ale to není až tak podstatné – důležité je:

• Jaká data a jak se budou mezi moduly předávat. Primitivní typy nestačí, bude potřeba předávat instance nějakých tříd. Některá budou definovaná v jádru Cadusu, některá alespoň jako rozhraní. Jiná budou definovaná v modulech – tam je potřeba vyřešit závislosti mezi moduly – abys měl k dispozici potřebné definice.
• Kdo bude zodpovědný za propojení signálů/slotů (nebo za registraci posluchačů událostí). Jestli to bude dělat modul sám nebo někdo zvenku. Asi bude potřeba obojí – každopádně když nainstaluji nový modul, musí s ním přijít i kus kódu, který ví, jaké signály/sloty ten modul má a napojí je na zbytek systému.
• Neměl by se z toho stát špagetový kód, kde je všechno propojeno se vším. Tam, kde to aspoň trochu jde, je potřeba použít společnou sběrnici, kam budou chodit události a ke které se budou moci registrovat ostatní moduly.
• Signály/sloty/posluchače/události nejsou všespásné, někdy je potřeba prostě volat metodu nějakého jiného objektu. Příklad: udělám modul pro hromadné ukládání ve víc formátech. Modul si od jádra vyžádá seznam všech dostupných exportních modulů (budou implementovat nějaké rozhraní). Modul zobrazí okno, kde uživatel zaškrtá formáty, ve kterých chce uložit (exportní modul o sobě říká, jaké formáty podporuje). Modul postupně zavolá metody vybraných exportních modulů a tím uloží výstup ve více formátech.

Nic proti signálům a slotům, myslím, že se sem hodí, ale kruciální je: 1) jak sdílet hlavičkové soubory, definice tříd/rozhraní mezi moduly 2) Jak sdílet a efektivně používat informaci o tom, kdo jaké signály/sloty/metody podporuje a jak je propojit (dostatečně spolehlivě, aby se nám systém nerozsypal pod rukama, když se změní nějaké rozhraní, a abys věděl, co jde jak propojit).

[:::]

"kruciální"? Vazne?

[Franta]

Copak jsi tu nový?

[pavlix]

Signály/sloty jsou akorát syntaktický cukr (neříkám, že nejsou fajn) a totéž jde obstarat pomocí posluchačů událostí.

Asi hloupý dotaz, ale… V tom je nějaký rozdíl?

[Franta]

Čemu nerozumíš na spojení „syntaktický cukr“?

[pavlix]

Dobrá, tak mi řekni, proč by to měli v Qt implementovat nestandardním způsobem, když tam je standardní nástroj pro obsluhu událostí.

V tom, že jsou signály jen syntaktický cukr, se mýlíš. Třeba Glib signály má a syntaktický cukr pro ně nemá a v C je musíš hezky registrovat, napojovat a volat běžnou funkcí. Signály jsou události, Qt signály či GObject signály jsou konkrétní implementace těch událostí. Že k tomu Qt nabízí syntaktický cukr, je víceméně nepodstatný detail.

[Franta]

Kdo bude zodpovědný za propojení signálů/slotů (nebo za registraci posluchačů událostí)

V Tracu teď je:

Modules does not connect themself, they are connected together by the glue (script engine).

jak se ale zařídí napojení nového modulu k tomu zbytku? Dejme tomu, že si napíšu vlastní modul nebo stáhnu nějaký z Iternetu. Pak je potřeba upravit i to „lepidlo“. To bude dělat uživatel ručně?

Neměl by pak být modulární i ten skript/lepidlo? Resp. každý modul by přinášel dynamickou knihovnu + kód, který zajistí napojení na zbytek.

[pavlix]

Konečně smysluplná poznámka. Já jsem to pochopil tak, že modul bude odpovídat nějakému standardnímu modelu a proto bude napojitelný univerzálně. Jestli je to v tomto případě dobrý nebo špatný nápad, je druhá věc, ale tenhle princip se běžně používá.

[Josef Kufner]

Jsou v podstatě dva use-case, které je potřeba rozlišit.

Prvním je poskládání aplikace jako takové. V tomto případě je potřeba upravovat lepidlo podle toho, jaké moduly jsou použity. Což je naprosto v pořádku, neboť od toho tam to lepidlo je. Tímto způsobem si také můžeš vytvořit vlastní aplikaci z existujících modulů (např. pro dávkové zpracování na serveru).

Druhým use-case je rozšiřování existující aplikace bez nutnosti zásahu do ní. Tak jako tak je potřeba vytvořit nový modul s požadovanou funkcionalitou. Otázkou je, jak jej pak integrovat do existující aplikace. Asi nejlepší bude dodat spolu s modulem i kousek dodatečného lepidla, který bude použit lepidlem aplikace k napojení modulu. Způsob interpretace tohoto dodatečného lepidla totiž závisí na konkrétní aplikaci, a proto nemůže být součástí modulu, neboť by to značně omezilo znovupoužitelnost takového modulu.

[Franta]

Asi nejlepší bude dodat spolu s modulem i kousek dodatečného lepidla, který bude použit lepidlem aplikace k napojení modulu.

Může být (i když stále mi nesedí skript jako centrální bod aplikace). Ale je potřeba vyřešit sdílení kódu/rozhraní mezi moduly, které na sobě závisí. Např. modul A produktuje objekt X a modul B ho chce používat.

[deda.jabko]

ale zase kdyby se začalo hned programovat, tak můžou být v návrhu chyby, které to znemožní použít pro některé účely…

no co, tak by byly v navrhu chyby, ...

ze kterych by se dalo poucit, ted nemate nic... hezky to vystihuje Paul Graham: Good design is redesign.

osobne se mi vic libi pristup toho cloveka, co tu programuje ten 3D engine/programovaci jazyk, ... taky to neni jednoducha vec, presto nediskutuje a programuje a projekt se hybe kupredu, ...

[Franta]

no co, tak by byly v navrhu chyby, ... ze kterych by se dalo poucit, ted nemate nic... hezky to vystihuje Paul Graham: Good design is redesign.

Čím později se chyba odhalí, tím je její oprava dražší – analýza, vývoj, testování, produkční nasazení. Jistě že chybu můžeš opravit i v pozdějších fázích, ale spotřebuješ na to víc zdrojů – které se mohly využít k něčemu užitečnému, kdyby se díky správné metodice nevyplýtvaly. Ve výsledku pak při bezmyšlenkovité živelné implementaci dodáš méně funkcionality nebo méně kvalitní produkt při využití stejných zdrojů.

taky to neni jednoducha vec, presto nediskutuje a programuje a projekt se hybe kupredu, ...

Třeba o tom nediskutuje veřejně, ale věřím, že o tom sám dost přemýšlel, než začal psát kód.

[JS]

No pokud by ti lide, co to programuji, byli opravdu zdroje (napr. je nekdo platil), pak je to mozna legitimni uvaha.

Ale pokud to maji byt nadsenci, tak k zadnym ztracenym "nakladum prilezitosti" nedochazi, to je proste blabol. Je to totiz na nich, jak chteji travit svuj volny cas - jestli navrhem dopredu a pak kodovanim, nebo nejdriv kodovanim a pak predelanim.

Quake66 (nebo jak se ten typek jmenuje) to predevsim programuje, takze to je jina situace.

[Franta]

Dokud tady nikdo nikoho neplatí, tak je jasné, že nejsilnější slovo bude mít ten, kdo udělá nejvíc programátorské práce, to je normální. Ale přijde mi dobré, že se ještě nic neprogramuje a je díky tomu čas v klidu prodiskutovat některé věci a udělat hrubý obrázek toho, co by měl systém umět.

[deda.jabko]

kdyby se díky správné metodice nevyplýtvaly

Kdyz si myslis, ze je mozne nahradit zkusenosti metodikou, budiz.

Ve výsledku pak při bezmyšlenkovité živelné implementaci dodáš méně funkcionality nebo méně kvalitní produkt při využití stejných zdrojů.

Ale ja nerikam, ze se to ma implementovat bezmyslenkovite. Jak uz jsem psal nekde jinde, tak dle meho projektu chybi clovek, ktery uz nekdy CAD programoval (byt treba neuspesne) a mel by schopnost ten projekt vest aspon v prvni fazi a mel by zaroven schopnost navrhnout a naprogramovat zaklad.

[JS]

+1

Fandim obema projektum (a i vsem ostatnim), ale v tomto pripade by opravdu bylo dobre najit si nekoho, kdo to tedy bude programovat. (A je pak otazka, jesti si do toho on bude chtit nechat mluvit od nekoho, kdo to neprogramuje, kdyz uz to dela z nadseni.)

Ale ja za to nechci nikoho kritizovat, taky mam problem s paralyzou analyzou (ale nechavam si to pro sebe).

[Franta]

A skutečně myslíš, že jde o paralýzu analýzou, když vznikly dva diagramy a trochu textu?

[JS]

Ja se o tom nechci hadat. Tohle ukaze az cas. Zatim mi to taky spis pripomina group project z tohoto videa, a jak rikam, nechci to kritizovat, ani se o tom prit, protoze tu situaci taky duverne znam.

[deda.jabko]

Fandim obema projektum (a i vsem ostatnim), ale v tomto pripade by opravdu bylo dobre najit si nekoho, kdo to tedy bude programovat.

Vidim to stejne.

[frEon]

mnooo, za Linuse to rozhodovani, co to ma umet uz udelali jini v nekdy v sedumdesatejch letech, ne?

[Divný host]

Kdyby někdo, jako já, nevěděl co je jekl: http://nase-rec.ujc.cas.cz/archiv.php?art=7670

[pawleeq]

Soused -- starý pán, má už přes 80 -- ješt používá slovo "jeklovina".

[xkucf03]

Zanedlouho (6. a 7. dubna) bude konference Openmobility. Je to dobré místo, kde hledat spřízněné duše – tipuji, že tam bude hodně lidí od 3D tisku, ale i dalších nadšenců, kteří by mohli pomoci nebo by je to minimálně zajímalo. Nechcete někdo (pawleeq, usama, JK,…) udělat krátkou přednášku? Jde o to, předat naši vizi a nadchnout další lidi.

[pawleeq]

Rád bych, ale na výlet do Blavy mmtálně nemám čas a hlavně prachy.

[pavlix]

Zase tolik to nestojí.

[Josef Kufner]

Já tuhle přednášku udělat nemůžu, protože nejsem ten, kdo ten CAD chce. Tohle si musí vzít na starost pawleeq a usama. Já pak můžu říct, jak se to dá realizovat, jak Cadus má vypadat uvnitř, ale ne proč ho dělat.

Rozhodně si ale myslím, že to je dobrý nápad a příležitost.

[Martix.]

Rád bych rozvinul, co napsal Franta. Není se čeho bát, krátkou přednáškou je myšlený 5 nebo 10 min Lightning Talk a nemusíte být ani moc připraveni. Obsah nechám na lidech okolo Cadusu, ale osobně bych rád slyšel o vašich důvodech, proč komunita potřebuje Cadus, co chcete udělat jinak a lépe a vaši představu jak to udělat. Prostě představit vaši vizi a s čím potřebujete pomoct. Vidím v tom příležitost jak vám pomoci nalákat vývojáře do zajímavého projektu.

[Dreit]

Jentak mimochodem k týmové spolupráci (původně se říkalo BitTorrent), co tak založit to na protokolu XMPP/Jabber? Stejným způsobem to mělo fungovat u Inkscape, bohužel to ale mělo chyby a už na tom nikdo nepracuje

Netuším teda jak na to (nejsem programátor), možná by se to dalo používat v režimu MUC (inspirace u IRC), ale příjde mi to jako dobře dostupná komunikační cesta. Jestli by se posílaly změny jako zprávy nebo jako patch soubory v base64 už je jedno.

Pokud by se použil MUC, tak by se z "historie chatu" dal zpětně postavit model a zdokumentovat průběh tvorby Když se připojí další tvůrce, tak si Cadus stáhne historii chatu a dál sleduje chat.

(snad jsem nenapsal nějakou kolosální blbost)

[xkucf03]

BitTorrent mi přijde nevhodný (ten je dobrý na velké objemy dat, která se nemění – tady to bude spíš spousta malých kousků měnících se dat), možná by šel použít na prvotní import nebo na sdílení knihoven, ale ne na online spolupráci.

Jabber už je lepší – dobrá volba. Ale v zásadě je to pro nás jen přenosový protokol – důležitější je, jaké zprávy přes něj budeme posílat (a ty se pak dají posílat i jiným protokolem). Jde o to, udělat nějakou abstrakci nad modelem – díky tomu bude Cadus moci pracovat nejen s modelem uloženým v lokálních souborech, ale i se sdíleným modelem, do kterého současně zapisuje více uživatelů (a dostávají i informace o změnách).

S tou rekonstrukcí z historie chatu to vidím složitěji stejně tak se zcela decentralizovaným modelem – master-master replikace – byť samozřejmě nic není nemožné, když to někdo naprogramuje

[Josef Kufner]

Ono se v podstatě hodí obojí. Jabber MUC lze snadno použít na real-time notifikace, kde bude vložen magnet link na aktuální balíček dat, která se pak přenesou pomocí BitTorrentu. Ale stejnak je nad tím potřeba nějaký verzovací systém, který to udrží pohromadě a konzistentní.

[xkucf03]

+1 torrent + jabber + verzovací systém, může být

Nicméně na nějakou master-master replikaci bych se v rámci jednoduchosti asi vykašlal a smířil se s tím, že tým bude potřebovat nějaký „server“ (klidně běžící na desktopu jednoho člena), protože jinak bys musel čekat, až se změny replikují (a potvrdí) ke všem kolegům.

[Josef Kufner]

Master-master replikaci nepotřebuješ. Master může být virtuální, kdy máš vlastně jen definovaný způsob určení aktuální verze, např. uložením jejího popisu někam (klidně bez velkých dat, ta se můžou válet všude možně).

Pro začátek bych se tím ale netrápil a předpokládal použití Gitu (s e-mail notifikacema) nebo toho Zima-něco nástroje. V Cadusu by pak bylo jen pár položek v menu na pohodlné spuštění takového nástroje.

[Dreit]

Já to vidím tak, že by se Cadus připojil na MUC, z historie si vytáhnul co se událo od založení chatu (podobně jako import souboru) a potom by jen sledoval chat.

Například když uživatel abc udělá díru do traverzy, tak jeho Cadus pošle do MUC popis akce (udělej takovou a takovou díru na tom a tom místě). Pokud se zpráva během určité doby (třeba sekunda) neobjeví v MUC, pokusí se ji poslat znovu. Jakmile se zpráva objeví v MUC, tak Cadus ostatních uživatelů provede danou akci, například tedy vytvoří díru v traverze. V případě duplikátních záznamů se duplikátní data ignorují (aby nevznikly tři stejné díry na stejném místě).

Je to asynchronní (na nikoho se nečeká), programy jednotlivých uživatelů si hlídají, že se jejich změny opravdu dostaly do chatu a osobně si myslím, že by to mohlo fungovat.

 

V případě ideální sítě (nulová prodleva, žádné ztracené pakety) by se to dalo teoreticky udělat následovně:

- jakýkoli Cadus pošle do MUC popis akce k vykonání, sám neudělá nic

- jakýkoli Cadus si akci v MUC přečte a vykoná ji - tedy i ten, který akci zadal

Samozřejmě v reálném světě by to nefungovalo dostatečně rychle a při ztrátě paketů by se nevykonalo nic Ideálně tedy program uživatele vykoná akci okamžitě (aby uživatele nezdržoval) a ostatní ji vykonají hned jak se objeví v MUC.

 

Bohužel asynchronní přenos má svoje chyby - co když se v chatu objeví nejdříve díra a teprve potom traverza? Byla by možnost vytvořit "díru" ve volném prostoru tak, aby po vytvoření traverzy byla na místě, kde má být? Napadá mě něco jako objekt s atributem "díra"

---

Nasdílení existujícího souboru na začátku sezení by se udělalo tak, že by se jeho obsah uložil do historie MUC.

Pokud by historie MUC nebyla k dispozici, tak by si nějakým příkazem nechal od náhodného člena poslat kompletní model do chatu, nebo jako běžná zpráva (chat s jedním uživatelem). Samozřejmě předpokládáme, že všichni pracují na jednom modelu a ne, že si někdo udělá nezávislý klon a potom jeho nasdílením zničí práci zbytku zkupiny

[Josef Kufner]

S tímhle jsem si hrál někdy před 5–8 lety... asynchronní stavové automaty peer-to-peer synchronizované po Jabberu. Fungovalo to hezky a na běžné síti jsou latence celkem přijatelné. Na interaktivní tvorbu čehokoliv to ale není.

Viz http://jk.frozen-doe.net/programy/netboard/.

[Dreit]

To vypadá moc hezky

Byl to jen návrh, nic lepšího mě na zadání "dostaň všechny změny ke všem účastníkům" nenapadlo