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.

do góry

On 2015-08-12 17:50, Sebastian Biały wrote:
> Nawet OSy są spieprzone, że przypomnę że głupi windows czeka kilka
> sekund na odpowiedź czy w napędzie jest płyta jesli własnie jest
> detektowana, a starsze windowsy zamarzaly się na czas odczytu dyskietki.

Zapomniałem o moim flagowym przykładzie. Dekoden nc+ czeka przy zmianie
kanałów na pojawienie się sygnału, w zasadzie czeka nawet na reakcje na
przyciski. H.. wie po co. Typowy przykład pisania "byle jak".

do góry

On Fri, 14 Aug 2015 18:37:26 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> 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.

Nie zawsze jest tak, że można rysować partiami, nikt nie chce oglądać
efektów komputerowych z filmów z lat 80 u.w.


> 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ł.

Przwciesz windows przyzwyczaiło wszystkich do takiego modelu, albo co
chwila okno modalne albo inna blokada gui, nie można sobie np.
otworzyć w aplikacji okna ustawień i mieć je otwarte nie blokując
reszty.

> 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.

Aaa Ty do przeglądarki pijesz. Trzabyło tak od razu. Tylko myślę, że
argument o deklaracji rozmiaru obrazka w html pasuje do lat 90 i
mosaica (nie wiem czy się orientujesz co to było) a nie do
współczesnego html, w którym jest coraz mniej html.
W kwesti przeglądarek to raczej rzucasz się z motyką na Słońce..
Nawet najlepszą przeglądarkę "ubije" webdeveloper, a
najoptymalniejszą stronę www ubije kiepska przeglądarką. To czego
oczekujesz wymaga kooperacji obu stron (obu progamistów) co w
praktyce jest niemożliwe.
Dlatego powstaje coś takiego jak aplikacje mobilne do serwisów www,
jakiś absurd.

--
Marek

do góry

On Fri, 14 Aug 2015 18:39:44 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Zapomniałem o moim flagowym przykładzie. Dekoden nc+ czeka przy
zmianie
> kanałów na pojawienie się sygnału, w zasadzie czeka nawet na
reakcje na
> przyciski. H.. wie po co. Typowy przykład pisania "byle jak".

Weź mnie nie wqr. U teściowej jest jakiś dekoder multimedi "java
powered". Reakcja na klawisz pilota 10s. Jak już oglądam tv u siebie
w domu to metodą 2 sek na kanał i przeskakuje na następny (analogowa
kablówka w tv) a z tym "java powered" się nie da. Jak się szybko
naciska to tylko buforuje 3 ostatnie i zareaguje na nie po minucie
albo się zawiesi.

--
Marek

do góry

On 2015-08-15 10:05, Marek wrote:
> Nie zawsze jest tak, że można rysować partiami, nikt nie chce oglądać
> efektów komputerowych z filmów z lat 80 u.w.

W interfejscie uzytkownika to czy lista pojawi się od razu czy po 5ms
nie ma żadnego znaczenia. Dla responsywności i płynności przewijania
scrollbara - ma znaczenie *zasadnicze*.

> Przwciesz windows przyzwyczaiło wszystkich do takiego modelu

Microsoft nigdy nie był i już nie będzie wzorcem dla gui. To oni
przyzwyczaili ludzi do dziadostwa, głwnie dlatego że ich API pochodzi z
Win3.x a tam nie bylo wątkow tylko cooperative multitasking. Efektem
czego współczesne bibloioteki, nawet te nowoczesniejsze jak Qt wymagają
paintowania z wątku GUI a nie z innych. I nikt tak naprawdę nie wie
dlaczego, bo dla karty graficznej nie ma znaczenia jaki wątek ją o coś
prosi, a synchronizacja i tak jest bo kazdy proces ma po jednym watku
głownym. Unix to samo, X-y wymagają paintowania z jednego wątku. Diabli
wiedzą dlaczego.

, albo co
> chwila okno modalne albo inna blokada gui, nie można sobie np. otworzyć
> w aplikacji okna ustawień i mieć je otwarte nie blokując reszty.

Modalność nie ma nic wspolnego z responsywnością. Responsywność - z
grubsza - polega na tym że jak masz załadować milion elementów do
drzewa, to tępak załaduje je od razu blokując GUI a mądrzejszy załaduje
je w 2 sekundy ale pozwoli na działanie gui w międzyczasie dając
*złudzenie* responsywności. Jego ładowanie potrwa dłużej, ale będzie
nieblokujące dla gui. Inna sprawa że tępaki zazwyczaj testują apliakcje
na kilku elementach, nie zastanawiają się nad O(N^2).

