Slax i RS232

Plik jest mniej elastyczny niż socket. W szczególności socket jest blokujący i to dwukierunkowo.

Toż to w skrypcie bash-a można zrobić. Jakiś mini Python to już byłby super komfort... ale może ktoś lubi kosić trawnik klimatyzowanym kombajnem ;)

Eee tam. Każdy przyzwyczajony do swojego.

Ja to robiłem jeszcze inaczej: read moja_zmienna </dev/cośtam z tym, że komenda musi być zakończona znakiem końca linii... a jeszcze jak "po ludzku" wygląda - np: next_image <enter> to już w ogóle inna rozmowa.

Pan Sebastian Biały napisał:

ImageMagic i 'display' możliwości ma wiele, więc jest się z czym pieścić. Niestety twórcy tych klocków zapomnieli o opcji, o którą aż się prosi do tego typu zastosowań -- wyświetlania nie w oknie, a w root window. Czyli niejako w tle, jak tapeta, bez żadnych ramek. To jest standardowa możliwość programów pisanych pod X11, można jej użyć lub nie. Wygaszacze ekranu zwykle pisze się w ten sposób -- są to normalne programy potrafiące pokazywać te swoje obrazki w okienku, a dopiero wywołane z opcją "--root" (lub podobną) zaczynają się prezentować jak typowy wygaszacz. Proponowany wcześniej xv akurat ma taką opcję.

To jest druga ważna kwestia. Ubijanie procesu po to, by go za chwilę na nowo uruchomić, nie jest najlepszym pomysłem (akademik Grigorij Syzyfow problem ten omawia w swojej głosnej pracy). Ani to porządne rozwiązanie, ani przeważnie nie wygląda ładnie na ekranie w czasie pracy. Chciałoby się, żeby program siedział w pamięci i pokazywał różne obrazki. To jest na tyle częsta potrzeba, że na przykład 'display' ma opcję "-update", która co podaną liczbę sekund czyta obrazek na nowo. Dobre do śledzenia jakichś zmieniających się procesów zapisywanych przez inny program jako grafika, czy choćby do podglądania kamery. Autor programu telak do tego przewidział parametr "refresh" dla każdego obrazka z osobna. Tu znowu widać, że czasem twórcom wyobraźni nie staje, albo zapominają o tym, co w Uniksie łatwo osiągnąć. Aż się prosi, by programy miały umiejętność reagowania na sygnały z zewnątrz. Chiałoby się szturchnąć taki proces sygnałem SIGUSR1 żeby wykonał coś. To "coś", to w najbardziej ogólnym i pożądanym przypadku, to ponowne przeczytanie konfigów lub parametrów i zweryfikowanie zawartych w nich poleceń. Wtedy można działać nie na pałę, co określony czas, ale dokładnie wtedy, kiedy potrzebujemy.

Do telaka wrażliwość na sygnał została dodana, i to błyskawicznie, jak już wspomniałem. Odbyło się to tak szybko, ze nie ma o tym nawet wzmianki w manie, ani w changelog w źródłach, jest tylko w changelog na stronie -- między innymi dlatego o tym teraz piszę. Do ImageMagic też można to oczywiście dopisać, ale do tej pory nikt tego nie zrobił.

Jarek

Mój pokazuje bez ramek na Ubuntu. Gdyby wyłaczyć menagera okien (a i tak by sie oprzydało w dyskutowanym zastosowaniu) to zadziała prawidłowo.

Można więc zrobic lepiej: poszukać procesu, zapamiętać pida, odpalić nowy, zamknąć stary. Jesli oprogramowanie pracuje na czymś lepszym niz kalkulator Bolek, nie zauważysz różnicy.

Rozwiązanie sprawdzi się bez względu na akademickie wywody. W tym przypadku okres wyświetlania obrazu będzie na tyle dlugi że zamortyzuje overheat odpalania procesu.

Nie rózni się to niczym od prawidlowego zamykania i odpalania procesów, jesli nie masz na mysli 50 obrazków na sekunde.

Myslę że w tym wypadku do niczego to nie jest potrzebne. Szyj oprogramowanie na miarę.

Pan Sebastian Biały napisał:

Nie miałem racji -- nie zapomnieli, tylko zrobili to inaczej niż inni. Uruchomienie programu przez "display -window root plik.png" działa nadzwyczaj dobrze -- obraz jest wyświetlony jako tapeta (w root window), a sam 'display' kończy działanie. Więc niczego później nie trzeba ubijać.

I to ma być lepiej?!

Argument z Bolkiem, to już w ogóle do niczego. Chcę *tylko* wyświetlać obrazki, co nawet dla Bolka nie jest ambitnym zadaniem, a mam se kupić maszynę z czterema rdzeniami i akceleratorem graficznym?

