tob

[Tomasz Kłoczko]

On Wed, 28 Feb 2001, Michal Moskal wrote:

> On Wed, Feb 28, 2001 at 01:16:19PM +0100, Tomasz Kłoczko wrote:
> > A ja miałbym jeszcze ejdną prośbę .. żeby możliwie blisko trzymać się nazw
> > identyfikatorów z TV. Powody są dwa. Pierwszy (najważniejszy ;-): znam TV
> > i będzie mi łatwiej pisać coś z użyciem tego co zrobimy. Drugi (mniej
> > ważny ;-): innym którzy znaja TV będzie łatwo pisać pod tym co zrobimy i w
> > ten sposób mozemy dość szybko przyczynić się do tego ze zarówno aplikacje
> > z TV jak i inni piszący/znajacy TV szybko poszerzą ilość aplikacji
> > pracujacych pod to środowisko.
> > To jest *bardzo* ważne. W tym sensie radziłbym się w mniejszym stopniu
> > skupiać na opisie interfejsu tego co bedziemy pisać, a raczej w większym
> > stopniu na analizie TV i poprawkach jakiś zauważonych niedogodności
> > czegoś co będzie w efekcie końcowym bardzo bliskie TV jeśli chodzi o
> > interfejs. To podejscie pozwoli znacznie przyśpieszyć prace bo pozwoli
> > założyć że wykonujemy port czegoś co jest dobrze znane i ugruntowane co
> > najwyżej robiać niezbedne naszym zdaniem poprawki.
> 
> Hmmm, nie jestem przekonany. Tzn. w sprawie tej szybkości. 
> Pisanie czegoś od nowa, nie wiem jak innym, ale mi, wychodzi
> szybciej niż adaptacja innych rozwiązań. Nie wiem do końca co chcemy
> osiągnąć. Dalej nie wiemy w jakim to ma być języku. Jeśli mamy
> się wzorować na tv (jeśli dobrze rozumiem) to C++. Nic innego.
> Co do tego, co chcemy osiągnać. TV raczej nie jest przystosowane
> do sieci, okienka obsługuje samo, tu mamy kapke inną sytuację.

Filozofia jest wrecz bardzo bliska tylko chyba tego nie widzisz jeszcze.
Opisze to nieco.
W klasycznym TV, masz cos takiego, że przychodzi do obiektu _kominikat_ o
tym żeby kontrrolka odrysowała się w przekazanym buforze. Zauważ .. żaden
z obiektów TV niegdy nie operuje bezpośrednio na pamieci wideo. To wszytko
jest kompletowane i po wszytkim niskopoziomowa funkacja (już
nieobiektowa) przelewa bufor jednycm ruchem do pamieci wideo. Nic ni
stoi na przeszkodzie tego żeby ta niskopoziomowa funkcja zamait operować
na buforze terminal komunikowała sie z serwerem twin pzrekazujac mu bufor
który twin powinien wrzucić w konkretne miejsce w buforze terminala.

Widzisz to teraz ? :_)

W zasadzie tylko ta jedna niskopoziomowa funkacja musi coś wiedzieć na
temat komunikacji z twin bezpośrednio jezli chodzi o odrysowywanie czegos
na na zdalnie dostepnym terminalu. Reszta pozostać powinna *dokładnie taka
sama* lub tylko nieznacznie zmieniona. Mówiąc inaczej: pełna elegancja bo
cała komunikacja z twin serwerm na potrzeby odrysowywania zwinie sie do
jednego punktu w kodzie toolkitu. W tym sensie jest to znacznie bardziej
eleganckie, spójne i łatwiejsze do kontroli, śledzenia niż w przypadku
tego co próbuje realizować Massimiliano któremu wyjdzie coś co bezie miało
nieokreśloną ilość punktóew styku miedzy klientem i serwerem.

