Compiz Fusion zniknie, Nomad i Compiz++ włączone do Compiza
- Dodano: 5 lutego 2009
- Wprowadził: Magnes
- Komentarze: 34
Twórcy Compiza zapowiedzieli, że Compiz++ (czyli Compiz w C++) oraz Nomad (odnoga Compiza) zostaną z powrotem włączone do głównego projektu. Podobny los spotka także Compiz Fusion.
Pięcioosobowa Rada Compiza ogłosiła także, że nowe stabilne wydanie, które być może będzie posiadać możliwości Nomada i Compiz++, ukaże się w sierpniu lub wrześniu tego roku.
Więcej informacji: http://www.phoronix.com/scan.php?page=ne...&px=NzAzOQ
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
34 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Jaki język programowania wybiorą? Może jądro będzie C, ale pluginy będą mogły być pisane w C++. Obecnie chyba do Compiza można dodawać rzeczy korzystające z Pythona. C nieco się różni od C++(nie mam teraz na myśli tego, że w C++ są nowe rzeczy). Chyba jednak po utworzeniu kodu obiektowego, da się zlinkować kod w C i C++ ? Raczej wyniknie sporo problemów, jak róznica w nazwach. Dlatego sądzę, że Compiz Core(jego jądro nadal będzie w C).
Lepiej by było odwrotnie. C++, ze względu na kodowanie (ang. mangling) symboli gorzej nadaje się do budowy wtyczek. Natomiast znacznie lepszy jest do całej reszty (nie chcę mi się prowadzić filozoficznych dyskusji — wystarczy powiedzieć, że circa 95% kodu w C kompiluje się jako C++).
Tia, a to co sie nie kompiluje to zazwyczaj niezbyt dobrej jakości kod C(np. złe typy, C++ bardziej restrykcyjnie do tego podchodzi).
Do wtyczek zawsze można użyć w C++ przed deklaracją 'extern "C" ' i ozdobniki znikają.
pure virtual abstract class można używać jako interfejsów w języku C++ – do wtyczek, dynamicznie ładowanych komponentów, pełnym wparciem możliwości rozszerzania i wersjonowania nadaje się to znakomicie i przy tym jest całkiem zgrabne. Nie trzeba z poziomu obiektowego schodzić na proste API w C z extern "C".
Zobaczcie sobie jak to Microsoft zaimplementował w COM (Component Object Model) poszukajcie w necie słów CoCreateObject , IUnknown, IDispatch (dynamiczna inwokacja – dla tzw. późnego wiązania).
Netscape'owy XPCOM używany ciągle przez Mozilla działa identycznie.
Jak jakaś dll'ka, ocx, ax, so, sl exportują mało funkcji to pewnie używa zbioru pure virtual abstract class i funkcji pomocniczych realizujących wzorzec class factory, itd. Biblioteki COM exportują zawsze 5 metod, a jakie to se looknijcie programem Dependency Walker na np.: comdlg32.ocx.
pure virtual abstract class w sensie C++ to klasa, która ma wszystkie metody wirtualne i zerowe:
virtual > >(>) = 0;
Taki czysty VTBL (layout wskaźników na metody)
To samo można oczywiście osiągnąć używają struktur czystego C.
Taki interfejs (pure virtual abstract class) trzeba oczywiście zaimplementować pisząc normalną klasę – można napisać wiele implementacji takiego interfejsu, nowsze implementacje mogą implementować też inne (np.: nowe) interfejsy, co sprzyja rozszerzalności bez utraty zgodności binarnej.
Ja osobiście polecał bym zaznajomienie się z XPCOM (open source, uniplatformowy), KDE lub GNOME używa jakiegoś zaawansowanego mechanizmu opartego chyba na CORBA – no właśnie, przecież w CORBA jest prawie identycznie: jest IDL z którego generuje się interfejsy i a potem się je implementuje klasami zwykłymi i w prawie dowolnym języku.
Sorry, dawno się już tym nie bawię – a skleroza działa.
poprawka bo zjadło:
class {
public:
…
virtual #resultType# #methodName# (#params#) = 0;
…
};
extern "C" nie znikają jeśli chcemy opakować to do innych języków (inaczej zgadujemy jak kompilator C++ przygotuje nam nazwy).
Co do CORBA'y to czy przez przypadek się od tego nie odchodzi? Chyba KDE i GNOME kiedyś z tego korzystały ale potem zrezygnowano.
CORBA generalnie zdechła – w systemach bankowych i podobnych niszowych zastosowaniach się jej (chyba) jeszcze używa. Przy integracji systemów jest to jeden z wariantów, ale został praktycznie wyparty przez technologie XML'owe (WS XML-RPC), lub REST.
Ja używałem MICO i VisiBroker dla C++ i tej wbudowanej w JRE 1.4.2 implementacji dla Java – było to jakieś 6 lat temu.
Protokół komunikacyjny IIOP, który został stworzony na potrzeby CORBA przetrwa myślę dłużej, bo jest zalecanym protokołem (RMI over IIOP) dla zdalnych EJB.
@Sławek
– problematyczne jest tylko linkowanie z asemblerem – plik objektów *.o mają w "C" przez nazwami zmiennych dodane podkreślenie "_" a te z asemblera nie.
Nomad i Compiz++ zostana ponownie włączone do Compiza. A Compiz i Compiz-Fusion zostaną połączone w jeden system. Wspaniałe wieści ;D
Przepraszam, to nie ignorancja, po prostu zagubiłem się już w tych gałęziach, odnogach, fuzjach i powrotach. Jak to w sumie było od początku?
Ja raczej nie słyszałem o Nomad lub Compiz++.
Nie dziwota. Rozwój Compiza to jeden wielki fork:P
Nie jestem pewny ale byl Beryl, i Compiz jako osobne projekty, potem byl Compiz Fusion, czyli wlasnie polaczenie Beryla + Compiz, a dalej juz nie wiem … :/
Sam osobiscie nigdy nie slyszalem czytalem o Compiz++ a tym bardziej o Nomad.
O Compiz++ niedawno było na phoronix-ie, bardzo niedawno temu.
a tego Nomada to nawet w googlach nie mogę znaleźć (nie żebym _bardzo_ szukał)
Tu chodzi o ulepszenia zw. z pulpitem zdalnym itede. Nie żeby było czym się podniecać jeśli chodzi o użytkowników domowych
.
beryl to nie osobny projekt – to odnoga compiza. (-> wiki)
"we sierpniu lub wrześniu tego roku."
a może we listopadzie?
Czy Compiz Fusion oznacza także narzędzia dla niego, typu ccsm, emerald?
Emerald przypadkiem nie został porzucony po drodze gdzieś w krzakach?
Chyba nie, bo mi ciągle działa i jest aktualizowany zdaje się.
mogło by sie jeszcze kwin dołączyć
Przecież kwin to całkiem inna bajka. Kwin nigdy nie miał nic wspólnego z compizem, więc po co miałby dołaczać? Druga kwestia, że kwin raczej stawia na stabilność, a compiz na bajery. Każdy może wybrać to co woli i tak powinno zostać.
A tak w ogóle da się używać kwina bez kde?
Bo o tym myśleli kiedyś programiści kwin-a? Wyszło jednak na to, że łatwiej będzie dodać menadżera kompozycji do kwin-a niż dodanie brakujących funkcji z kwin-a do compiz-a.
Da się. Tak na szybko, to włanczasz przez 'kwin –replace', albo przez ikonkę copiz-fusion, tam masz wybór menagera okien.
Tyle to wiem, ale co z kwestią zarzązdania efektami?
Nie "we sierpniu" tylko "w sierpniu". Czy tu nie ma jakiegoś redaktora?
(I przy okazji – przed "ukaże" w ostatnim zdaniu ma być przecinek)
jest wielu – to obywatelski serwis. Chętnie poczytamy jakiegoś nowego, nieomylnego. Dobrze jeszcze gdyby umiał _czytać_
o compiz++ pisałem już wcześniej np. tu: http://groups.google.pl/group/pl.comp.os.linux/br…
i
http://debian.linux.pl/viewtopic.php?t=12002
Panom programistom chyba bardzo się nie chcę pisać, to dla wymówki co pół roku robią kompletną reorganizację i powstaje kolejny fork…
Co się dziwisz? Welcome to model bazaru. Czy kto ma jeszcze jakieś wątpliwości? Niestety, w tradycyjnym modelu programowania w zespole: za pensję, z organizacją odgórną i deadline'ami deweloperzy nie są od strzelania fochów tylko od pracy. W robocie często się ludzie na wzajem nienawidzą, ale mimo to razem pracują, bo takie mają zadanie. A wolontariat w programowaniu to wieczne obrażanie się na współpracowników i uzytkowników, niełatanie bugów a za to implementowanie pierdół dla frajdy. Nie jest to przypadek, że jedyne jako tako popularne i rozwijające się projekty opensource (Kernel linuksa, Firefox, OpenOffice itd.) to projekty rozwijane modelem katedry?
Od kiedy jądro Linuksa jest rozwijane w modelu katedry? Przecież możesz się w każdej chwili podpiąć pod gita i ściągnąć aktualną wersję od Torvaldsa czy od kogo tam sobie chcesz… To typowy bazar.
Nie jestem programistą. Jaką różnicą dla użytkownika jest ukierunkowanie się na określony język programowania?
Zależy jak na to patrzeć. Jest kilka aspektów i możliwych podejść:
1. Nie ma żadnej różnicy – wszystko na czym zależy użytkownikowi, to to, by aplikacja działała i spełniała wymagania (w tym niefunkcjonalne, takie jak przenośność, licencja itp.). Jeśli to jest spełnione, to nie ma znaczenia, w czym aplikacja jest napisana.
2. Jest różnica z tego punktu widzenia, że niektóre języki są bardziej popularne, inne mniej, co w jakiś sposób przekłada się na wsparcie programistów (w przypadku aplikacji rozwijanych przez społeczności).
3. Jest różnica ze względu na to, że niektóre języki uważane są za łatwiejsze od innych, co może przełożyć się na szybkość rozwoju aplikacji i dostarczania kolejnych wersji.
4. Jest różnica, ponieważ niektóre języki są kompilowane do kodu natywnego, na daną architekturę procesora, niektóre są kompilowane do kodu pośredniego i wymagają osobnych środowisk uruchomieniowych (które trzeba często osobno ściągać i instalować), a niektóre są interpretowane bezpośrednio i należy mieć zainstalowany odpowiedni interpreter. (Oczywiście wiele języków z tej drugiej i trzeciej grupy też można skompilować do postaci natywnej, np. python, ale nie jest to częsty scenariusz).
Generalnie jest temat lekko filozoficzny, więc różne osoby mogą mieć różne poglądy na ten temat i rózne podejścia:)