W dniu 2016-11-17 o 12:50, grapeli23 pisze:

> Jeśli ktoś nie rozumie że to co działa na ekranie dotykowym zadziała
> równie skutecznie na takim bez, to ja podziękuję i mogę życzyć jedynie
> dalszych sukcesów.

ROTFL! Teraz to już naprawdę nie wiem, czy Ty tak na serio, czy
najzwyczajniej w świecie trollujesz...
W takim razie napiszę wprost: nie, nie twierdzę, że program napisany z
myślą o ekranie dotykowym nie odpali się RasPi z LCD bez digitizera.
Słowem kluczowym w tym przypadku jest jednak ergonomia obsługi.
Proponujesz zastosowanie programów, w których połowa ekranu jest zajęta
przez elementy interfejsu dotykowego. I co ja mam niby z tym zrobić?
Myszkę podpiąć?

Wolę napisać swój własny kod. Choćby był dużo skromniejszy pod względem
funkcjonalności, choćby z początku służył jedynie do wyświetlania
informacji odczytywanych z MDP, to przynajmniej będę miał te informacje
wyświetlone na całej powierzchni LCD, a nie tym kawałku, który akurat
nie jest zajmowany przez wirtualne przyciski.

do góry

On 2016-11-17 00:32, Marek wrote:
> On Wed, 16 Nov 2016 21:47:27 +0100, Sebastian Biały<h...@p...onet.pl>
> wrote:
>> Od nie pisania pod Xy.
> Dlaczego? Atlantis chce coś lekkiego, wyczuwam, że chce wykorzysta8
> jakąś grafikę napisaną pod arduino, a tam tylko rysuję się na
> prymitywach. Podstawi wraper x11 i już ma lekkiego klienta.

Ale po co lekki klient na Pi?

>> Weź Qt jesli znasz C/C++.
> Od kiedy w Qt można pisać w C?

Od zawsze można w C z klasami, czyli niepełnym C++.

> Nie ma czegoś takiego jak
> programowanie.C/C++. Albo C albo C++.

C++ to rozwinięcie C i poza patalogiami pisanymi przez idiotów każdy
program w C jest poprawny w C++. Qt stoi w połowie.

> "Specjalistom" od C++ piszącym de
> facto w C dziękujemy.

Ale Qt nie podziękował, dał im do reki MOCa i skończyło się własnie w
połowie.

>> chciał szybko i tanio to w swingu w javie.
> Rotfl, ~ 500 MB jvm w RAMie

a) nie zajmuje tyle
b) nawet jesli zajmuje 40MB to co szkodzi?

Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż
kilka MB za centa.

> by narysować parę kresek

Pare kresek zaczyna być nietrywialnym zagadnieniem kiedy nalezy je
narysować ładnie, równo, ciekawie, elastycznie, wygodnie itp duperele.

do góry

On 2016-11-17 10:48, Atlantis wrote:
>> Jasne, że jest banalne rozwiązanie. Lazarus. Komponenty wrzucasz na
>> formę na zasadzie "drag and drop". Programujesz w Pascalu. Składnia
>> podobna, tyle że bardziej czytelna. Np. w C masz coś takiego jak
>> a||b, w Pascalu (a or b), w C a&&b, w Pascalu (a and b). Co jest
>> bardziej czytelne? W zasadzie cała filozofia języka C i jego klonów,
> Naprawdę nie rozumiem, gdzie problem.

Chebel chyba od dziesięciolecia probuje ewangelizować ludzi że a&&b jest
gorsze niż a and b komplenie nie rozumiejąc istoty lepszośc języków
ktora leży zupełnie gdzie indziej niż w duperelach składniowych.

do góry

On 2016-11-17 10:01, Atlantis wrote:
> Dokładnie. Na chwilę obecną chodzi mi o prosty program, który będzie
> pokazywał na wyświetlaczu aktualny status MPD (aktualny utwór, status
> odtwarzania, głośność, jakiś pasek postępu itp.). Głównie tekst,
> ewentualnie jakaś prosta ikonka.

IMHO nic lepszego i szybszego w programowaniu niż Swing w Javie nie
znajdziesz. Jest mały i nie zajedzie Pi, jak powiedziałem działa na
znacznie gorszym hardware.

Jesli jednak chcesz alternatywnego przepisu to sugeruje tak:

Najmniejszym znanym mi środowiskiem do pisania GUI bedzie wxWidgets.
Pewno jest jakis pakiet wx-dev na Pi. Piszesz na pececie (nawet na
windowsie), kiedy jesteś zadowolony możesz to skompilować na Pi i
cieszyć się działaniem.

WxWidgets ma jeszcze jedną niedocenianą zaletą: ma driver który rysuje
wprost na framebufferze, bez udziąłu managera okien, systemu, widgetów
systemowych itp. Sam rysuje kazdy pixel samodzielnie. Może sie nadać.

Jednak dalej silnie sugeruje Swinga. Nie dośc że developujesz sobie na
PC to jeszcze nic nie trzeba kompilowac na Pi. Odpalasz i działa.
Niewielkim kłopotem może byc jednak dostęp do hardware, musiałbyś opisać
jak to robisz aby ocenić czy z javy się da (a da) i jak.

> W przyszłości ewentualnie dodam do tego jakieś menu. Jednak biorąc pod
> uwagę fakt, że nie mam tam ekranu dotykowego, a do sterowania posłużą
> dwa przyciski i enkoder obrotowy (ewentualnie pilot), nie potrzebuję
> złożonego interfejsu graficznego.

