Já si ale vyhraju :-)

1.8.2006 22:47 | Přečteno: 1609× | Linux

Jsem od přírody strašně hravý člověk Hraju si programováním, baví mě to. Teď si programuji takovou C++ nadstavbu nad Gtk. Ano, existuje Gtkmm, ale dle mého názoru má strašně hnusné API. Nadstavbu jsem pojmenoval jedinečným názvem Toolkit. Cílem Toolkitu je rychle a jednoduše vytvářet GUI ve stylu knihovny Qt. Toolkit následně využiji pro JXP Commander. Toolkit nevyužívá žádné dynamické knihovny (kromě Gtk a závislostí), je přímo slinkován s binárkou, a tudíž by nemělo docházet k žádným pomalostem, jako je tomu v případě Gtkmm. Zde je menší příklad:

#include <Toolkit/Toolkit.h>

class AppWindow: public Window{
protected:
	Toolkit::Button *button;
	Toolkit::Label *label;
	Toolkit::Entry *entry;
	void onButtonClick()
	{
		Toolkit::MsgBox( this, entry->getText(), L"Your name", mbOk | mbInformation );
	}
public:
	AppWindow()
	{
		Toolkit::VBox *vbox = new Toolkit::VBox(this);
		label = new Toolkit::Label(vbox, L"Some text");
		label->setText( L"Enter your name" );
		entry = new Toolkit::Entry(vbox);
		button = new Toolkit::Button(vbox, L"OK");
		CONNECT_BUTTON_CLICK( button, onButtonClick );
		showAll();
	}
	virtual ~AppWindow()
	{
		puts("Bye");
		Toolkit::App->quit( 0 );
	}
};

void ToolkitMain()
{
	AppWindow *window;
	Toolkit::App->init( L"JXP Commander" );
	StringArray args = Toolkit::App->getArgs();
	window = new AppWindow;
	Toolkit::App->run();
}

Toolkit má již deklarovánu funkci main (popř. WinMain), kde se inicializuje Gtk, vytvoří se instance třídy Toolkit::Application (App) a předá se řízení funkci ToolkitMain(). App->init nastaví jméno programu. Argumenty programu jsou v poli stringů App->getArgs(). App-> spustí hlavní smyčku programu (gtk_main()). App->quit(navratovyKod) ukončí smyčku zavoláním gtk_main_quit(), pak už jen nastane zrušení objektu App a konec programu.

Nastavení rodičovského objektu se může provést v konstruktoru nebo pomocí funkce Widget::setParent. Vše má ještě další parametry odpovídající parametrům funkcí gtk_box_pack_start, gtk_container_add a gtk_table_attach. Typ rodičovského prvku je zjištěn a zavolá se vždy správná funkce.

Ještě jsem si vzpomněl na jeden prográmek, jež jsem programoval na praxi. Parsuje binární eventlogy Windows (*.evt) a ukládá je v textovém formátu. Čtení eventlogů je to řešeno jako třída, mohla by se to někomu hodit. Program pak tuto třídu využívá a ukládá pak informace do texťáku v kódování cp1250. Ve třídě jsou ale stringy uloženy v ucs2, takže s převodem do libovolného jiného nebude problém. Délka řetězců ve výstupním texťáku je omezena, z důvodu vkládání do databáze.

       

Komentáře

[Martin]

Hraju si programováním, baví mě to.

Docela změna. Ty seš člověče jak korouhvička. Ne že by na téhle změně bylo něco špatného, ba naopak.

Na přečtení a vstřebání celého příspěvku už nemám sílu a klížej se mi oči, ale podle nadšeného tónu to bude asi opravdu super. Těším se, až si to zítra prostuduju.

[zabza]

Kdo si hraje, nezlobí

[Michal Kubeček]

Toolkit … je přímo slinkován s binárkou, a tudíž by nemělo docházet k žádným pomalostem, jako je tomu v případě Gtkmm.

Nerozumím. Můžete, prosím, tuto úvahu trochu rozvést?

[Luk]

