Dwa tygodnie temu wydano GTK+ w wersji 2.90.7, lada moment pojawić się ma trzecie wydanie w wersji stabilnej, porzucające GDK na rzecz Cairo.
Nowa wersja GNOME – 3.0 – zostanie wydana dopiero w marcu przyszłego roku z powodu opóźnienia, które już omawialiśmy. Prace nad GTK+ 3.0 są jednak bardzo zaawansowane i stabilne wydanie ma pojawić się na dniach – 29 września.
Deweloperzy projektu zapewniają, iż GTK+ 3.0 będzie można zainstalować równolegle do 2.x, by dać czas programistom aplikacji wykorzystujących tę bibliotekę na migrację na nową wersję, która jest rozwijana już od kilkunastu miesięcy i obsługiwana przez większość modułów środowiska GNOME.
Ważną informacją dotyczącą GTK+ 3.0 jest to, iż stopniowo projekt przesiada się z GDK do Cairo jeśli chodzi o rysowanie okien. GIMP Drawing Kit od dawna pełnił funkcję pośrednika pomiędzy GTK+, a X Serwerem – teraz sytuacja ulega zmianie. Decyzja odnośnie tej zmiany podyktowana została ulepszeniem semantyki GTK+ i łatwiejszym przenoszeniem aplikacji na inne platformy – biblioteka Cairo jest wieloplatformowa, posiada obsługę back-endu dla Win32 GDI, Mac OS X Quartz oraz OpenGL. Więcej na ten temat mówi na swoim blogu Ben Otte.
Podsumowanie zmian wersji 2.90.7 dostępne jest na liście dyskusyjnej.
Będzie wreszcie kompatybilne z X’em i standardami?
Rozwiń temat.
GTK+ działa na Xach, tak samo, nie potrafię sobie przypomnieć jakiego kolwiek standardu jeśli chodzi o zakres którym zajmuje się GTK+.
http://serwer22962.lh.pl/garsc-informacji-ze-swiata-gnome/#comment-5263932
Poza tym nieprzestrzeganie wielu własność NET_WM_*:
http://standards.freedesktop.org/wm-spec/
Oraz innych standardów freedesktop.org.
Jednym słowem GTK wymaga przeprojektowania i napisania od początku.
Nigdy nie zrozumiem, skąd u osób nie mających pojęcia o danym projekcie zawsze pojawia się idea „przepisania i przeprojektowania”. Gdyby była taka potrzeba, to chyba autorzy/opiekunowie projektu sami by na to wpadli? A może oni wiedzą, że naprawienie kilku widocznych bugów jest łatwiejsze niż przepisywanie 15 letniego kodu, który *działa*?
Anyway, nikt do używania GTK+ nie zmusza. Idź marudzić gdzieś indziej, albo wyślij patche na Bugzillę.
PS nie mylisz GTK+ (toolkit) z Metacity (window manager)?
oO ostatnio już ci wszyscy udowodnili, że bredzisz, a ty dalej swoje. Filmik ci trzeba nakręcić by ci pokazać, że ten błąd istnieje tylko w twojej wyobraźni?
W pierwszym linku jest cos o metacity, w drugim tez nie ma nic o gtk. Z dobrym trollem to i zabawnie pogadac mozna, czasami nawet docenic wiedze, ale ciebie to zal czytac bo zawsze nie na temat.
Tak btw. bo nie jestem na biezaco, co sie stalo z minusami ktore oszczedzaly mi komentarzy oO?
A to ja nie wiedziałem, że wdaję się w dyskusję z nierokującym trollem. Wybaczcie, nie śledzę wszystkich komentarzy. Won’t happen again.
@marcinsud: A moze byc i filmik. Swiezo zainstalowane Ubuntu:
http://yfrog.com/juoutz
😉
Problem z metacity wystepuje. Wylacz Compiz i sprawdz Kadu.
OO: o NetWM już dawno temu dałem ci linka. Twoich problemów z Metacity nie ma nikt inny, więc jeśli go masz to zgłoś do bugzilli.
@mariusz
Dzięki, wyręczyłeś mnie.
Dodam tylko, że zerknąłem w kod Kadu i jest tam zwykłe QWidget::hide() i QWidget::show(). Żadnych udziwnień.
Miałem ten sam problem w przypadku tlena…
@mariusz: u mnie na Ubuntu ten problem z Kadu na Gnome z Compiz nie występuje. Mam też nagrać filmik?
Jest to znany problem z metacity, a nie compizem
@Piotr Drąg: Tok myslenia oO jest bardzo prosty: wedlug niego wrogów ludu nalezy rozstrzelac. W przypadku projektow software’owych rozstrzelac mozna co najwyzej developerow; odpowiednikiem w odniesieniu do kodu jest przepisanie od nowa. Stad to, co napisal powyzej.
@Tomasz Woźniak: to, że u ciebie problem nie występuje nie oznacza, że go nie ma.
@Reddie: no wiem. Ale oznacza to, że wskazane przyczyny nie są wystarczające do odtworzenia błędu.
@Tomasz Woźniak
Metacity, nie Compiz.
Compiz chyba nie ma tego błędu. Wyłącz Compiza i zostaw samo Metacity.
Co nie znaczy, że samo GTK nie kombinuje z tymi parametrami okien.
Bo ono jakoś na Metacity działa. Musi więc robić coś więcej niż czysty X czy Qt.
@iria, oO: wyłączenie compiza nic nie daje. Dalej działa prawidłowo. Nagrać filmik?
Nic nie pisałeś, że wyłączyłeś Compiz i sprawdzałeś na Metacity. Dlatego parę osób zwróciło Ci uwagę. Nie musisz, dla mnie to bez znaczenia.
U mnie ten problem też występuje w Gnome z Kadu na Fedorce.
Rzeczywiście, nie zauważyłem tego – nie używam Kadu. Używam za to Psi na co dzień, w którym (niespodzianka!) wspomniany problem nie występuje. Psi napisane jest w Qt. Słowem, jak się chce to się potrafi. Innymi słowy: złej baletnicy…
@Tomasz Wozniak: Alez ja sie nie upieram, ze kazdemu na kazdym sprzecie nie dziala. U mnie blad wystepowal na archu, na ubuntu i chyba fedorze, przy czym ubuntu jest od razu po instalacji.
@el.pescado: z psi potwierdzam, na linkowanym wyzej ubuntu dziala poprawnie. Az chyba sprawdze w czym problem…
Skoro to Kadu sprawia problemy, to błąd na pewno musi być w GTK+;) Ale żarty na bok, ta dyskusja ciągnie się już bodaj pod trzecim artykułem, czas napisać w końcu coś mądrego. Wbrew temu co twierdzi oO, problem nie leży po stronie konkretnego toolkitu czy menedżera okien. Po prostu, jest to drobny defekt architektury X-ów, sprawiający, że ta akurat czynność (pobieranie położenia okna) staje się dosyć problematyczne. O czym informuje dokumentacja zarówno GTK+:
jak i Qt:
Temat uważam za zamknięty.
Zaraz. Ja nie piszę aplikacji desktopowych, ale tak na logikę, po co toolitowi znajomość położenia okna z dekoracjami? Jeśli chodzi o to, by okno po schowaniu do traya i przywołaniu z powrotem było w tym samym miejscu, to przecież wystarczy pozycja… Cóż, okna. Dekoracje dorysuje menedżer okien i będą takie same jak przedtem. Z pozycją okna bez dekoracji X11 też ma problemy?
Sytuacja: program zamyka swoje okno. Zapamiętuje jego położenie (bez dekoracji). Następnie ponownie chce je otworzyć, przekazując do WM te współrzędne. Ten natomiast bierze pod uwagę dekoracje i okno 'przesuwa’ się o grubość dekoracji.
W sumie głupota i spore przeoczenie, bo funkcje przeliczające z jednych na drugie współrzędne były już w systemach okien daaaawno temu. Takie coś powinno być już dawno dodane do specyfikacji.
@Reddie: to właśnie taka pierdoła, która do oO została rozdmuchana do afery. Technicznie, rzecz polega na tym, że kiedy program otwiera okno, zdarzenie to jest przechwytywane przez menedżer okien, który tworzy nowe okno, którego pierwotne staje się dzieckiem. Tak więc aplikacja ma okno top-level, które tak na prawdę nie jest top-level…
przemo_li: Nie warto. To zabieg logiczny porównywalny z „Czy przestałeś już bić swoją żonę?”.
[OT] Odpowiesz co wynika (wg. logiki) z odpowiedzi „Nie” na tak postawione pytanie?
Pozdrawiam
Kamil
Wynika, że nie przestał.
Co dla inteligentnej osoby znaczy, że albo 1) nadal bije, albo 2) nigdy nie bił, więc nie musiał przestawać.
Ale co mniej inteligentnym wyjdą inne wnioski.
Ja jestem co mniej inteligentnym i wyszło mi, że zapomniałeś:
3) Ktoś bił i przestał i skłamał mówiąc „nie”.
Kiedy całkowicie zniknie GDK i zastąpi je Cairo? 3 To wstęp do tego czy już, definitywne zakończenie?
Kiedy całkowicie zniknie GTK i zastąpi je Qt?
Kiedy całkowicie zniknie Linux i zastąpi go BSD?
Nigdy. Prędzej Linux zastąpi BSD.
No, zaraz po tym, jak wszyscy zaczna uzywac Linuksa na desktopach :->
Linux nie ma już najmniejszych szans zniknąć. Jest używany wszędzie, ogromne firmy w niego zainwestowały ogromne pieniądze. IBM, Novell, RedHat, Canonical, ostatnio Google i Nokia opierając na Linuksie swoje systemy dla komórek, i wiele, wiele innych. Jak na razie to Linux bardzo szybko zdobywa nowe rynki i cały czas się rozwija.
A jakie zaplecze ma BSD? Jedynie Apple używa BSD w macosie nie dając zbyt dużo w zamian. Wystarczy, żeby rynek serwerów przestawił się całkowicie na Linuksa, i BSD nie ma racji bytu.
Nie twierdzę, że BSD ma zniknąć, bo ma się na razie całkiem dobrze.
Ale jeśli miałbym obstawiać, co z tych dwóch zniknie, to na pewno nie będzie to Linux.
@oO: Oczywiscie, ze Linux nie zniknie. Ale znaczenia na desktopach nie nabierze.
A co do BSD – jest uzywane w calej masie urzadzen, glownie w high-endowych appliance’ach. Tyle, ze go nie widac, bo spolecznosc niespecjalnie nastawia sie na „hype” – w efekcie malo kto wie, jaki procent maszyn z TOP500 ma storage serwowany przez pochodną FreeBSD. ;->
A co ma do desktopu IBM, Novell, RedHat, Google i Nokia?! Bo ja zawsze myślałem ze to rynek enterprise i mobile. Zresztą dlaczego rynek serwerów ma się przestawić na linuksa skoro BSD i Windows lepiej się sprawdza, Linux tylko jako serwer WWW (choć nie zawsze) i przeciętnej bazydanych MySQL -czyli taki system na serwer dla Kowalskiego.
Rynek serwerów już dawno przestawił się na Linuksa.
@Reddie: Ale nie calkowicie. Co wiecej, w ciagu ostatnich kilku lat widac trend przeciwny – vide IBM i powrot do promowania AIX-a, czy Oracle i Solaris.
„przeciętnej bazydanych MySQL -czyli taki system na serwer dla Kowalskiego.”
Skoro dla ciebie oracle to przeciętna baza, a sam oracle robi swoje własne distro kompatybilne z rhel, duże centra obliczeniowe to też dla ciebie przeciętne zastosowania?(łącznie z rynkiem CAE)
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Servers
@el.pescado: wprawdzie nie musiałeś podawać źródła na poparcie tego, co napisałem, ale i tak dzięki 😉
@el.pescado: A przeczytałeś czego dotyczą te statystyki? Poskanuj sobie serwisy wwww to będziesz miał wgląd czego używają.
@Edek: no, to wszystko prawda i nie pisałem, że jest inaczej. Tym niemniej teza z komentarza konskiego_pytonga, jakoby świat stał Windowsem i BSD jest, delikatnie mówiąc, bzdurna.
gdzie napisałem ze oracle to kiepska baza danych? tak samo ze cały swiat stoi na serwerach freeBSD i Windows? czytajcie ze zrozumieniem a nie nadinterpretowujecie i szukacie sensacji..
@Reddie && mikolajs: po raz kolejny zaznaczam, że „serwer” != „serwer www”. Jeżeli chodzi o całość serwerów, Linux, niestety, nie jest najpopularniejszym rozwiązaniem. Serwery WWW, z drugiej strony, są niszą Linuksa.
@el.pescado: jeżeli chodzi o całość serwerów to nie wiadomo, jakie jest najpopularniejsze rozwiązanie, bo nie da się tego zmierzyć – co masz opisane w podanym przez siebie linku.
Z kolei trzeba mieć naprawdę spore poczucie humoru, by www nazywać „niszą” 😉
ptaszyno, nie musiałeś.
Za to udowodniłeś, że nie masz pojęcia jaka jest różnica między licencję Oracla a PostgreSQL, a zwłaszcza w kwestii ich kosztów. Od tego momentu stałeś się niepisanym ekspertem w oczach wielu bywalców. 🙂
Fajnie by było, ale niestety niektórzy wolą odkrywać koło na nowo choć i tak im jakies kwadratowe wychodzi 😉
A tak bardziej na temat: w newsie jest poważny błąd merytoryczny. GTK+ 3.0 ma zostać opublikowane w okolicach grudnia 2010, razem z GTK+ 2.24.
W zeszłym tygodniu wydano GTK+ 2.22, a 29 września zostanie opublikowane środowisko GNOME 2.32, oparte właśnie na GTK+ 2.22.
Trochę to skomplikowane. 😉
> posiada obsługę back-endu dla Win32 GDI, Mac OS X Quartz oraz OpenGL
Nie wiem jak z OGL, ale GDK mialo backendy dla windy i maka – taka
zreszta chyba byla idea rozwarstwienia GTK / GDK.
Znow postanowili sobie przeklepac od zera to samo, znow wmawiajac
ludziom ze tym razem to juz na pewno bedzie super-duper?
Kiedy obstawiacie kolejne przepisywanie? Za dwa lata?
Jakie to typowe dla ołpen sors.
To znaczy jaka?
Bo GTK też działa na Win32 i OSX.
Cairo jest zdecydowanie lepsze od GDK. Podstawową i chyba największą zaletą Cairo jest niezależność od rozdzielczości, ale to dopiero początek zalet w porównaniu do GDK.
GDK to taki framework w 'starym stylu’ – porównywalny z GDI w Windows, i wieloma innymi frameworkami mającymi korzenie w latach 80 (np. VDI). Cairo to zupełne inne, nowoczesne, podejście do tematu.
Z GDK jest ten problem, że co prawda chodzi pod OSX i Windows, ale architekturalnie jest bardzo mocna przywiązane do X-ów.
@jarek: Sugerujesz, w projektach closed source nie ma takiej potrzeby? Czy że jest, ale czasami się nie opłaca i brnie się dalej w błoto? Dlaczego uważasz że jest to typowe dla open source (pominę Twoje osobiste frustracje objawiające się ww tym komentarzu kreatywną pisownią – to mniej więcej na poziomie pisania „Mikro$zit”).
GTK+ pod Windowsem działało, jak wcale.
Zauważ też jedno. GDM było biblioteką nie obsługującą wspomagania sprzętowego i rysującą dosyć wolno. GDK wszystko robiło w swojej pamięci, a Cairo część rzeczy stara się przerzucić na system.
jak to nie będzie GDK? Cairo posiada analogiczne odpowiedniki dla „gdk_draw_rgb_image()”, „gdk_draw_indexed_iamge()”, itp.?
Tak odnosnie tej pieknosci: polecam przeczytanie http://blogs.gnome.org/otte/2010/06/26/fun-with-benchmarks/, ze szczegolnym uwzglednieniem wykresow pokazujacych, jak bardzo Cairo z OpenGL moze ssac wydajnosciowo.
😀 czekałem na pierwsze wynurzenia wydajnościowców Cairo 😀
Ale po panu, panie Edwardzie się nie spodziewałem.
Nie zrozum mnie zle – Cairo jest bardzo fajne, i koncepcyjnie (bardzo umiejetna kalka z OSX-owego Quartza), i implementacyjnie. Tylko trzeba ta wydajnosc poprawic – i wydaje mi sie, ze problemem jest nie tylko Cairo, ale tez (a nawet glownie) cala reszta stosu.
panie Edwardzie- ja pana źle nie zrozumiałem, wręcz przeciwnie. Sam jestem pod wrażeniem Cairo, ale zawsze jak ludzie rozpisują się nad jego zaletami, pojawia się ktoś kto pokaże, że w danym teście Cairo jest mało wydajne.
Ot, taki pewniak jak AdBlock na argument przy info o niszowym rynku desktopów Linuksa na statystykach portali www 😀
Co do Cairo… pamiętam pierwszy programik konwertujący SVG na PDF. Odpalam i nic się nie dzieje. W pierwszej chwili wkurzony szukam co skopałem, by po chwili dojść, że on po prostu już skończył.
Czytanie ze zrozumieniem się kłania. Nie Cairo ssie tylko nvidia ze swoim zamkniętym sterownikiem.
Sterownik otwarty ssie rowniez, aczkolwiek – w tych konkretnie testach – mniej. W sensie, nadal z akceleracja jest wolniej, niz bez niej.
na linuksie to powinno się nazywać deceleracja sprzętowa.
kupujesz kartę, na niej siedzi kilkadziesiąt układów simd z zegarem 500MHz+ i otrzymujesz przetwarzanie grafiki wolniejsze niż na intel atom 1.5GHz.
„Czytanie ze zrozumieniem się kłania. Nie Cairo ssie tylko nvidia ze swoim zamkniętym sterownikiem.”
Zwłaszcza, że porównywane są zamknięte stery nvidii i otwarte stery nouveau.
W ogóle to ciekawe, że implementacja na gpu prawie we wszystkich testach jest wolniejsza niż na cpu. Albo linuksowa akceleracja ssie, albo tak dobrze napisali softwareowy renderer. Obstawiam to pierwsze.
Linuksowa akceleracje tak samo ssie jak akceleracja na innych systemach. Przynamniej nvidia. Więc raczej to drugie.
z chęcią bym zobaczył jakikolwiek benchmark na windzie, gdzie gpu będzie gonić ogon cpu.
To weź coś niezoptymalizowanego ale korzystającego z np. D3D i porównaj z dojrzałą biblioteką softwarową. Ot, rewelacja.
wiec konkretów jak nie było tak nie ma.
http://jeffhoogland.blogspot.com/2010/09/linux-out-performs-windows-in-opengl.html
Dla niekumatych, cytat ze strony Cairo:
(wyróżnienie moje)
http://www.phoronix.com/scan.php?page=article&item=781&num=2
Jahaha, Intel FTW xD
Przez chwilę myślałem że padnę. Benchmark arcyciekawy.
> jak bardzo Cairo z OpenGL moze ssac wydajnosciowo
No dobrze: ktoś na serio może odpowiedzieć dlaczego właściwie tak jest? Kto coś spartolił i gdzie? Zepsute są sterowniki, X-serwer, Mesa czy jakieś biblioteki? Co trzeba przepisać?
Po przeczytaniu artykułu źródłowego wychodzi, że GDK wcale nie zostaje porzucone. Porzucona ma być jedynie część GDK odpowiedzialna za rysowanie. Za rysowanie w GTK+ już dzisiaj odpowiada Cairo, więc nie jest to żadna rewolucja.
„Prace nad GTK+ 3.0 są jednak bardzo zaawansowane i stabilne wydanie ma pojawić się na dniach – 29 września.”
Dziś 30 a żadnej wzmianki o wersji 3.0 na stronie projektu nie widać.