[Ovocníček]

To sdílení přes torrent se mi nezdá. Torrent stojí na tom, že při změně obsažených dat vypadanete ze swarmu. To znamená, že byste museli při každé změně obeslat swarm aktualizovaným indexem, to je na palici. Jenom jste ten problém sdílení změn zdojnásobil, imho :D

No, možná že to jenom špatně chápu, ale tohle mi vůbec nepřijde jako životaschopné řešení. Tohle se bude muset vyřešit stylem, jakým to dělají ostatní normální kolaborační nástroje, a to je... nemám šajna :>

[stativ]

Ty si to taky představuješ jako hurvínek válku.

Pokud chceš, aby to opravdu dobře fungovalo, musíš mít nějaké slušné parametrické jádro, které je schopno, pokud možno, pracovat s prakticky libovolným typem objektů. Iterativní styl vývoje je krásná věc, ale ve chvíli, kdy by výsledkem navrhovaného postupu bylo udělat všemožné operace s jednoduchými objekty (koule, kvádr apod), přidat podporu křivek, zjistit, že to dohromady nefunguje, vše přepsat na něco obecnějšího atd to nemá moc smysl. Možná by šlo použít Open CASCADE, ale vzhledem k bugům ve FreeCADu, co jsem viděl u když jsem zkusil kombinovat křivky a primitiva si nejsem jistý, jestli ty bugy nejsou zrovna v Open CASCADE, protože FreeCAD OpenCASCADE používá.

Pokud se nepoužije nějaká rozumná obecná reprezentace (kterou je těžké najít a vždy to bude nějaký kompromis), tak se spousta věcí snadno rozbije, nepůjde vůbec udělat nebo to bude fungovat blbě. IIRC byly v nějakém CADu některé uzavřené křivky řešené tak, že se tam vložil další bod, který zdánlivě spojil první a poslední bod neuzavřené křivky a pak to dělalo bordel. Nebo to bude jako v AutoCADu, kde podle všeho donedávna nefungoval loft z neplanárních křivek.

PS: Sorry za nepozitivní příspěvek.

[qwubla]

některé ty bugy budou možná spíše patřit knihovně Coin3D nebo jak se jmenuje...

V každém případě je FreeCAD ze všech open source projektů s 3D CAD programem jednoznačně nejdále.

Když nebudeme brát přímo 3D CAD, tak tu máme Blender a ten s knihovnou BMesh umí už i nějaké vlastnosti pro 3D CAD, ale stále to není na úrovni FreeCADu

[qwubla]

btw ještě aby to nevyznělo, že ten nápad neschvaluji, to rozhodně ne. Sám jsem pro lepší programy, jsem konstruktér, takže vím o čem je řeč. Takže nápad super!:) Ale ještě bych promyslel to, jestli se vyplatí začínat na zelené louce nebo spíše něco znatelně vylepšit a přinést do vývoje větší zapojení.

Inspiraci pro program bych např. hledal u SpaceClaim což je teď asi jeden z nejzdařilejších nápadů v 3D parametrickém modelování.

[tul]

Iterativní způsob vývoje může fungovat dost dobře i v tomto případě. Rozmyšlení na začátku nebude určitě fungovat, protože se na něco zapomene, tak se to bude muset předělávat stejně. Lepší je rovnou ve vývoji počítat se změnami. Problém je v tom, že dnešní komerční CAD systémy se vyvíjeli víc než 10 let. Těžko někdo může čekat, že opensource projekt to bude mít výrazně rychleji. Já to vidím tak, že pokud do toho někdo neinvestuje velké peníze, tak dřív než v roce 2018 verze 1 z blogu nebude. Mám ale pocit, že autor s tím počítá (viz. příprava projektu do konce roku), takže by to mohlo dopadnout.

[qwubla]

Příloha:

• Snímek obrazovky pořízený 2013-03-10 17:56:15.png (153364 bytů)

stále mi nejde do hlavy, že tady nikdo nevidí jaké možnosti má Blender nebo FreeCAD (Jo má blbé jméno, ale je použitelný).

spíše by stále za to, pokud někdo opravdu má nápady tak zapracovat a pořádně otestovat možnosti FreeCADu.. tedy např. Assembly a výkresy pak následně se hodí i třeba pořádně simulace a animace/rozpady etc.. Rozhodně by to mohlo být produktivnější než, opět dělat nový engine a další typické začáteční věci...

živá ukázka v příloze, takže to jde a na webu mají plno dalších ukázek... problémem jsou ale výkresy, anotace, popis a pak sestavy

[qwubla]

Zapoměl jsem ještě zmínit to důležité, pokud by se vybral např. FreeCAD pro vylepšení nebo i ten Blender Tak jsem ochoten se zapojit umím trochu Python a CAD programům rozumím.

[Bedňa]

Má parametrické jadro?

[qwubla]

Ano má

[Bedňa]

Wow, tak to je pekný základ.

[stativ]

Parametrické jak? Dovede to udělat např. průnik krychle a nurbs plochy?

[xxxxxxxxxxx]

Samozřejmě by se měl free CAD pořádně otestovat. Ale dle mého soudu je Free CAD co se týká GUI totálně špatně navržen. Co se týká jádra totálně chybí sestavy a výkresy. Co se týká mého dojmu z FREE CADu proč si myslím že jdou špatnou cestou se zakládá z dojmu tohodle softu že mají rozpracovány spoustu nepodstatných hovadin které jsou pro reálnou práci naprosto k ničemu.... Tříští síly a proto jim moc nevěřim... jednoduší by byl oplátek po plátku postavit ten CAD na základě nějakýho jádra OpenCAS CADE a nebo BRL-CADu odzačátku někým kdo s tím bude pracovat....Bez pořádnýho ovládání je i špičkové jádro naprosto k ničemu....

[stativ]

Zásadní problém je nějak dát dohromady lidi, kteří jsou schopni udělat ono nablýskané jádro a ty, kteří k tomu udělají dobrý interface.

[stativ]

Lépe – lidí, kteří ví jak má dobrý interface vypadat. Protože spáchat interface je vcelku jednoduchá záležitost, pokud se použije nějaký rozumný framework. Třeba Qt je výborné.

[pawleeq]

Na tvorbu UI se hlásím dobrovolně :)

Nic proti QT, funguje to, vypadá to slušně a z LibreCADu nebo QGISu s ním mám pozitivní zkušenost. Ale to je jen jeden kousek skládačky. Další -- a to naprosto nezbytná -- věc je editace konstrukčních a konstruovaných prvků v okně. Je tam potřeba přepínání, kdy těleso vidím vystínovaný, jenom linie, jenom viditelný linie, snapping k mřížce a konstrukčním přímkám & křivkám a miliony dalších blbin, který budou v čase přibejvat. Nejsa programátor a znalec knihoven/frameworků, nevím, jestli tohle QT zvládne. Pokud ano, well boys, here we go.

[pavlix]

