🚀 go-pugleaf

Bart Ogryczak wrote:

> 
> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
> instrukcji zaglądać nie musi...

To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.
Jeśli wg ciebie najlepiej wyciąć wszystkich makówkarzy, to może ci się 
przydać: 

http://www.amazon.com/Complete-Idiots-Guide-
Voodoo/dp/0028642368/ref=sr_1_1?s=books&ie=UTF8&qid=1299080457&sr=1-1

i to:

http://sedition.com/a/1022


-- 
Pozdrawiam
ds

W dniu 11-03-02 16:45, ds pisze:
> Bart Ogryczak wrote:
>
>>
>> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
>> instrukcji zaglądać nie musi...
>
> To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.

oczywiście że potrzeba. albo znajomy makówkarz.

-- 
Paweł

On 2011-03-02, Paweł <jas@nie.doczekal> wrote:
> W dniu 11-03-02 16:45, ds pisze:
>> Bart Ogryczak wrote:
>>
>>>
>>> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
>>> instrukcji zaglądać nie musi...
>>
>> To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.
>
> oczywiście że potrzeba. albo znajomy makówkarz.

W ogóle interfejs dotykowy jest bardzo trudny, przynajmniej z punktu
widzenia programisty.  Kursor ma zawsze jakiś stan, bo jest umieszczony
w konkretnym miejscu na ekranie, więc programista jest w stanie po
prostu przypisać akcję do stanu.  W przypadku interfejsu dotykowego nie
da się, bo nie ma kursora, więc programista musi zgadywać co użytkownik
może w danym momencie zrobić i przypisać akcje na zasadzie "co by było
gdyby".  Jedyną wskazówką jest kontekst, który jest jednak o wiele mniej
oczywisty niż konkretny stan, szczególnie w sytuacji gdy mamy do
czynienia z kilkoma aplikacjami jednocześnie.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

W dniu 11-03-02 20:53, Andrzej Rosa pisze:
> On 2011-03-02, Paweł<jas@nie.doczekal>  wrote:
>> W dniu 11-03-02 16:45, ds pisze:
>>> Bart Ogryczak wrote:
>>>
>>>>
>>>> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
>>>> instrukcji zaglądać nie musi...
>>>
>>> To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.
>>
>> oczywiście że potrzeba. albo znajomy makówkarz.
>
> W ogóle interfejs dotykowy jest bardzo trudny
ja akurat osx miałem na myśli. kto bez czytania instrukcji domyśli się 
jak zrobić w nim prtscr?


-- 
Paweł

W dniu 11-03-02 21:38, Paweł pisze:

> ja akurat osx miałem na myśli. kto bez czytania instrukcji domyśli się
> jak zrobić w nim prtscr?
Ja akurat domyśliłem się do czego służy program "Grab", nie było to 
trudne :) A skróty klawiszowe są w standardowym helpie, nie trzeba 
żadnego "missing manual" - wystarczy szukać po "zrzut ekranu"

-- 
Grych

W dniu 11-03-02 20:53, Andrzej Rosa pisze:
> W ogóle interfejs dotykowy jest bardzo trudny, przynajmniej z punktu
> widzenia programisty.  Kursor ma zawsze jakiś stan, bo jest umieszczony
> w konkretnym miejscu na ekranie, więc programista jest w stanie po
> prostu przypisać akcję do stanu.  W przypadku interfejsu dotykowego nie
> da się, bo nie ma kursora, więc programista musi zgadywać co użytkownik
> może w danym momencie zrobić i przypisać akcje na zasadzie "co by było
> gdyby".  Jedyną wskazówką jest kontekst, który jest jednak o wiele mniej
> oczywisty niż konkretny stan, szczególnie w sytuacji gdy mamy do
> czynienia z kilkoma aplikacjami jednocześnie.
Akurat w iOS to jest bardzo proste (z punktu widzenia programisty), 
normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej 
obsłużyć suwanie paluchami (drag&drop), a jeszcze troszkę trudniej 
multitouch. Natomiast nie jest to na pewno "bardzo trudne" :)

-- 
Grych

On 2011-03-04, Tomek "Grych" Gryszkiewicz <grych@nospam.tg.pl> wrote:
> W dniu 11-03-02 20:53, Andrzej Rosa pisze:
>> W ogóle interfejs dotykowy jest bardzo trudny, przynajmniej z punktu
>> widzenia programisty.  Kursor ma zawsze jakiś stan, bo jest umieszczony
>> w konkretnym miejscu na ekranie, więc programista jest w stanie po
>> prostu przypisać akcję do stanu.  W przypadku interfejsu dotykowego nie
>> da się, bo nie ma kursora, więc programista musi zgadywać co użytkownik
>> może w danym momencie zrobić i przypisać akcje na zasadzie "co by było
>> gdyby".  Jedyną wskazówką jest kontekst, który jest jednak o wiele mniej
>> oczywisty niż konkretny stan, szczególnie w sytuacji gdy mamy do
>> czynienia z kilkoma aplikacjami jednocześnie.
> Akurat w iOS to jest bardzo proste (z punktu widzenia programisty), 

Bo masz do czynienia z jedną aplikacją na raz?

> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej 
> obsłużyć suwanie paluchami (drag&drop), 

To jest bardzo trudne nawet w przypadku klasycznego kursora.  

> a jeszcze troszkę trudniej 
> multitouch. Natomiast nie jest to na pewno "bardzo trudne" :)

Bo nie wnikasz.  Rozpatrz wszelkie możliwe przypadki kiedy przenosisz
dowolną zawartość bądź akcję z jednej aplikacji do drugiej a dokopiesz
się totalnego galimatiasu.  Jak dodasz do tego brak kursora, czyli brak
informacji skąd co przenosisz, konsekwencje robią się zupełnie
nietrywialne.

Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
Jak masz kursor wiadomo co robić (w tym wypadku nic).  W przypadku
interfejsu dotykowego nie masz kursora, który "zapamięta" że niesiesz
pędzel, nie ma przycisku myszy, który możesz upuścić, więc wszystko
zależy od mocy predykcyjnej programisty, w którą sądząc po tej dyskusji
mam powody powątpiewać... ;-)

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 3/2/11 9:38 PM, Paweł wrote:
> W dniu 11-03-02 20:53, Andrzej Rosa pisze:
>> On 2011-03-02, Paweł<jas@nie.doczekal> wrote:
>>> W dniu 11-03-02 16:45, ds pisze:
>>>> Bart Ogryczak wrote:
>>>>
>>>>>
>>>>> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
>>>>> instrukcji zaglądać nie musi...
>>>>
>>>> To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.
>>>
>>> oczywiście że potrzeba. albo znajomy makówkarz.
>>
>> W ogóle interfejs dotykowy jest bardzo trudny
> ja akurat osx miałem na myśli. kto bez czytania instrukcji domyśli się
> jak zrobić w nim prtscr?

Prawdziwy Polak instrukcji obsługi nie czyta!

OSX:
Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na 
pulpicie.

Windows:
Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint, 
Ctrl+V, zapisz jako...

Na Maczku jednak trochę to łatwiejsze jest...

W dniu 11-03-04 12:33, Tomek "Grych" Gryszkiewicz pisze:
> W dniu 11-03-02 21:38, Paweł pisze:
>
>> ja akurat osx miałem na myśli. kto bez czytania instrukcji domyśli się
>> jak zrobić w nim prtscr?
> Ja akurat domyśliłem się do czego służy program "Grab", nie było to
> trudne :) A skróty klawiszowe są w standardowym helpie, nie trzeba
> żadnego "missing manual" - wystarczy szukać po "zrzut ekranu"
>
help to też manual

-- 
Paweł

W dniu 2011-03-04 20:04, Teo pisze:

>
> OSX:
> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
> pulpicie.
>
> Windows:
> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
> Ctrl+V, zapisz jako...

Narzędzie wycinania, zaznaczyć potrzebny obszar, zapisać. Tak to się 
robi we współczesnych Windows.


-- 
Andrzej Libiszewski; GG: 5289118
"I must rule with eye and claw — as the hawk among lesser birds."

On 3/4/11 8:32 PM, Andrzej Libiszewski wrote:
> W dniu 2011-03-04 20:04, Teo pisze:
>
>>
>> OSX:
>> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
>> pulpicie.
>>
>> Windows:
>> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
>> Ctrl+V, zapisz jako...
>
> Narzędzie wycinania, zaznaczyć potrzebny obszar, zapisać. Tak to się
> robi we współczesnych Windows.

Command + Shift + 4 -> zaznacz obszar i robi się png na pulpicie.
Szybko i przyjemnie.

