wuch + twin = nowa jakosc ?

[Tomasz Kłoczko]

On Mon, 26 Feb 2001, Paweł Kołodziej wrote:

> Dnia Mon, Feb 26, 2001 at 03:53:44PM +0100, Michal Moskal napisał(a):
> > On Sat, Feb 24, 2001 at 03:53:14PM +0100, Tomasz Kłoczko wrote:
> > > On Fri, 23 Feb 2001, Michal Moskal wrote:
> > > 
> > > > Jakieś maile ma tej ich liście są, ale na pewno
> > > > nie jest to RAD...
> > > 
> > > Oczywiście. Ale mógłbyś napisać *aplikację* pracujacą w tym środowisku
> > > która służyłaby do interakcyjnego projektowania elementów interfejsu pod
> > > twin.
> 
> Nie. to niemożliwe. Autor twina chyba z góry założył, że nikt nie bedzie
> używał jego dzieła, i robi co w jego mocy żeby dopiąć tego celu.

I to mnie trochę dziwi. Z jednej strony jest to ciekawy priojekt i autor
daje do zrozumienia że przydałaby mu się pomoc, a z drugiej strony na
argumenty udziela odpowiedzi "nie, bo nie" albo "nie bo to mi się
niepodoba" podkładajac pod to w zasadzie tylko własne widzimisie.
Szkoda trochę. Jeszcze troche sprawę mozan podrążyć, a jeżeli sie nei da
to zawsze można zrobić fork() bo w końcu projekt jest GPL.

> > > IMHO, najpierw toolkit (ttk?), później builder :)
> > Co do toolkitu, myślałem trochę o tym przez łikend (zamiast
> > kodować, eh...). Dalej nie jestem pewny kilku rzeczy:
> > 1. w jakim języku to pisać, zanim zostanę zakrzyczany, że 
> > w C, imho pisanie jakiegokolwiek gui (text | gfx) w języku
> > obiektowym jest znacznie prostsze. Chodzi o to, że to i
> > tak trzeba pisać obiektowo, a w C trzeba to symulować.
> > Da się (jak widać na przykładzie gtk+), ale nie jest to
> > zbyt czyste/przejrzyste (ten sam przykład). Mam już z grubsza
> > idee jak to napisać w C, ale kilka razy już się zabierałem do
> > textmode ui, kilka razy w C kilka w C++, w C++ naprawde wychodzi
> > prościej. Może objc? (ma tę zaletę, że go nie znam :)
> 
> Brawo za odwage. W sumie C++ to niegłupie. Ale z drugiej strony -- pod X'y
> jest tyle toolkitów w C (nawet poza gtk+) , więc jednak sie da.

Kto wie czy nie byłoby dobrze użyć czegoś na kształt i podobieństwo gob.
Jeżeli nawet to poziom "podłogi" w takim rozwiazaniu dobrze byłoby mieć w
C. I tak na razie jeszcze jest troche do zrobienai po stronie sewera, a
toolkit ewentualny mozan pisać w trakcie (czyli jeszcze na ustalenie
ogónych wytycznych mamy troszkę czasu :)

> Narazie jako większym problemem jawi mi sie osobowość autora (może
> podchodzę do sprawy zbyt emocjonalnie). Kloczek tłumaczy mu że
> autoconf/make bedzie super, i wogóle, sypie argumentami na lewo i
> parawo a makaroniarz odpowiada w stylu "Ja sie tam nieznam. Moze i
> jest to fajne, ale ja roziwjam twina bo to lubie. Autoconfa/make nie
> lubie (bo nie) wiec nie wlacze tego do twina".  Kloczek oferuje mu już
> niemal 24 godzinny support telefoniczny a koles "nie, bo nie".  Na
> moje argumenty w innej sprawie też jest zaskakująco odporny. A czas
> leci...

To musiało być dość zabawne czytając to bo moja angielszczysna jest
chyba więcej niż nieheblowana :)

Tak wogóle co do jego argumentów za buforami per okienko to już dawno
udowodniono teoretycznie i praktycznie także (TurboVision, X11, Win*), że
bufor per okno/gadget jest mniej efektywny/bardziej
pamieciożerny/powodujący więcej kłopotów i to szczególnie przy już średnio
skomplikowanych elementach (jak choćby okienka dialogowe z wieksz.ą ilocią
wigetów. Kiedyś w bibliotekach róznyc analizowałem przypadki przewijanego
okienkadialogowego (kiedy wszystkie elementy nie mieściły się w okiemnku).
W przypadku redtraw było to prosto obsługiwalne gdy tymczasem przy
podejściu z odrysowywaniem całość była przejrzysta i zwarta w
kodzie. Owsze można realizować różne kawałki z cachowaniem jak w X11 ale i
tak X11 to nie to samo char env gdzie objętości tego wszystkiego co jest
przesyłane między displayem i funkcjami odrysowującymi jest o rząd
wielkości conajmniej mniejsza niż w przypadku środowiska graficznego. I
tym bardziej nie ma co wszystkiego kisić po stronie serwera. Owszem prosta
apliakcja typu terminal musi mieć bufor na całe okno ale to wynika z tego,
że emuluje ona w środowisku message passing/display redraw środowisko dla
aplikacjai która nic o takich rzeczach nie wie (choćby mc).

Tak czy inaczej TV jest obiektowe. Licencja an TV jest troche
liberalniejsza niż kiedyś i IMHO możnaby z TV (już nie pamiętam czy
przypadkiem nie ma jakieś mutacji na BSD nawet zczy też sam Borland na
tokową nei zmienił jakiś czas temu) ściagać dość dużymi kawałkami
powołując się co najwyżej że wzorowaliśmy sie na modelu TV. W TV też dość
dobrze jest zrealizowana separacja elementów środowiska od reszty
struktóry programu (co ułatwiało pisanie róznych aplikacji wspomagających
projektowanie elemenów interfejsu), a dodanie do tego gettexta nie będzie
raczej formalnością.

Tak czy inaczej dla mnie jasne są dwie rzeczy, że po pierwsze: ścisła
separacja serwera od możliwie dużego zaplecza dla potencjalnego toolkitu
jest warunkiem podstawowym (po to żeby chocby jak komuś sie nie spodoba
jeden toolkit to niech se pisze inny). I po drugie: jeżeli nie bedzie
można jakoś dojść do porozumienia czy też próby wymiany argumentów
nie zmienią z obecnego rzucania nimi w wode byłbym za fork() (w razie
czego zrobiliśmy co mogliśmy).

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*