Qt samo od sebe nic takového nedělá. Je to toolkit na výrobu okýnek s tlačítky. A v čem uděláš tlačítka i ty věci okolo je otázka osobních preferencí. To hlavní stejně budeš dělat nad nějakým OpenGL.

[pawleeq]

To jsem čekal a taky jsem někde tady psal, že to bude dost tuhý sousto.

[Josef Kufner]

Qt má i velice dobře použitelný skriptovací framework (postavený na Javascriptu, ale zcela bez knihoven). Trošku jsem si s tím hrál a QObjecty se tím lepí dohromady krásně. Pokud se použije Qt na GUI, nemá smysl hledat něco lepšího.

[stativ]

Tak tak. Na čudlíkovou část není nic lepšího. Horší to bude s hlavním oknem. Tam má smysl asi jedině něco vlastního nad OpenGL. Bál bych se akorát jedné věci, a to je spojení OpenGL a Qt. Když jsem to svého času potřeboval, tak používat nové verze OpenGL s Qt byl dost opruz.

[kralyk z abclinuxu]

Na druhou stranu je pěkné, že Qt Widgety se dají renderovat do OpenGL kontextu / zobrazení / jak se to jmenuje.

V Qt5 bylo napojení na OpenGL afaik přepracováno (zejména co se týče API), viz, oni to koneckonců dost potřebují na mobilních platformách...

[stativ]

V Qt5 bylo napojení na OpenGL afaik přepracováno (zejména co se týče API), viz, oni to koneckonců dost potřebují na mobilních platformách...

Jo, o tom vím a mám to ve svém TODO už pěkně drahnou dobu. Nějak se ale zatím nenašel čas/chuť to zkutečně prozkoumat.

[kralyk z abclinuxu]

Jsem na tom podobně :-/

[stativ]

OMG, ta hrubka.

[xxxxxxxxxxx]

jádro je. třebas lze použít BRL CAD...

[qwubla]

Ano, sestavy a výkresy jim chybí, není to však nic by se nedalo dodělat ve výsledku to mít. Ostatní části totiž již "mají" a ovládání zase tak hrozné není. Ano když to porovnám se SpaceClaim nebo s Catia, tak ten rozdíl je velký... Ale jsou nejblíže. Ostatní projekty ani neotevřou někdy 3D dxf R12...natož aby s tím pracovali. Viz např. Blender, kde se o to snaží již docela dlouho a stále to moc nejde. Ostatní není třeba ani jmenovat. Jakmile se např. vezme STEP nebo IGES format tak ostatní už mohou téměř končit..

mimo ještě zmíním projekt, není sice asi open source, ale importy má slušné http://gcad3d.org/ a zřejmě to ti vývojáři i používají...

[smazáno]

Hezky, snad to vyjde. Jen bych doporucil neprogramovat vsechno od zacatku, ale podivat se jaky open-source kod by se dal pouzit! A taky bych se nebal high-level jazyka (co musi byt rychle se da "odklonit" do cecka ). Mozna si myslis ze to jsou technicky detaily, ale tohle ovlivnuje uplne vsechno.

[Dreit]

Kickstarter?

[dumblob]

+1

[Jakub Lucký]

V tomhle případě spíš IndieGoGo, protože Kickstarter vyžaduje někoho s US občanstvím...

[Dreit]

Tak samozřejmě, myslel jsem způsob, ne konkrétní službu - o IndieGoGo jsem se dozvěděl dva dny zpátky a určitě nejsem sám, kdo nemusí vědět, co je tím myšleno

[Josef Kufner]

Rodmap je vcelku pěkná, jen bych se vykašlal na třetí číslo, ať to nevypadá tak depresivně. Však mezi 0.0 a 1.0 je místa dost.

Začít GUI odznovu a udělat ho pořádně schvaluju. Engine bych ale radši vzal už existující, nějaký slušně napsaný a začal s ním, neboť to jinak bude obrovský kopec práce navíc. Na druhou stranu by ale bylo rozumné, aby vazba mezi GUI a enginem nebyla moc silná. Pak půjde engine vyměnit za lepší, nebo přidat jiný.

BitTorrent je hezký nápad. Bude to ale chtít podporu pro verzování a rozhodně pro šifrování a podepisování souborů/archivů. Také by se hodila podpora VPN (propojení všichni se všemi), po které by to běhalo, aby bylo možné používat i další nástroje a služby v rámci pracovní skupiny. K tomu určitě bude stačit vzít existující nástroje, ale bude potřeba jim připravit automatickou konfiguraci a integraci s CADem.

Jako centrální bod pro autokonfiguraci by se hodilo použít něco snadno použitelného a jednoduše provozovatelného, např. společná IMAP schránka (bez SMTP), kam by každý klient automaticky umístil aktuální kontaktní informace a svůj veřejný klíč (něco jako DynDNS). Taková schránka by se pak dala použít i jako nástěnka.

[Filip Svoboda]

Ne, prosim zadnou integraci s bit-torrentem, cloudem, imapem ani nicim podobnym.. CAD ma kreslit, nema resit sync dat projektu.

Uvital bych jedinou zasadni vlastnost: ukladat projekty do ciste textovych formatu, nebo treba do archivu kde bude soustava textovych formatu a napr. binarek vlozenych bitmap (neco jako ma ms office).. tohle totiz prinasi zasadni vyhodu v tom, ze se pak da projektu ukladat do gitu (nebo jineho verzovaciho systemu), zkoukmat diffem, syncovat mezi vice lidma, a pomoci par skriptu to muze podporovat klidne cloudy a bittorent..

[xxxxxxxxxxx]

Na jednoduchém sync nástroj pro CAD už pracujem. do konce týdne uveřejním BLOG.

[pawleeq]

Integrace a sync se vzdáleným serverem se hodí, protože spousta a čím dál tím víc kanceláří funguje rozptýleně. Nejsou potřeba torrenty, cloudy atd, dtačí prostě centrální úložiště s verzovacím systémem. Nezatracoval bych to, ale taky bych z toho nedělal killer feature, který se podřizuje všechno ostatní.

BRL-CAD má dva datové formáty. Interně pracuje s binárním (přípona .g) a na transport používá ascii file, kde je všechno krásně popsaný. Proto s nim taky furt otravuju :)

[Josef Kufner]

Tou integrací nebylo myšleno kdoví co nablýskaného a nepoužitelného. Prostě jen připravený nástroj, který s tím prvním (CADem) pěkně spolupracuje. Textový formát a použití gitu mi přijde jako nejrozumější možnost, pokud to výkonově bude stačit. BitTorrent by mohl být transportním protokolem pro Git – Git ubalí pack s objekty potřebnými pro konkrétní verzi, BitTorrent+VPN to nakopíruje všem. Nebo tak něco.

[xkucf03]

S textovým (resp. nebinárním) formátem souhlasím, ale ne zabalené v archivu. Ať je to radši složka a více malých souborů, to se verzuje a porovnává lépe, než když to musíš nejdřív rozbalit. (archivy a balení do jednoho souboru může být pro import/export, ne pro samotnou práci).