Andrzej Rosa <bakters@yahoo.com> wrote:
>> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej 
>> obsłużyć suwanie paluchami (drag&drop), 
> To jest bardzo trudne nawet w przypadku klasycznego kursora.  

Dlaczego bardzo trudne? W prostym przypadku na Windowsie, zwłaszcza gdy 
chodzi o .Net może to być kwestia kilku linijek kodu. Niedawno pisałem 
aplikację, która musiała obsługiwać upuszczanie plików i dosłownie 
implementacja samego upuszczenia bez wliczania obsługi danych to były 4 
linie kodu. Podobnie było z przeciąganiem.

-- 
Piotr Borkowski

W dniu 11-03-04 18:26, Andrzej Rosa pisze:
>> Akurat w iOS to jest bardzo proste (z punktu widzenia programisty),
>
> Bo masz do czynienia z jedną aplikacją na raz?
A co ma do tego ilość aplikacji? Eventy przypisane są do obiektów, 
obiekt należy do aplikacji. Tak samo jak w aplikacjach desktopowych, np. 
event "on click".

>
>> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej
>> obsłużyć suwanie paluchami (drag&drop),
>
> To jest bardzo trudne nawet w przypadku klasycznego kursora.
Nie no, bez przesady. Suwanie paluchami w iOS robi się w sposób naprawdę 
niezbyt trudny, są eventy "touches begin" i "touches end", możesz też 
dostać eventy w trakcie suwania, żeby zapisać sobie ścieżkę. To nie 
rocket science :)
Da się to nawet zrobić w javascripcie w Safari, jak masz coś z iOS to 
możesz zobaczyć sobie tutaj:
http://o.sitepen.com/labs/code/iphone/events.html
Działa nawet multitouch :) A kod jest dość banalny.

>
>> a jeszcze troszkę trudniej
>> multitouch. Natomiast nie jest to na pewno "bardzo trudne" :)
>
> Bo nie wnikasz.  Rozpatrz wszelkie możliwe przypadki kiedy przenosisz
> dowolną zawartość bądź akcję z jednej aplikacji do drugiej a dokopiesz
> się totalnego galimatiasu.  Jak dodasz do tego brak kursora, czyli brak
> informacji skąd co przenosisz, konsekwencje robią się zupełnie
> nietrywialne.
>
> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
> Jak masz kursor wiadomo co robić (w tym wypadku nic).  W przypadku
> interfejsu dotykowego nie masz kursora, który "zapamięta" że niesiesz
> pędzel, nie ma przycisku myszy, który możesz upuścić, więc wszystko
> zależy od mocy predykcyjnej programisty, w którą sądząc po tej dyskusji
> mam powody powątpiewać... ;-)
>
Nie ma przycisku myszy, ale jest paluch... Łapiesz coś, przesuwasz, 
puszczasz (podnosisz paluch). Niewiele to się różni od złapania myszką.

-- 
Grych

Andrzej Rosa wrote:

> więc wszystko
> zależy od mocy predykcyjnej programisty, w którą sądząc po tej dyskusji
> mam powody powątpiewać... ;-)
> 

To co dla jednego jest relatywnie łatwe dla kogoś innego będzie trudne. Dla 
ciebie jest trudne i ok. Ale nie jest.

-- 
Pozdrawiam
ds

On 04 Mar 2011 17:26:56 GMT, Andrzej Rosa wrote:

[...]

> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
> Jak masz kursor wiadomo co robić (w tym wypadku nic).

To dokładnie tak samo jak z przeciąganiem palcem.


> W przypadku
> interfejsu dotykowego nie masz kursora, który "zapamięta" że niesiesz
> pędzel,

Huh? Andrzej, powiedz, że żartujesz. Właśnie stwierdziłeś, że obsługa
tabletów na desktopie jest w zasadzie jakimś kompletnym chaosem. A to jest
dokładnie to samo (nie licząc takich bajerów jak nachylenie piórka czy
stopnie nacisku). Różnica jest taka, że naciskasz piórkiem na miejsce na
tablecie, a nie palcem na ekranie. Co niczego nie zmienia.


> nie ma przycisku myszy, który możesz upuścić,

Za to jest palec, który możesz podnieść?


-- 
Michał Gancarski

On 2011-03-04, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
> Andrzej Rosa <bakters@yahoo.com> wrote:
>>> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej 
>>> obsłużyć suwanie paluchami (drag&drop), 
>> To jest bardzo trudne nawet w przypadku klasycznego kursora.  
>
> Dlaczego bardzo trudne? W prostym przypadku na Windowsie, zwłaszcza gdy 
> chodzi o .Net może to być kwestia kilku linijek kodu. Niedawno pisałem 
> aplikację, która musiała obsługiwać upuszczanie plików i dosłownie 
> implementacja samego upuszczenia bez wliczania obsługi danych to były 4 
> linie kodu. Podobnie było z przeciąganiem.

Zaznaczasz parę rubryk w Excellu i upuszczasz do Photoshopa.  Co i gdzie
powinno zostać wklejone?  

Nie wiem jak jest w Windows, ale w Iksach aplikacje komunikują się ze
sobą i na tej podstawie podejmują decyzję co zrobić z zawartością
schowka.  Szczerze powiedziawszy, nie potrafię sobie wyobrazić innego
rozwiązania, ale może czegoś nie rozumiem?

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-03-04, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>>>> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej 
>>>> obsłużyć suwanie paluchami (drag&drop), 
>>> To jest bardzo trudne nawet w przypadku klasycznego kursora.  
>>
>> Dlaczego bardzo trudne? W prostym przypadku na Windowsie, zwłaszcza gdy 
>> chodzi o .Net może to być kwestia kilku linijek kodu. Niedawno pisałem 
>> aplikację, która musiała obsługiwać upuszczanie plików i dosłownie 
>> implementacja samego upuszczenia bez wliczania obsługi danych to były 4 
>> linie kodu. Podobnie było z przeciąganiem.

> Zaznaczasz parę rubryk w Excellu i upuszczasz do Photoshopa.  Co i gdzie
> powinno zostać wklejone?  

To już nie jest kwestia drag and drop tylko właściwej obsługi 
otrzymanych danych.

> Nie wiem jak jest w Windows, ale w Iksach aplikacje komunikują się ze
> sobą i na tej podstawie podejmują decyzję co zrobić z zawartością
> schowka.  Szczerze powiedziawszy, nie potrafię sobie wyobrazić innego
> rozwiązania, ale może czegoś nie rozumiem?

Na najniższym poziomie aplikacje implementują trzy interfejsy OLE: 
IDropSource, IDropTarget i IDataObject oraz wywołują funkcję DoDragDrop 
i RegisterDragDrop. Tak więc nie ma bezpośredniej komunikacji między 
aplikacjami. Przeniesienie danych realizuje OLE. W przypadku WPF lub 
WinForms powyższe już jest zaimplementowane i aplikacja musi tylko 
obsłużyć odpowiednie zdarzenia np. w Winforms dla upuszczania są to 
DragEnter i DragDrop.

-- 
Piotr Borkowski

On 2011-03-05, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
> Andrzej Rosa <bakters@yahoo.com> wrote:
>
>>> Dlaczego bardzo trudne? W prostym przypadku na Windowsie, zwłaszcza gdy 
>>> chodzi o .Net może to być kwestia kilku linijek kodu. Niedawno pisałem 
>>> aplikację, która musiała obsługiwać upuszczanie plików i dosłownie 
>>> implementacja samego upuszczenia bez wliczania obsługi danych to były 4 
>>> linie kodu. Podobnie było z przeciąganiem.
>
>> Zaznaczasz parę rubryk w Excellu i upuszczasz do Photoshopa.  Co i gdzie
>> powinno zostać wklejone?  
>
> To już nie jest kwestia drag and drop tylko właściwej obsługi 
> otrzymanych danych.

Czyli jedyne co chciałeś napisać, to że schowek jest łatwo zrobić?  ;-)

>> Nie wiem jak jest w Windows, ale w Iksach aplikacje komunikują się ze
>> sobą i na tej podstawie podejmują decyzję co zrobić z zawartością
>> schowka.  Szczerze powiedziawszy, nie potrafię sobie wyobrazić innego
>> rozwiązania, ale może czegoś nie rozumiem?
>
> Na najniższym poziomie aplikacje implementują trzy interfejsy OLE: 
> IDropSource, IDropTarget i IDataObject oraz wywołują funkcję DoDragDrop 
> i RegisterDragDrop. Tak więc nie ma bezpośredniej komunikacji między 
> aplikacjami. Przeniesienie danych realizuje OLE. W przypadku WPF lub 
> WinForms powyższe już jest zaimplementowane i aplikacja musi tylko 
> obsłużyć odpowiednie zdarzenia np. w Winforms dla upuszczania są to 
> DragEnter i DragDrop.

