Vlákna a GTK

10.12.2006 21:41 | Přečteno: 1364× | Linux

Bože, už jste někdy zkoušeli pracovat s vlákny a GTK najednou? Nejde to do sebe. Ačkoliv je glib "thread safe", u GTK tomu tak není. Před jakoukoliv manipulací s widgetem musíte zavolat gdk_threads_enter() a po dokončení manipulace gdk_flush() a gdk_threads_leave(). A do toho ještě signály ... V těch od glib se to volat musí, ale v těch od gtk ne.

Proč se o to nepostará samo GTK, tak jako je tomu třeba u Qt, WinAPI a jánevímkdeještě.

Bože, jak mam naprogramovat kvalitní commander bez podpory (nebo s debilní podporou) vláken.

       

Anketa

Anketa

Komentáře

[xxxxxxxx]

Chybí mi možnost "Nedělám"

[Luk]

Připomínám, že takový javovský Swing také není thread-safe. Všechno se tam dělá z jednoho vlákna (event-dispatching thread) a když se musí něco udělat odjinud, volá se invokeLater() nebo invokeAndWait(). Má to logiku, nemusí se pak nic zbytečně zamykat, není tedy režie navíc.

[petr]

Jo, tohle řešení Swingu se mi osobně líbí ze všeho nejvíc a okamžitě jsem si na něj zvyknul... Od té doby řeší thread-safe jen v modelu mých aplikací

[Luboš Doležel (Doli)]

Bože, jak mam naprogramovat kvalitní commander bez podpory (nebo s debilní podporou) vláken.

Vykašlat se na celé GTK+ a začít s Qt 4. Taky jsem dělal v GTK+ a GTKmm, ale jakmile jsem poznal Qt, tak už si na GTK+ ani nevzpomenu - je to neuvěřitelná úleva.

R.I.P. GTK...

[Fuky]

Je dobré nejprve věci pochopit a teprve poté je odsuzovat a samozřejmě veškerou kritiku podložit argumenty, za kterými si můžete stát

GTK je moc chytře udělané a nevyvíjí ho žádní žabaři. To samé platí o Qt. Tyto dva toolkity jsou si +- naprosto rovny

[Daniel Kvasnička ml.]

No pokud vim, tak autorovi jde o twin-panel commander pro GTK+, takze me zatim napada jedina zachrana a to zkusit wxWidgets. S wxPythonem jsem celkem spokojen.

[Fuky]

Mě to vyhovuje Dříve jsem používal také enter/leave, ale pak jsem se dočetl, že toto řešení nedoporučují ať použiju raději:

gobject.idle_add(tlacitko_BT.set_sensitive, True)

Když to najdu pošlu sem link. Každopádně tenhle druhý způsob se mi líbí víc.

[Jaroslav Šmíd]

Tak tohle se zdá být lepší. Tak nějak to snad v tom C++ spatlám (snad to půjde)

[Petr "Glubo" Sýkora]

Nevím, ale přijde mi, že o každý widget by se stejně mělo starat právě jedno vlákno. Jelikož když si budou jednotlivá vlákna povídat tím, že jedno vlákno šoupne šoupátkem doleva jinému vláknu místo toho, aby mu prostě poslalo int, pak tu něco strašně smrdí... Když už vlákna, tak pořádně :)

[Jardík]

Né, takto to řešit opravdu nehodlám. Při zahájení kopírování souborů se vytvoří nové vlákno, které obdrží seznam souborů. To vytvoří nové okno s ukazatelem průběhu a spustí se kopírování. Po dokončení ze okno zruší a vlákno se ukončí. Bude tak možné dále pracovat s commanderem a přitom se v klidu kopírují soubory.

[Jardík]

Teď přemýšlím, jestli by nebylo lepší vytvořit dočasný soubor a nespustit novou instanci aplikace s parametrem cesty k souboru .... Bylo by to méně bugové. Asi to tak udělám a vykašlu se na vlákna.

[Luk]

A proč to neudělat tak, že kopírující vlákno bude pouze aktualizovat nějakou hodnotu stavu kopírování (třeba 0 .. 100) a hlavní vlákno (starající se o GUI) bude periodicky - např. každých 500 ms - tuto hodnotu číst a aktualizovat progress bar? To mi připadá jako čistší a méně náročné řešení než nějaké nové spouštění aplikace.

[petr_p]

Ale priznejme si, ze neni nad cisty vlaknomilny toolkit. Ty aplikace jinak uvnitr vypadaji hrozne, cely to je GUI-centricky a clovek je pak strasne omezeny a vubec.