Odp: Dokumentacja - podstawa to porzadek (trochę offtopic)

[Tomasz Kłoczko]

On Fri, 5 Nov 1999, Radosław Habelski wrote:
[..]
> 10.Czy ktoś uważa ,że jeden interfejs graficzny dla wszystkich dystrybucji
> to zły pomysł ?

Jasne. Każdy ma mieć to co chce, a nie każdy ma mieć to co my chcemy.
Nie widze jakichkolwiek logicznych powodów nastawianai się na jakikolwiek
desktop. Pod GNOME powstaje równie dużo aplikacji co pod KDE (a moze jest
nawet odwrotnie niż Ci sie wydaje).
Zamiast opowiadać o swoich podejrzeniach co do Qt przeczytłabyś wreszcie
licencję na jakiej jest udostępniana ta biblioteka.

Moje osobiste zdanie co do KDE jest takie, że to co robią te aplikacje
możan zrobić w o wiele mniejszej ilości kodu .. czyli szybciej i
efektywniej jeśli chodzi o działającą aplikację.
Niemniej to jest tylko moje zdanie i nie ma ono tutaj znaczenia.

Schemeat skryptów do X session ma yć taki że ma umożliwiać dowolny desktop
czy też pracę ze środowisiem w którym nie ma wogóle DM.
Najprawdopodobniej będzie to też zestaw modularnych skryptów bazujących na
tym co jest w repo w module Xsession.

Już po za tematem .. przyglądał sie ktoś może zapowiedziom rozwoju KDE i
GNOME ?
Moze wnioski jakie udało mi się wyciągnąć:
- ORB:
  - GNOME bazuje na ORBit i ta biblioteka bedzie się rozwijąć dokładnie w
    rytm rosnących potrzeb, a te okazuje się, że wcale nie rosną szybko co
    daje możliwość zachowania zaplecza ORB w bardzo małych rozmiarach,
  - KDE bazuje na mico, które jest maksymalną implementacja specyfikacji
    przez co jest duże, ociężałe i z nadal dużą ilością błędów; ponieważ
    mico jest niewygodne do mniej wymagających zadań zamierza się sięgać
    od RPC do implementacji DCOM, co zapewniać bedzie to, że apliakcje
    wykotrzystujące te mechaizmy bedą miały wrodzone wodogłowie,
- image manipulation,
  - GNOME - odejście od poronionych pomysłów rastermana i budowanie
    zaplecza wokół context drawing zamiast pixbuf drawing oparytego o
    bibliotegkę gdk-pixbuf, która jest o wiele mniejsza niż nawet obecne
    imlib
  - oparcie sie o ImageMagick z dodatkową otoczką do C++. Przypomne, że IM
    jest już obecnie dużo wieksze nić imlib i nadal sie "rozwija".

Z innych rzeczy .. w KDE jest nadal brak infrastruktury porównywalnej
funkconalnością do bonobo z GNOME. Skutek jest tego taki, że każda
apliacja czy też grupa apliacji w KDE ma własne metody wymiany informacji
o obiektach w mniejszym czy też wiekszym sttopniu oparte o ORB. Zapewne
dzieje sie tak dlatego, że mico swoim skomplikowaniem poraża nie jeden
umysł tego czy innego twórcy programów.

GNOME było od początku wspierane przez RH i nie wydaje sie żeby inni
chcieli ten rozwój wspierać ale przyczyna tego stanu jest raczej taka, że
nie ma nikogo innego w okolicy o takiej pozycji jak RH, kto mógłby
wspierać GNOME w podobny sposób. Inna sprawa, to to, że spora ilość
apliacji GNOME rozwija się po za cvs.gnome.org. Jedną z nich (irssi) sami
przygarneliśmy i prawdopodobnie za kawałek będzie druga (netferret).

> ( Nie napisałem tego w celu wywołania wojny,stwierdziłem tylko, że KDE ma na
> razie największe szanse stać się wspólnym interfejsem graficznym)

Spokojnie .. dopóty potrafisz oddzielić własne wrażenia i umiesz spojrzeć
na coś poprzez fakty nigdy nie wywołasz takiej "wojny". Spróbuj jeszcze
raz spojrzeć na te dwi grupy aplikacji poprzez to jak są konstruowane i
jak się rozwiją. Troche pomieszałeś własne odczucia z tym co wiesz, a
raczej czego nie wiesz jeszcze o GNOME/KDE.

> > Patrz słowniki z PTM i grupy polskich tłumaczy GNU.
> > Wiget
> 
> Jak sam napisałeś są to słowniki nie słownik.
> A może by tak zrobić jeden.

Jest słowkik główny i tematyczne. Nie wszyscy potrzebują tych dodatkowych.
Tak to wygląda.

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*