Przynajmniej na pierwszy rzut oka wygląda na to, że przynajmniej w
ramach OLE działa to analogicznie.  Za to ma wszelkie prawa działać
gorzej, jak użytkownik przeciągnie coś niezrozumiałego dla OLE.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-03-05, Tomek "Grych" Gryszkiewicz <grych@nospam.tg.pl> wrote:
> W dniu 11-03-04 18:26, Andrzej Rosa pisze:
>>> Akurat w iOS to jest bardzo proste (z punktu widzenia programisty),
>>
>> Bo masz do czynienia z jedną aplikacją na raz?
> A co ma do tego ilość aplikacji? Eventy przypisane są do obiektów, 
> obiekt należy do aplikacji. Tak samo jak w aplikacjach desktopowych, np. 
> event "on click".

To naprawdę nie jest proste.  Z tego co piszesz widać po prostu, że
nigdy nie wniknąłeś głębiej w problem.  Ja osobiście też nie, tylko
kiedyś z nudów wykład na ten temat obejrzałem.  Szczerze polecam zrobić
podobnie...

>>> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej
>>> obsłużyć suwanie paluchami (drag&drop),
>>
>> To jest bardzo trudne nawet w przypadku klasycznego kursora.
> Nie no, bez przesady.

Jak najbardziej bez przesady.  

> Suwanie paluchami w iOS robi się w sposób naprawdę 
> niezbyt trudny, są eventy "touches begin" i "touches end", możesz też 
> dostać eventy w trakcie suwania, żeby zapisać sobie ścieżkę. To nie 
> rocket science :)
> Da się to nawet zrobić w javascripcie w Safari, jak masz coś z iOS to 
> możesz zobaczyć sobie tutaj:
> http://o.sitepen.com/labs/code/iphone/events.html
> Działa nawet multitouch :) A kod jest dość banalny.

Oj, nawet mi się nie chce odpisywać.  Za to przypomniała mi się dyskusja
jak się dzieciaki od Waylanda wymądrzały, jak to wszystko im się uda
lepiej i prościej zrobić...

A bawcie się.  Piwo sobie otworzę, bo popcornu nie lubię. ;-)

>>> a jeszcze troszkę trudniej
>>> multitouch. Natomiast nie jest to na pewno "bardzo trudne" :)
>>
>> Bo nie wnikasz.  Rozpatrz wszelkie możliwe przypadki kiedy przenosisz
>> dowolną zawartość bądź akcję z jednej aplikacji do drugiej a dokopiesz
>> się totalnego galimatiasu.  Jak dodasz do tego brak kursora, czyli brak
>> informacji skąd co przenosisz, konsekwencje robią się zupełnie
>> nietrywialne.
>>
>> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
>> Jak masz kursor wiadomo co robić (w tym wypadku nic).  W przypadku
>> interfejsu dotykowego nie masz kursora, który "zapamięta" że niesiesz
>> pędzel, nie ma przycisku myszy, który możesz upuścić, więc wszystko
>> zależy od mocy predykcyjnej programisty, w którą sądząc po tej dyskusji
>> mam powody powątpiewać... ;-)
>>
> Nie ma przycisku myszy, ale jest paluch... Łapiesz coś,

W jakim sensie "łapiesz".  "Złapałeś" coś w jednej aplikacji, druga
nawet nie musi wiedzieć że coś w ogóle jest "złapane", to tylko
użytkownik myśli że to oczywiste.  

Ale niech tam, powiedzmy "złapałeś" coś niezrozumiałego dla innej
aplikacji.  Teraz w tej innej aplikacji dotykasz Menu.  Co ona ma z tym
zrobić?  Usiłować obsłużyć schowek i się wywalić?  Zignorować schowek i
obsłużyć dotknięcie Menu?  A może poczekać z obsługą schowka aż
użytkownik się przeklika przez Menu?

I tak w *każdej* aplikacji z osobna.

> przesuwasz, 
> puszczasz (podnosisz paluch). Niewiele to się różni od złapania myszką.

Nie masz stanu, masz kontekst.  System musi zgadnąć co użytkownik miał
na myśli.  Każdy programista każdej aplikacji musi być świadom tych
problemów, a najwyraźniej nie jest.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-03-05, ds <ds@bezpoczty.pl> wrote:
> Andrzej Rosa wrote:
>
>> więc wszystko
>> zależy od mocy predykcyjnej programisty, w którą sądząc po tej dyskusji
>> mam powody powątpiewać... ;-)
>> 
>
> To co dla jednego jest relatywnie łatwe dla kogoś innego będzie trudne. Dla 
> ciebie jest trudne i ok. Ale nie jest.

Ja o tyle mam prosto, że w ogóle nie jestem programistą, więc nie mam
problemu z ego.  Ja jestem tylko lekko nabzdryngolonym, wybitnie
inteligentnym i zadowolonym z życia motocyklistą.

Sezon się zaczął! :-)))

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

Andrzej Rosa wrote:

> Ja o tyle mam prosto, że w ogóle nie jestem programistą, więc nie mam
> problemu z ego.  Ja jestem tylko lekko nabzdryngolonym, wybitnie
> inteligentnym i zadowolonym z życia motocyklistą.
> 
> Sezon się zaczął! :-)))

Brrr, jeszcze chyba trochę wcześnie...

:)

-- 
Pozdrawiam
ds

On 3/5/11 6:53 PM, Andrzej Rosa wrote:
> On 2011-03-05, Tomek "Grych" Gryszkiewicz<grych@nospam.tg.pl>  wrote:
>> W dniu 11-03-04 18:26, Andrzej Rosa pisze:
>>>> Akurat w iOS to jest bardzo proste (z punktu widzenia programisty),
>>>
>>> Bo masz do czynienia z jedną aplikacją na raz?
>> A co ma do tego ilość aplikacji? Eventy przypisane są do obiektów,
>> obiekt należy do aplikacji. Tak samo jak w aplikacjach desktopowych, np.
>> event "on click".
>
> To naprawdę nie jest proste.  Z tego co piszesz widać po prostu, że
> nigdy nie wniknąłeś głębiej w problem.  Ja osobiście też nie, tylko
> kiedyś z nudów wykład na ten temat obejrzałem.  Szczerze polecam zrobić
> podobnie...

Zapodaj linka.

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-03-05, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>>
>>>> Dlaczego bardzo trudne? W prostym przypadku na Windowsie, zwłaszcza gdy 
>>>> chodzi o .Net może to być kwestia kilku linijek kodu. Niedawno pisałem 
>>>> aplikację, która musiała obsługiwać upuszczanie plików i dosłownie 
>>>> implementacja samego upuszczenia bez wliczania obsługi danych to były 4 
>>>> linie kodu. Podobnie było z przeciąganiem.
>>
>>> Zaznaczasz parę rubryk w Excellu i upuszczasz do Photoshopa.  Co i gdzie
>>> powinno zostać wklejone?  
>>
>> To już nie jest kwestia drag and drop tylko właściwej obsługi 
>> otrzymanych danych.

> Czyli jedyne co chciałeś napisać, to że schowek jest łatwo zrobić?  ;-)

Łatwo jest zaimplementować obsługę drag and drop.

>>> Nie wiem jak jest w Windows, ale w Iksach aplikacje komunikują się ze
>>> sobą i na tej podstawie podejmują decyzję co zrobić z zawartością
>>> schowka.  Szczerze powiedziawszy, nie potrafię sobie wyobrazić innego
>>> rozwiązania, ale może czegoś nie rozumiem?
>>
>> Na najniższym poziomie aplikacje implementują trzy interfejsy OLE: 
>> IDropSource, IDropTarget i IDataObject oraz wywołują funkcję DoDragDrop 
>> i RegisterDragDrop. Tak więc nie ma bezpośredniej komunikacji między 
>> aplikacjami. Przeniesienie danych realizuje OLE. W przypadku WPF lub 
>> WinForms powyższe już jest zaimplementowane i aplikacja musi tylko 
>> obsłużyć odpowiednie zdarzenia np. w Winforms dla upuszczania są to 
>> DragEnter i DragDrop.

> Przynajmniej na pierwszy rzut oka wygląda na to, że przynajmniej w
> ramach OLE działa to analogicznie.  Za to ma wszelkie prawa działać
> gorzej, jak użytkownik przeciągnie coś niezrozumiałego dla OLE.

OLE nie obchodzi jakie dane zawiera DataObject. To aplikacja ma 
sprawdzić jakie dane są przenoszone i jeśli je obsługuje wybrać 
odpowiedni Effect i obsłużyć dane.

-- 
Piotr Borkowski