Akurat akademickie wywody się tu przydają. Nie można na przykład pominąć tego, co w swoim słynnym podręczniku do fizjologii napisał prof. Widzeń. Telewizory, co teraz na lotniskach wyświetlają odloty i przyloty, na ogół projektowane są przez ludzi, który żadnej tego typu książki nie czytali. Coś się zmienia w rządku cyfr, a ekran nawet nie błyśnie. Trzeba wciąż śledzić co się tam zmieniło. Ale równie często jest inaczej -- zależy nam na możliwie płynnej zmianie. Kolejne obrazy są niemal takie same, zmienia się kilka szczegółów i nic nie może nawet mignąć. Rozwiązanie z odpalaniem na nowo procesu na ogół się nie sprawdza (choć akurat przy 'display' i root window będzie ok).

A jesli mam? Albo jeśli program, to wielka kobyła? Na przykład chciałbym uruchomić firefoksa w root window. I szturchać go sygnałem, żeby robił 'reload' strony. Niestety nie da się, ktoś zapomniał albo olał problem, bo sam uważał, że to bez sensu (albo ja nie potrafię znaleźć rozwiązania).

Autorzy programu myśleli co innego. Jakby nie było potrzebne, to by tego nie zrobili. ImageMagick używam rzadko, więc tego nie pamiętałem. Ale trafiłem na to w dokumentacji pakietu jako sposób na robienia tapety.

Ta zasada sprawdza się u krawców mężczyźnianych. W uniksie lepszą zasadą jest "szyj oprogramowanie na wyrost". Nie chodzi o przerost formy nad treścią, tylko o udostępnianie nic nie kosztujących opcji. Nawet jak ktoś sobie myśli, że "w tym wypadku do niczego to nie jest potrzebne".

Zdefiniuj najpier kryterium "lepiej". IMHO w zastosowaniu o jakim tu rozmawiamy lepiej oznacza prościej. Prościej się chyba nie da.

Dlatego nie widze sensu pisania oprogramowania do czynności która jest osiągalna od ręki w dowolnym unixie. O to całe boje od początku. W dodatku nie widze sensu robienia akademicko poprawnie, skoro problem nie ma żadnych zagadnień związanych z wydajnościa, zajętością pamięci czy czymkolwiek istotnym *akademicko*. Powiedzmy że problem ma być rozwiązany biznesowo: napisać jak najmniej, uzyskać jak najwięcej, nawet jesli to oznacza pogwałcenie wszelkich zasad w tym akademickich. To i tak lepiej niż Lazarus.

Dreptasz w absuradlnym kierunku.

To *nie* ma żadnego związku z tematem bo nie mamy pojęcia jakie to obrazki mamy pokazywać.

Nie wiesz tego.

Nic nie rozumiem, co ma odpalanie procesu z kiepskim designem gui?

To sa inne rozwiązania. Nijak nie pasujące do rozwiązania problemu w tej dyskusji. Ogólnie nie istnieje prawidłowe rozwiązanie wszystkich problemów ludzkości. Do odtwarzania filmów weźmiesz mplayera. Do obrazkow display. Do muzyki mpeg123. Oprogramowanie na miarę, a nie uniwersalne. Uniwersalne zazwyczaj nie pasuje nigdzie.

Ale co to ma wspólnego z czymkolwiek ?

Nie pamiętam aby ktokolwiek dorabiał switcha gdziekolwiek na zaś. Zazwyczaj wiele absuralnych switchy miało uzasadnienie w postaci zarośniętego admina w serwerowni w singapurze który chciał zwiększyć czas na pożeranie pizzy. Być może dlatego do tej pory nie ma jak sensownie skonwertowąc bajta do liczby w bashu. Nikt tego na zapas nie zrobił choć np. programiście wydaje się oczywiste.

Pan Sebastian Biały napisał:

"Lepiej" się nie definiuje, wystarczy definicja "gorzej" i wiadomość, że są to rzeczy przeciwstawne. W tym przypadku prościej, to jest na przykład wysłanie procesu SIGUSR1. W tej chwili wszystkie przeglądarki PDF, PS albo DVI poszły jeszcze dalej -- same śledzą, czy oglądany plik się zmienił, a jeśli tak, to go przeładowują. Owszem, kiedyś tak się pracowało, że się "odpalało nowy viewer i zamykało stary". Ale skoro teraz można jeszcze lepiej i prościej, to czemu nie?

Czemu od razu boje? Miły, sympatyczny człowiek potrzebuje coś zrobić, a sam nie umie, albo ma głupie pomysły, więc prosi o pomoc. Jacyś mu pomagają i coś z tego wychodzi. Nawet bez bólu. Gdzie te boje?

Przepraszam, może to ja sobie sam te założenia gdzieś w głowie dopisałem, ale problem wydał mi się tak podobny do wcześniej rozwiązywanych przeze mnie, że trudno mi się pozbyć skojarzeń. Więc jak coś ma chodzć z flasha sterowane portem seregowym, to zakładam, że będzie na mało wydajnym sprzęcie.

Rozwiązanie biznesowe, to takie, które się powiela w wielu egzemparzach. Może ja i drogi jestem, ale nie aż tak, by moje myślenie było więcej warte niż ileś egzemplarzy pomnożone przez ileś złotych, dolarów, czy nawet orzechów zmarnowanych nie wiadomo po co. Akademicko, to ja se mogę dla siebie, w jednym egzemlarzu, na swoim komputerze na biurku