Toto tvrzení zřejmě vychází z chybného názoru, že umístění kódu do sdílené knihovny je příčinou oné pomalosti. Tento názor je ovšem velice zhoubný, protože zabraňuje využít mnoha výhod, které sdílené knihovny nabízejí.

[funny]

Vono i záleží, jak je ta sdílená knihovna veliká a jak moc používaná. Až ji budou používat všichni programátoři ve všech programech, bylo by lepší ji udělat sdíleně. Do té doby doporučuji KISS (=jednoduchost).

[pasmen]

Mam takovy dojem, ze z JXP commanderu bude akorat velky pruser...

[Deleted [8409]]

Nechceš mi radši pomoct s něčím úplně novím čistě pod iXa?

[Luk]

Proč dělat něco úplně nového? Vždyť existuje např. FoxToolkit, na kterém se dá stavět.

[MEDss]

Proč vlastně někdo dělal linux, když už tu byl unix, když se na něm dá tak hezky stavět :))))))))

[Luk]

Licence?

(Není to úplně přesné. Linus Torvalds si nejdřív jen tak hrál, teprve později se to dalo dohromady s GNU.)

[Michal Kubeček]

Nechápu, co tím chcete říct? Buď termínem Unix rozumíte opravdu ten původní Unix od AT&T, ale ten už dávno nikdo nepoužívá. Nebo tím rozumíte celou rodinu unixových systémů, ale pak je Linux jedním z nich, stejně jako třeba AIX nebo Solaris. To jen windowsofilové rádi dělí statistiky serverů na Windows, Unix a Linux, aby to pro Windows vypadalo lépe, jinak k tomu není žádné opodstatnění…

[Deleted [8409]]

Stačí se podívat na 'GUI toolkit framework page' a zjistíme že toolkitů je opravdu hodně, já jich mám stáhlou celou řadu a některé jsem i hlouběji zkoumal, včetně Qt, fltk, MiniGui, ale i třeba Ecore/Evas.

Ale nevím o toolkitu který by splňoval moje požadavky:

• BSD styl licence
• 32 Byte unikód i ve Windows (je krásné jak je wchar_t nekompatibilní)
• Podpora themes a API pomocí kterého se dají témata kreslit, né linky a čtverečky, ale gradienty, alpha blending atd...
• Windowing system jako plugin
• C++ API, ale bez RTTI a exceptions
• Výsledek malá knihovna (max 1MB), která pojede na 150MHz procesoru

Myslím si, že tyto požadavky lze 100% splnit, ale asi to nepůjde s tím, co jsem zatím viděl. Smajlík

[Luk]

Hlavně ten poslední požadavek bude pěkný oříšek (hlavně v kombinaci s těmi hračkami jako gradienty a alpha blending)

[Deleted [8409]]

Moc nechápu proč by zrovna toto měl být oříšek. Vykreslit gradient je skoro stejně rychlé jak vyplnit obrázek jakoukoliv barvou, něco jiného je dithering nebo alpha blending, ale při použití MMX to není tak strašné... Pamatujete si na staré hry ?

Kdyby někdo měl velký zájem tak jsem napsal článek o výpočtu gradientu přes MMX. Zatím není publikováno, možná se někdy dočkáte

[Luk]

No, s MMX, to moc přenositelné nebude Ale jestli to má být jen na Intel-compatible, pak není problém.

Jinak pamatuji nejen staré hry na PC, ale i hry na Atari. Hra měla celá 20 KB, pěknou grafiku, zvuky, hudbu... Kdeže ty časy jsou

Kdyby někdo měl velký zájem tak jsem napsal článek o výpočtu gradientu přes MMX. Zatím není publikováno, možná se někdy dočkáte

A co to nabídnout Robertovi k vydání tady na abíčku? Určitě by měl zájem

[Deleted [8409]]

Já kód větvím podle procesoru, ale je možné udělat i hardcoded verzi třeba pouze pro SSE2 (Mám v plánu i pár vedlejších optimalizací nejen pro grafiku, ale i třeba pro stringy )

Atari naprostý souhlas, třeba Bouler Dash nezapomenu

