Jak moc se "opisuje"?

[vyvojar]

Pár dní pracuju na jednom cross platform gui toolkitu, který bude sloužit jako základ pro něco dalšího.
V podstatě něco takového není úplně jednoduchá záležitost a nelze tam moc vymýšlet. Dělal jsem si nějakou dobu rešerši
a pak začal programovat defakto stylem - analýza kódu v open source existujícím gui toolkitu a následné zanesení do vlastní implementace, pokud to dávalo smysl.

Jenže...velice brzo jsem si uvědomil jednu věc, že v podstatě tam není nic, co se dá vypustit nebo udělat nějak jinak.
Víceménně to skončilo tak, že inkrementálně přepisuji do jiného jazyka - tzn. implementuji nejprve podstatné části jako nastavení velikosti okna apod.. a věci jako drag and drop, clipboard atd.., nechávám na později. Změny se týkají akorát nahrazením nějakých jazykových konstruktů a či hodně ojediněle udělání něčeho jinak.

Ty frameworky jsou za ty roky práce xy lidí tak vyladěné, že to opravdu skoro nejde jinak, než to přepisovat 1:1.  Všiml jsem si, že ale některé bloky kódu i v tom fw, ze kterého čerpám nejvíce, jsou úplně totožné s bloky kódu v jiném frameworku .

Otázka - takhle nemám z toho úplně dobrý pocit, že to v podstatě přepisuju, jenže když potřebuju cross platform gui toolkit čistě implementovaný v jazyce, ve kterém zatím žádný neexistuje, tak co mi zbývá? Všechno se snažím analyzovat a opravdu jsem zatím nenarazil až na cca 2-3 připady na něco, kde bych měl pocit, že by to šlo udělat líp, navíc jsem na to sám a chci, aby se to nějak hýbalo ten progress.
Je bežné v open source komunitě, když vznikají nové projekty, že se "opisuje" z jiných projektů?

[Reklama]

[<sfaf]

1) proc bys nemohl obslehnout neco co uz existuje, je zbytecne vynalezat znova kolo.
2) pouzij konstrukce sveho jazyka a co neni exfektivni zkus ve svem projektu zlepsit.
3) dej to ven a nekdo ti treba s projektem pomuze.

[gll]

místo opisování rovnou použij něco existujícího.

[Míla Rozner]

místo opisování rovnou použij něco existujícího.

+1 I když v tom jazyce zatím žádný GUI toolkit není, tak to není důvod do toho zabrušovat a psát to úplně znova. Třeba v takovém Pythonu nebo Perlu taky žádné tookity napsané nejsou, ale existují tam bindingy na stávající C/C++ toolkity jako Qt nebo GTK či další.

Nedělej NIH, ať z toho pak nemusíš vybrušovat.

[yesdude]

Vím, že něco takového jsem kdysi dávno viděl řešit jinde.

Ve finále je to tak, že nesmíš použít jen copy-paste, to by podléhohalo autorskému zákonu, ale pokud přepíšeš danou knihovnu sám a jinak pojmenuješ funkce, proměné atd, tak už to není považováno za krádež duševního vlastnictví.

Proto si defakto větší firmy takhle chrání source code, on ten kod sam o sobě má hodnotu nula, to v čem jsou prachy je business logika a implementace. A ta když se dostane ven, tak ji může použít každý ve svém vlastním projektu a beztrestně

[Reklama]

[borekz]

Ve finále je to tak, že nesmíš použít jen copy-paste, to by podléhohalo autorskému zákonu, ale pokud přepíšeš danou knihovnu sám a jinak pojmenuješ funkce, proměné atd, tak už to není považováno za krádež duševního vlastnictví.

A co číselné konstanty a algoritmy ?
A platí stejná logika i pro normy ? Pokud bych v programu implementoval nějaký výpočet podle normy, dopouštím se tím "rozšiřování části normy" ?

[mhi_]

Dle meho nazoru pokud jste dosel k tomu, ze jen kopirujete cizi kod, tak nevymyslite nic vlastniho a nedavate do toho zadnou invenci. Casto jsem ve stavu, kdy treba pouziju cizi fragment kodu a je treba jednodussi zkopirovat i logiku okolo (napr. parametry, organizaci souradnic, apod.)., ale kdyz neokopiruju cely zbytek tak to vetsinou vede do neskutecneho chaosu.

GUI veci rozhodne nejsou dokonale a je co na nich vymyslet. Staci se podivat treba jen na systemy souradnic a transformaci, viz historie Win16 API vs Win32 API (NT) vs OS/2 vs ... kazdy to dela trosku jinak a architekti jednotlivych API se casto inspirovali u konkurence, jenze taky videli nedostatky. K OS2 vs WIN16 existuje krasny clanek od jednoho z autoru WIN16 API.