Co se týče integrace – nemělo by se to hnát do extrémů, ale když bude program umět vytvořit verzi, vrátit se ke starší, porovnat je, vypsat historii, pracovat s nějakým verzovacím systémem nebo API typu WebDAV… tak to považuji za dobrou vlastnost.

V IDE je tohle běžná vlastnost – a programování je podobně tvůrčí činnost a taky tam potřebuješ verzovat a spolupracovat s ostatními.

[Josef Kufner]

Zobrazit rozdíly mezi verzemi přímo ve výkresech by mohlo být velmi zajímavé. Ale diffovat kopec souřadnic asi nebude moc praktické.

[pawleeq]

Toť otázka, pokud budeme chtít zobrazit rozdíly v modelu, asi se diffování souřadnic nevyhnem. Pokud budeme pracovat s rozumným textovým souborem, který posuje kde je jaké těleso, tak se to asi dá. Hlavně se vyhnout mračnům bodů a triangulovaným tělesům.

Pokud bychom chtěli vidět v rozdíly ve výkresu, nejspíš zase budeme diffovat nějaký XML soubor (nejspíš SVG).

Podle mě, je to prašť, jak uhoď.

[Josef Kufner]

Právě proto to bude chtít zobrazit přímo ve výkresu. Tedy jako obrázek a barevně zvýraznit změny, nikoliv jako text (ten tam může být pro upřesnění).

[pawleeq]

Zkrátka potřebujeme něco jako texdiff.

[David Jaša]

Hlavně se vyhnout mračnům bodů a triangulovaným tělesům.

Pokud to má být použitelné i pro liniové stavby, tak se tomuhle nevyhneš.

[pawleeq]

+1

Co se týče integrace – nemělo by se to hnát do extrémů, ale když bude program umět vytvořit verzi, vrátit se ke starší, porovnat je, vypsat historii, pracovat s nějakým verzovacím systémem nebo API typu WebDAV… tak to považuji za dobrou vlastnost.

Tesat do kamene, přesně tohle a nic víc.

Jinak nejsem kompetentní do toho kecat, ale nebylo by fajn mít aspoň zipovanou komunikaci? Přece jenom, jeden prjekt může mít řádově desítky souborů.

[xkucf03]

To bych bral jako import a export – program může podporovat oboje: složku i archiv – struktura bude stejná, není to nic složitého umět oboje. A uživatel si vybere, co je v danou chvíli výhodnější. Složka má výhodu v tom, že se nemusí do paměti natáhnout všechno najednou a rozbalit a při ukládání se nemusí přepsat celý velký soubor, ale jen to, co se skutečně změnilo. A archiv se zase dá snadno poslat e-mailem.

[pavlix]

To hlavně neříkej Jirsákovi :).

[xkucf03]

Tahle diskuse mi asi unikla…

[pavlix]

Diskuze o změně UI stran importu a exportu nenativních formátů v Gimpu.

[xkucf03]

• Název klidně může obsahovat CAD, aspoň bude na první pohled vidět, o co jde. Jinak souhlas, že by to chtělo nějaký originální a chytlavý název.
• Souhlas i s marketingem, webem, GUI… ale neměla by to být jen hezká fasáda a pod tím sračka, je potřeba to pojmout profesionálně, protože je to nástroj pro profesionály, kteří potřebují pracovat a nemají moc čas na nějaké hraní si s nehotovým programem.
• Zapojil bych ale komunitu kolem 3D tiskáren – to jsou obvykle nadšenci a zvládnou se vypořádat i s ne zcela perfektním GUI – a můžou dost pomoct v začátcích, minimálně s testováním.
• Jako jazyk bych zvolil C++ pro jádro + nějaký skriptovací pro rozšiřitelnost (ECMA Skript, Guile, moduly v Javě atd.)
• Ad spolupráce týmů v „cloudu“ – tohle by mohl být i dobrý zdroj pravidelných příjmů.
• Co se týče technologie, nevím, jestli je BitTorrent ideální. Co radši nějaký verzovací systém? V jaký řádech se budou pohybovat objemy dat? Jednotky až desítky MB? Stovky MB? GB?
• A zásadní otázka na konec: pro koho bude CAD určen? Jen pro strojaře? Nebo i pro architekty a majitele 3D tiskáren? Nevím, jestli se dá udělat něco tak univerzálního, ale snad by to šlo – společné jádro + moduly/nadstavby pro různé profese.

[xkucf03]

BTW: až teď koukám na tu přezdívku a datum registrace. Ale ty se ani podepisovat nemusíš

[xxxxxxxxxxx]

Zdarec a vítám tě do klubu. Co spojit síly? V současnosti makáme na jednotlivých na CAD nezávislých prográmkách který budou pracovat a budou použitelný ať už pro jakýkoli CAD. Zmínil jsi práci v kolektivu. Teďka dokončujem program ZIMA-CAD-Sync, který bude slouži k synchronizaci dat konstruktérů. Dobudoucna chci doprogramit do programu ZIMA-CAD-parts části které budou sloužit jako prezentační část pro zákazníky kteří si přez tento program budou moci přebírat online práci. Další věci kterou tam budeme chtít naprogramit jsou nástroje pro komplexní zprávu CAD dat a projektů jako takových. Což bude znamenat že ZIMA-CAD-PARTS bude využívat jednotlivých utilitek které teďkda programujem v jeden mocnej nástroj.

Co se týká myšlenek který si v blogu napsal s většinou plně souhlasim. Programátoři zdejší si ani neuvědomují kolik prachů se v tomhle odvětví nachází. A kolik by šlo vydělat na otevřeném řešení.

Co se týká vývoje samotného CAD... Se v současnosti domnívám že by šlo postavit komplexní parametrickej CAD nad BRL-CADem. Jde vlastně jenom o to využít jádra systému který umí matematiku a umí počítat průniky a tvořit křivky. Všechno ostatní je už "jenom" uředničina, když pominu tvorbu chytrého skicáře.

Napíšeš mi a nebo ti mám napsat sám? Co ti navrhuji je spojit síly! Vytvořit strukturu, plán a jít do toho!

[pawleeq]

Pokud vezmeme do začátku toto (co jiného se taky ode mě dá čekat, že ?:)), tak se dá roadmap vcelku proškrtat a zůstane tam jenom vyrobení hezkýho GUI (včetně okna pro interaktivní editaci těles, což je asi docela tuhý sousto) a exportu do výkresů. A administrativa.

Protože v BRL-CADu máme: - základ napsaný v Cčku - jádro pro logické operace s tělesy - raytracing - nehezké, ale funkční rozhraní napsané v TCL (knzervativní mged, nověji pojatý Archer).

Mám z poslední doby srovnání BRL-CAD vs. PTC Pro/E WF3. Uživatelsky je to nebe a dudy, a po funkční stránce BRL umí všechno podstatný, stačí udělat GUI pro modelování a výkresy.