Jinak s tím článkem zatím počkám, asi ho umístím někam na osobní web, protože jich mám v plánu víc a hodně z nich bude o 2d grafice a o optimalicačních problémech které jsem osobně řešil. Jenže problém je bohužel čas

[Martin]

Tady na Ábíčku si ho/je ale podle mě přečte nepoměrně více lidí.

[Deleted [8409]]

Já nevím kolik čtenářů ABC zajímá jak se urychlí výpočet gradientu přes MMX včetně C a inline ASM kódu. Já jsem to napsal, protože na netu nic takového není a musel jsem to opravdu vymyslet, kdežto třeba alpha blending a jiné už někdo vymyslel dříve a není problém to dohledat, třeba v kdefx je to docela hezky napsané a je to mimochodem pod BSD licencí

Nemyslel jsem to proti čtenářům, určitě je tady hodně programátorů, ale koho zajímá tak odborná věc, tak asi použije první vyhledávač

[Filip Jirsák]

Že by mělo Abíčko záplavu kvalitních článků a muselo je odmítat si nemyslím. A pokud bude článek kvalitní, čtenáře si zde najde.

[Martin]

Nemyslel jsem to proti čtenářům, určitě je tady hodně programátorů, ale koho zajímá tak odborná věc, tak asi použije první vyhledávač

Tady si to ale určitě přečtou i lidé, kteří takovou věc v té chvíli zrovna nepotřebují (a tudíž by ten vyhledávač nepoužili), ale určitě k tomu mají co podnětného říci.

[Marek Bernát]

20kB, pekná grafika, zvuky, hudba? To potom tá hudba musela byť generovaná háhodne, zvuky boli beepy a grafika už neviem ako. O kvalitnom komprimovaní obrázkov v tom čase zrejme nemohlo byť ani chýru, takže netuším, ako by niekto nacpal bitmapy potrebné pre hru, detailné postavy a predmety, pozadia (navyše hovoríte, že pekné) do 20kB. A to som ešte nespomenul kód. To tá hra mala akože 10 inštrukcií?

Vychádza mi z toho, že a) robíte si srandu b) nechutne zveličujete c) vymýšľate si d) máte sklerózu e) to teplo vám lezie na mozog.

[Josef Kufner]

Hudba se vejde na pár bajtů, zvuky totéž. Podívej se jak velké jsou mod, it, mid,...

Rozlišení bylo tehdy mrňavé a tím pádem i obrázky byly mrňavé. Při použití mála barev a indexované palety se lze vejít opravdu do mála i bez komprese.

10 instrukcí je celkem dost. Minimálně na počítání skóre to stačí

Vlastně s těma 20KB celkem přeháněl...

$ du -h vlak.com 
16K     vlak.com

[Marek Bernát]

Hudba se vejde na pár bajtů, zvuky totéž. Podívej se jak velké jsou mod, it, mid,...

Z pár mod/mid bajtov rozhodne nedostanete peknú hudbu a rozhodne jej nedostanete dosť na to, aby vás po piatich minútach nebolela hlava z jej opakovania. Pojem pekná hudba je relatívny, ale obávam sa, že ak niekto nazve pár bajtov peknou hudbou, tak ho budem musieť považovať za hluchého.

Rozlišení bylo tehdy mrňavé a tím pádem i obrázky byly mrňavé. Při použití mála barev a indexované palety se lze vejít opravdu do mála i bez komprese.

Tak s tým súhlasím, nenapadlo ma, že na tom tie hry kedysi boli až tak zle

10 instrukcí je celkem dost. Minimálně na počítání skóre to stačí

Len či ešte zostane aj nejaká inštrukcia na inicializáciu a zobrazenie toho, čo počíta.

Ale vážne, žiadna rozumná hra nemôže mať pár len inštrukcií. Ak si teda autor pod hrou nepredstavoval veci typu "Guess number"

Vlastně s těma 20KB celkem přeháněl...

$ du -h vlak.com 
16K     vlak.com

V tejto hre nebola pekná grafika, zvuky boli odporné a hudba žiadna. A opať, ja za hru považujem niečo trochu zložitejšie, takže aj kódu tam bolo málo. Ale už začínam veriť, že v rádoch desiatok kilobajotv sa dajú robiť nejaké hry