> Aaa Ty do przeglądarki pijesz.

Nie. Przeglądarki to typowy przykład że masz 20 zespołów programistow i
*WSZYSCY* popelniają te same błedy robiąc logikę w onklikach. Bo tak
jest taniej. Myślałem że może Edge coś zmieni, ale wygląda na to że
podstawą zmianą w Edge jest branch repozytorium IE.

> Trzabyło tak od razu. Tylko myślę, że
> argument o deklaracji rozmiaru obrazka w html pasuje do lat 90

Dalej działa i roku na rok jest coraz rzadziej stosowany. Głównie
dlatego że proces layoutu strony przerzuca się na gówno wydziargane w
javascript. Nie zmienia to jednak faktu że np. głowne logo allegro po
załadowaniu powoduje przesuniecie strony za co student dostał by czapę
na zaliczenie.

> i mosaica
> (nie wiem czy się orientujesz co to było)

Używałem.

> a nie do współczesnego html,
> w którym jest coraz mniej html.

Zgoda. To powoduje że mimo to że strony migają, zmieniają layout w
trakcie ładowania, zmieniają style itd dalej sa używalne. Bo nie jest
istotne żeby strone załadować *szybko* i od razu gotową. Istotne jest
aby w trakcie procesu ładowania pozwolić na interakcję. A to wymaga
zmiany myslenia i czasem zakopania kilku liderow zespołu programistów.
Obecnie to działa bardzo przeciętnie, ładowanie w tle to tylko jakaś
cześć procesu, dalej przetwarzamy dane w onklikach.

> W kwesti przeglądarek to raczej rzucasz
> się z motyką na Słońce.. Nawet najlepszą przeglądarkę "ubije"
> webdeveloper, a najoptymalniejszą stronę www ubije kiepska przeglądarką.

Nie. To wina przeglądarki, że gui staje się nieresponsywne. Nawet jeśli
trafie na debila z portalu robiącego O(N^3) to dalej - gui przeglądarki
nie ma prawa zatrzymać sie na dłużej niż 50ms a i tak to jest grube
przegięcie. Scrollbary mają działać, linki mają się klikać. To jest
wyłacznie wina przeglądarek że tak nie jest.

> To czego oczekujesz wymaga kooperacji obu stron (obu progamistów) co w
> praktyce jest niemożliwe.

Nie wymaga. Wymaga zakopania liderów zespołów programistów przeglądarek,
spalenia kilkudziesięciu durnych książek (głównie o delphi, przepraszam
za złośliwość) i zmiany kilu OSów. Czyli pikuś.

> Dlatego powstaje coś takiego jak aplikacje mobilne do serwisów www,
> jakiś absurd.

Powstawały zawsze ponieważ głos decydujący o kierunku tego rynku nie
należy do ludzi inteligentnych z wizją tylko do prawników, ekonomistów,
cieciów i innej swołoczy.

do góry

Marek <f...@f...com> wrote:
> On Fri, 14 Aug 2015 18:39:44 +0200, Sebastian Biały<h...@p...onet.pl> wrote:
>> Zapomniałem o moim flagowym przykładzie. Dekoden nc+ czeka przy zmianie
>> > kanałów na pojawienie się sygnału, w zasadzie czeka nawet na reakcje
>>> na > przyciski. H.. wie po co. Typowy przykład pisania "byle jak".
>
> Weź mnie nie wqr. U teściowej jest jakiś dekoder multimedi "java
> powered". Reakcja na klawisz pilota 10s. Jak już oglądam tv u siebie w
> domu to metodą 2 sek na kanał i przeskakuje na następny (analogowa
> kablówka w tv) a z tym "java powered" się nie da. Jak się szybko naciska
> to tylko buforuje 3 ostatnie i zareaguje na nie po minucie albo się zawiesi.


Pewnie w Dalviku pływa po głębokiej wodzie :-)

do góry

Marek <f...@f...com> wrote:
> On Fri, 14 Aug 2015 18:37:26 +0200, Sebastian Biały<h...@p...onet.pl> wrote:
>> 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.
>
> Nie zawsze jest tak, że można rysować partiami, nikt nie chce oglądać
> efektów komputerowych z filmów z lat 80 u.w.

Nic bardziej wkurzajacego przy oglądaniu niektórych "dizajnerskich" stron
www to jak nie-do-konca namalowana stronka po 10 sekundach dociągania
czegoś postanowi przesunąć fragment na który właśnie zamierzasz kliknąć i w
efekcie klikasz na coś innego.

