wuch + twin = nowa jakosc ?

[Tomasz Kłoczko]

On Tue, 27 Feb 2001, Michal Moskal wrote:
[..]
> > 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 :)
> 
> Wystarczy porównać przejrzystość programów w qt z gtk, żeby się
> przekonać, że "dobrze byłoby" nie jest wystarczającym powodem :)

Wydaje mi się, że nie masz jednak racji. Co wiecej argumenty na poparcie
tego, że tak w istocie moze być są w źródłach twin gdzie w pojedynczym
pliku nagłówkowym jest kompletny wrapper C++. Ważne jest jedno w tym
wypadku, że jezeli chcesz i zależy Ci na tym to w przyapdku implemtacji
podstaw w C możesz napisać aplikację która bedzie miała małe wymagania
pamieciowe. Chcesz pisać w C++ ? proszę bardzo ale dobzre by było
żeby była to wtedy juz kolejna warstwa toolkitu.
Inny wariant jest taki, że piszemy owszem i w C++ ale z pewnymi ramami
które umożliwiałyby taką konstrukcję całości żeby nie trzeba było programu
wynikowego linkować libstdc++ (tak jak to jest np. lftp). Ten sposób
pisania programów jest tylko trochę krępujący, a ma tą zaletę, że
jednoczęśnie przy nienadętym kodzie wynikowym i braku wymagania linkowanai
z C++ runtime umożliwia skorzystanie z tego że program o obiektowej
konstrukcji jest pisany w języku native obiektowym.

Czyli mówiąc inaczje są conajmniej dwa warianty. na razie nie widze
tzreciego (może jeszcze objectiv C ale tu nie znam charakterystyki
efektywności kodu wynikowego generowanego przez gobjc). Turaj runtime ma
około 130KB biblioteki statyczne. Wiem, że są inne implementacje obj C w
włąsną biblioteką podstawową niezalezne od GNU GCC które są jednocześnie
GPL (na icewalkers.com co kwałek pojawiają sie anonse o nowych wersjach).

> Chodzi o to, że interface to sparawa obiektowa. On jest taki z
> natury. A pisanie w C obiektowego kodu jest męczące (jakkolwiek
> nie niemożliwe :).

Ano. Dużo jedmnak zależy od implemtacji.

> Pozatym wsponiałem jeszcze o objective C. Pomysł mi się coraz
> bardziej podoba, język prawdziwie obiektowy (jak smalltalk, 
> a nie C++) i prosty. Hmmm.. ale jeszcze zobaczę.
> 
> > 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ą.
>  
> IMHO tv to nie jest dobry pomysł. Pisałem w nim kiedyś trochę.
> Pod dosem i pod L. Ono jest w wielu miejscach okrojone,
> ze względu na pamięć i procesor.

Nie zauważyłem tego. Rozwiń to. Dla mnie TV było w porównaniu do innych
bibliotek wyjątkowo szybkie.

> O ile mały program jest fajny,
> to scrollbary o długości 64k nie są najlepsze...

Scroll bar to osobny obiekt. Możesz mieć róne scroll bary. Jakie chcesz
mieć ?

> Dzisiejsze kompy są znacznie szybsze.

Też tego tu nie kumam.

> Pozatym jest tam dość dużo drawbackow do x86... hardware karty itp.

Też nei rozumeim tego. co to maja być te drawbacki (?). Prośba rozwiń to
bo nie jest to przynajmniej dla mnie jasne co chcesz pzrez to powiedzieć.

> Anyway są dwie wersje tv pod L.

Tym lepiej.

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*