Vlákno názorů k článku Narovnání perspektivy v Gimpu od Jouda - Ach jo, pro clanek o grafice nepise nekdo,...

0) napisu si nejaky soft, ktery mi chybi (treba animacni) tak aby delal v ty oblasti presne to co chci a potrebuju aby delal, o animaci toho moc nevim tak to pisu tak nejak jak si myslim, ze by to melo byt

1) mam radost, ze se lidi o moji praci zajimaji a vychazim vetsine vstric aspon se naucim neco o ty vecny oblasti (tady animaci), mozna jim tam udelam i nejaky to UI i kdyz teda sam ho moc nepouzivam - mozna ze to jadro casem i trochu prepisu protoze ted kdyz o animaci uz neco vim, vidim, ze puvodni navrh nebyl uplne OK - to delam dokud me to bavi/dokud studuju/dokud me nekdo zivi/dokud na to mam prachy, chut a cas (pak nastava 2))

2) o animaci se uz nijak hloubeji nezajimam, novy verze vydavam tak jednou za rok, dva, a spis to jsou bugfixy, vetsinu requestu na featury zdvorile odmitam beru jenom fakt dobry napady, ktery jsou ale vetsinou moje to vsechno do doby kdy ten svuj soft i sam pouzivam (pak nastava 3))

3) uz v tom ani neanimuju (nebo na to mam nejaky jiny soft), projekt uz nijak neudrzuju, visi na webu i se zdrojakama tak at si to udelaj sami nebo za to treba nekomu zaplati, ja uz to nedelam, ted si hraju zase s necim uplne jinym (nastava 0))

kdekoliv mezi tim se muze objevit nekdo, kdo to prevezme (treba do sve faze 1 az 2) a mozna na tom postavi i neco vic (nebo to dokonce nekdo i koupi)

gimp bych videl ted tak ve fazi 2 s tim, ze uz na nem samozrejme dela vic lidi

To skoro vypada ze zijete v bludu ze vsichni lidi jsou programatori.

Ano zas je trochu jinak popsano proc je kolikrat OSS "slaby".

Sila se navic tristi do ruznych vyvojovych vetvi a to je spatne.

Pokud by se programy psaly kompletne objektove-pluginove tyto otazky by ztartily smysl, kazdy by si poskladal soft z komponent a umistil casti UI kam a jak by potreboval. Vnitrni logika programu by se po pridani komponentu doslova dratovala ve vizualnim navrhovem prostredi (podobne jako se dnes da sestavit softsynt zvukový nástroj pomocí komponent jako generátor efekt gaing a propojování jejijech vsupních a výstupních bodů).

Namátkou malá ukázka o co vizuálně zhruba při takovém sestavování jde a že to zvládne i neprogramátor:

http://rooster.stanford.edu/~ben/bliss/shots/screen-0.1.2.png
http://2ka.org/images/firstdaybuzz.png

Pokud by by byla tato filosofie siroce podporována je sestaveni editoru cehokoliv sranda, komponenty: parser, loader, buffer, input tab, enumerator, render...

no spis ziju v bludu (nebo mozna i realite), ze vsichni _tvurci_ OSS jsou jenom programatori

ale jinak OK, kdyz bude dobry framework, pak si editor na prani nesestavi asi uplne kazdy, ale bude mit velkou sanci i kazdy trochu schopnejsi, kdo je treba schopny obstojne myslenkove pracovat s funkcemi ve spreadsheetu nebo s elementy v HTML - tj. radove vice lidi i tech, kteri se jinak na plno venuji tem svym oborum a nemaji cas/chut/schopnosti se hrabat v cecku

jenom se bojim, aby to s navrhem a tvorbou toho 'skladaciho' frameworku a klikacich editoru editoru nedopadlo jako s ruznymi GUI frameworky :)

Nechapu, nedopadlo jak a nedopadlo s cim ? konkretne ! a proc framework ? ty "pluginy" by byly normalni uz zkompilovane programy (=da se dobre vyuzit vicejadro) akorat by soucasti distribuce byl zdrojak a definice pro pouziti v tom sestavovacim gui klikaci, tento sestavovac by nasledne z projektu zkompiloval main aplikaci (ktera zase muze byt znovu bez uprav vyuzita jako "plugin").

