Dotaz: Python - oživení uživatelského rozhraní

[Milan Uhrák]

Zdravím všechny .. hm, nadpis je asi matoucí, lepší jsem nevymyslel.

popis situace :

pomocí pyqt jsem vytvořil prográmek, který vytváří obří soubory. Aby vytváření nebylo "jen tak nasucho", je indikováno progressbarem s nějakými údaji a tlačítkem "stop". Po spuštění vytváření se toto dialogové okno objeví, ale chová se jako ve Vonnegutově invazní lodi - jako by tam bylo jen z psychologických důvodů.

Signál clicked toho tlačítka je spojen s rutinkou, která nastaví self.cancel na true.

během vytváření obrazu (zapisují se postupně úseky asi 1MB) se toto kontroluje, a pokud je self.cancel true, vytváření se přeruší, a obraz se smaže.

nevím, kde dělám chybu, nebo jak obejít "vlastnost", že jakmile se spustí zápis, tak v podstatě celé GUI zablokuje, protože je vytíženo (si myslím) tím zapisováním.

pokud sleduju vytvářený obraz např. krusaderem, tak i progressbar a informativní label pod nim má docela zpoždění za realitou. Např. label ukatuje 3,5GB hotovo, krusader již vidí 6GB soubor.

Dá se z toho nějak vymotat ?

zde skusím pastnout zdroják, ale je trochu složitější, snad to z toho bude vidět

díky předem za rozumné nápady ..

Milan

class image_create( QtGui.QDialog ):
	def __init__( self,  Parent ):
		super( image_create, self ).__init__()
		self.ui=uic.loadUi('UI/create_image_progress.ui')
		self.ui.label_progress.setText("%i z %i" % ( 0, 0 ))
		self.connect(self.ui.buttonBox_abort.button( QtGui.QDialogButtonBox.Cancel ),  SIGNAL("clicked()"),  self.get_cancel)

	def get_cancel(self, event=False):
		self.image_break = True

	# it určí, jak se zobrazuje prováděná úloha, zda v IT MiB, nebo dakadických
	def create(self, path, name, size, it=False ) :
		self.ui.show()
		self.image_break = False
		if (size < 1024**3):
			part_size = 128*1024 # 128k bloky
		else:
			part_size = 1024**2  # 1M bloky
		parts=int(size/part_size)
		frag=size-parts*part_size
		allpath = os.path.join(path,  name)
		newfile=open(allpath,  'w')
		oldperc=0
		perc=0
		part=chr(0)*part_size
		for seq in range (1, parts+1):
			newfile.write(part)
			if ( self.image_break == True ) :
				newfile.close()
				os.remove(allpath)
				break
			total_done = part_size*seq
			perc = int(float(total_done*100 / size))

			#print "%i %i %i %f" % (seq,  total_done,  perc,  float(total_done*100 / size))
			if (oldperc < perc):
				self.ui.progressBar.setValue(perc)
				oldperc=perc
			self.ui.label_progress.setText("%s z %s" % ( hr_value( total_done, 3 , it ),  hr_value( size, 1, it ) ) )

			if ( self.image_break == True ):
				return 1

		newfile.write(chr(0)*frag)
		total_done = part_size*seq + frag
		perc = int(float(total_done *100 / size))
		#print "%i %i %i %f" % (seq+1,  total_done,  perc,  float(total_done*100 / size))
		self.ui.progressBar.setValue(perc)
		self.ui.label_progress.setText("%i z %i" % ( total_done,  size))
		newfile.close()
		return 0
#		time.sleep( 5 )

---

---

Odpovědi

[Logik]

PyQt neznán detailně, ale IMHO je problém v tom, že se UI nedostane "k lizu". Je třeba mu dát šanci. Zkus to co raděj tady:

http://stackoverflow.com/questions/2482437/label-in-pyqt4-gui-not-updating-with-every-loop-of-for-loop

[Milan Uhrák]

tohle vypadá zajímavě ... děkuji.