In the darkest hour on Fri, 04 Mar 2011 21:19:19 +0100,
Teo <tee9o@onet.pl> screamed:
>>> OSX:
>>> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
>>> pulpicie.
>>>
>>> Windows:
>>> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
>>> Ctrl+V, zapisz jako...
>>
>> Narzędzie wycinania, zaznaczyć potrzebny obszar, zapisać. Tak to się
>> robi we współczesnych Windows.
>
> Command + Shift + 4 -> zaznacz obszar i robi się png na pulpicie.
> Szybko i przyjemnie.

A aktywne okno da się? Coś a'la Alt + Prtsc w Windows.

-- 
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:224B ]
[ 10:43:30 user up 12733 days, 22:38,  1 user, load average: 0.18, 0.00, 0.09 ]

                 New studies show that 100% of all smokers die.

Dnia 06.03.2011 Artur M. Piwko <milusi.pysiaczek@buziaczek.pl> napisał/a:
> In the darkest hour on Fri, 04 Mar 2011 21:19:19 +0100,
> Teo <tee9o@onet.pl> screamed:
>>>> OSX:
>>>> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
>>>> pulpicie.
>>>>
>>>> Windows:
>>>> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
>>>> Ctrl+V, zapisz jako...
>>>
>>> Narzędzie wycinania, zaznaczyć potrzebny obszar, zapisać. Tak to się
>>> robi we współczesnych Windows.
>>
>> Command + Shift + 4 -> zaznacz obszar i robi się png na pulpicie.
>> Szybko i przyjemnie.
>
> A aktywne okno da się? Coś a'la Alt + Prtsc w Windows.

Z pudełka chyba nie ma.
A co do ww to jeszcze dodatkowo trzymając alt kopiowanie zrobi się do
schowka a nie do pliku na pulpit. I łatwiej je pamiętać jako:
command+# i command+$ bo shift jest jako taki bardziej naturalny.

On 2011-03-05, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
> Andrzej Rosa <bakters@yahoo.com> wrote:
>
>>> To już nie jest kwestia drag and drop tylko właściwej obsługi 
>>> otrzymanych danych.
>
>> Czyli jedyne co chciałeś napisać, to że schowek jest łatwo zrobić?  ;-)
>
> Łatwo jest zaimplementować obsługę drag and drop.

Sam mechanizm nigdzie nie jest specjalnie trudny.  

>>> Na najniższym poziomie aplikacje implementują trzy interfejsy OLE: 
>>> IDropSource, IDropTarget i IDataObject oraz wywołują funkcję DoDragDrop 
>>> i RegisterDragDrop. Tak więc nie ma bezpośredniej komunikacji między 
>>> aplikacjami. Przeniesienie danych realizuje OLE. W przypadku WPF lub 
>>> WinForms powyższe już jest zaimplementowane i aplikacja musi tylko 
>>> obsłużyć odpowiednie zdarzenia np. w Winforms dla upuszczania są to 
>>> DragEnter i DragDrop.
>
>> Przynajmniej na pierwszy rzut oka wygląda na to, że przynajmniej w
>> ramach OLE działa to analogicznie.  Za to ma wszelkie prawa działać
>> gorzej, jak użytkownik przeciągnie coś niezrozumiałego dla OLE.
>
> OLE nie obchodzi jakie dane zawiera DataObject. To aplikacja ma 
> sprawdzić jakie dane są przenoszone i jeśli je obsługuje wybrać 
> odpowiedni Effect i obsłużyć dane.

Przecież piszę, że sprowadza się to do tego samego.  Za to nadal nie
wiem co się stanie, jeśli użytkownik przeciągnie coś, czego OLE nie
rozumie.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-03-05, Teo <tee9o@onet.pl> wrote:
> On 3/5/11 6:53 PM, Andrzej Rosa wrote:
>>> A co ma do tego ilość aplikacji? Eventy przypisane są do obiektów,
>>> obiekt należy do aplikacji. Tak samo jak w aplikacjach desktopowych, np.
>>> event "on click".
>>
>> To naprawdę nie jest proste.  Z tego co piszesz widać po prostu, że
>> nigdy nie wniknąłeś głębiej w problem.  Ja osobiście też nie, tylko
>> kiedyś z nudów wykład na ten temat obejrzałem.  Szczerze polecam zrobić
>> podobnie...
>
> Zapodaj linka.

Nie mogę znaleźć.  Jeszcze poszukam, ale nie obiecuję że mi się uda.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-03-05, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>>
>>>> To już nie jest kwestia drag and drop tylko właściwej obsługi 
>>>> otrzymanych danych.
>>
>>> Czyli jedyne co chciałeś napisać, to że schowek jest łatwo zrobić?  ;-)
>>
>> Łatwo jest zaimplementować obsługę drag and drop.

> Sam mechanizm nigdzie nie jest specjalnie trudny.  

To w czym widzisz problem?

>>>> Na najniższym poziomie aplikacje implementują trzy interfejsy OLE: 
>>>> IDropSource, IDropTarget i IDataObject oraz wywołują funkcję DoDragDrop 
>>>> i RegisterDragDrop. Tak więc nie ma bezpośredniej komunikacji między 
>>>> aplikacjami. Przeniesienie danych realizuje OLE. W przypadku WPF lub 
>>>> WinForms powyższe już jest zaimplementowane i aplikacja musi tylko 
>>>> obsłużyć odpowiednie zdarzenia np. w Winforms dla upuszczania są to 
>>>> DragEnter i DragDrop.
>>
>>> Przynajmniej na pierwszy rzut oka wygląda na to, że przynajmniej w
>>> ramach OLE działa to analogicznie.  Za to ma wszelkie prawa działać
>>> gorzej, jak użytkownik przeciągnie coś niezrozumiałego dla OLE.
>>
>> OLE nie obchodzi jakie dane zawiera DataObject. To aplikacja ma 
>> sprawdzić jakie dane są przenoszone i jeśli je obsługuje wybrać 
>> odpowiedni Effect i obsłużyć dane.

> Przecież piszę, że sprowadza się to do tego samego.  Za to nadal nie
> wiem co się stanie, jeśli użytkownik przeciągnie coś, czego OLE nie
> rozumie.

Najwyżej aplikacja docelowa nie obsłuży, nie OLE. Nic się nie stanie. 
Upuszczenie po prostu nie będzie możliwe.

-- 
Piotr Borkowski

On 3/6/11 10:44 AM, Artur M. Piwko wrote:
> In the darkest hour on Fri, 04 Mar 2011 21:19:19 +0100,
> Teo<tee9o@onet.pl>  screamed:
>>>> OSX:
>>>> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
>>>> pulpicie.
>>>>
>>>> Windows:
>>>> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
>>>> Ctrl+V, zapisz jako...
>>>
>>> Narzędzie wycinania, zaznaczyć potrzebny obszar, zapisać. Tak to się
>>> robi we współczesnych Windows.
>>
>> Command + Shift + 4 ->  zaznacz obszar i robi się png na pulpicie.
>> Szybko i przyjemnie.
>
> A aktywne okno da się? Coś a'la Alt + Prtsc w Windows.

Command + Shift + 4 -> spacja - wybierasz okno

Trochę bardziej intuicyjne niż pod Windowsem, bo "widzisz" któremu 
okienku robisz screena.

On 2011-03-06, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
> Andrzej Rosa <bakters@yahoo.com> wrote:
>
>>>> Czyli jedyne co chciałeś napisać, to że schowek jest łatwo zrobić?  ;-)
>>>
>>> Łatwo jest zaimplementować obsługę drag and drop.
>
>> Sam mechanizm nigdzie nie jest specjalnie trudny.  
>
> To w czym widzisz problem?

W kopiowaniu nietrywialnych danych pomiędzy niemożliwymi do przewidzenia
kombinacjami aplikacji.

>>>> Przynajmniej na pierwszy rzut oka wygląda na to, że przynajmniej w
>>>> ramach OLE działa to analogicznie.  Za to ma wszelkie prawa działać
>>>> gorzej, jak użytkownik przeciągnie coś niezrozumiałego dla OLE.
>>>
>>> OLE nie obchodzi jakie dane zawiera DataObject. To aplikacja ma 
>>> sprawdzić jakie dane są przenoszone i jeśli je obsługuje wybrać 
>>> odpowiedni Effect i obsłużyć dane.
>
>> Przecież piszę, że sprowadza się to do tego samego.  Za to nadal nie
>> wiem co się stanie, jeśli użytkownik przeciągnie coś, czego OLE nie
>> rozumie.
>
> Najwyżej aplikacja docelowa nie obsłuży, nie OLE. Nic się nie stanie. 
> Upuszczenie po prostu nie będzie możliwe.