[Bedňa]

jj ideš do toho :)

[pawleeq]

Si piš:) Ohledně celkovýho GUI atd už mám svoje představy, vyrobim nějakej draft, spíš teda slovní popis a zkusíme se nad tím domluvit, co a jak:)

[xxxxxxxxxxxxxxxx]

Hm, to vypada hezky... ted uz staci jen rozumny GUI frontend.

[Aleš Kapica]

Takové komunistické myšlenky jsem měl naposledy v páté třídě.

[xxxxxxxxxxx]

To si spíš nepochopil obchodní model, státní zaměstnanče.

[Aleš Kapica]

Ani bych neřekl. A jenom upozorňuji, že i když že se stokrát opakovaná lež v této zemi obvykle stává pravdou, nejsem státní zaměstnanec.

[Aleš Kapica]

Financování vysokého školství

[xxxxxxxxxxx]

Takže jsi placen z toho co se vybere na daních od daňových poplatníku jako jsem já a nebo autor blogu...

[Prcek]

Včera mě v televizi pobavili na tohle téma Krotitelé duchů .

[xxx]

Zdroje získávané od státu

Roli státu ve financování veřejného vysokého školství pokládáme za nezastupitelnou, a to z následujících důvodů:

Jasne, ani koruna ze statniho. Takze v okamziku, kdyby stat prestal platit za studenta, a utnul penize na vedu a vyzkum, tak by si toho na skole ani nevsimnete .

[Luboš Doležel (Doli)]

Takže člověk pracující ve firmě dělající státní zakázky je taky státní zaměstnanec?

[xxx]

Ah jsem zapomnel. Tyhle drobne nuance. Tak statni zamestnanec vs. clovek placeny ze statnich penez. (A ted jeste pres kolik prostredniku...)

Ale to uz se tu resilo, takze tahle debate je stejne redundantni.

[xxxxxxxxxxx]

pokud ta firma je živena výhradně ze státních zakázek tak je to defakto státní zaměstnanec protože netvoří žádnej zisk pro stát. Nula nulou pojde defakto. Jo a těmhle firmám se říká pijavice.

[manasekp]

ja bych rekl ze statni zamestnanec je clovek ktery ma uzavrenou pracovni smlouvu s nejakou statni organizaci, nechapu co to tady resite za silenosti

[xxxxxxxxxxx]

jo to máš recht. Řešíme místo CADu kraviny.

[Aleš Kapica]

V okamžiku, kdy by stát přestal za studenty platit, by se z nich stali samoplátci - stejní, jako jsou zahraniční studenti. A já bych si toho - přesně jak píšeš - ani nevšimnul.

[xxxxxxxxxxx]

já myslel že pracuješ na VUT?

[Aleš Kapica]

Ve statutu ČVUT není ani slovo o státní spoluúčasti na vedení či řízení.

[xxxxxxxxxxx]

Jo ale v reálném výsledku jsi placen z toho co se vybere od lidí co makaj v reálném světě jako zaměstnanci firem, podnikatelé a firem. nebo snad chceš tvrdit že když si stát natiskne penízky tak to bude fungovat aniž by to nebylo podložený reálnými zdroji? Prdlajs kámo. Všechno je to o pudě, ropě a zdrojích obecně. Služby jsou až druhořadé...

[Aleš Kapica]

V reálném výsledku je z těchto peněz placen naprosto každý. Na tom je celý monetární systém založen.

[xxxxxxxxxxx]

vzdit joo, natisknem si papírky a budem všichni delat pro stát... ))) víš kam tahle cesta vede....

[Aleš Kapica]

No očividně k lepším výsledkům než komunistický systém navržený v blogpostu.

Abychom si rozuměli - komunistický v původním slova smyslu, nikoliv tak jak se o něm hovoří z politologického či mediálního hlediska.

[xxxxxxxxxxx]

hele to že se lidi sdruží za účelem snížení nákladů ti přijde komunistický a utopistický? hehe vidím že máš fakt velkou představu o tom jak se ve světě vydělávaj prachy...

[Franta]

Proč si vlastně stát může tisknout peníze (resp. vydávat dluhopisy) na platy státních zaměstnanců a státní zakázky a ty si nemůžeš tisknout na zaplacení daní (resp. vydat dluhopisy ve stejném stylu splácení jako stát – ten svoje dluhy už nikdy nesplatí)?

[Aleš Kapica]

Ale můžeš. Říká se tomu směnka.

[xxxxxxxxxxx]

Muže, ale pak dojde k hyperinflaci. Protože v dnešním globálním světě ti nikdo potom neuzná měnu založenou na tisknutí papírků.... Prostě nebude ti nidko českou korunu nesmění a z toho plyne že si nenakoupíš zdroje které nemáme, jako je ropa atd...

[lm]

to je ale nesrovnatelne
vs dostane prachy/dotaci podle tabulek, napr. podle poctu studentu a to je takova jista domu. zamestanec v privatni firme nebo podnikatel (bavime se o bezne situaci, ne o nejakem gigantu s monopolnim/oligopolnim postavenim) se ale musi sakra otacet a prodavat svoje schopnosti aby se udrzel/prezil. chapu, ten pocit sucha a bezpeci na akademicke pude je navykovy, ale tak trochu mimo realitu ;)

[Aleš Kapica]

Ty seš mimo realitu. Žádné privátní firmě nikdo neříká kdy a na co může prostředky čerpat a na co ne. Ze školy jako takové přichází - alespoň tedy k nám na katedru - pouhá polovina financí. Jinak tady panuje normální tržní prostředí - katedra platí za prostory ve kterých sedí úplně stejně, jako by šlo o komerční subjekt. Co na tom, že se ty prachy přelívají v rámci jednotlivých částí ČVUT. To nikoho nezajímá. S tvým pocitem sucha a bezpečí by si mě stěží mohla dovolit katedra zaměstnávat, protože by neměla ani na uklízečky.

[mirec]

Ak by sa začalo stavať na nejakom funkčnom jadre môže to vyzerať zaujímavo. V takom prípade by som bol ochotný pomôcť s rozhraním za predpokladu, že by to bolo Qt (GTK moc neovládam).

[xxxxxxxxxxx]

Nechci do toho kecat, protože to není muj blog ale QT jooo.

[Grunt]

Co si budem povídat, o potřebě kvalitního volného CAD systému tu už bylo napsáno víc než dost.

Potřeba pro koho?

[xxxxxxxxxxx]

pro lidi, konstruktéry. Jde o svobodu tvorby.

[Grunt]

pro lidi

Yay, here we go.

[alkoholik]

Vykasli se na desktop aplikaci a napis to nad WebGL. Budes najednou multiplatformni s centralnim zalohovanim a podobne..

[mirec]

Vývojár webových aplikácií, to bolo len tak napísané niekym, kto weby nevyvíja?

[Josef Kufner]

To zní jako námět na dobrý horor

Nicméně jako prohlížeč souborů v repositáři na serveru by to nemuselo být úplně zcestné.