[Deleted [8409]]

A proč ne...? Stačí stáhnout emulátor a zkusit, je nutné si uvědomit, že obrázky=16 barev, instrukce byly maličké a ta hudba...? Myslím že byste se divil jakou měli 20 a více let staré hry hudbu, konkrétně na Atari byly lepší hry než na x86 když nastupovala x86 éra. Ale nechci se hádat, dnes je vše jinak, ale třeba takové hry v mobilech, XDA, ... 8 bit scénu docela vykuřujou

[Marek Bernát]

No veď hej. Ale chcel by som nejaký dôkaz, nejakú starú hru do 20kB, ktorá je naozaj pekná, má dobrú hudbu a je trochu nápaditejšia ako horeuvedený vlak, takže kód aj zaberá nejaké nezanedbateľné miesto

[Deleted [8409]]

Třeba ten BoulderDash ? Na svou dobu dobrá hra ne? Myslím že pod emulátor je to kolem 17kb

[Marek Bernát]

Od vlaku sa to príliš nelíši, ani veľkosťou, ani zjavom, a pointa nie je veľmi zložitejšia. Ale nechcem sa o tom hádať, veď je to úplne jedno

Ja presne neviem, čo si predstavujem pod pojmom hra s peknou grafikou, zvukmi, hudbou a tak, ale možno skôr nejakú adventúrku, napríklad niektorého Dizzyho; hlavne neskoršie diely mali veľmi peknú grafiku. Myslím, že žiadny diel by sa nezmestil do 20kB. Ak to niekto máte doma, tak napíšte veľkosť

[Deleted [8409]]

Možná bysme spíš měli používat "na tu dobu s dobrou grafikou" Ale s tím dizzy souhlasím

[Josef Kufner]

Zrovna mám rozepsaný program na monitorování systému. Takový přerostlý dockapp ve vlastním okně. Hotové mám zatím jen GUI. Bere si to o polovinu míň paměti než bash a při neustálém překreslování s 1us sleepem si toho procesor ani nevšimne. Tím chci říct, že ta knihovna by opravdu mohla mít o mnoho méně než 1MB, být náročností někde na úrovni Motifu (acrobat 5) či Atheny (gv) a přitom být použitelnější než GTK+ či Qt. Stačí to slušně a pořádně napsat.

[Deleted [8409]]

A já už jsem si myslel, že v tom jsem sám

Pokud máte nějaký svůj widget set nebo API pod X, můžete dát link nebo mi poslat na email, já si to rád prostuduju a třeba se i poučím (Upřímně mě zrovna zajímají jen věci pod X a akcelerovaná 2d grafika pomocí MMX a SSE2). Můj projekt je zatím pod pokličkou a jestě tak měsíc bude

[Josef Kufner]

Ta knihovna, kterou to používá vypadá takle:

/* xwindow.h */
XWINDOW * xwindow_init(void);
void xwindow_load_widgets(XWINDOW *xwin, char *filename);
void xwindow_destroy(XWINDOW *xwin);
void xwindow_process_events(XWINDOW *xwin);
void xwindow_reposition (XWINDOW *xwin, int now);
void xwindow_recalculate(XWINDOW *xwin);
void xwindow_redraw(XWINDOW *xwin, int recalculate);
#define xwindow_get_fd(xwin) {ConnectionNumber((xwin)->disp);}
#define xwindow_is_broken(xwin) ((xwin)->is_broken)

/* xdraw.h */
void xdraw_frame(XWINDOW *xwin, long x, long y, long w, long h, int is_raised);
void xdraw_frame_color(XWINDOW *xwin, long x, long y, long w, long h, int is_raised, int cl, int cs, int draw_border);
int  xdraw_select_font(XWINDOW *xwin, int fid);
void xdraw_text(XWINDOW *xwin, long x, long y, char* text, float align, int shadow);
void xdraw_bar(XWINDOW *xwin, long x, long y, long w, long h, float fill);
void xdraw_vsep(XWINDOW *xwin, long x, long y, long len);
void xdraw_hsep(XWINDOW *xwin, long x, long y, long len);