Tak z ciekawości, to dlatego na Windowsie nie da się skopiować
komunikatu błędu i wkleić do Googla?

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-03-05, Michał Gancarski <michal@gancarski.com> wrote:
> On 04 Mar 2011 17:26:56 GMT, Andrzej Rosa wrote:
>
> [...]
>
>> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
>> Jak masz kursor wiadomo co robić (w tym wypadku nic).
>
> To dokładnie tak samo jak z przeciąganiem palcem.

Niedokładnie.  Dokładnie byłoby gdybyś miał dostępne menu kontekstowe,
kilka przycisków i kursor o jasno określonym stanie.

>> W przypadku
>> interfejsu dotykowego nie masz kursora, który "zapamięta" że niesiesz
>> pędzel,
>
> Huh? Andrzej, powiedz, że żartujesz. Właśnie stwierdziłeś, że obsługa
> tabletów na desktopie jest w zasadzie jakimś kompletnym chaosem. A to jest
> dokładnie to samo (nie licząc takich bajerów jak nachylenie piórka czy
> stopnie nacisku). Różnica jest taka, że naciskasz piórkiem na miejsce na
> tablecie, a nie palcem na ekranie. Co niczego nie zmienia.

Zmienia, bo kursor jest zawsze na ekranie i czasami się go klika, a
palec jest zawsze w powietrzu i tylko czasami czegoś na ekranie dotyka.

>> nie ma przycisku myszy, który możesz upuścić,
>
> Za to jest palec, który możesz podnieść?

Możesz podnieść?  Superancki ten twój interfejs, który wymaga trzymania
palca cały czas na ekranie...

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

Andrzej Rosa wrote:

> Możesz podnieść?  Superancki ten twój interfejs, który wymaga trzymania
> palca cały czas na ekranie...

Czasem sami sobie komplikujemy problemy które nie są zbyt skomplikowane. 
Znam trudniejsze rzeczy od drag'n'dropa i multitoucha. I wiem że nawet 
najprostszą rzecz można obciążyć tak że nikt nie dojdzie o co chodzi.

http://www.ifans.com/forums/showthread.php?t=133201
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/DragandDrop/DragandDrop.html

-- 
Pozdrawiam
ds

On 06 Mar 2011 18:33:49 GMT, Andrzej Rosa wrote:

> On 2011-03-05, Michał Gancarski <michal@gancarski.com> wrote:
>> On 04 Mar 2011 17:26:56 GMT, Andrzej Rosa wrote:
>>
>> [...]
>>
>>> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
>>> Jak masz kursor wiadomo co robić (w tym wypadku nic).
>>
>> To dokładnie tak samo jak z przeciąganiem palcem.
> 
> Niedokładnie.  Dokładnie byłoby gdybyś miał dostępne menu kontekstowe,
> kilka przycisków i kursor o jasno określonym stanie.

Czyli jest prościej, bo możliwości mniej. I nie rozumiem w jaki sposób w
dotykowym interfejsie nie ma ustalonego stanu. Dotykasz albo nie dotykasz.
Jeśli dotykasz, to dodatkowo możesz przeciągnąć i tyle. Różnica jedynie
taka, że w multitouchach może się to dziać w kilku miejscach.


>>> W przypadku
>>> interfejsu dotykowego nie masz kursora, który "zapamięta" że niesiesz
>>> pędzel,
>>
>> Huh? Andrzej, powiedz, że żartujesz. Właśnie stwierdziłeś, że obsługa
>> tabletów na desktopie jest w zasadzie jakimś kompletnym chaosem. A to jest
>> dokładnie to samo (nie licząc takich bajerów jak nachylenie piórka czy
>> stopnie nacisku). Różnica jest taka, że naciskasz piórkiem na miejsce na
>> tablecie, a nie palcem na ekranie. Co niczego nie zmienia.
> 
> Zmienia, bo kursor jest zawsze na ekranie i czasami się go klika, a
> palec jest zawsze w powietrzu i tylko czasami czegoś na ekranie dotyka.

No i? W jaki sposób to komplikuje? Co daje "ciągła obecność kursora na
ekranie"? Nic. W znakomitej większości przypadków liczą się tylko momenty,
w których wciśnięty jest przycisk myszy, co jest równoważne z dotknięciem
palcem.


>>> nie ma przycisku myszy, który możesz upuścić,
>>
>> Za to jest palec, który możesz podnieść?
> 
> Możesz podnieść?  Superancki ten twój interfejs, który wymaga trzymania
> palca cały czas na ekranie...

No właśnie nie wymaga, bo można podnieść palec.


-- 
Michał Gancarski

W dniu 11-03-05 18:53, Andrzej Rosa pisze:
> To naprawdę nie jest proste.  Z tego co piszesz widać po prostu, że
> nigdy nie wniknąłeś głębiej w problem.  Ja osobiście też nie, tylko
> kiedyś z nudów wykład na ten temat obejrzałem.  Szczerze polecam zrobić
> podobnie...
Naprawdę nie rozumiem w czym widzisz problem. Chodzi Ci o to, w jaki 
sposób system wysyła te eventy do programu? W to też nie wnikałem, nawet 
nie obejrzałem z nudów wykładu. Za to napisałem parę aplikacji na iOS, 
które obsługują dotykowe eventy. Szczerze polecam zrobić podobnie...

>
>>>> normalnie przypisujesz eventy do konkretnych obiektów. Trochę trudniej
>>>> obsłużyć suwanie paluchami (drag&drop),
>>>
>>> To jest bardzo trudne nawet w przypadku klasycznego kursora.
>> Nie no, bez przesady.
>
> Jak najbardziej bez przesady.
>
>> Suwanie paluchami w iOS robi się w sposób naprawdę
>> niezbyt trudny, są eventy "touches begin" i "touches end", możesz też
>> dostać eventy w trakcie suwania, żeby zapisać sobie ścieżkę. To nie
>> rocket science :)
>> Da się to nawet zrobić w javascripcie w Safari, jak masz coś z iOS to
>> możesz zobaczyć sobie tutaj:
>> http://o.sitepen.com/labs/code/iphone/events.html
>> Działa nawet multitouch :) A kod jest dość banalny.
>
> Oj, nawet mi się nie chce odpisywać.  Za to przypomniała mi się dyskusja
> jak się dzieciaki od Waylanda wymądrzały, jak to wszystko im się uda
> lepiej i prościej zrobić...
No teraz to z kolei mi nie chce się odpisywać. Naprawdę chciałem 
podyskutować na temat interfejsu dotykowego, bo mam troszkę doświadczeń 
w iOS, ale wolisz robić porównania do wymądrzających się dzieciaków. EOT.

-- 
Grych

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-03-06, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>>
>>>>> Czyli jedyne co chciałeś napisać, to że schowek jest łatwo zrobić?  ;-)
>>>>
>>>> Łatwo jest zaimplementować obsługę drag and drop.
>>
>>> Sam mechanizm nigdzie nie jest specjalnie trudny.  
>>
>> To w czym widzisz problem?
> W kopiowaniu nietrywialnych danych pomiędzy niemożliwymi do przewidzenia
> kombinacjami aplikacji.

To chyba jasne że kopiowane dane muszą być w formacie zrozumiałym przez 
obydwie aplikacje.

>>>>> Przynajmniej na pierwszy rzut oka wygląda na to, że przynajmniej w
>>>>> ramach OLE działa to analogicznie.  Za to ma wszelkie prawa działać
>>>>> gorzej, jak użytkownik przeciągnie coś niezrozumiałego dla OLE.
>>>>
>>>> OLE nie obchodzi jakie dane zawiera DataObject. To aplikacja ma 
>>>> sprawdzić jakie dane są przenoszone i jeśli je obsługuje wybrać 
>>>> odpowiedni Effect i obsłużyć dane.
>>
>>> Przecież piszę, że sprowadza się to do tego samego.  Za to nadal nie
>>> wiem co się stanie, jeśli użytkownik przeciągnie coś, czego OLE nie
>>> rozumie.
>>
>> Najwyżej aplikacja docelowa nie obsłuży, nie OLE. Nic się nie stanie. 
>> Upuszczenie po prostu nie będzie możliwe.

> Tak z ciekawości, to dlatego na Windowsie nie da się skopiować
> komunikatu błędu i wkleić do Googla?

Da się:
[Window Title]
foobar

[Content]
Windows cannot find 'foobar'. Make sure you typed the name correctly, 
and then try again.

[OK]

Use Ctrl+C, Luke.
-- 
Piotr Borkowski

On 2011-03-06, Tomek "Grych" Gryszkiewicz <grych@nospam.tg.pl> wrote:
> W dniu 11-03-05 18:53, Andrzej Rosa pisze:
>> To naprawdę nie jest proste.  Z tego co piszesz widać po prostu, że
>> nigdy nie wniknąłeś głębiej w problem.  Ja osobiście też nie, tylko
>> kiedyś z nudów wykład na ten temat obejrzałem.  Szczerze polecam zrobić
>> podobnie...
> Naprawdę nie rozumiem w czym widzisz problem. Chodzi Ci o to, w jaki 
> sposób system wysyła te eventy do programu?