[xxxxxxxxxxx]

Jo a až si otevřeš velkou sestavu tak si budeš moci jít na pul denní svačinku... ))

[alkoholik]

Zkuste se oprostit od ideologie. Kde presne vidite objektivni problemy?
Lokalni storage v HTML5 mate, vypocty dela silny serverovy backend, akceleraci GL resi prohlizec.

[xxxxxxxxxxx]

když by to bylo stejně rychlé jako lokální Cčková aplikace tak beru zpět co jsem napsal.

[mirec]

Som webový vývojár (primárne). Vidím problémy v tom, že veci, ktoré sa písali pred pol rokom nefungujú. Už pri malých aplikáciách stačí stotinková zmena verzie webkitu a rozbije sa to. O ostatných enginoch ani nehovorím. Celé weobové aplikácie sú také ... nefunkčné. Ešte aj obyčajný google od kedy je napchatý javascriptom nefunguje poriadne a pár krát som zaznamenal zatuhnutie pri použití back / forward. To hovoríme o službe, ktorá má 1 input a 1 tlačidlo a stojí za ňou obrovská spoločnosť!

[rADOn]

Objektivní problém: Reálný výkon WebGL je někde na úrovni toho co se koncem devadesátých let honilo v Céčku přes software. Skuteční inženýři potřebujou trochu víc polygonů než má demo s rotující kostkou. Akcelerace znamená jen to, že ty polygony můžeš rychleji přepočítat a vykreslit, čili webGL rovná se čekání až pomalý javascript natlačí data do grafule. Zkoušel jsem předělávku minecraftu do webGL – cpu je na plech a grafule nehne vrtuli. Takže budu mít "aplikaci" která položí prohlížeč do kolen, nebude fungovat bez internetu a bude pomalejší.

Zkus se oprostit od ideologie… Jaký problém se vyřeší tím že to bude v prohlížeči?

(Nic proti webGL, na skládání mapových dlaždic, animace gui a podobné vylomeniny je to určitě bezva.)

[alkoholik]

To spis vypada, ze ti v prohlizeci neslape korektne akcelerace.
A dnes se uz offline webova aplikace napsat taky da.

[xkucf03]

Ono se dá spousta věcí… ale proboha proč?

[xkucf03]

A mezi tím je brzda a destabilizační prvek: interpretovaný skriptovací jazyk (a taky síť).

Web a webové aplikace mají své kouzlo pro případy, že nechceš nic instalovat, jednou za čas tam přijdeš a použiješ to, pak zase zavřeš prohlížeč a už ti tam nic nestraší, máš od té aplikace pokoj. Ale pro programy, které používá člověk den co den jako pracovní nástroj to nemá smysl.

[kralyk z abclinuxu]

Zkuste se oprostit od ideologie. Kde presne vidite objektivni problemy?
Lokalni storage v HTML5 mate, vypocty dela silny serverovy backend, akceleraci GL resi prohlizec.

Jo, taková je teorie, praxe vypadá tak, že i relativně velmi malá WebGL aplikace ti sežere velký množství prostředků. Onehdá jsem si s tim hrál, schválně se podívej, kolik ti jen tahle malá kravinka sežere CPU/RAM, případně zkus něco, kde je víc dat. Nehledě na to, že celkem ani nevidim důvod, proč něco takovýho do prohlížeče vůbec cpát...

[David Jaša]

jede mi to krásně - narozdíl od webgl varianty gůglích map.

[pavlix]

Jede mi to bezvadně na slabším notebooku (Lenovo x61).

[kralyk z abclinuxu]

Tak což o to, mně to taky jde plynule, ale mrkni se, kolik to zabere RAM. U mně ten druhej příklad dohromady skoro 300MB (proces tý karty + GPU proces).

Kolik by asi sežrala nějaká komplexnější CAD aplikace, že...

[alkoholik]

300MB RAM je dnes nic. Navic ten CAD bude pouzitelny nejdriv za par let a a kde bude prumerna pamet tou dobou, ze?

[kralyk z abclinuxu]

300MB RAM je dnes nic.

Jo, jasný, 300MB pro v podstatě hello world aplikaci je pohoda, optimalizace se dělá až zítra a přinejhorším si uživatel koupí nové železo, žejo, je to jeho problém... Tyhle kecy fakt miluju. Ale ono asi se nemá smysl o tom hádat, oni už stejně lidi výše poukázali, že je nesmysl to psát pro prohlížeč...

[Bedňa]

Neviem čím to je, ale najskôr asi uložením predpočítaných pozícií (otázka je či by žralo menej keby som mal menej RAM), u mňa to žerie rovnako. Webgl s veľkou pravdepodobností pokročí do budúcnosti, keď to má behať aj na embedded zariadeniach. Neviem či si niekedy hral Quake Online, ale to hádam skúšali všetci :) A behá to aj na šuntovej grafike krásne.

Úplne by sa to nemuselo zavrhnúť, pretože aj v Quake Online bude engine napísaný v C++ a potom ho plugin implementuje do prehliadača, teda myslím si to, inak si neviem ako to mohlo makať na šuntovom kompe čo som mal.

[smazáno]

premature optimization is the root of all evil

[xkucf03]

Jenže neházet si klacky pod nohy není předčasná optimalizace – to by měl být výchozí stav.

[jkb]

to tak nemusi bezpodminecne byt. V tom WebGL bezi opengl knihovna, napsana v C/C++ a ten javascript hraje pri zobrazovani jen podradnou ulohu. Mnohem dulezitejsi je, ze graficka karta musi mit nejaky opengl driver, jinak se to emuluje pres mesa3d. Pak je to samozrejme pomale, ale to by byla i nativni aplikace. Jako 3d-prohlizec to urcite jde.

Ale to je jen teoreticka poznamka. Ta multiplatformita je dana uz tou opengl, ta existuje pro vsechno. Proto je vyvoj cele CAD aplikace pod webgl myslim volovina. (delat se s tim javascriptem , to musi byt asi opruz )

[Dreit]

Jak tu někdo zmínil, bylo by fajn, kdyby šel měnit backend. Nějaká volitelná mezivrstva, která konvertuje příkazy z frontendu do několika konkrétních backendů.

Mimochodem jak někdo navrhoval BRL-CAD, co tak OpenSCAD? Rozhodně možnost zvolit si backend by nemusela být na škodu, GNU/Linux je přece o svobodě výběru...pokud je z čeho vybírat

[xxxxxxxxxxx]

To co jsem viděl tak openSCAD fakt nic neumí. BRL je dalek odál. U BRL je problém ovládání jinak to co řikal Pavel tak vevnitř je to našláplý.

[Dreit]

OpenSCAD bylo první CAD udělátko, co mě napadlo, určitě to nebude to nejlepší, s čím pracovat

[pawleeq]