[vyvojar]

Jo díval jsem se na to, že by byl zřejmě problém s tím, že to bude "Derived work".

Jenže co chcete vymýšlet na implementaci cross platform window tookitu? Třeba pro X11 je protokol s X Serverem jasně danej a komunikace s WM to samé, ICCCM a EWMH. Co na tom mám vymýšlet? Četl jsem, že se často dělá, že se najmou lidi, kteří prostudují zdrojáky a pak to napíšou "na zelený louce", jenže já to dělám sám a fakt se mi nechce vynalézat kolo a po x týdnech skončit s něčím, co bude zabugovaný a nebude to mít podporu pro nějaké podstatné věci, protože jsem si to neuvědomil dostatečně brzo.

Binding bych mohl teoreticky udělat do GTK, dokonce v tomhle roce už má i SceneGraph, podobně jako Qtčko má Quick. Jenže já to bych to chtěl mít pěkně naimplementované všechno ve Swiftu

[Franta <xkucf03/>]

Jenže já to bych to chtěl mít pěkně naimplementované všechno ve Swiftu

Jak jste velká firma? Kdo se o to bude starat, udržovat to? Uvolníš to jako svobodný software?

[vyvojar]

Jenže já to bych to chtěl mít pěkně naimplementované všechno ve Swiftu

Jak jste velká firma? Kdo se o to bude starat, udržovat to? Uvolníš to jako svobodný software?

Jsem jen já, začal jsem to dělat ve volném čase cca před 3 týdny a teď jsem měl dovolenou, tak se to malinko hnulo. Prozatím jsem to pozastavil, dokud se nerozhodnu, jak to udělat s tím přepisováním, jestli se na to vykašlat a implementovat to podle sebe, udělat nějaký základ a postupně to nabalovat tak, jak to bude potřeba nebo co vlastně.

Jako open source bych to chtěl aby to bylo, ale bez nějakých restrikcí, takže když bych defakto opsal část Qtčka, tak by to byl zřejmě problém a musel bych se na to odkazovat a pro komerční účely by se to použít nedalo. Chtěl bych pak naimplementovat i Quick, ale žádný JavaScript. Prostě výstupem by v ideálním případě měl být moderní a snadno použitelný GUI tookit, kde by se vykreslovalo na grafice.
Qtčko je top framework, akorát to C++ by mohlo být nahrazeno a Swift je ideální kandidát. Binding se mi nechce dělat, protože by tam byla závislost na těch Qt knihovnách.

[mhi_]

Nechci odrazovat od tohoto "amaterskeho" pristupu delani novych veci, nicmene berte v potaz, ze lide, kteri spoustu API/frameworku/knihoven navrhovali (a to zejmena komercne) uz za sebou casto meli mnoho zkusenosti a vedeli kde minule narazili (casto delali v jednom oboru - napr GUI - cely zivot), takze s kazdou novou veci zakomponovavali vsechny sve minule zkusenosti.

Ono se to moc nezda, ale dabel je prave v naprostych detailech. Treba v tom, jak probihaji ruzne transofrmace pri vykreslovani grafiky. Udelam-li to blbe, zavre mi to vratka v imlementaci ruznych zajimavych fci.

Nedelam do grafiky, ale bavil jsem se docela dlouho treba s jednim clovekem co nekolikrat za zivot delal JustInTimeCompiler (treba ten Javovsky) a ve spouste jeho mailu byly fraze typu "tehdy jsem to nevedel" ... "dneska bych vyzkousel" ... "tehdy jsme si mysleli" ... "tehdy jsem udelal chybu, ze", apod.

[xxx]

Několik GUI knihoven už jsem si napsal a je to přesně tak, jak píše kolega nahoře. Pokaždé to prostě uděláš "znova a líp", než se dopracuješ k něčemu použitelnému a škálovatelnému. UI se na první pohled může zdát jako jednoduchá záležitost, ale když se začneš ztrácet ve špatně navržených závislostech, nepřehledném toku dat, nepředvídatelných kaskádách událostí a dalších věcech, které ti na začátku nepřišly na mysl, tak to radši smažeš a přepíšeš, než ti z toho začne hrabat. Na druhou stranu někde se začít musí :-) Jde o to, jestli máš zrovna čas a chuť si celým tím martýriem procházet. Pokud ne, tak to prostě překlop 1:1, hlavně nic moc nevypouštěj ani nepřidávej - ten člověk, co to psal, zřejmě věděl, proč tam ty věci dával. Pokud se do toho pustíš od nuly, tak pamatuj, že méně je více a čím víc explicitní kód, tím líp - vždycky radši napiš o několik řádek navíc, než by se něco mělo dít "samo" - magie je dobrá do cirkusu, v kódu to je cesta do pekla. Přeji hodně zdaru a pevné nervy.