Częściowo.  Tzn. programowo to się da zrobić i jest to robione często na
sensownym poziomie, ale prawdziwe problemy są z zaprojektowanie
interfejsu w taki sposób, by przetrzymywał interakcję z użytkownikiem
bez istotnych wtop.

> W to też nie wnikałem, nawet 
> nie obejrzałem z nudów wykładu. Za to napisałem parę aplikacji na iOS, 
> które obsługują dotykowe eventy. Szczerze polecam zrobić podobnie...

Po co?  

>>> Suwanie paluchami w iOS robi się w sposób naprawdę
>>> niezbyt trudny, są eventy "touches begin" i "touches end", możesz też
>>> dostać eventy w trakcie suwania, żeby zapisać sobie ścieżkę. To nie
>>> rocket science :)
>>> Da się to nawet zrobić w javascripcie w Safari, jak masz coś z iOS to
>>> możesz zobaczyć sobie tutaj:
>>> http://o.sitepen.com/labs/code/iphone/events.html
>>> Działa nawet multitouch :) A kod jest dość banalny.
>>
>> Oj, nawet mi się nie chce odpisywać.  Za to przypomniała mi się dyskusja
>> jak się dzieciaki od Waylanda wymądrzały, jak to wszystko im się uda
>> lepiej i prościej zrobić...
> No teraz to z kolei mi nie chce się odpisywać. Naprawdę chciałem 
> podyskutować na temat interfejsu dotykowego, bo mam troszkę doświadczeń 
> w iOS, ale wolisz robić porównania do wymądrzających się dzieciaków. EOT.

Co Ty taki delikutaśny jesteś?  To w końcu p.c.o.a, nie szkółka
niedzielna.

BTW - http://www.slideshare.net/ngkabra/understanding-the-touch-interface

Slide 21 
	Problem: No "Select"
	No "Select-Delete"
	No "Select-Copy-Paste"

	Solution: Identify relevant use-cases and come up with workarounds.

Slide 29 - Podobny problem i podobne rozwiązanie.
Slide 32 - Każda aplikacja musi implementować standardowe gesty (a ja od
		   siebie dodam, że powinna również ignorować niestandardowe,
		   ale to na marginesie).
Slide 33 - Kolejny problem wymagający solidnego przemyślenia interfejsu.
Slide 37 - O, facet poparł mój dopisek do Slide 32.
Slide 38 - Każda aplikacja musi być przyzwoicie przemyślana itd.
Slide 40 - Każdy deweloper musi rozumieć "touch".

Innymi słowy, specjalista w tej dziedzinie napisał praktycznie dokładnie
to samo co ja wcześniej w tym wątku, czyli programista musi zgadnąć co
użytkownik może mieć na myśli i wydumać jak to obsłużyć.  W ogóle nie
wnikał w problem obsługi kilku aplikacji na tym samym ekranie, ale dodam
tylko, że w takim wypadku problemy się po prostu mnożą.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-03-06, Michał Gancarski <michal@gancarski.com> wrote:
> On 06 Mar 2011 18:33:49 GMT, Andrzej Rosa wrote:
>
>>>> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
>>>> Jak masz kursor wiadomo co robić (w tym wypadku nic).
>>>
>>> To dokładnie tak samo jak z przeciąganiem palcem.
>> 
>> Niedokładnie.  Dokładnie byłoby gdybyś miał dostępne menu kontekstowe,
>> kilka przycisków i kursor o jasno określonym stanie.
>
> Czyli jest prościej, bo możliwości mniej. I nie rozumiem w jaki sposób w
> dotykowym interfejsie nie ma ustalonego stanu. Dotykasz albo nie dotykasz.

Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
czego masz w tej sytuacji?  

Użytkownik _z kontekstu_ oczekuje, że jak dotknie palcem obszaru na
rysunku to będzie malował dotkniętym _wcześniej_ pędzlem.  Nie oczekuje,
że jak dotknie obszaru poza rysunkiem to też będzie malował.
Programista musi _przewidzieć_ oczekiwania użytkownika i je odgadnąć.
Nie ma kursora o jednoznacznie określonym stanie.

> Jeśli dotykasz, to dodatkowo możesz przeciągnąć i tyle. Różnica jedynie
> taka, że w multitouchach może się to dziać w kilku miejscach.

A to dodatkowy problem, w który w ogóle nie chce mi się wnikać.

>>> Huh? Andrzej, powiedz, że żartujesz. Właśnie stwierdziłeś, że obsługa
>>> tabletów na desktopie jest w zasadzie jakimś kompletnym chaosem. A to jest
>>> dokładnie to samo (nie licząc takich bajerów jak nachylenie piórka czy
>>> stopnie nacisku). Różnica jest taka, że naciskasz piórkiem na miejsce na
>>> tablecie, a nie palcem na ekranie. Co niczego nie zmienia.
>> 
>> Zmienia, bo kursor jest zawsze na ekranie i czasami się go klika, a
>> palec jest zawsze w powietrzu i tylko czasami czegoś na ekranie dotyka.
>
> No i? W jaki sposób to komplikuje?

W taki, że użytkownik podnosząc palec w wielu wypadkach będzie
oczekiwał, że system zapamięta co wcześniej dotknął i zastosuje tę
informację w innym miejscu.  Tak jak to opisałem powyżej, gdzie
dotknięcie pędzla i podniesienie palca ma działać tak samo jak
kliknięcie pędzla i przesunięcie kursora na obszar rysunku.

Innymi słowy, w wielu wypadkach programista musi obsłużyć sekwencję
dotknięć, nie pojedynczą akcję.  Sekwencja ma sens jedynie w konkretnym
kontekście, którego programista musi być świadom.

> Co daje "ciągła obecność kursora na
> ekranie"? Nic. W znakomitej większości przypadków liczą się tylko momenty,
> w których wciśnięty jest przycisk myszy, co jest równoważne z dotknięciem
> palcem.
>
>>>> nie ma przycisku myszy, który możesz upuścić,
>>>
>>> Za to jest palec, który możesz podnieść?
>> 
>> Możesz podnieść?  Superancki ten twój interfejs, który wymaga trzymania
>> palca cały czas na ekranie...
>
> No właśnie nie wymaga, bo można podnieść palec.

Może teraz udało mi się zilustrować przynajmniej niektóre problemy?

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-03-07, Andrzej Rosa <bakters@yahoo.com> wrote:

[...]

> Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
> czego masz w tej sytuacji?  

Kliknąłeś przyciskiem pędzel w paincie i puściłeś. Czym to się różni?

> Użytkownik _z kontekstu_ oczekuje, że jak dotknie palcem obszaru na
> rysunku to będzie malował dotkniętym _wcześniej_ pędzlem.

No to aplikacja na podstawie wybranego wcześniej narzędzie w momencie
(roboczo nazwijmy) ontouch na aktywnym polu (które obsługuje), będzie 
wykonywała akcję przypisaną do wybranego narzędzia.

W czym problem?

> Nie oczekuje, że jak dotknie obszaru poza rysunkiem to też będzie 
> malował.

No i jaki w tym problem?
Programowanie zdarzeniowe nie polega na robieniu pętli wyjątków tylko
na obsłudze konkretnego zdarzenia w konkretnych warunkach. W pozostałych
przypadkach obsługa jest domyślna, przez system.

> Programista musi _przewidzieć_ oczekiwania użytkownika i je odgadnąć.

Po co? Programista ma obsłużyć akcje, które potrzebuje. 
Nic mniej, nic więcej.

> Nie ma kursora o jednoznacznie określonym stanie.

Ale przecież w normalnych aplikacjach to Ci nie jest potrzebne. Po xuj
Ci pozycja kursora myszki jak nic nie wciskasz? Przecież w programach
tego nie śledzisz, bo Ci nie jest to potrzebne. Reagujesz na onclick,
albo na onbuttondown albo onbuttonup i dopiero wtedy odczytujesz 
współrzędne (bo wtedy zazwyczaj Ci potrzebne). Na gładzikach masz to 
samo, tylko musisz prowadzić kursor, bo gładzik sam w sobie nie przekazuje 
prawidłowo pozycji XY względem ekranu.

-- 
Wojciech Bańcer
proteus@post.pl

On 2011-03-07, Wojciech Bancer <proteus@post.pl> wrote:
> On 2011-03-07, Andrzej Rosa <bakters@yahoo.com> wrote:
>
> [...]
>
>> Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
>> czego masz w tej sytuacji?  
>
> Kliknąłeś przyciskiem pędzel w paincie i puściłeś. Czym to się różni?