Je to vlastne takovy koncept knihoven na steroidech s moznosti pro uzivatele-neprogramatory sestavovat si libovolne celky (proto ten sestavovac a definice pro nej), jista odbornost je stale potreba ovsem daleko mensi nez pro klasicke programovani, navic tohle usetri kvanta casu pri sestavovani aplikaci a umozni rychle ozivovani novych myslenek (takove ze se ani nebude stihat u komerc. konkurence patentovat ;-).

A ano uz by nebylo potreba rabovat cizi zdrojaky ;-)

konkretne GTK a dalsi ergonomicke skvosty

No to by tezko tahle dopadlo, kdyz by se ti nelibilo usporani/rozvrzeni aplikace stahl by sis projekt preskládal v sestavovaci a bylo by (proto ta fragmentace na bloky a jejich propojovani) kdyz by se ti nelibil vzhled prezentace jednotlivych bloku pouzil bys proste jiny render plugin, naprosto easy a otazka 5min, jak dlouho trva prekopani aplikace pro jiny okynkovac dneska ?

no prave to je dejme tomu ideal ale k tomu idealu (tj. vytvoreni takoveho "integratoru" a klikaciho "navrhatoru") vede stejna cesta (tj. "ohrozena" i podobnou menatalitou a postupy lidi) jako ke vsem ostatnim OSS aplikacim - vcetne treba GTK

Tam to ale nevadi, rekl bych ze systemovy navrh tohoto integratoru by treba typ lidi co delaji na jadre linuxu zvladli dobre. No a zbytek by se postaral o pestrou paletu komponent ("pluginu") teto system se pomerne osvedcil u rozsirenych aplikaci kdy jsou doplnovany dalsi funce jako pluginy tretimi stranami.
Kdyz by nevyhovoval plugin proste bys pouzil jiny, o co je snadnejsi nahrada pluginu (treba ten render) nez cele aplikace (gimp) !
Zde by se navic jednalo o pluginy kompatibilni krizove (mezi vsemi typy aplikaci) a pouzitelne rekurzivne tzn. siroce pouzitelne a silne.
Dal by se pak dle stupne integrace rozdelovali na "base", "genies", "comlex", comlex uz by byl treba editor textu a editor obrazku ktere bych si propojil do DTP editoru v jednom prostredi = bleskovy pritup k funkcim bez nutnosti meziukladat data (jako samostatne obrazky na disk)

Ne, nejsem programator. Jenom uvazuju jak ziskavat dobre nastroje, me se tyhle vizuelne propojovaci a konfigurovatelne vecicky vzdy moc libili a vyvoj k nim jednoznacne smeruje (existuji nove takto fungujici texturegen casti v 3D softech, softsynt casti v hudebnich programech etc), ja to akorat povysil na uroven celeho programu (coz zase nikdo kompletne na uzavrenem softu logicky nikdy neprovede - posiloval by tak i konkurenci a prisel by vlastne o moc nad svym programem a o moznost prodat nove verze), vubec nejlepsi by bylo mit takovy cely system (to by se dalo blbnout se vzhledem a chovanim a celou konstrukci systemu) to uz treba od MS nehrozi absolutne vubec, nikdy by uz neprodal novou verzi systemu :-)

Co je vlastne operacni system ? support pro pluginy = programy, akorat to neni nejak ono, neni tam ta volnost aby se to dalo menit pruzne a rychle a nema to vizualni editor, neni tam ta modularni sestavovatelnost z libovolnych hotovych modulu na uzivatelske urovni.

Ale zpet k "nastrojum", kdyz chci program co veme soubor a vybere mi radky s nejakym datem a vygeneruje podle toho obrazky s obsahem tech datumu musim ho slozite dlouho programovat, kdyz bych mel sadu sikovnych modulu, dal bych nekolikrat "add", natahal bych par car nechal prelozit a uz bych si do inputu psal kriteria pro datum a to je jenom zacatek !