[D.A. Tiger]

Kdyby jen opisuje.

Nebyl jsem spokojeny s defaultnim WM v LXDE. Svoje projekty nejcasteji delam v C++ pod Foxlib. No a sveho casu existoval projekt FXWM. Tak jsem si stahl zdrojaky a hezky jsem si to tu pro ten ucel forknul. Autor se na to casem vykvakl, takze v tuhle chvili jsem asi jediny kdo cas od casu v tom neco posonta. Ale moc casu tomu uz ted nevenuji. Jednak ted pouzivam prevazne Awesome WM a jednak to vypada s Xorg dost nahnute, takze to nema momentalne zadnou prioritu. Ale faktem je ze, jsem se na tom hodne, ale opravdu hodne o C++ naucil. Neni tedy ceho litovat :-)

[Franta <xkucf03/>]

Jenže já to bych to chtěl mít pěkně naimplementované všechno ve Swiftu

Jak jste velká firma? Kdo se o to bude starat, udržovat to? Uvolníš to jako svobodný software?

Jsem jen já, začal jsem to dělat ve volném čase cca před 3 týdny a teď jsem měl dovolenou, tak se to malinko hnulo. Prozatím jsem to pozastavil, dokud se nerozhodnu, jak to udělat s tím přepisováním, jestli se na to vykašlat a implementovat to podle sebe, udělat nějaký základ a postupně to nabalovat tak, jak to bude potřeba nebo co vlastně.

Jako open source bych to chtěl aby to bylo, ale bez nějakých restrikcí, takže když bych defakto opsal část Qtčka, tak by to byl zřejmě problém a musel bych se na to odkazovat a pro komerční účely by se to použít nedalo. Chtěl bych pak naimplementovat i Quick, ale žádný JavaScript. Prostě výstupem by v ideálním případě měl být moderní a snadno použitelný GUI tookit, kde by se vykreslovalo na grafice.
Qtčko je top framework, akorát to C++ by mohlo být nahrazeno a Swift je ideální kandidát. Binding se mi nechce dělat, protože by tam byla závislost na těch Qt knihovnách.

Hoď sem prosím odkaz, ať to můžu sledovat, tohle mne zajímá :-)

Co se týče licence, Qt je pod LGPL, která je hodně benevolentní. Dovoluje i použití v proprietárním softwaru, pokud ti jde o tohle.

Chápu i ten přístup, že si to chceš napsat sám, ale zvaž, jestli je to schůdná a dlouhodobě udržitelná cesta. Na jednu stranu by bylo fajn mít nějaký jednoduchý moderní GUI toolkit, ale:

• Jak ti psali ostatní, je to dost složité, spousta lidí si na tom vylámalo zuby a dobrý software se jim povedlo napsat třeba až napodruhé napotřetí. I kdyby ti to šlo hladce a trefil bys to napoprvé, je to obrovský objem práce.
• Další toolkit znamená, že ty aplikace budou vypadat zase trochu jinak a prostředí bude zase o něco méně jednotné – už takhle máme Qt a GTK (+další, ale ty se moc nepoužívají). A stálo celkem dost úsilí, aby ty aplikace šly nastylovat tak, že prostředí vypadá celkem jednotně (i když to stále není dokonalé).
• Je otázka, kdo se o to bude starat a rozvíjet to. Tebe to může přestat bavit nebo na to nebudeš mít tolik času, kolik bys chtěl. Do vývoje GTK a Qt se vždycky zapojí dost lidí, protože je na tom založeno spousta programů a to tam ty vývojáře přitáhne. Ale kolik programů bude používat tvůj toolkit? Proč by na tom měl chtít někdo dělat? Tohle je trochu začarovaný kruh – pokud to bude vyvíjet a udržovat malý tým/jednotlivec, tak to nebudí moc důvěru, aby na tom někdo začal stavět svoji aplikaci – a pokud je málo aplikací, nebude to zase tolik přitahovat nové vývojáře.

Rozhodně tě ale nechci odrazovat. Pokud se ti to povede napsat čistě a nebude to žádný bloatware, tak si dovedu představit, že bych to pro nějaký produkt i použil, protože tam bude možnost / záložní varianta ten vývoj převzít sám, kdyby se na to původní autor vykašlal. Pokud to ale bude něco velkého, tak bych se o to sám starat nechtěl → tzn. musí za tím stát buď někdo dostatečně silný a stabilní nebo to musí mít spousty uživatelů, abych si řekl, že přinejhorším se nějak domluvíme a na vývoj se složíme. Nicméně varianta, že by to byl rozsáhlý software spravovaný jedním člověkem nebo malou firmou a já byl jeden z mála uživatelů, je neschůdná.