Prostě jen nakresli tohle támhle. Nic víc pro ten program nepotřebuju. A aby to trošku ladilo s desktopem, vypdadá to jako kdyby to bylo podle defaultního témata gtk2 :) Chybějící podpora jakéhokoliv vstupu je naprosto záměrná.

Předpokládám, že to dopíšu koncem prázdnin, případně v září. Teď na to nemám moc času. Chybí tam jen část, která bude sbírat data. Kreslení a načítání rozložení widgetů lze víceméně považovat za hotové.

Adresa: http://jk.myserver.cz/programy/icebuteo/

[Deleted [8409]]

No můj návrh je trošičku obsáhlejší, nejedná se jen o GUI toolkit, ale také o soubor tříd, které nejsou s GUI nijak svázané. Například výpis obsahu domácího adresáře do souboru se dá zapsat takto:

#include <wpp/core/core.h>

using namespace WPP;

WPP_MAIN()
{
	FileStream fileStream("out.txt", IO::Create | IO::Write | IO::Truncate);
	TextStream textStream(&fileStream);

	Directory d;
	if ( d.open( User::homeDirectory() ).ok() ) {
		const Directory::Entry* e;
		while ( (e = d.read()) != NULL ) {
			textStream.writeLine(e->name());
		}
	}

	textStream.end();
	return ExitSuccess;
}

Tento kód běhá na Win/Lin, výsledný soubor je v UTF8 kódování, pro současné kódování stačí před zápisem napsat:

textStream.setTextCodec(TextCodec::local());

Lomítka v cestách jsou vždy v posix tvaru '/' atd, ... Šlo mi jen o to maximálně sjednotit API dvou různých OS a až naněm něco stavět.

Jestli bude čas tak o tom napíšu blog, ale v současnosti mám dočasnou práci v .IE takže to nejde

ahoj

[Josef Kufner]

Já bych to teda nemíchal vše do jedné velké knihovny. Daleko radši bych měl malou knihovnu, která by používala standardní datové typy, nenutila mi svoje vlastní ptákoviny na to či ono a prost dělala jen to co od ní chci – zobrazovala GUI.

[Marek Bernát]

používala standardní datové typy

Hovoríme o tom istom C/C++, kde ešte stále v štandarde nie je popísaná veľkosť základných dátových typov, o unicode ani nehovoriac?

Ak ten toolkit má byť multiplatformný, tak nevidím lepšiu cestu, vy áno?

[Marek Bernát]

Malá oprava. Nevidím lepšiu cestu, ak to má byť v C/C++

[Deleted [8409]]

Jenže to je velký problém!

Jak chcete zaručit třeba správné kódování textu nějakého tlačítka...? Já nechci používat pointer na nějaký nulou ukončený řetězec a při každém jeho výpisu ho procházet a hledat null terminator abych zjistil jakou má vůbec délku, tak je to ze vším. Představme si třeba list box, ve kterém máme jen řetězce bez ikonek, každý programátor by si ňejakou strukturu nebo třídu udělal, aby zjistil třeba kolik těch položek tam vlastně je. Proč bych teda neměl použivat stejné API v celém toolkitu?

Jde mi o to, že nikoho nenutím používat můj String, ale API ho používá a ví, že má pokaždé stejné kódování, že může zjistit rychle jeho délku a používat jeho metody.

Třeba když jsme u zmíněného příkladu, tak jak byste vypsal obsah domácího adresáře na těchto platformách do souboru v UTF8 nebo jiném kódování, kolik knihoven byste musel použít?

Nechci se přít, glib/gtk+ to řeší Vaším způsobem, ale když chci napsat opravdu jednodušší aplikaci tak proč použivat 10 knihoven na to, abych si přečetl konfiguraci, zobrazil nějaké ovládací prvky a při ukončení zase zapsal konfiguraci (xml).

Celá binárka má po zkompilování asi 300kb a je tam opravdu veškeré non-gui co pro gui potřebuji tak proč z toho dělat samostatný balík?