On vlastne programator dela to samo akorat zbytecne slozite a pomalu, schani a studuje zdrojaky a pak z nich opisuje nebo pastuje, vymejsli logiku a pak se v tom straci protoze ma nudli a desitky souboru zdroje ... pak si to nakresli na tabuli jako bloky a udela si sipky co kam a proc... tak proc tohle neudelat na PC a rovnou z toho neziskat program (navic znovupouzitelny jako komponent).

???

To si pořát ještě nerozumíme, já mluvím o spojování hotových "pluginů" tzn. již přeložených, proč překládat neustále to samé ? proč mít tu samou funkčnost v programu tisíckrát ? zdrojáky jsou ke kontrole či přeložení pro jiný proc, ne jako základ pro sestavování a využití. Tady jde především o odstínění zbytečné a zbytečně složité činnosti, jak pro stroj tak pro lidi, proč se zabývat kódem když je to neefektivní a hlavně PRINCIPIELNĚ NEMUSÍM.

Pokud by byla řec o "genies" a dalších již integrovaných modulech z více modulů, tak je na zvolení či přilinkovat obsažené "base" (nebo base a genie v comlex) či je jen nakopírovat do adresáře k main.

Co se týče jazyka pro vytváření základních ("base") "pluginů" tak si myslím že platí to samo co pro vývoj běžných na strojový čas mírně i více i velice náročných aplikací. Tzn. interpretované jazyky jsou asi všechny vyloučeny.

Taky jde o nezávislost na produkční platformě base pluginu, musí být jedno kdo v čem vyprodukje "base plugin třetí strany" C/C++/.net/Delphi a já nevím co ještě se tak hodně používá, musí to jedno alespoň stejně jako je to jedno když se dělá "normální" program.

To si myslis ze tu napastuju plany na sestaveni tohoto systemu ? to by bylo jako z rukavu vytahnout hotovy zbrusu novy operacni system, rozhodne si to jako hurvinek valku nepredstavuju ale hledet se musi dopredu a hledat nove spusoby jak to ci ono udelat, ne duvody proc to nebo ono nejde, ja se snazim prispet jak umim, pak musi nastoupit nekdo kdo dokaze navrhnout a udelat komunikaci, nekdo kdo doda freagmenty = ruzne moduly ruzne funkce atd.

Kazdopadne v tomto systemu vidim stokrat vetsi smysl nez ve vytvareni osamocenych ostruvku kodu a osamocenych programu.

Co se tyce protokolu v tom se nevyznam ale prijde mi rozumne jedna vyuzit toho co je dostupne v systemech a toho co je dostupne pro existujici pluginove systemy, staci vzdy pro dany protokol udelat wrapper, tak se pro zacatek ziska obrovske mnoztvi funkcnosti "zadarmo" minimalne me napadaji pluginy pro PS, DX, VSTi, Buzz, ruzne skriptove orientovane tech jsou desitky.
Spousta knihoven by se dala tez pomerne snadno upravit do podoby pluginu co poskytuji specialni funknost.

MD mas nejake dalsi konstruktivni pripominky?

1.) plne modifikovalny gimp by nebyl tez na skodu, me by se to libilo urcite.

2.) ano i to by bylo mozne a jeste mnohem vic, beru to tak ze po zaobaleni by slo vkladat kazdej s kazdym i vlozene cizi kody viz 3.)

3.) a) zaprve by musel existovat vlastni flexibilni system "integratou" pak uz je mozne b)ruzne cizi protokoly, knihovny a pod zaobalit a nawrapovat pluginem k tomu urcenym, mimochodem uz se to tak docela bezne dela (to wrapovani). V tomto nevidim zadny principielni problem, pak se daji udelat ruzne transkodovaci "base" pluginy pro specialni uzivatelske prevody ruznych dat s struktur na jine, pluginy na zachytavani zprav atd. ruznym spojovanim jmenovanych a naznacenych dosahnes cokoliv, jak jsem rekl je to velice silny princip.