Stav Toolkitu

5.8.2006 17:54 | Přečteno: 1025× | Linux | poslední úprava: 5.8.2006 19:41

Stále mě ještě nepřestalo bavit pracovat na Toolkitu. Dnes jsem se definitivně rozhodl, že nebude defaultně vytvořená statická knihovna, ale jen dynamická. Velikost knihovny je zatím 276 kB (překládáno s parametrem -fPIC). Defaultně jí nebudu stripovat, ale bude možné to udělat příkazem make strip. Po stripnutí má nějakých 70 kB. configure skriptu bude možné předat parametr --enable-static. To bude mít za následek i vytvoření statické knihovny.

Tak a teď k tomu stavu Toolkitu. Mám zatím dokončenu implementaci jen těchto widgetů:

• Alignment
• HBox
• Label
• Table
• VBox
• Window

Dále jsou dokončeny třídy AnsiString, WideString a UnicodeString s možností konverze mezi jednotlivými znakovými sadami nebo kódováními, třídy pro čtení a zápis souborů (File, InputFile, OutputFile) a nakonec třídy Array a Application.

Následuje zdrojový kód (pro ukázku), který je již opravdu přeložitelný (ten posledně byl jen návrh). Nejsou v něm ukázány všechny dosavadně implementované možnosti Toolkitu, spíš takové minimum. Je to prostě jen ukázka.

#include <Toolkit/Application.h>
#include <Toolkit/Window.h>
#include <Toolkit/Label.h>
 
Toolkit::Application *app;

class MainWindow: public Toolkit::Window{
public:
	MainWindow()
	{
		setTitle( app->getName() );
		setDefaultSize( 500, 480 );
		new Toolkit::Label( L"Hello world!\nHlavní okno", this );
	}
	~MainWindow()
	{
		app->quit(0);
	}
};

class ChildWindow: public Toolkit::Window{
public:
	ChildWindow()
	{
		setDefaultSize( 400, 250 );
		setTitle( L"Modální dialog" );
		new Toolkit::Label( L"Hello world!\nModální okno", this );
	}
	~ChildWindow()
	{
		
	}
};

MainWindow *mainWindow;
ChildWindow *childWindow;
 
int main( int argc, char **argv )
{
	app = new Toolkit::Application( &argc, &argv );
	app->init( L"JXP Commander" );
	
	mainWindow = new MainWindow;
	mainWindow->showAll();
	
	childWindow = new ChildWindow;
	childWindow->setTransientFor(mainWindow);
	childWindow->setSkipTaskbarHint(true);
	childWindow->setModal(true);
	childWindow->showAll();
	
	return app->run();
}

Update: Jedna výborná zpráva - glib obsahuje konverzní funkce pro řetězce používající iconv. Licence tedy zůstává BSD.

       

Komentáře

[Josef Kufner]

A co udělat místo toolkitu GUI? Blami se o tomhle kdysi dávno zmínil a je to celkem zajímavá myšlenka.

Jde o to, že místo sem dej tohle, támhle todle se udělá jakési obecné gui, které bude vyhovovat všem aplikacím. Pak tvorba programu bude vypadat asi tak, že se inicializuje GUI, řekne: "Chci pohled na dokument, tady jsou funkce, které to umí, tady je kód na vykreslení dokumentu, tady jsou callbacky na tyhle události."

Program se vůbec nemusí zabývat tvorbou GUI, jen definuje relativně obecný typ a pár základních vlastností. Např: pohled na dokument, konfigurační dialog, paleta s nástroji, zobrazení informace/otázka,...

Ve výsledku by všechny programy měly stejné GUI, plně konfigurovatelné a na desktopu nezávislé. Bez sebemenšího zásahu do programu by bylo možné používat stejný program na PC, PDA, tabletu,... Bylo by možné překonfigurovat ovládání tak, že by se okna otočily naruby a ještě dělaly kotrmelce

Mohla by vzniknout nová vrstva mezi programem a X serverem. Jakýsi správce GUI, který by zobrazoval palety s nástroji zadokované v pevných docích na okraji displeje (nikoliv okna, ani jako samostatné okno) a menu by mohlo být jako je už dlouho na Macu. Jen by to šlo daleko dál.

Prakticky by mohl přestat existovat současný desktop s okny. Myšlenka zachycená Ionem by se mohla dál rozvinout,... pak by uživatel přepnul téma a koukal by na desktop ve stylu Windows 3.1, žádné panely, jen okna...

Tohle by ale neznamenalo konec toolkitu jako takového, ten by byl použit na vykreslování tlačítek, menu,... prostě to co dělá teď, jen by ho nepoužíval program, ale nějaký ten správce GUI.

Pak je ještě problém se zobrazením onoho dokumentu. To může být prakticky cokoliv, nemyslím tím jen kus textu či obrázek, ale třeba i hru, mail klient, terminál, prostě cokoliv. Jak tohle zapasovat do tak obecného návrhu je trošku problém. Viděl bych to tak, že by se program prostě staral o ten jeden widget. Ale jen o ten.

[David Jaša]

Ač neprogramátor, tak mě už něco podobného taky napadlo. Akorát jsem to nerozvíjel.

BTW nesnaží se o něco podobného wxwidgets?

[ajikdpoe]

Skus moj toolkit:

http://simpletoolkit.sourceforge.net/

[Jardík]

Zkoušel jsem ho už před pár dny. Není vůbec špatný. Jenom by potřeboval dodělat :) Jenže já to chci mít pod Gtk. Gtk má ale pro mě hnusné API a proto dělám ten Toolkit (je to wrapper pro Gtk).

[Deleted [8409]]

Co je tak neuvěřitelného na gtk?

[Deleted [8409]]

Xlib->gdk->gtk->Toolkit->aplikace

Nevím, ale 70kb se mi zdá trošku moc, na to že to je jen wrapper pro 5 widgetů.

[Jardík]

V tom seznamu ti ještě chybí glib, ale to je jedno. Nevím, co si tim chtěl říct.
libgtkmm má 3,3 MB. 70kb rozhodně moc není (jen 8,75kB), ale já psal 70kB (musel jsem si rejpnout) ale to podle mě také moc není.

[Deleted [8409]]

glib tam není úmyslně, šlo mi čistě o vrstvu, která se dostane k xlib.

Jde o to jestli není lepší mít toolkit který je nativně napsaný v jazyce ve kterém se budou psát i aplikace, C++ wrapper pro C++ toolkit by totiž asi nikdo nedělal a bylo by to jenom dobře.

[Deleted [8409]]

Jenom by mě zajímalo jestli se ve Vašem příkladě korektně uvolní ty vytvořené widgety?

[Jardík]

Widgety automaticky handlují (nebo jak to nazvat) signál "delete-event". Mám ošetřeno, jestli je nejprve zavolán destruktor (v tom případě se volá gtk_widget_destroy) nebo je nejprve zavolána callback fce pro "delete-event" (zavolá se delete this).