Trochu mi uniká, proč to dělat. Pokud máme aplikaci složenou z klikadla, mezivrstvy a backendu (já radši budu říkat jádra), tak jádro je asi to poslední, co uživatele* zajímá. Vzhledem k rozdílnosti momentálně představitelnejch jader by bylo navíc potřeba dělat i celou mezivrstvu pro každý jádro zvlášť.

*: Zde nemyslím BFU zvedavého na CAD, ale profíka, kterej je zvyklej v tom softu dělat denně několik hodin a změny a volby nemající vliv na výsledek, nebo způsob práce ho dost iritujou.

[Josef Kufner]

Ono ty mezivrstvy asi budou žádoucí dvě, takže budeš mít klikadlo, skriptovací engine, obal jádra a jádro (v tomto pořádí od shora dolů). Při výměně jádra pak musíš vyměnit i jeho obal, neboť to je spojení mezi jádrem a zbytkem aplikace. Tenhle obal ale bude celkem tenký a nebude neobsahovat nic z GUI (od toho jen předá jádru OpenGL kontext).

[Dreit]

Obal může být víceméně jen sed

[Dreit]

Neznám "jádra", ale nevěřím tomu, že všechny běží stejně efektivně, že se nezmění API,...určitě je lepší mít možnost rychle přemigrovat jinam pro případ, že by se něco pohnojilo. A samožřejmě že mezivrstva bude muset být v několika verzích pro víc backendů, ale v případě změny backendu je to jednodušší, než kompletní přepisování frontendu.

 

Napadá mě příklad dvou jader - první umí počítat na CPU i GPU, druhé jen na CPU, ale o dost efektivněji. A pokud moje grafika neumí OpenCL, mám se potom opravdu trápit s pomalejším jádrem, když existuje efektivnější verze?

Případně další příklad - první jádro umí multithreading, ale výkonově se vyrovná druhému až od určitého počtu jader. A teď babo raď které zvolit Buď znevýhodníme majitele více jader, nebo majitele s méně, než X jádry.

[jkb]

pro nas vsechny, kteri bychom se radi zapojili by mozna bylo vhodne nejak objasnit ty souvislosti ohledne CAD. Je zde v diskuzi rec o CAD kernelu a openGL, Qt a pod. Myslim, ze nejsem sam., kdo se v tom neorientuje.

Ukazal bych to na prikladu te OpenCASCADE. Ve vseobecnem popisu je tam na strance s tim Technical overview obrazek, ktery by ty souvislosti mel vysvetlovat. Nejasne jsou mi zde zejmena bloky s nazvy GUI (..Qt), OCAF (application framework) a Visualization. Je k nim i popis, ale presto:

- jak Qt , OCAF nebo Visualization pouzivaji (mohou vyuzivat) OpenGL. Pouzije se to z Qt a nebo jine OpenGL?

- kdo vytvori to hlavni okno s 3D nahledem a interakci. (Qt nebo jiny dil opencascade)?

- jak je udelana interakce - drive myslim OpenGL interakci nemela, musel se vzit napr GLUT. Je to dnes jeste tak?

Dalsi cast je oblast tvorby vykresu. bez toho to vubec nejde (podle statistiky jen 6% vsech uzivatelu CAD pracuji vyhradne jen s 3D, zatimco 77% pouzivaji 2D + 3D) , proto ma take FreeCAD akceptancni problemy, protoze jenom s 3D modelem vpodstate nikdo nic neporidi. Nikde jsem ale nenasel popis toho principu, jak vytvaret z 3d-modelu 2D nahledy. Na to musi byt urcite take nejaka finta.

Pro me, kdyz bych neco delal je proste dulezite se v problematice trochu orientovat. Doufam, ze se najde nekdo, kdo ma takovy prehled a mohl by to popsat. Pak by se dalo urcite snaze zjistit, jaky je rozdil mezi tim BRL-CAD a OpenCascade a na cem stavet.

[xxxxxxxxxxx]

Ty jo pokusím se popsat co vím a předem říkám že nevidím do programování.

Jádro CAD systému je dle mého soudu něco čemu ty pošleš 3D geometrii a to jádro ji dokáže přičíst a nebo odečíst a vrátí ti výslednou geometrii v číselný podobě. Pak by se dalo asi využíti na další věci jako ve výkresech poslat mu dotaz na geometrii a on by ti vrátil z potřebný výsledek. takže jádro je čistě počítací záležitost, nemá nic společného z grafikou. Jádro muže počítat třebas objem, přejmenovávat soubory atd...

Co se týká OpenGL/QT tak to je jenom zobrazovací část.

Co se týká výkresové dokumentace tak to si představuji následovně. Máš 3D geometrii objekt part, assembly. Ty pošleš jádru příkaz aby vzal nejkrajnější bod ze strany kterou chceš zobrazit na výkresu a jádro spočítá kde jsou z té strany viditelné a neviditelné hrany a pošle ti 2D geometrii. Atd...

[pawleeq]

Taky přispěju trochou do guláše.

CAD kernel (jádro) je novum této diskuse. V zásadě je to program, který dovede vytvářet tělesa, umisťovat je v prostoru a provádět s nimi logické operace. To je nezbytné minimum. Může mít i další funkce, třeba raytracing, import export dat z jiných formátů atd.

Qt je knihovna sloužící k vytváření grafického rozhraní. Organizuje okýnka, čudlíky a dialogy. Tady v debatě na to jsou větší fořti :)

Interaktivní okno zobrazující tělesa a umožňující jejich editaci je věcí OpenGL, nebo něčeho podobného, třeba knihovny OGRE. Komunikace této knihovny s jádrem je základním stavebním kamenem celého projektu.

Výkresy a co k nim potřebujeme: vektorový grafický formát (nejspíš SVG) a vlastní metody editace. Klíčový je sběr dat pro výkres z rosáhlejší množiny dat o tělesech. Žádoucí je obousměrná komunikace, tedy když změním kótu ve výkresu, změna se projeví i na tělese. Pokud by se udělala nějaká interní výměna na bázi XML, tak to asi není nic neřešitelného.

Provnání BRL-CADu a OpenCascade není špatný nápad. Hlavní rozdíl z hlediska uživatele je v tom, že BRL-CAD se dá pro modelování použít už teď, je to de-facto samostatná aplikace, se kterou vymodelujete vyrenderujete cokoliv si jen zamanete. OpenCascade je podklad por vytváření takových aplikací.

[Josef Kufner]

Jen malé doplnění: Na OpenGL se hodí v případě Qt aplikace použít QtOpenGL, což je v podstatě obyčejný Qt widget, který zapouzdřuje OpenGL kontext a kreslí se tam z připravených metod QGLWidgetu běžnými OpenGL funkcemi. Tedy pokud máš kód který kreslí v OpenGL bez Qt, mělo by ho stačit obalit do QGLWidgetu a máš hotovo.

[pawleeq]

Užitečná informace; nejsa programátor, kód nemám. Ale co není, může být :)

[faha]

Jste blazinci, ale kdo si hraje nezlobi.