[Josef Kufner]

Kódování je naprosto nezajímavá veličina a jsou s tím akorát problémy. Minimálně z pohledu obyčejného GUI. Prostě je kódování takové, jaké je ve zbytku systému – locales, zvolené fonty, atd. A je úplně jedno jestli to je ASCII, Latin 2 nebo UTF-8.

Délka stringu je o něco zajímavější, ale proč obtěžovat s dalším typem? Ať si to knihovna interně udržuje, ale neotravuje s tím. Navenek bohatě char* stačí.

Když budu mít na každou věc jednu specializovanou knihovnu, není problém ji vyměnit za něco jiného, když nebude vyhovovat. Pokud budu mít jednu velkou, tak můžu maximálně přidávat. Také se bude menší knihovna lépe udržovat a bude přehlednější.

Ad příklad: Pokud bych měl použít knihovnu na každou ptákovinu, tak bude jedna. Adresář na každé platformě otevře opendir(), pak vemu iconv, abych to převedl ze systémového kódování na požadované utf8.

[Deleted [8409]]

1) No jestli je to tak jednoduché jak říkáte, proč má glib, Qt, wxWidgets atd své vlastní ekvivalenty...?

2) Myslím že kompatibilitu v mém případě zajišťuje to, že jde o jeden balík, programátor nemusí hlídat změny dalších knihoven, prostě balík bude vždy fungovat.

3) opendir, ve windows se dá použít i funkce FindFirstFile která při kompilaci s _UNICODE má WCHAR výstup, což je mě osobně bližší a navíc na některých platformách při použití opendir je ještě nutné zavolat stat() abychom vůbec zjistili s čím máme tu čest, takže by si programátor asi stejně napsal svou vlastní funkci, která zařídí vše za něj

K tomu char*) a obecně stringům:

Představme si situaci, že máte aplikaci která je závislá na současném kódování a otevíráme data, které jsou v jiném kódování a převod znamená ztrátu nebo chybu (iconv), myslím že nemá cenu dál pokračovat, protože nejenom že se data špatně zobrazí, ale překódování způsobí i to, že se špatně i uloží, pokud uděláme změnu.

A už vůbec nemluvím o manipulaci s textem, který může, ale nemusí být UTF8 atd. To jsou zbytečné problémy kterým chci předejít. Funkce která jde o jeden znak dopředu nebo dozadu v UTF8 stringu je docela nechutná a zbytečná a navíc není nikde jistota že to opravdu ten UTF8 string je.

pokud máte char* v lokálním kódování, není problém s něj udělat String:

Příklad:

char* asciiText = "neco";
char* utf8Text = "neco";
char* localText = "neco";
wchar_t* wcharText = L"neco";

String s1(asciiText, TextCodec::ascii());
// nebo
String s1(asciiText);

String s2(utf8Text, TextCodec::utf8());
String s3(localText, TextCodec::local());
String s4(wcharText, TextCodec::localWChar());

A pokud chcete zpět

ByteArray a = s1.to(TextCodec::utf8());

// pokud chcete opravdu char*
char* text = malloc(a.length() + 1);
memcpy(text, a.constStr(), a.length());
text[a.length()] = 0;

Ale právě takovým věcem jsem se chtěl vyhnout. To co jsem zde napsal mě normálně funguje a je to standardní postup. Navíc je zde možnost implicitního sdílení jako třeba u Qt což dodává programování ještě další rozměr

A co třeba manipulace:

StringList sl = String("a|b|c|d|e|f").split("|");

Myslím že jednotný Char na všech platformách má svou výhodu, wchar_t je pro mě nepoužitelný protože na linuxu je 32 bit a ve win 16 bit, s tím ale nikdo z nás nic neudělá.

Ale multiplatformnost není jenom problém se strings (kéž by), problém jsou třeba cesty k souborům (lomítka / \, pracovní adresář atd...), o GUI rači mlčím

[Josef Kufner]

Ale ono to není až takovej horor... když jsem měl problém s kódváním, tak to bylo jen kvůli tomu, že toolkit používal něco jiného než všechno ostatní.