Nie wiem jak oni to robią, bo przecież linki do obrazków powinny być dla
klienta http dostępne od razu wraz z rozmiarem w pikselach, wiec nie trzeba
mieć całego gifa czy jpg z reklamą, aby zarezerwować dla niego miejsce.

>> 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ł.
>
> Przwciesz windows przyzwyczaiło wszystkich do takiego modelu, albo co
> chwila okno modalne albo inna blokada gui, nie można sobie np. otworzyć
> w aplikacji okna ustawień i mieć je otwarte nie blokując reszty.
>> 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.


Dokladnie.

> Aaa Ty do przeglądarki pijesz. Trzabyło tak od razu. Tylko myślę, że
> argument o deklaracji rozmiaru obrazka w html pasuje do lat 90 i mosaica
> (nie wiem czy się orientujesz co to było) a nie do współczesnego html, w
> którym jest coraz mniej html. W kwesti przeglądarek to raczej rzucasz się
> z motyką na Słońce.. Nawet najlepszą przeglądarkę "ubije" webdeveloper, a
> najoptymalniejszą stronę www ubije kiepska przeglądarką. To czego
> oczekujesz wymaga kooperacji obu stron (obu progamistów) co w praktyce jest
niemożliwe.
> Dlatego powstaje coś takiego jak aplikacje mobilne do serwisów www, jakiś absurd.

Ale i te aplikacje maja ten sam problem.

To sie chyba bierze stad, ze ramka z reklama przychodzi od dostarczyciela
monetyzacji - i zmienia rozmiar z kazda odslona witryny bo jest ciagle inny
rozmiar i rozsuwanko.

do góry

On 2015-08-15 10:29, Marek wrote:
> Weź mnie nie wqr. U teściowej jest jakiś dekoder multimedi "java
> powered". Reakcja na klawisz pilota 10s.

To nie jest wina Javy. Zapewniam że można osiągnąć bajeczna płynność w
Javie. Tutaj nawet nie jest winien garbage collector bo nie da się
technicznie wyjaśnić jego działaniem tych lagów. Tu jest bylejakość
programisty a może głównie projektanta. Powszechna w branży embedded
gdzie się nie tyle projektuje co pisze ad-hoc.

Miałem okazję bawić się dzisiaj nowym tv Samsunga. Przyznam, że nawet
gdy bym chciał nie potrafiłbym tak spieprzyć *wszystkiego*. Dosłownie
wszystkiego, od responsywności pilota przez absurdalne błędy w GUI po
ewidentną fuszerkę robienia na kolanie i klejoną gumą do żucia. Ja mam
bardzo niskie mniemanie o programistach embedded ale tutaj przeszli
samych siebie skutecznie mnie lecząć z pomysłów zakupu Stupid TV. Ba,
nawet aplikacja Samsunga na PC do DLNA jest tak kiepska że nie wiadomo
od czego zacząć aby się nie rozpłakać nad gównianością w każdym
szczególe. Żeby nie było: Mój 10 letni Sony Bravia ma te same objawy
tylko w mniejszej skali bo imniej softu. Ewolucja stoi w miejscu. Nie
zakopiesz liderów zespołów programistow i projektantów - nic się nie zmieni.

Przeszliśmy daleką drogę od interfejsu GUI w Amidze żeby 30 lat później
stwierdzić że się cofnelismy w rozwoju do jaskiń.

Android ma natłok aplikacji pisanych przez tych samych mistszuf co daje
ogólny pogląd o tym że jest "wolny". Apple się od tego próbowało odciąć
pisząc responsywny system, ale dali w łapę programistów jakieś onkliki i
pozamiatane, apliakcje są napisane po staremu. Dalej czekam na jakąś
rewolucję albo reset i wracamy do Amigi.

do góry

On Sat, 15 Aug 2015 10:33:35 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> głownym. Unix to samo, X-y wymagają paintowania z jednego wątku.
Diabli
> wiedzą dlaczego.

To czego szukasz nazywa się "eXene". Tam każdy widget to osobny wątek
i miało rozwiązać problem "async reply" w X bo do tego chyba pijesz?
Czy jest rozwijane - nie wiem.

--
Marek

do góry

On Sat, 15 Aug 2015 17:21:36 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Miałem okazję bawić się dzisiaj nowym tv Samsunga. Przyznam, że
nawet
> gdy bym chciał nie potrafiłbym tak spieprzyć *wszystkiego*.

A zwykły user nie narzeka. Myślę, że nie jesteś już targetem dla
poroducentów współczesnej elektroniki.

--
Marek

do góry