Takze jak to profinancujem? Davam do placu prvnich 500,- , podminkou je website (redmine/trac...) s roadmapou projektu.

Dale doporucuji precist http://knihy.nic.cz , Tvorba opensource software, Karel Fogel.

[pawleeq]

Financování:

• Jednotně
• Přes Crowdfunding

Díky za ochotu pustit chlup.

A díky za knižní typ. :)

[xxxxxxxxxxx]

můj problem spočívá v tom ze už tedka financuji cad projekty po gpl. takze je potrbuji dokoncit, což stojí nemalé penize. ale řekněme pokud se mi bude dařit tak 5 litru měsíčně. Klidne i mnohem víc ale jak říkám záleží jak se bude dařit.

[JS]

Ahoj, jenom otazka (v CADech se vubec nevyznam):

Nedalo by se to nejakym zpusobem postavit na Blenderu? Ptam se ted spis na UI nez jadro. Mozna by se z nej dala rada veci vykostit znovu pouzit. Nebo se alespon inspirovat jejich SW architekturou, kdyz uz se tu o ni bavite - maji dost zkusenosti a je to podobny problem. Taky by me zajimalo, co si myslite o uzivatelskem rozhrani Blenderu. Bylo by neco podobneho pouzitelneho i pro CAD?

[Aleš Kapica]

Jakási CAD nadstavba pro Blender existuje.

[xxxxxxxxxxx]

jo existuje a je mrtvá.

[Aleš Kapica]

page updated: 2013.02.10

Takže asi úplně mrtvá ne.

[Aleš Kapica]

Stačí se podívat sem.

[xxxxxxxxxxx]

huh tak to čumim. Asi jsem měl na mysli jiný projekt. Nicméně garantuji ti to že v tomhle dělat nikdo z konstruktérů nebude. Navíc vývojář je architekt....

[Aleš Kapica]

Už to tady několikrát padlo. Jádro je jedna věc, UI druhá. Těžko můžeš očekávat, že dotyčný navrhne UI použitelné pro strojaře. Osobně bych si na to rovněž netroufl, i když svého času jsem pracoval s CAD prostředím poměrně intenzivně. Ale patnáct let je v oblasti IT neskutečný skok.

[Aleš Kapica]

Možná by bylo prospěšnější začít spolupracovat, než znova vymýšlet kolo. Jak sám autor píše - je to zatím víceméně one-man show. A vcelku se tomu nedivím, protože jedna věc je o tom plácat a druhá - něco konkrétního splácat. Na to každý nemá - znalosti, zkušenosti, čas. Každý nechť si vybere dle vlastního uvážení. Peníze jsou v tomto ohledu podle mě až na posledním místě.

[xxxxxxxxxxx]

hmm tak se podívej na reakci dole a máš odpověď. Ps. Samozřejmě není dobré vymejšlet kolo kdžy už existuje BRL CAD... Sory ale Blender není stavěnej na CAD v žádném případě... Aby jsi porozuměl příměru přestavovat domácí mixér na bagr je totální nesmysl...

[Franta]

License:
CADtools is freeware / registerware.
CADtools can be licensed only for individuals (natural persons).
Your license is not transferable. Your copy of CADtools is personalized and password protected - you are obligated to keep it private.
You can use it for all your private and commercial projects.

[pawleeq]

S Blenderem jsem dělal před několika lety a dostlao mě to "gamerské" UI. Levačka na klávesnici přepíná funkce, pravačka na myši loví prostoru nebo menu. To fungovalo skvěle a určitě bych se toho držel.

Jinak problém blenderu je jiný pojetí modelování, tam se totiž dělá se síťovym modelem (mesh), kdežto pro CAD jsou potřeba tělesa (solid).

[JS]

Aha, dik za odpoved. Uznavam, ze ten jiny zpusob modelovani je asi dost zasadni problem, presto si myslim, ze rada jinych veci nebo alespon zkusenosti by se mozna prevzit dala.

Jinak to s tim UI, ptal jsem se prave proto, ze to tu lide kritizovali na jinych CADech, jak maji spatne UI, tak me zajimalo, jestli je Blender-like UI vhodne nebo ne a proc. I kdyz jsem si s Blenderem hral jen chvilicku, "gamerske UI" je vystizne pojmenovani.

[mirec]

Blender je v podstate hlavne o stenových modeloch (mesh). CADy zase potrebujú skôr konštruktívny geometriu tj. kombinácia základných tvarov a ich boolovksých operácií. Spôsob modelovania je v oboch prípadoch diametrálne odlišný.

[David Jaša]

teda umístění zemního tělesa do terénu bych modeloval spíš těmi povrchy než tělesy (a říkám to tady už podruhé).

[xkucf03]

To máš ale malý kousíček architektonického CADu (vymodelovat krajinu kolem stavby), ale i tam jsou hlavně ta tělesa – zdi, stropy… všechno je to hmota (a ještě z různých materiálů, což se pak počítá), ne jen nějaké 0 mm tlusté textury umístěné do prostoru jako ve hrách (to se dá použít leda pro výslednou vizualizaci).

[pawleeq]

Na terény je v BRL-CADu speciální těleso jménem DSP, displacement map. Vypadá nějak takhle a můžete ho vyrobit z rastrového digitálního výškového modelu. Stačí? :) Samotřejmě s ho můžete kombinovat s jinými tělesy.

[David Jaša]

Jestli se ten rastrový model dá vygenerovat z bodového pole (a případných hran), tak ano, stačí. :)

[pawleeq]

Rastrový model se musí udělat venku, já na to používám GRASS.

[qwubla]

popravdě podobného výsledku se dá dosáhnout v Blenderu a docela jednoduše. Na druhou stranu je jasné, že Blender není vhodný systém pro stavbu celé CAD aplikace, ne že by to ale nešlo. Ten BRL-CAD na to bude jistě lepší, ale jak jsem již psal na začátku tématu, myslím, že by více stálo za to spíše vylepšit a pracovat na FreeCADu, která již se solidně rozšiřuje a jeho použitelnost na dva poslední roky dramaticky vzrostla.

[jkb]

že by více stálo za to spíše vylepšit a pracovat na FreeCADu

ja si myslim, ze je treba ty veci pojmenovat jak jsou. A ta skutecnost je takova, jako u rady ostatnich open source projektu. Staci si precist na strankach FreeCADu ty poznamky pro potencionalni zajemce o vyvoj. Co se zada je dokumentace, cizojazycna dokumentace a hlaseni chyb. Co se programovani tyce, tak tam (trochu provokativne prelozeno) stoji:

"Jsme mala skupina vyvojaru, kteri na FreeCADu pracujeme. Nemame na vsechno cas a proto take nevedeme nejaky prehled uloh nebo co je treba delat. Kdyz se vyznas v programovani, tak si projdi vsechny potrebne podklady - protoze k programovani je potreba znat to tochu do detailu, jak to uvnitr funguje. A pak si najdi sam neco co te zajima, co chces delat. Hlavne zacni s tim, abys umel ten system prelozit"