[Deleted [8409]]

Já si myslím že chybné zobrazení textu je ostuda a omezit uživatele na výchozí 8 bit kódování je krok směrem zpět.

[Josef Kufner]

Jo to je, ale pokud používám Latin 2 a toolkit mi vnucuje UTF-8, není to o nic lepší.

[Deleted [8409]]

Ale na druhou stranu pokud toolkit používá UTF8 a Vy mu vnutíte latin2, je vše v pořádku...?

[Deleted [8409]]

Jo a ve Vašem profilu máte v tom kódu chybku, ale nevím jestli to není naschvál

[Deleted [8409]]

můj omyl

Ale pro segfault bych radši napsal:

*((unsigned long *)NULL) = 0UL;

[ajikdpoe]

alebo nechces radsej pomoct ty mne?

http://simpletoolkit.sourceforge.net/

[Deleted [8409]]

Díky za odkaz (tento toolkit novinka), už to tahám a mrknu na to

jenže mi vadí tyto věci:

• Licence (chci BSD like)
• Teď to tahám, ale uršitě má každý widget své xwindow okno což já řeším docela složitým způsobem abych se tomu vyhl (Pro každé top level okno vytvořím xwindow a do něho embeduju vše ostatní, tomuto postupu jsem podlehl pouze k vůli rychlosti, prostě chci co nejmíň komunikovat přes socket, myslím že Qt o tomto postupu hodně uvažuje)
• Přímá závislost na xlib, mám radši multiplatformnost, protože asi nikdo z nás nemůže být pořád v linu a svoje aplikace si chci spustit kdekoliv, já řeším windowing system jako plugin a aplikace zkompilované pod tímto toolkitem nemusí o xlib vůbec vedět a nejsou k ní přilinkované, to samé platí třeba o knihovnách libjpeg a libpng, atd... Důvoj je absolutní přenositelnost a možnost spustit si grafické nastavení třeba nějakého exportu souboru kdekoliv, pokud někdo napíše plugin pro SDL, pojede to i tam, i když asi jen jedno okno, ale to není už můj problém

Ale určitě mrknu na Vaše zdrojáky a s radostí Vám pošlu i ty moje, o toolkitech by možná chtělo pokecat více chatu

[ajikdpoe]

- licencia nieje problem, kludne to dam aj pod public domain, bsd licencia nieje problem (z mojej strany urcite nie)

- ano, kazdy widget ma vlastne okno (teraz je STK 2.x) predtym som to robil v inak (STK v1.0) a zistil som ze to nieje dobre riesenie (najme s pohladu obsluhy udalosti a z hladiska rychlosti). Tak som to cele prepisal.

- k prenositelnosti: uz dlhsie planujem port na FBUI (framebuffer user interface) to je 26kB kernel modul ktory robi to co X Server. Pisal som aj toolkit pre SDL, ale ten som nedotiahol...

- Inak pisat toolkit v xlib je docela porod. Je to tak trochu alchimia. Mizerna dokumentacia. Asi najhorsie bolo dokopat X Windows-ovi fokus handling na pouzitelnu uroven (defakto pouzivam vlastny).

- Urcite mozeme pokecat, aj ked teraz som menil ICQ klienta na SIM a neviem ci je 100% funkcni ale kludne - icq:284233649 alebo na moj email...

[Deleted [8409]]

No já jsem xwindow pro každý widget odmítl ze dvou důvodů: - Komunikace s X (podle mě zdlouhavé) - Možnost udělat opaque region a přiřadit composite operaci pro kterýkoliv kontrol (ten region je v poho, ale compositing ještě nemám hotové, problém je že nechci vytvářet double buffer pro každé podokno což je na compositing potřeba)

S Xlib jsem zatím neměl problémy, ale měl jsem problém třeba s fontconfig a myslím že je to brzda spuštění pro všechny aplikace které ho používají.

FBUI znám, ale spíš bych přemýšlel o XCB.

[ajikdpoe]