Mimo to rysowanie kresek, fontów, gradiendów itp rzeczy tylko *pozornie*
wydają się łatwe. Na tej grupie bez wątpienia znadziesz na kilogramy
programistów z gatunku "co, ja nie potrafie?" ale nie o to chodzi mam
nadzieję.

> 1) Co powinienem zainstalować pod Raspbianem Lite, żeby mieć możliwość
> rysowania na ekranie przez serwer X, jednak żeby nie zaśmiecić sobie za
> bardzo w systemie. NIE CHCĘ żadnego graficznego ekranu logowania,
> menadżera okien czy ogólnie rozumianego GUI. Innymi słowy: co wpisać po
> "sudo apt-get install"? ;)

Poszukaj X server framebuffer. Powinien jakis być. Po jego instalacji
*nic* sie nie stanie. Jesli chcesz żeby zobaczyc go w pracy: napisz na
konsoli X i naciśnij enter. Jesli Twój FB działa, zobaczysz na ekranie
szachownicę i kursor na środku. Od tego momentu mógłbys już odpalać
aplikacje na tym ekranie.

> 2) Gdzie znajdę jakieś podstawowe przykłady rysowania w ten sposób na
> ekranie? Chodzi mi o ogólny szkielet programu, podstawowe funkcje itp.

Nie rób tego w Xach. Naprawdę, nie chcesz się tym bawić na tak niskim
poziomie. Po to powstały wysokopoziomowe bibloteki.

> 3) Informacja o tym, z którego framebuffera ma korzystać program ma się
> znaleźć w jego kodzie, czy należy go odpalić w jakiś specyficzny sposób?

Załatwia to zmienna env DISPLAY="127.0.0.1:0.0". Co to po dwukropku z
grubsza określa na którym ekranie pojawi się aplikacja która znajdzie
taką zmienną, ale prawie na pewno będzie to 0.0 bo bedzie jeden.

Jak pokazać który fb ma być uzywany przez Xy nie pamiętam. Doszukaj w
docu. Domyślnie odpala się na jedynym dostepnym.

do góry

Użytkownik "Sebastian Biały"

>> Jasne, że jest banalne rozwiązanie. Lazarus. Komponenty wrzucasz na
>> formę na zasadzie "drag and drop". Programujesz w Pascalu. Składnia
>> podobna, tyle że bardziej czytelna. Np. w C masz coś takiego jak
>> a||b, w Pascalu (a or b), w C a&&b, w Pascalu (a and b). Co jest
>> bardziej czytelne? W zasadzie cała filozofia języka C i jego klonów,
> Naprawdę nie rozumiem, gdzie problem.

Chebel chyba od dziesięciolecia probuje ewangelizować ludzi że a&&b jest
gorsze niż a and b komplenie nie rozumiejąc istoty lepszośc języków
ktora leży zupełnie gdzie indziej niż w duperelach składniowych.
---
Czyli gdzie ?

do góry

Użytkownik "Sebastian Biały"

...

>> chciał szybko i tanio to w swingu w javie.
> Rotfl, ~ 500 MB jvm w RAMie

a) nie zajmuje tyle
b) nawet jesli zajmuje 40MB to co szkodzi?

Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż
kilka MB za centa.
---
Ale co Ci to da jak nie pójdzie na mniejszym i słabszym systemie ?

do góry

On 2016-11-17 17:59, re wrote:
>> Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż
>> kilka MB za centa.
> Ale co Ci to da jak nie pójdzie na mniejszym i słabszym systemie ?

Już pisałem że pracowało bez najmniejszego problemu na *znacznie*
mniejszym embedded niz Pi. I jeszcze poganiało engine JS. Twierdzenie że
Java nie pójdzie na Pi uważam za komiczne.

do góry

On 2016-11-17 17:53, re wrote:
> Chebel chyba od dziesięciolecia probuje ewangelizować ludzi że a&&b jest
> gorsze niż a and b komplenie nie rozumiejąc istoty lepszośc języków
> ktora leży zupełnie gdzie indziej niż w duperelach składniowych.
> ---
> Czyli gdzie ?

Na przykład w paradygmatach. Albo w metaprogramowaniu. Albo w
równoległości wbudowanej w język. Albo w biblitekach. Albo w
pierdyliardzie miejsc gdzie są rzeczy istotne z punktu widzenia
programisty. Składnia nie należy do rzeczy specjalnie istotnych (poza
Perlem gdzie nalezy do rzeczy dyskwalifikujących) bo współczesne języki
imperatywne niczym istotnym sie nie różnią.

do góry

Użytkownik "Sebastian Biały"

>> Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż
>> kilka MB za centa.
> Ale co Ci to da jak nie pójdzie na mniejszym i słabszym systemie ?

Już pisałem że pracowało bez najmniejszego problemu na *znacznie*
mniejszym embedded niz Pi. I jeszcze poganiało engine JS. Twierdzenie że
Java nie pójdzie na Pi uważam za komiczne.
---
Ja piszę o testowaniu programów na PC a nie javy na RPi

do góry

On 2016-11-17 20:28, re wrote:
> Użytkownik "Sebastian Biały"
>>> Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż
>>> kilka MB za centa.
>> Ale co Ci to da jak nie pójdzie na mniejszym i słabszym systemie ?
> Już pisałem że pracowało bez najmniejszego problemu na *znacznie*
> mniejszym embedded niz Pi. I jeszcze poganiało engine JS. Twierdzenie że
> Java nie pójdzie na Pi uważam za komiczne.
> Ja piszę o testowaniu programów na PC a nie javy na RPi

Sugerujesz że testowanie na szybszym sprzecie nie ma sensu? Sugerujesz
że należy pisać kod na embedded skoro ma pracować na embedded? Serio?

do góry