Kursor zachowuje stan.  Żeby użyć pędzla, muszę go przesunąć na rysunek.
W przypadku interfejsu dotykowego niczego nie przesuwam, więc gubię
stan.

>> Użytkownik _z kontekstu_ oczekuje, że jak dotknie palcem obszaru na
>> rysunku to będzie malował dotkniętym _wcześniej_ pędzlem.
>
> No to aplikacja na podstawie wybranego wcześniej narzędzie w momencie
> (roboczo nazwijmy) ontouch na aktywnym polu (które obsługuje), będzie 
> wykonywała akcję przypisaną do wybranego narzędzia.
>
> W czym problem?

Nie rozumiem.  Na przykładzie.  Dotknąłem pędzla, aplikacja zapamiętała
to dotknięcie, dotykam rysunku i rysuję.  Wszystko pięknie.  Ale gdy
dotykam poza rysunkiem a aplikacja nadal rysuje jest wtopa.  

I dalej w tym samym stylu.  Załóżmy aplikację pełnoekranową, żeby nie
było komplikacji.  Dotknąłem pędzla, aplikacja zapamiętała że ma być
pędzel, po czym dotykam menu.  Aplikacja powinna dać mi się przeklikać
przez menu a mimo to nadal pamiętać, że wyimaginowany kursor ma
przylepiony do niego pędzel.  Nie powinna zapomnieć wybranego narzędzia
zanim użytkownik z niego osobiście nie zrezygnuje.

>> Nie oczekuje, że jak dotknie obszaru poza rysunkiem to też będzie 
>> malował.
>
> No i jaki w tym problem?
> Programowanie zdarzeniowe nie polega na robieniu pętli wyjątków tylko
> na obsłudze konkretnego zdarzenia w konkretnych warunkach. W pozostałych
> przypadkach obsługa jest domyślna, przez system.

Problem w tym, że w przypadku interfejsu dotykowego warunki nie są
konkretne.  Decyduje kontekst, który nie jest konkretem, bo istnieje
głównie w umyśle użytkownika.

Na przykład.  Użytkownik klika w menu, system otwiera menu, użytkownik
klnie.  Dlaczego?  Bo on przecież "dotknął i przeciągnął" a nie "dotknął
menu".  "Komputery są gupie!" 

>> Programista musi _przewidzieć_ oczekiwania użytkownika i je odgadnąć.
>
> Po co? Programista ma obsłużyć akcje, które potrzebuje. 
> Nic mniej, nic więcej.

No i obsłużył proste dotknięcie w sytuacji gdy powinien się domyślić, że
powinien obsłużyć gest.  Albo jak w poprzednim wypadku, obsłużył
malowanie w sytuacji gdy powinien obsłużyć proste dotknięcie.

>> Nie ma kursora o jednoznacznie określonym stanie.
>
> Ale przecież w normalnych aplikacjach to Ci nie jest potrzebne. Po xuj
> Ci pozycja kursora myszki jak nic nie wciskasz?

Jednoznacznie określa kontekst.  Jak kursor jest nad rysunkiem,
pracujemy w paincie.  Jak kursor jest poza rysunkiem, obsługujemy zwykłe
kliknięcia.  Jak kursor jest poza aplikacją, obsługujemy generyczne
zachowanie myszy w systemie.

W przypadku interfejsu dotykowego kontekst trzeba zgadnąć.

> Przecież w programach
> tego nie śledzisz, bo Ci nie jest to potrzebne. Reagujesz na onclick,
> albo na onbuttondown albo onbuttonup i dopiero wtedy odczytujesz 
> współrzędne (bo wtedy zazwyczaj Ci potrzebne). Na gładzikach masz to 
> samo, tylko musisz prowadzić kursor, bo gładzik sam w sobie nie przekazuje 
> prawidłowo pozycji XY względem ekranu.

Jak kursor w ogóle jest, sytuacja się upraszcza.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Rosa"
>>> Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
>>> czego masz w tej sytuacji?  
>> Kliknąłeś przyciskiem pędzel w paincie i puściłeś. Czym to się różni?
>Kursor zachowuje stan.  Żeby użyć pędzla, muszę go przesunąć na rysunek.
>W przypadku interfejsu dotykowego niczego nie przesuwam, więc gubię
>stan.

Rzeco? Aplikacja dostaje od systemu tylko WM_LBUTTONDOWN (czy inszy
odpowiednik). Jak sobie chcesz pamiętać, że wybrałeś jakieś narzędzie,
to twoja sprawa.
Jak klikniesz gdzie indziej, dostaniesz gdzie indziej WM_whatever 