Komunikacja z myszką czy klawiaturą jest realzowana dokładnie tak samo
realizowana. Jest niskopoziomowa nie onbiektowa funkcja komunikująca sie z
twin serwerem i dalej po stronie klienta wciśnięcie myszki i jej pozycja
na ekranie czy też wciśnięty klawisz zamieniane jest na komunikat. Dalej
to sobie wędruje po drzewie aktualnie dizałjacych obiektóe i na podstawie
tego które okno ma focus czy też w jakim punkcie myska został wciśnięta
każdy z obiektów w drzewku sam swierdza czy ów komunikat powinien być
odebrany i zabity czy nie po to żeby inny obiekt w drzewku mógł to
odebrać.

Przy odrysowywaniu kontekstu normalnie masz cos takiego że dostep nie jest
buforowany ale przy okienkach zawierajacych pakrę czy parenaście elementów
możesz dodac blokowanie odrysowaywania wprost na rzecz robienia
wszystkiego w zaalokowanym buforze. po zrobieniu unlock całosć jednym
ruchem jest przekazywana czy to do pamieci video (TV) czy też u nas do
twin serwera. W ten sposób mozesz minimalizowac ilość odowłań do twin
serwera. Dokąłdnie tak samo dział to w X11 czy Windows tyle że Windows tak
jak TV operuje bezposrenio na pamieci wideo i nie ma wastwy w ktrórej
całosć nie jest siciowa. Niemniej wszelkiego rodzaju citrixy czy inne tego
typu rozwiazanai z zdalnym dostępem do displaya pod Win wstzreliwuja sie
tylk ow ten punkt. Mówiac jeszcze inaczej .. zrobić Windows podobne do X11
byłoby niesamowicie prosyto. To, że w MS tego nie zrobili mżna jz uznać
tylko za dokąłdnie zaplanowane i zamierzone działnie obliczone na
nakręcanierynku sprzętu.

Jeszcze jedna uwaga co do bufora to bedzie to tzreba zrobić tak żeby bufor
był unicodowy albo przy stałej długości znaku łatwo tłumaczalny na unicod,
bo wtedy mamyu załatwione sprawy z ramkami, poskimi znakami jak to że
można bedzie wylicząć adres w buforze któremu odpowiada dany znak potem na
ekranie/boforze terminala.

Co do jeszcze TV. To jest naprawdę bardzo dobrze przemysłana biblioteka
bazujaca na opracowanaich opracowanych na kilku uczelniach duużo wcześniej
spreparowanych niż postał Borland C czy Pascal :) (jeszcze przed epoką
Turbo Pascala na CP/M na ośmiobitowce :)
Ten model jest tu naprawdę ładnie zaimplemetowany bedąc jednoczęsnie
naprawde neisamowicie przejrzystym i klarownym. Możan się conajwyżej IMHO
próbować czepaić szczegułów implementacyjnych czy też próbować rozszerzać
niektóre funkcjinalności jakie są w TV ale tak czy inaczje nie pzrewiduję
żeby całosć się mocno zmieniał w momencie kiedy zacniemy to implemetować.

Jeszcze co do języka. C++ wcale nie musi być. Jęzli dałoby sie zrobić
tob-a to w zasadzie nic nie stoi IMHO na przeszkodzie w zaimplemetowaniu
mozę nie tyle wprost TV co modelu jaki implemetuje TV w czymś innym ale
też obiektowym. Po zrobieniu całosci na spodzie nieobiektowo (po
wygenrowaniu tob-em źródeł w C) zrobienie rzeczywistego wrappera do C++
nie powinno być chyba niczym innym jak grupą plików nagłówkowych
zawierajacych odpwoeidnie makra itd.
Poprostu na tym etapie tak czy inaczej nie staraj sie nastawiać do czegoś
aż tak jednoznacznie opozycyjnie 9nawet jezli co do tego wrappera do C++
nie mam racji), bo jeszcze nie zdążyłeś sie odpwoeidnio dobzre zapoznać z
tym co zawiera TV :)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*