On 2015-08-13 01:11, Marek wrote:
> Jak sobie wyobrażasz synchronizacje gui->user gdy wszystko wrzucisz w
> tło?

95% akcji gui nie wymaga żadnej synchronizacji. Po prostu kręci się
gdzieś throbber. Nawet interaktywne elementy GUI takie jak wyświetlanie
strony nie wymagają żadnej synchronizacji - klikasz w linki i zakładasz
że po chwili możesz *przewijać* tekst nawet jesli nie załadowaly się
wszystkie obrazki i reklamy. Szybkośc jest zbedna. Niezbedna jest
responsywność.

> Przecież musi to być zsynchronizowane.

Nie musi. Myliusz jak niedzielny programista Delphi. oko ma ograniczone
mozliwości i nie musisz wszystkiego nagle narysować na gotowo, nic sie
nie stanie jak po chwili coś się gdzieś dorysuje po 5ms.

> Wynik zadania w tle w 99% ma
> być jakoś odzwierciedlony w zmianie stanu w gui (coś ma się "narsować").

Nic ma się nie narysować, ma się narysować w połowie, ma się narysowac
za godzinę. Współczesne aplikacje nie wymagają *natychmiastowej*
reakcji, wymagają tylko *płynnej* obsługi. jak klikasz w przycisk to
spodziewasz się ze bedzie to widac/slychać, a sama akcja może się
wykonać po chwili. Natomiast w dobie onklikowych implementatorów
zazwyczaj jest tak że pacniesz w przycisk a on jak zaklęty, nawet nie
widac że zareagował.

> Najprostrzy sposób to progress bar (długa operacja) lub zamrożenie gui
> (krótka operacja). Co wybierasz?

Kilka innych.

> Jeśli ani jedno i ani drugie to wtedy gui aplikacji będzie dla usera
> zachowywać się kompletnie niedetermistycznie

Przeglądarki się tak zachowuja. Dowolny sewis a-la portal zatrudnia
imbecyli którzy nie slyszeli że rozmiar obrazkow mozna podać zawczasu w
htmlu, więc takowy portal skacze po calym ekranie podczas ladowania.
Masz jakiś wiekszy kłopot poza przeklinaniem, żeby z niego korzystać?

, To pozbawienie usera
> sprzężenia zwrotnego z gui. User nie będzie wiedział czy już może coś
> kliknąć czy poczekać, czy w ogóle coś się dzieje.

W dobie imbecyli z JavaScript i tak nie wie. I jakoś sie kręci.