-- 
[------------------------] 
[  Kruk@epsilon.eu.org   ] 
[ http://epsilon.eu.org/ ] 
[------------------------] 

On 2011-03-07, Mariusz Kruk <Mariusz.Kruk@epsilon.eu.org> wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Rosa"
>>>> Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
>>>> czego masz w tej sytuacji?  
>>> Kliknąłeś przyciskiem pędzel w paincie i puściłeś. Czym to się różni?
>>Kursor zachowuje stan.  Żeby użyć pędzla, muszę go przesunąć na rysunek.
>>W przypadku interfejsu dotykowego niczego nie przesuwam, więc gubię
>>stan.
>
> Rzeco? Aplikacja dostaje od systemu tylko WM_LBUTTONDOWN (czy inszy
> odpowiednik). Jak sobie chcesz pamiętać, że wybrałeś jakieś narzędzie,
> to twoja sprawa.
> Jak klikniesz gdzie indziej, dostaniesz gdzie indziej WM_whatever 

Ale rozumiesz, że kursor jest jeden a ludzie mają dwie ręce po pięć 
palców, a do tego czasami wiele osób pracuje przy jednym ogromnym
interfejsie dotykowym?

I co, nadal proste?

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 07 Mar 2011 15:22:56 GMT, Andrzej Rosa wrote:

> On 2011-03-07, Mariusz Kruk <Mariusz.Kruk@epsilon.eu.org> wrote:
>> epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Rosa"
>>>>> Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
>>>>> czego masz w tej sytuacji?  
>>>> Kliknąłeś przyciskiem pędzel w paincie i puściłeś. Czym to się różni?
>>>Kursor zachowuje stan.  Żeby użyć pędzla, muszę go przesunąć na rysunek.
>>>W przypadku interfejsu dotykowego niczego nie przesuwam, więc gubię
>>>stan.
>>
>> Rzeco? Aplikacja dostaje od systemu tylko WM_LBUTTONDOWN (czy inszy
>> odpowiednik). Jak sobie chcesz pamiętać, że wybrałeś jakieś narzędzie,
>> to twoja sprawa.
>> Jak klikniesz gdzie indziej, dostaniesz gdzie indziej WM_whatever 
> 
> Ale rozumiesz, że kursor jest jeden a ludzie mają dwie ręce po pięć 
> palców, a do tego czasami wiele osób pracuje przy jednym ogromnym
> interfejsie dotykowym?
> 
> I co, nadal proste?

Ale rozumiesz, że mysz ma co najmniej dwa przyciski, a najczęściej trzy
plus kółko, a w dodatku mamy klawiaturę z ponad setką klawiszy i wszystko
to może być naciskane jednocześnie w dowolnej liczbie kombinacji?

I co, nadal proste?


-- 
Michał Gancarski

On 2011-03-07, Michał Gancarski <michal@gancarski.com> wrote:
> On 07 Mar 2011 15:22:56 GMT, Andrzej Rosa wrote:
>
>>> Rzeco? Aplikacja dostaje od systemu tylko WM_LBUTTONDOWN (czy inszy
>>> odpowiednik). Jak sobie chcesz pamiętać, że wybrałeś jakieś narzędzie,
>>> to twoja sprawa.
>>> Jak klikniesz gdzie indziej, dostaniesz gdzie indziej WM_whatever 
>> 
>> Ale rozumiesz, że kursor jest jeden a ludzie mają dwie ręce po pięć 
>> palców, a do tego czasami wiele osób pracuje przy jednym ogromnym
>> interfejsie dotykowym?
>> 
>> I co, nadal proste?
>
> Ale rozumiesz, że mysz ma co najmniej dwa przyciski, a najczęściej trzy
> plus kółko, 

Wszystko w tym samym miejscu z punktu widzenia systemu.

> a w dodatku mamy klawiaturę z ponad setką klawiszy i wszystko
> to może być naciskane jednocześnie w dowolnej liczbie kombinacji?
>
> I co, nadal proste?

Jednoznaczne.  

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On Mar 4, 8:04 pm, Teo <te...@onet.pl> wrote:
> On 3/2/11 9:38 PM, Paweł wrote:
>
>
>
>
>
>
>
>
>
> > W dniu 11-03-02 20:53, Andrzej Rosa pisze:
> >> On 2011-03-02, Paweł<j...@nie.doczekal> wrote:
> >>> W dniu 11-03-02 16:45, ds pisze:
> >>>> Bart Ogryczak wrote:
>
> >>>>> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
> >>>>> instrukcji zaglądać nie musi...
>
> >>>> To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.
>
> >>> oczywiście że potrzeba. albo znajomy makówkarz.
>
> >> W ogóle interfejs dotykowy jest bardzo trudny
> > ja akurat osx miałem na myśli. kto bez czytania instrukcji domyśli się
> > jak zrobić w nim prtscr?
>
> Prawdziwy Polak instrukcji obsługi nie czyta!
>
> OSX:
> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
> pulpicie.
>
> Windows:
> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
> Ctrl+V, zapisz jako...

W Windows to jest OotB narzędzie pt.  Snipping Tool
http://en.wikipedia.org/wiki/Snipping_Tool

> Na Maczku jednak trochę to łatwiejsze jest...

Nie jest.  Mac to komputer dla niereformowalych nerdów, w łatwości
obsługi jest lata za Win7, w wygodzie interfejsu lata za KDE.

On 3/8/11 11:49 AM, Bart Ogryczak wrote:
> On Mar 4, 8:04 pm, Teo<te...@onet.pl>  wrote:
>> On 3/2/11 9:38 PM, Paweł wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> W dniu 11-03-02 20:53, Andrzej Rosa pisze:
>>>> On 2011-03-02, Paweł<j...@nie.doczekal>  wrote:
>>>>> W dniu 11-03-02 16:45, ds pisze:
>>>>>> Bart Ogryczak wrote:
>>
>>>>>>> A przecież to takie łatwe, intuicyjne i nikt nigdy do żadnej
>>>>>>> instrukcji zaglądać nie musi...
>>
>>>>>> To że instrukcji nie trzeba nie oznacza że nikt jej nie napisze.
>>
>>>>> oczywiście że potrzeba. albo znajomy makówkarz.
>>
>>>> W ogóle interfejs dotykowy jest bardzo trudny
>>> ja akurat osx miałem na myśli. kto bez czytania instrukcji domyśli się
>>> jak zrobić w nim prtscr?
>>
>> Prawdziwy Polak instrukcji obsługi nie czyta!
>>
>> OSX:
>> Command + Shift + 3 (pod warunkiem, że user zna - wątpię) i robi png na
>> pulpicie.
>>
>> Windows:
>> Prnt Scrn (pod warunkiem, że user wie co to jest - wątpię), paint,
>> Ctrl+V, zapisz jako...
>
> W Windows to jest OotB narzędzie pt.  Snipping Tool
> http://en.wikipedia.org/wiki/Snipping_Tool

OSX ma ootb Graba
http://en.wikipedia.org/wiki/Grab_(software)

>> Na Maczku jednak trochę to łatwiejsze jest...
>
> Nie jest.  Mac to komputer dla niereformowalych nerdów, w łatwości
> obsługi jest lata za Win7, w wygodzie interfejsu lata za KDE.

Nie troluj. OSX jest wygodniejszy.

On Mar 9, 12:29 am, Teo <te...@onet.pl> wrote:

> >> Na Maczku jednak troch to atwiejsze jest...
>
> > Nie jest.  Mac to komputer dla niereformowalych nerd w, w atwo ci
> > obs ugi jest lata za Win7, w wygodzie interfejsu lata za KDE.
>
> Nie troluj. OSX jest wygodniejszy.

Nie jest. Dawno nie widziałem tak spierdolonej obsługi wielu ekranów.
Co za debil wymyślił, żeby cień zmaksymalizowanego okna lewego ekranu
był widoczny na prawym? Albo żeby nie było żadnej wyczuwalnej granicy
między ekranami? Spali na wykładach HCI.

On 3/9/11 10:32 AM, Bart Ogryczak wrote:
> On Mar 9, 12:29 am, Teo<te...@onet.pl>  wrote:
>
>>>> Na Maczku jednak troch to atwiejsze jest...
>>
>>> Nie jest.  Mac to komputer dla niereformowalych nerd w, w atwo ci
>>> obs ugi jest lata za Win7, w wygodzie interfejsu lata za KDE.
>>
>> Nie troluj. OSX jest wygodniejszy.
>
> Nie jest. Dawno nie widziałem tak spierdolonej obsługi wielu ekranów.
> Co za debil wymyślił, żeby cień zmaksymalizowanego okna lewego ekranu
> był widoczny na prawym? Albo żeby nie było żadnej wyczuwalnej granicy
> między ekranami? Spali na wykładach HCI.

Nic takiego nie ma. O której wersji OS X piszesz?

On Mar 20, 2:42 pm, Teo <te...@onet.pl> wrote:
> On 3/9/11 10:32 AM, Bart Ogryczak wrote:
>
> > On Mar 9, 12:29 am, Teo<te...@onet.pl>  wrote:
>
> >>>> Na Maczku jednak troch to atwiejsze jest...
>
> >>> Nie jest.  Mac to komputer dla niereformowalych nerd w, w atwo ci
> >>> obs ugi jest lata za Win7, w wygodzie interfejsu lata za KDE.
>
> >> Nie troluj. OSX jest wygodniejszy.
>
> > Nie jest. Dawno nie widzia em tak spierdolonej obs ugi wielu ekran w.
> > Co za debil wymy li , eby cie zmaksymalizowanego okna lewego ekranu
> > by widoczny na prawym? Albo eby nie by o adnej wyczuwalnej granicy
> > mi dzy ekranami? Spali na wyk adach HCI.
>
> Nic takiego nie ma. O której wersji OS X piszesz?

10.6.6; W ogóle obsługa wielu ekranów w OS X jest totajnie spieprzona,
dlatego, że w ogóle tego nie przewidzieli tworząc MacOS. W normalnych
systemach takich jak Windows, KDE lub Gnome, menu masz przyklejone do
okna, więc problemu nie ma. W OS X odziedziczył z MacOS menu
przylepione do góry ekranu. Jednego ekranu. Zajebiście wygodne, kiedy
menu okna z jednego ekranu jest na drugim ekranie.
Da się "połatać" hackerskimi narzędziami typu SecondBar, ale to
prowizorka, która czasami działa, czasami nie.

epsilon$ while read LINE; do echo \>"$LINE"; done < "Bart Ogryczak"
>10.6.6; W ogóle obsługa wielu ekranów w OS X jest totajnie spieprzona,
>dlatego, że w ogóle tego nie przewidzieli tworząc MacOS. W normalnych
>systemach takich jak Windows, KDE lub Gnome, menu masz przyklejone do
>okna, więc problemu nie ma. W OS X odziedziczył z MacOS menu
>przylepione do góry ekranu. Jednego ekranu. Zajebiście wygodne, kiedy
>menu okna z jednego ekranu jest na drugim ekranie.

O bosz. Aż tak spaprali? W KDE to działa bez problemu. Po prostu pasek
menu jest na każdym ekranie.

-- 
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb 
`b  Kruk@epsilon.eu.org   d' 
d' http://epsilon.eu.org/ Yb 
`b,-,.,-,.,-,.,-,.,-,.,-,.d' 

On Mar 22, 10:50 am, Mariusz Kruk <Mariusz.K...@epsilon.eu.org> wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done < "Bart Ogryczak"
>
> >10.6.6; W ogóle obsługa wielu ekranów w OS X jest totajnie spieprzona,
> >dlatego, że w ogóle tego nie przewidzieli tworząc MacOS. W normalnych
> >systemach takich jak Windows, KDE lub Gnome, menu masz przyklejone do
> >okna, więc problemu nie ma. W OS X odziedziczył z MacOS menu
> >przylepione do góry ekranu. Jednego ekranu. Zajebiście wygodne, kiedy
> >menu okna z jednego ekranu jest na drugim ekranie.
>
> O bosz. Aż tak spaprali? W KDE to działa bez problemu. Po prostu pasek
> menu jest na każdym ekranie.

No więc rzekomą dbałość Apple o ergonomię to można między bajki
włożyć. Zarówno Dock jak i Menu może być tylko na ekranie wybranym
jako główny. Są różne pryszczersko-hackerskie metody jak SecondBar czy
DejaMenu, ale to drapanie się lewą ręką za prawym uchem.  Ogólnie
rzecz biorąc, rozwiązania w tej kwestii mają z czasów MacOS 8, kiedy
to mało kto wielu monitorów używał. Apple ma trudności z zauważeniem,
że mamy rok 2011, a nie 1997.