Jinak na ruznych forech je mozno se docist, jak lide zapasi uz s tim prekladem.

Ja mohu za sebe rici, ze v nejakem takovem projektu bych pracovat nemohl. Povazuji za stezejni, ze je prace rozdelena, ti kteri ji delaji vedi co delaji a proc to delaji. Ani mi vlastne neprekvapuje, ze ten projekt uz trva 11 let.

[xxxxxxxxxxx]

Právě, věci se maj dělat plátek po plátku...

[Josef Kufner]

Ono to chce, aby někdo hlídal, jakým směrem se projekt ubírá a co je potřeba udělat. Dokázal identifikovat a specifikovat jednotlivé úkoly. Pak na stránkách projektu byly tyto úkoly přehledně vystaveny jako součást roadmap, takže každý hned vidí, jak na tom projekt je, proč to či ono ještě není (jednoduché závislosti mezi úkoly) a hlavně, kde může pomoct.

Druhou částí je pak motivace a nabuzení vývojářů. Peněz z toho moc nebude, určitě ne v začátku, takže je nutné se porozhlédnout jinde. Na Stackoverflow vcelku efektivně funguje model se získáváním reputace (byť jinak ta celá rodina webů má množství zásadních nedostatků). V podstatě by to mohlo vypadat tak, že by na každý úkol byla vypsána odměna v podobě reputace a úspěšný řešitel by ji za splnění úkolu dostal. Aby reputace nebyla jen bezvýznamné číslo, musí být přispěvatel nějak odměněn, například vyššími oprávněními, snažším schválením commitu, umístěním na žebříčku nejlepších, VIP pozvánka na sraz vývojářů a podobně. Docela to i funguje v různých hrách, kde hráč získává vcelku bezvýznamné achievementy, kterými se pak může pochlubit ostatním.

Zásadní však je, aby bariéra nutná k poslání prvního patche byla co nejmenší. U mnoha projektů jen jeho první zkompilování znamená hodiny zkoumání, co je vlastně potřeba udělat a co mi chybí. Cokoliv složitějšího než git clone && make && ./run je nepřípustné (ok, beru ještě nainstalování pár balíčků s knihovnama).

[pawleeq]

Souhlas.

Ještě bych k motivaci vývojářů přidal prachy a sháněl do začátku u potenciálních budoucích uživatelů. Asi bude spousta kanceláří, který se rádi zbavěj pravidelnýho výpalnýho pro všechny ty autodesky a ptc atd. A financování na pricnipu funkce za úplatu: chci aby to umělo tohle a dám na to tolik a tolik, buď to zalepím sám, nebo zavolám fantovi, ten by tu funkci taky využil...

[Josef Kufner]

Peníze určitě, ale z pohledu dlouhodobého řízení vývoje bych je řešil až jako sekundární záležitost i přesto, že jsou důležitější. Když si vývojář bude vybírat nějaký velký úkol, půjde po penězích vázaných na konkrétní požadavek (bug #123, odměna X rep + Y Kč).

Pokud ale nebude mít náladu/možnosti se uvrtat do většího díla (např. má jen volný víkend před začátkem semestru), je potřeba ho podporovat v lovení malých bugů a celkovém dolaďování. Tady přijde vhod hodnocení nezaložené na penězích a pokud bude prostor v rozpočtu, lze snadno přidat peněžní odměny podle reputace získané za poslední měsíc, nebo soutěž o něco unikátního. Díky oddělení jednotek ve výpočtech bude snažší nastavit pravidla hry.

[pawleeq]

Beru. Jste ochoten se zapojit?

[Josef Kufner]

Jsem.

[pawleeq]

Tak se do toho pustíme :)

[rADOn]

A proc misto vymysleni noveho nevyuzijete perfektne fungujici linuxovy model? To jest, vybrat si projekt a zamestnat nekoho aby ho tlacil do funkci ktery chcete? Stejne tu mluvite o dlouhodobym projektu… Bountyhunting imo povede ke kodu "po me potopa", to se da pouzit na jednorazovy nastroje a ne na projekt s dlouhodbou perspektivou.

[Josef Kufner]

Samozřejmě se nesmí začlenit kdejaký kus hnoje, co někdo pošle. Pomocí reputace lze snadno omezit, kdo může code review udělat, a jak velkou bude mít jeho hlas váhu.

Nakonec je stejně potřeba souhlas toho, kdo má právo to začlenit. Ale protože code review může udělat i vývojář s nižší reputací, tak se tak dá odfiltrovat hnůj dřív, než se dostane k začleňujícímu. A aby to review někdo chtěl dělat, tak za to dostane trochu reputace.

[pavlix]

Zásadní však je, aby bariéra nutná k poslání prvního patche byla co nejmenší. U mnoha projektů jen jeho první zkompilování znamená hodiny zkoumání, co je vlastně potřeba udělat a co mi chybí. Cokoliv složitějšího než git clone && make && ./run je nepřípustné (ok, beru ještě nainstalování pár balíčků s knihovnama).

Proto jsem v NetworkManager dělal to harakiri s odstraněním detekce většiny distribucí. Zbyly jen čtyři distribuce. U třech se jedná pouze o výběr, které pluginy budou zakompilované by default a jedinou motivací je, aby packageři nemuseli měnit stávající definiční soubory. Jedinou rodinou distribucí se specifickým kódem tak zůstává SUSE a to asi holt nějak přežijem.

Všem projektům doporučuju vyvarovat se takovýchto věcí.

ok, beru ještě nainstalování pár balíčků s knihovnama

Jo, to je trochu problém. S autotools je nejjednodušší configure natvrdo zaříznout a nahlásit chybu. Ale pro nováčky je to neskutečná cypovina, protože se tak dozví pouze o prvním chybějícím balíku. Ideální by bylo napsat configure.ac tak, že nic nezařízne natvrdo, ale místo toho na konci procesu vypíše všechno, co člověku chybí. Ale v tom už autotools moc nepomáhají.

Na druhou stranu za autotools neznám žádnou smysluplnou náhradu. Autotools nastavily docela standardní chování ./configure, popřípadě ./autogen.sh a různé způsoby následného 'make'. Ani slavný Cmake mě nepřěvědčil, že je dostatečně dobrý, aby měla změna smysl, spíš naopak.

Cokoliv složitějšího než git clone && make && ./run je nepřípustné

A to by mě docela zajímalo. Věčně řeším to, že si program při spuštění nalinkuje knihovny ze systémových adresářů místo těch ze stromu. Výsledkem je naprosto neočekávané chování.

[JZD]

Tomuhle CADu chybí ještě jedna věc. Neumí

KOŠIŠKÝÝÝ

.

[pawleeq]

Pokud přispějete šestimístnou částkou, osobne si koupím důtky a donutím nějakého programátora vyrobit genrátor koťat. Aspoň bude materiál na deformační analýzy.

[pavlix]

Co když chtěl jenom košíčky?

[Dreit]

Nebo Košice