Zkouším app.processEvents(), ale narážím na jeden úplně obecný problémek : ten zdroják zde hozený je v modulu, který importuju do hlavní appky, jenže v tom modulu je "app" (definovaný v hlavní appce) nedostupný (tedy myslím si to - před pár dny jsem narazil na podobnou věc, ani global nepomáhalo, a nakonec jsem to nějak obešel pomocí "parent".

Je nějaký konkrétní způsob, jak přenést proměnné z hlavního kódu do importovaných modulů ? nebo se importuje nějak jinak ? V Pythonu se sotva zajíždím.

Milan

[rADOn]

Ciste pro ukazku:

import spam
spam.ham = "dirt"

Uvnitr modulu uvidis promenou ham, spam je odkaz na jeho jmenny prostor. Ale takhle to nedelej, pacz je to neskutecna prasarna a prvni pythonista ktery to uvidi ti pracky urazi a necha te to za trest prepsat do php.

Porad prasacky ale aspon pouzitelny je udelat si v modulu inicializacni funkci ktera bude fungovat jako konstruktor. Ne ze by v tom byl technicky rozdil, ale je prehlednejsi mit veskerou logiku modulu uvnitr toho modulu a nespolehat se ze nekdo "zvenku" vi co a kam ma strcit aby to zacalo fungovat.

Uplne nejcistsi zpusob je udelat proste objekt a strkat veci konstruktoru. Vsechno je reference, takze muzes zonglovat s relativne velkym mnozstvim dat bez kopirovani a je veskrze jedno jestli mas v hlanim programu referenci na modul nebo referenci na nejakou instanci – vsechno je objekt. Jestli vis ze nebudes potrebovat vic jednu instanci tak je to zbytecne, naopak je jednodussi trochu opevnit modul s inicializacni funkci (hlavne zajistit aby nesel inicializovat vicekrat) a interpret z nej udela perfketni singleton bez prace.

[Milan Uhrák]

aha, díky, zatím jsem to tak i řešil, v initu byl

class myobjekt()

def __init__(self, parent ...) self.parent = parent

a to mi umožňovalo volat

mo = myobjekt(self),

a pak jsem se v mo přes parent dostal o patro nahoru. řesil jsem tak i (při uzavírání formuláře) předání proměnných z formuláře volajícímu objektu ... tohle prostě jen zkouším, vidím, že to takto jde, ale nevím, zda je to dostatečně košer.

a díky za ukázku i jiných možností, určitě to zvážím

milan

[Milan Uhrák]

vyzkoušel jsem napovězené app.processevent, a je to uplne presne to, co jsem čekal ..

velký dík oběma ....

Milan

[Bill Gates]

Zdravim, pokud se mohu vmisit do diskuze.. Ja sice gui uz neprogramuju, soustredim se spise na webove aplikace, ale mozna vam jeste prijde vhod ma zkusenost.

Na widlich tehda v delphi jsem onehda pouzival stejny princip a narazil na stejny problem jako vy. Jmenovalo se to Application.ProcessMessages, kdy se GUI dostalo k lizu a fungovalo. Neco jako kooperativni multitasking uvnitr/v ramci jedne aplikace.

Narazil jsem ale na problemy, ze se mi obcas v jistych specifickych situacich stalo, ze ten utek k systemu pomoci Application.ProcessMessages zpusobil nove zavolani funkce, kde byla umistena smycka s Application.ProcessMessages a jeste k tomu jsem mel na zacatku takove funkce napriklad cekani nez se okno zavre a opet pomoci smycky Application.ProcessMessages. Tzn deadlock.

Pozor na to.. muze se to stat, dost obtizne se to hleda a pak sice GUI reaguje, tlacitka tlacitkuji, ale nereaguje to na nic... okno se nezavre a naopak se zmensi programovy zasobnik o jedno rekurzivni volani.

Tak snad vam ma informace bude k necemu dobra, mam pocit ze tady u vas v Pythonu bude princip uplne stejny jako onehda u me v Delphi na widlich.

[Milan Uhrák]

Tak v tomto případě to snad nebude zlobit, protože k Appprocessevent jsem se uchýlil hlavně proto, že ve smyčce, kde BY SE MĚLO plynule aktualizovat rozhraní + detekovat stisknutí tlačítka byl proces, který úplně vyžral strojový čas a GUIko nepustil pořádně k lízu. Nyní to jede jedna báseň. UI je živé, aktualizuje se naprosto synchronně s postupem hlavní smyčky ... prostě paráda.

každopádně díky za upozornění, s touto funkcí je asi opravdu potřeba zacházet opatrně. (možná spíše s návrhem jednotlivých eventů a slotů, aby se navzájem nezacyklily)