-- wtedy mogę gwałcić, co tylko zechcę.

Przeważnie.

Lubię takie spacery.

Jak *nie* wiemy, to wszystko ma związek. Gdyby ktoś tu zażądał, by zrobić za niego projekt dokładnie taki jak w opisie i to koniecznie na jutro, to byśmy go słusznie olali. A tak, to sobie możemy o tym i owym pogadać.

A co to ja telewizora na lotnisku nie widziałem? Więc wiem.

Ja też nie rozumiem. Z czym w ogóle ma mież związek "kiepski design gui"?

Dlaczego muszą być inne? Ja częściej niż 'display' używam 'kuickshow'. To są bardzo podobne programy, napisane w tym samym celu. I ja tego używam również do oglądania ruchomych obrazów z kamery, kilkadziesiąt klatek na sekundę, ad hoc tworzących film z poszczególnych plików JPG w katalogu. Wystarczy wcisnąć i przytrzymać klawisz Pg-Up albo Pg-Down. Gdymym trzymał się założeń, że ma być "lepiej i prościej", a do każdego zdjęcia trzeba odpalić nowy proces przeglądarki, to bym guzik zobaczył, a nie film.

A gwoździk w ścianę mogę wbić tylko młotkiem? Bo mosiężna figurka stojąca ma kominku się do tego nie nadaje. Psycholodzy mówią na to "fiksacja funkcjonalna". I pokazuja palcem na mnie jako na najlepszy przykład gościa, który tego nie ma. No więc ja oglądam filmy programem do obrazków i twierdzę, że (w konkretnym przypadku) mplayer się do tego zupełnie nie nadaje.

Perl jest uniwersalny. Da się nim muzyki słuchać. I to nie jak w bash (który też uniwersalny), czyli przez wywołanie programu z zewnątrz, na przykład mpg123.

Program 'convert' pasuje do wszystkich obrazków o formatach znanych innym programom dostępnym w systemi. I można nim konwertować nie posiadając wiedzy tajemnej (do Perla posiadać potrzeba).

Z czymkolwiek, to wszystko ma coś wspólnego (ja też potrafię pisać niekonkretnie, a zwłaszcza lubię dawać niekonkretne odpowiedzi na niekonkretne pytania).

No bo nikt nie *dorabia*, tylko robi się to od razu wszystko, co tylko uda się przewidzieć. Choćby taki program jak "ls", służący do zadawłoby się tak banalnej rzeczy, jak pokazanie plików w katalogu, ma tyle opcji, że ledwie alfabetu starcza. Ja ich oczywiście w większości nie pamiętam.

Mam sentyment do zarośniętych adminów w serwerowniach w Singapurze. Pizzy takiemu nie mam jak kupić, ale jeśli nieużywane przeze mnie opcje programów mogą mu w jego doli ulżyć, to nie mam nic przeciwko nim.

To nie tak. Bash już jest wystarczającą rewolucją w stosunku do wcześniejszego sh. Ale zrobioną jednorazowo. Tak jak nienajlepszym pomysłem jest obcinanie psu ogona po kawałku, żeby się przyzwycził, tak nie jest dobrze dorzucać do programu po jednej możliwości co jakiś czas. To może dobre, jak się chce ludzimom co roku sprzedawać nowego iPhona. Ale porządne programy robi sie inaczej -- najpierw się dłuuugo myśli, a dopiero potem pisze.

Ale gdyby mrugnął cały ekran byłoby jeszcze gorzej - coś się zmieniło a nie wiemy co (ślepota na zmiany czy jakoś tak się to nazywa) Lepiej zauważyć pojedynczą zmianę kiedy reszta ekranu jest statyczna. Jeszcze lepiej byłoby, gdyby zmiany pomrugały sobie z częstotliwością kierunkowskazów przez kilkanaście sekund - wtedy już takie coś przeoczyć jest bardzo trudno.

Pan Mirek napisał:

Ja nie mówię, że ma cały migać. Ani nawet nie doradzam jak to konkretnie ma wyglądać. Ot, można powiedzieć, że czcze krytykanctwo uprawiam. Ale że można i należy to zrobić lepiej, to nie ulega wątpliwości.

Ja się dłuuugo myśli, to może i wyjdzie aplikacja idealna pod każdym względem, lecz okazać się może że:

- przestała być potrzebna, z rozmaitych względów

- lub w międzyczasie konkurencja wypuściła szybciej na rynek aplikację, która się zagnieździła na rynku na dobre, i nikt naszej nie kupi.

Pan DJ napisał:

Nie, na pewno nie wyjdzie idealna, a zwłaszcza pod każdym względem. Ma wyjść porządna.

Kolejny pozytyw. Czasem nawet myśleć nie trzeba, wystarczy trochę poczekać, by ustrzec się przed niepotrzebną pracą.

To jest to "inaczej". Casus iPhone był omówiony w poprzednim zdaniu cytowanej wiadomości -- tutaj nie pasuje.

Jarek