XCB tiez poznam ale neviem ci sa medzitym xlib nezlepsila natolko ze uz tie nedostatky oproti XCB nema. To neviem. Aj ked raz som skusil na RedHat 7.2 a Fedora Core 4 to xcb skompilovat ale nepodarilo sa tak som to XCB zatial pustil k vode.

Ano, ten tvoj sposob s tym oknom je lepsi prave vtedy ak uz potom vramci toho jednoho okna nejdes cez xserver ale cez DRI alebo nieco podobne proste priamo na grafiku.

Lebo ak by si isiel cez xserver (cez 1 okno) a mal by si tam napr. 1 velke tlacitko (pouziva len mouse-click) a paintbox (pouziva aj mouse-move udalost) tak aj keby si bol nad tym tlacitkom tak by si musel mat nastavenu masku udalosti aj na mouse-move (lebo je to 1 okno) a vsetky tie mouse move udalosti by isli cez socket zbytocne. Nehovoriac o tom ze potom v kode musis napisat vlastny event handler a ten co som napisal ja bol velmi podobny tomu co je v xlib, proste kopirovanie rovnakeho kodu ktory robi to iste 2x. Ak ides priamo na grafiku (to bude pripad aj toho fbui) tak tam tento problem nebude.

[Creckx]

No.... hlavně že už se nechceš zabít. Ať si tady říká kdo chce co chce, že toolkitů je hodně a podobně, tak se tím vůbec nenech vynést z míry. Nejlepší toolkit je ten co ti vyhovuje a to bude s největší pravděpodobností pouze ten co si napíšeš.

[Luk]

Nejlepší toolkit je ten co ti vyhovuje a to bude s největší pravděpodobností pouze ten co si napíšeš.

To je samozřejmě pravda a platí to obecně. Ale při pohledu na to, kolik se mi během let nahromadilo kostlivců ve skříni, raději každého předem varuji. Napsat něco většího (což takový toolkit bezpochyby je) znamená překonávat řadu situací, kdy má člověk tendenci se na to vykašlat.

[ajikdpoe]

Musim povedat ze pisat si vlastny toolkit je zaujimava skusenost. Viem o com hovorim: simpletoolkit.sourceforge.net ;)

[Michal Vyskočil]

Tohle není toolkit, ale wrapper. A když jsem se díval na PyQt4 od riverbanks, tak se ani nedivím, že vzniká nový wrapper, který využívá boost.

[ajikdpoe]

tak tak, pokial tam niekde v kode nemate XDrawLine(...) alebo nieco podobne tak to nieje toolkit. Na druhu stranu pre usera (programatora ktory ho vyuziva) je to blackbox zvany toolkit a viacej ho nezaujima...

[Deleted [8409]]

Spíš bych místo XDrawLine() napsal XCreateWindow(), protože bez XDrawLine() se dá obejít

[ajikdpoe]

Ok, tak aspon XDrawText alebo nieco podobne proste "hmatatelna grafika" kde vie ze toto fyzicky bude kreslit na obrazovku... Kdesto ked si v gtk alebo qt pozries zdrojaky napr. tlacitka a postupne ides po jeho funkciach tak nie a nie sa dostat k tym cisto grafickim veciam. Proste od buttonu k pixelom je v tychto naboptnalych toolkitoch strasne dlha cesta... (a neviem ci tam ciel je?) Podobne je to napr. aj v Delphi vo windows, tak ked mas button tak nikde neuvidis v zdrojakoch kde sa vykresluju ciari atd...

[Deleted [8409]]

Já jsem jednou prochálel zdrojáky VCL s C++ Builderu 1.0 (hluboká minulost) a právě tam jsem si všiml, že si všechno kreslili sami, bylo to samé MoveTo() a LineTo() ale Qt a Gtk+ je úplně jinde. Nejhorší na tom je, že ten builder jsem měl ješte tehdy na 486 s 8MB ram a jelo úplně krásně.

Třeba tehdejší ZoneRings32 - hezký prográmek na naučení, sice v Delphi ale hukot

[Luk]

Tohle není toolkit, ale wrapper.

To nic nemění na faktu, že za půl hodiny se to nenapíše