Canonical rozważa przejście Ubuntu Mobile na Qt

David Mandala z Canonical na konferencji linux.conf.au opowiadał o przyszłości projektu Ubuntu Mobile. Być może najbardziej obiecująca pełna dystrybucja Linuksa na handheldy zmieni środowisko z GTK na Qt.

Środowisko graficzne w mobilnej wersja Ubuntu to obecnie GNOME Mobile (bazujące na frameworku Hildon). Mandala zapowiada jednak “rozejrzenie się” za alternatywną i wspomniał o “wysiłkach firm takich jak Intel i Nokia w tym rejonie”. Gdy przypomnimy fakt niedawnego wydania biblioteki Qt na licencji LGPL, wydaje się, że Ubuntu Mobile z Qt to poważna alternatywa.

Mandala przyznał, że był zaskoczony decyzją Nokii i dodał, że może zmienić to sporo na rynku. Stwierdził też, że aplikacje na Qt doskonale radzą sobie na małych ekranach urządzeń typu MID czy netbooków.

Pierwsze oficjalnie wspierane wydanie Ubuntu Mobile — Jaunty Jackalope — czeka nas w kwietniu tego roku i będzie jeszcze działać na mobilnym GNOME. Obecnie trwają intensywne prace nad portem systemu na architekturę ARMv7, wykorzystywanym często na małych przenośnych komputerach. Co będzie dalej – zobaczymy. Ale na pewno będzie ciekawie.

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar jellonek
    jellonek

    efl radzi sobie jeszcze lepiej (ten z e17)

    1. Awatar rkowal
      rkowal

      Ale efl jako całość teoretycznie nie jest oznaczona jako stabilna.
      Druga sprawa to, że elf to tylko gui, a qt oznacza dużo więcej.

  2. Awatar mmm
    mmm

    Jestem za QT 🙂 Najlepsza biblioteka.
    Liczba klas robi wrazenie -> i czyni dzieki temu qt biblioteke, ktora moze byc zastosowana od biznesowych po hobbystyczne projekty…

    1. Awatar Królik
      Królik

      Eee tam. Najlepsza to może spośród bibliotek C++.
      Czasy kompilacji czegokolwiek większego niż "Hello world" są masakryczne i nie wiem w ogóle jak można w tym tak się męczyć. Javowy Swing jest IMHO dużo lepszy.

      1. Awatar CeCeron
        CeCeron

        Będziesz kompilował wszystkie aplikacje na mobilnym urządzeniu? 😀

        1. Awatar Królik
          Królik

          Nie, na normalnym 2 rdzeniowym AMD Athlon 3800+ z 2GB RAM czasy budowania projektu są masakryczne, a linkowanie QT się do tego mocno dokłada. Np. taki Amarok buduje się ponad 5 minut. I jeszcze żeby to było tylko przy pełnym buildzie. Nie – zmienisz treść jednego pliku .h i trzeba przekompilowywać pół projektu. 🙁

        2. Awatar tuxmaniak
          tuxmaniak

          Użytkownicy używają aplikacji, a nie je kompilują.

        3. Awatar Królik
          Królik

          Miałem na myśli "najlepsze" z punktu widzenia developera. Bo użytkownikom to wsio ryba.

        4. Awatar tuxmaniak
          tuxmaniak

          Jeśli jakieś biblioteki stwarzają większe możliwości dla programisty (np. zapewniają ustandaryzowane szablony podstawowych funkcjonalności, a nie tylko GUI), to programista może skupić się na budowaniu funkcjonalności aplikacji. Może poświęcić czas i wysiłek na zapewnienie programowi funkcji, na które zwracają uwagę użytkownicy, zamiast borykać się z już rozwiązanymi przez innych programistów problemami, o których użytkownicy często nie mają i nie muszą mieć pojęcia. Dzięki temu, przy użyciu rozbudowanych bibliotek (takich jak Qt, ale tez .NET i Mono), można szybciej i łatwiej osiągnąć cel. To, że zwykli użytkownicy o tym nie wiedzą, nie znaczy, że nie przynosi im to korzyści.

          Właściwie, to kwestie, na które zwróciłem uwagę, mają także ogromne znaczenie dla developerów 🙂

        5. Awatar CeCeron
          CeCeron

          Amarok to nie jest taki mały projekt, 5 minut jakoś mnie (jako początkującego programisty) nie odstrasha. :]

        6. Awatar kwant
          kwant

          Gadacie jak potłuczenie… 5 minut kompiluje się od zera, ale jak zmienisz coś w jednym pliku i rekompiliujesz to jest już błysk bo *.o masz już pogenerowane, robisz tylko jeden brakujący xxx.o i linkujesz wszystko do kupy. Oczywiście jeżeli zmienisz coś w .ui, albo dosz slot/socket to wtedy jest więcej zabawy bo trzeba wygenerować moc_xxx.cpp, no ale bez przesady.

          Qt4 jest naprawdę fajne zrobione. Ma ogromne możliwości, mocno prenośne (własne thread, wsparcie dla opengl i wiele innych fajnych zabawek), dodatkowo całkiem dobry designer do projektowania UI. Z wad to brak jest integracji z dobrym IDE. Intergracja z Eclipse jest beznadziejna (w nietrywialnych projektach trzeba sobie samemu rzeźbić skrypty do wywoływania qmake) w kdevelop nie wiem i jeszcze niedawno wyszło jakieś narzędzie natywne ale w wersji mocno beta. Najbardziej brakuje mi podpowiadania i sprawdzania składni wewnątrz funkcji connect – można tam bzdury nawpisywać i się skompiluje, dopiero w runtime wyrzuca ostrzeżenie na konsolę, że źle jest zbindowany socket z sygnałem)

        7. Awatar mario
          mario

          @kwant: jeszcze pozostaje zmiana pliku nagłówkowego, jak tam coś zmienisz to rekompilujesz wszystkie pliki *.ccp, które go inkudują. Moim zdaniem mechanizm plików nagłówkowych w C++ jest co najmniej głupi, potwornie wydłuża to czas kompilacji.

          Tutaj zgadzam się z Królikiem, API SWINGa jest dużo przyjemniejsze, szkoda, że nie ma takiego GUI dla C++.

          @tuxmaniak: skoro Królik powiedział, że przyjemniej pisze się w SWINGu to chyba pisze w Javie, a w Javie nie ma problemu z podstawowymi klasami, nie tylko do GUI ale do wątków, socketów itp. Niestety brak standardu dla podstawowych w dzisiejszych czasach funkcji bibliotecznych w C++, mocno godzi w przyjemność pisania w tym języku. Obsługa XML, socketów, kilku podstawowych protokołów (HTTP, FTP…), GUI, to w obecnych językach standard – szkoda, że C++ ma tutaj tyły.

        8. Awatar Królik
          Królik

          Nic do QT w sumie nie mam. Bardzo dobra biblioteka, najlepsza moim zdaniem spośród bibliotek C++ do GUI.

          Problemem jest raczej samo C++. Implementacja sygnałów i slotów to sztandarowy przykład słabości C++ i konieczności łatania za pomocą dodatkowego preprocesora. Gdyby C++ miało domknięcia jak Java, to nie potrzeba by było takich hacków. Podobnie kweestia plików nagłówkowych, które w czystym C służą b. dobrze, za to w C++ niestety dotykanie plików *.h zachodzi na tyle często, że staje się to poważnym problemem. Znowu – pokutuje założenie, że składowe prywatne muszą być deklarowane w plikach nagłówkowych. No i żeby toto rozsądnie inline'owało, to trzeba dużo kodu pakować w nagłówki. Razem efekt jest taki, że może kilku minut się nie czeka, ale kilkanaście-kilkadziesiąt sekund owszem i to przy niemal każdej rekompilacji. A to jest strasznie wnerwiające, jak się człowiek przyzwyczaił do Javy/Rubiego/Pythona i takich tam, gdzie można zmieniać kod źródłowy tak, że __bez restartu aplikacji__ widać od razu naniesione zmiany.

          O zarządzaniu pamięcią napisano już setki artykułów. Firefox pisany w C++ ma nadal probemy z fragmentacją i wyciekami pamięci i po pewnym czasie zżera większość RAMu. Dla porównania inna kobyła – Eclipse, zżera dużo, ale cały czas tyle samo. Nie ma problemu z hibernowaniem kompa i używaniem jednej sesji przez np. tydzień.

        9. Awatar mby7930
          mby7930

          "Gdyby C++ miało domknięcia jak Java, to nie potrzeba by było takich hacków."

          Czy mówisz może o "closures"? Myślałem, że dopiero jest planowane ich dodanie do JAVA 7.

        10. Awatar Królik
          Królik

          Java implementuje closures jako klasy anonimowe. Mają pewne ograniczenia i upierdliwości (np. niemożliwość modyfikacji domkniętego kontekstu lokalnego, czy zbytnie rozgadanie składni), niemniej w większości przypadków można z nimi robić wszystko to samo co z closures w Rubym czy Pythonie.

        11. Awatar Królik
          Królik

          A tak w ogóle to nie wiem, czemu temat zszedł na Javę. Swinga można używać z poziomu języków Scala, Nice, Groovy, Jython, JRuby. Wszystkie mają pełną implementację closures i masę innych rzeczy, których Java nie ma.

        12. Awatar jellonek
          jellonek

          to, ze pod cpp po zmianie czegos w "haku" trzeba czekac wieki na przekompilowanie polowy projektu – zawdzieczamy nedznemu kompilatorowi, tkwiacemu w archaicznych standardach – przez co prawie nie wykorzystujacemu "precompiled headers", jak i innym metod cacheowania procesu kompilacji…

        13. Awatar Królik
          Królik

          Nie, to nie jest kwestia kompilatora. Jakbyś kiedyś sam próbował napisać parser C++, to zobaczyłbyś, że jest to bardzo trudne zadanie w porównaniu do np. parsera Pythona, Rubyego czy Javy. Gramatyka C++ nie jest jednoznaczna (ani nawet LL(k)). Efekt jest taki, że
          nie podzielisz kompilacji na osobny etap analizy składniowej i semantycznej, a na dodatek musisz zapewnić implementację nawrotów w samym parserze. Wszystko to bardzo komplikuje i spowalnia kompilację.

          No i do tego te nieszczęsne pliki nagłówkowe powodujące, że do __powolnej__ kompilacji dochodzi druga rzecz: __częsta__ kompilacja.
          Sorry, co Ci da nawet prekompilacja nagłówków, kiedy nagłówki b. często zawierają kod i niewielka zmiana w prywatnej części jakiejś klasy pociąga za sobą przekompilowanie wszystkich plików korzystających z tego nagłówka? Tak samo: co to da, kiedy każda konkretyzacja wzorca innym parametrem to osobna kompilacja całego wzorca dla nowego parametru?

          Dziwnym trafem wszystkie kompilatory C++ kompilują kod koszmarnie wolno, a np. kompilatory Object Pascala, Javy czy D kompilują rzędy wielkości razy szybciej. I jak w Javie dorzucę nową prywatną metodę do jakiejś klasy wykorzystywanej niemal wszędzie, to przekompilowuje mi się tylko ta klasa, a nie pół projektu.

      2. Awatar krzychoocpp
        krzychoocpp

        Javowy Swing ? Tak, rozwiązanie ala "pętla wiadomości" w EventListenerach, zamiast Callbacków GTK+ lub sygnałów i slotów w Qt. Do tego ten cudownie integrujący się z systemem wygląd na wszystkich platformach…

        1. Awatar Królik
          Królik

          Akurat Nimbus L&F integruje się świetnie ze wszystkimi platformami i wygląda b. dobrze. Pod KDE 4.x też. A co do mechanizmu sygnałów i slotów w QT to miałeś na myśli ten hack używający dodatkowego preprocesora?

  3. Awatar m
    m

    Nie oszukujmy się, QT będzie w tym momencie zajmować coraz większy udział na rynku. Nie zdziwiłbym się, gdyby GNOME 3.0 było na QT 😀 GTK nie ma już absolutnie żadnej przewagi nad QT. RH, Novell mogą również zrezygnować z GNOME jako głównego środowiska z tych samych powodów…

    1. Awatar k2
      k2

      QT zawsze było lata świetlne przed GTK

      1. Awatar Jakub
        Jakub

        TO racja, jedyną zaletą GTK+ była licencja… to już jest niebyłe… 🙂 Nadchodzą dobre lata dla Qt, i dobrze bo to soft naprawdę wysokiej jakości!

        1. Awatar mith (lstarba)
          mith (lstarba)

          Tak, zgadzam się z tym. Niedawno pisałem projekt zaliczeniowy na uczelnię i przy tej okazji zaznajomiłem się z Qt. Sama biblioteka naprawdę mi się spodobała, a najbardziej chyba fakt, że aby skompilować program pod Windowsem nie musiałem zmieniać dosłownie ani jednej linijki kodu (faktem jest jednak, że specjalnie starałem się pisać to w taki sposób, żeby nie używać nadmiarowych bibliotek, a do komunikacji ze światem zewnętrznym tylko Qt używać).

          I wtedy jedyne, co mi przeszkadzało, to fakt, iż biblioteka nie nadawała się do zastosowania w małych przedsiębiorstwach, których po prostu nie stać na wykupienie drogiej licencji. Bo tak, jak uważam, że utrzymywanie się z obsługi technicznej, jest dobrym pomysłem – ale dla dużych projektów – tak małe mogłyby mieć nawet problem, żeby wystartować.

        2. Awatar kwant
          kwant

          No znowu nie przesadzaj, licencja nie jest taka droga. Jeżeli kupisz na jedną platformę to w wersji podstawowej zapłacisz dla jednego developera około 1000$. Jak na narzędzie developerskie nie jest to jakoś bardzo drogo, zwłaszcza, że możesz taką licencją ,,wygenerować'' dowolną ilość ,,sprzedawalnego'' kodu. Dodatkowo inni developerzy mogą pracować na licencjach darmowych a dopiero kod wyjściowy rekompilijesz używając tej licencji.

          Ale teraz już w ogóle nie ma problemu, będzie LGPL dla co najmniej dla jednej, nowej wersji. Opierając się o tą wersję (>4.2 jest dojrzałe) można przez długie lata wypuszczać soft bez obawy o zacofanie technologiczne.

        3. Awatar Ktoś
          Ktoś

          "Sama biblioteka naprawdę mi się spodobała, a najbardziej chyba fakt, że aby skompilować program pod Windowsem nie musiałem zmieniać dosłownie ani jednej linijki kodu"

          Generalnie podzielam entuzjazm związany z przejsciem QT na LGPL. Chciałem tylko zauważyć, że kiedy pisałem pewną aplikacę w Javie (Swing, JDBC, Postgresql, XML, Sockets, Netbeans) nie tylko nie musiałem zmieniać ani jednej linijki kodu – mogłem wysłać klientowi binarke wygenerowaną pod Linuxem a ten uruchamiał ją sobie pod Windowsem i nie zgłaszał żadnych zastrzeżeń jeśli chodzi o działanie programu. W tym czasie jak i teraz nie miałem nawet zainstalowanego Windowsa na swoim domowym komputerze.

          Przy okazji mam pytanie: swego czasu interesowałem się językiem D – który miał (ma) zastąpić C++ i Jave łącząc ich najlepsze cechy (prostote, łatwość programowania (Java) i wydajność (C++) ) a eliminując te najgorsze ("trudność" (C++) wydajność (Java)). Zastrzeżenia dotyczące Javy (generalnie) w moim odczuciu nie dotyczyły samego języka a faktu, że program jest kompilowany do bytecode-u i uruchamiany w maszynie wirtualnej co ma wpływ na wydajność.

          A teraz pytanie: Dlaczego nie powstają kompilatory Javy, które generowałyby kod maszynowy a nie bytecode? Inaczej mówiąć po co wymyślać nowy język, który pozostawia np: garbage collector jako rzecz porządaną której brak ma być przyczyną wielu błedów w c++ a nie stworzyć po prostu kompilatora Javy na i386 albo power pc?

        4. Awatar szatox
          szatox

          "Przy okazji mam pytanie: swego czasu interesowałem się językiem D – który miał (ma) zastąpić C++ i Jave łącząc ich najlepsze cechy (prostote, łatwość programowania (Java) i wydajność (C++) ) a eliminując te najgorsze (”trudność” (C++) wydajność (Java))."
          a wyjdzie dokładnie na odwrót 😉

          "Dlaczego nie powstają kompilatory Javy, które generowałyby kod maszynowy a nie bytecode? "

          AFAIR istnieją kompilatory javy. Można wygenerowć binarkę wykonywaną przez procesor bez stosowania symulatorów takich jak maszyna wirtualna

        5. Awatar Królik
          Królik

          Ale nie zawsze ma to sens, bo obecne JVM kompilują kod w locie i wydajnością dorównują C/C++. Dla aplikacji okienkowych te różnice wydajności kompletnie nie mają znaczenia na dzisiejszym sprzęcie.

        6. Awatar Królik
          Królik

          A i jeszcze jedno: w D jak włączysz jego prymitywny GC oraz sprawdzanie zakresów tablic i wszelkie inne zabezpieczenia, to wydajnośc będzie dużo gorsza niż Javy czy C#. W D te rzeczy są jako opcjonalny dodatek, w Javie i na platformie .NET były uwzględniane od samego początku jako kluczowy element. Więc znowu masz – albo super wydajny kod, albo wygodę i bezpieczeństwo. Na Great Language Shootout różnice wydajności między Javą i D rzadko przekraczają 30% (i to w obie strony, bo D też przegrywa niektóre benchmarki z Javą).

        7. Awatar el.pescado
          el.pescado

          "Dlaczego nie powstają kompilatory Javy, które generowałyby kod maszynowy a nie bytecode?"

          Tak działa maszyna wirtualna Javy – w trakcie wykonywania programu kompiluje bajtkod do kodu natywnego, który jest wykonywany (tzw. kompilacja JIT).

          Poza tym, jest coś takiego jak
          http://en.wikipedia.org/wiki/GNU_Compiler_for_Jav…

        8. Awatar Królik
          Królik

          "Poza tym, jest coś takiego jak
          http://en.wikipedia.org/wiki/GNU_Compiler_for_Jav…

          No jest, tyle że częściej nie działa niż działa i o Javie 5 i wyżej można zapomnieć. Jakość generowanego kodu maszynowego też pozostawia bardzo wiele do życzenia. Oryginalna JVM od Suna bije gcj wydajnością na głowę.

        9. Awatar mby7930
          mby7930

          "Ale nie zawsze ma to sens, bo obecne JVM kompilują kod w locie i wydajnością dorównują C/C++. Dla aplikacji okienkowych te różnice wydajności kompletnie nie mają znaczenia na dzisiejszym sprzęcie."

          Zwłaszcza, gdy weźmiemy pod uwagę, że realnym konkurentem JAVy mam być C#, który akurat nie jest jakimś demonem szybkości i wydajności w porównaniu z JAVą.

        10. Awatar Królik
          Królik

          Z mojego doświadczenia wynika, że obecnie JVM i .NET wydajnościowo są dosyć zbliżone, przynajmniej na Windows. Java jest trochę szybsza w trybie serwerowym, jak długo działa, ale nie na tyle, żeby miało to jakieś istotne znaczenie. Mono jeszcze trochę odstaje, ale szybko nadrabia straty.

        11. Awatar mario
          mario

          Java ma tylko jedną dużą wadę w stosunku do C++, JVM zużywa dużo pamięci operacyjnej, dlatego większość ludzi woli jak aplikacje biurkowe są napisane i skompilowane pod konkretny system natywnie. Wydajnościowo Java jest bardzo dobra, choć na ten temat krąży wiele mitów.

        12. Awatar Królik
          Królik

          Dużo RAMu? Eee tam, lekka przesada. Samo JVM zjada może kilkanaście MB pamięci współdzielonej i może ze 20 MB na klasy związane z okienkami (też wspóldzielone między instancjami JVM). Co to jest narzut 20MB, jeśli teraz prawie każdy ma >1GB?
          Kwestia większego zużycia RAMu w Javie jest raczej natury psychologicznej – w Javie dużo łatwiej korzysta się z bibliotek (bo są przenośne i pisane możliwie w jednej konwencji) i łatwo można napisać program, który ładuje setki MB wtyczek na starcie – np. takie Eclipse.

          Jeśli chodzi o pamięć alokowaną przez Javę na stercie, to tutaj systuacja jest bardzo podobna co w aplikacjach natywnych – zwykle schodzi ok. 50% więcej niż rzeczywiste zapotrzebowanie danego programu. W C++ traci się na fragmentacji (i wyciekach), w Javie na tym, że pamięć nie jest zwalniana natychmiast.

    2. Awatar trasz
      trasz

      @m: Ma – GTK+ mozna uzywac z poziomu C, a tym jezykiem potrafi sie poslugiwac wiecej programistow open source niz C++.

      A co do GNOME – KDE przy GNOME nie ma szans chocby z tego powodu, ze jest nastawione na bajery, ktorymi developerzy moga sie pochwalic kolegom, a nie na uzywalnosc.

      1. Awatar Ivan
        Ivan

        LMAO, uzywalnosc i GNOME w jednym zdaniu (!)

        1. Awatar 3ED
          3ED

          KDE jest jak porysowany kamień, a Gnome jak nieoszlifowany z jednej strony.. Ja osobiście jakbym miał wybierać między KDE, a KDE to wybrałbym fluxbox'a bo on jest bardziej podobny do Gnome – skupiasz się na czymś naprawdę ważnym, a nie konfiguracji bzdetów.. Naprawdę szkoda życia, później ktoś będzie wam mówił, że wy "noł lajfy".. ;þ

        2. Awatar tuxmaniak
          tuxmaniak

          Ja myślałem, że zabawa z fluxboxem, blackboxem czy innym *boxem to hardkorowa konfiguracja (za pomocą jakichś plików tekstowych), a potem nie mniej hardkorowe uzywanie… W kde możesz sobie wszystko skonfigurować łatwiej i prościej, co nie znaczy że musisz, bo środowisko to jest gotowe do użytku od pierwszego uruchomienia…

      2. Awatar tuxmaniak
        tuxmaniak

        łał.
        Podaj przykład. Powiedz mi np. w czym lepszy jest nautilus od dolphina czy f-spot od gwenview. Jaką przewagę mają moduły konfiguracji GNOME nad KDE? Czekam na odpowiedź…

        PS nie mów mi, że udostępnienie użytkownikom konfigurowalnej i spójnej powłoki pulpitu (wiem, upraszczam…) jaką jest plasma, świadczy o "nastawieniu na bajery".

        1. Awatar tuxmaniak
          tuxmaniak

          Dodam jeszcze, że:
          -KDE ma wszystko to, co ma GNOME. To, że ma coś, czego GNOME nie ma, nie świadczy wcale na korzyść GNOME.

          -KDE udostępnia basę dla tworzenia przyszłych funkcjonalności tego środowiska, których stworzenie w gnome nie byłoby możliwe bez jego przebudowy (czyli bez tego, czego nie chce się zrobić programistom GNOME, a za co krytykowani są programiści KDE)

          -KDE już ma funkcje/moduły "ustandaryzowujące" środowisko, o których GNOME może na razie pomarzyć. Mówię tu m.in o Phononie

          -Co z tego, że w KDE możesz używać widgetów i możesz sobie zmieniać motyw graficzny pulpitu plasmy? To, że w GNOME obsługa widgetów jest mniej związana z pulpitem (nie można umieszczać widgetów pulpitu na panelu, ani tworzyć nowych, "specjalizowanych" paneli), i obsługuje mniej języków programowania, nie znaczy wcale, że gnome jest lepsze. A motywy graficzne paneli? W GNOME tez istnieje ich obsługa. To, że silnik motywów graficznych paneli i widgetów (gadgetów) jest uboższy, nie znaczy, że lepszy… Ach, zapomniałem! GNOME nie ma czegoś takiego, jak jeden spójny motyw dla widgetów i paneli 🙂

          -W ciągu 2 (chyba) lat rozwoju KDE4 Dolphin wyprzedził nautilusa (rozwijanego od 2001 roku, i pamiętającego czasy GTK 1.x) pod względem funkcjonalności.

          -Od tych "bajerów", jak to określasz, czyli od plasmy, KDE ma 1 (słownie JEDNEGO) programistę: Aarona Seigo. Wszelkie pretensje co do większej funkcjonalności pulpitu KDE4 od pulpitu GNOME i jego ładniejszego wyglądu proszę kierować do niego. No, i może jeszcze do paru grafików. Powiedz im, co myślisz o efektach ich pracy, to na pewno czym prędzej przerzucą się na programowanie :>. Wtedy na pewno KDE zrównałoby się ( w dół) z GNOME pod względem funkcjonalności programów

        2. Awatar trasz
          trasz

          @tuxmaniak: Pojecie KISS cos ci mowi?

          GNOME jest proste i robi to, co trzeba. KDE natomiast przytlacza iloscia zbednych wodotryskow. GNOME wzoruje sie na Apple. KDE – chyba na linuksowym kernelu. ;-P

        3. Awatar Paweł Ciupak
          Paweł Ciupak

          „W ciągu 2 (chyba) lat rozwoju KDE4”

          Jeżeli liczyć od rozpoczęcia prac, to trochę więcej; jeżeli od wydania KDE 4.0, to w ciągu 1 roku.

          Notabene, widzę że dzięki GNOME-owemu fanbojstwu zobaczymy pierwszy wysoko zaplusowany komentarz trаsza :).

        4. Awatar Paweł Ciupak
          Paweł Ciupak

          @trasz: Tylko że GNOME nie jest ani KISS, ani też proste – ani w tworzeniu (GObject, ubogość GNOME-owych bibliotek (takie podstawowe rzeczy, jak zmiana kolejności przycisków na pasku narzędzi każdy musi sobie sam w każdym programie napisać), czy też zależności od wielu różnych bibliotek, których funkcjonalność w KDE pokrywa już zwykłe Qt), ani też w używaniu (trzeba grzebać w GConfie nawet w takich trywialnych rzeczach, jak przełączenie Nautiliusa w nawigacyjny tryb pracy, czy też wyłączenie ikon na pulpicie).

          I tak, GNOME wzoruje się na Apple – w traktowaniu użytkownika jako idioty, który pogubiłby się gdyby w oknie zamiast trzech przełączników byłoby cztery.

        5. Awatar de_tox
          de_tox

          Kwestia, które środowisko graficzne jest lepsze jest względna. Tak naprawdę chodzi tutaj o "target" danego GUI.
          GNOME jest skierowany przede wszystkim do początkujących użytkowników Linuksa (a nawet komputera) lub do osób, które nie potrzebują nadmiaru opcji lub oczekują przejrzystego interfejsu (między innymi dla mnie 😛 ).
          KDE natomiast jest dla tych, którzy oczekują czegoś więcej – bardziej konfigurowalnego środowiska. Zdecydowanie nie polecałbym go dla newbies, gdyż mnogość opcji może ich tylko odstraszyć. No i do tego KDE do wersji czwartej miało ten paskudny, pastelowy wygląd ala Doda ]:-> (chociaż muszę przyznać, że Clearlooks również jest ohydny).

        6. Awatar tuxmaniak
          tuxmaniak

          KISS to tylko pojęcie. Może się sprawdzać lub nie. Nie jest przykładem, a o przykład prosiłem. Ciężko chwalić za daleko idące upraszczanie. Nautilus oferuje podstawową funkcjonalność (przeglądanie plików), ale ciężko uznać to za plus w przypadku aplikacji rozwijanej przez tyle lat…

          "GNOME jest proste i robi to, co trzeba"
          Kiedy zrobi widok plików w grupach? Kiedy będzie tak spójne i komplementarne jak KDE? Kiedy Brasero dorośnie do pięt k3b, a Totem-Kaffeine
          GNOME jest proste, i robi to co trzeba. KDE robi to co GNOME, i jeszcze więcej.

          "GNOME wzoruje sie na Apple"
          Najpierw "KISS", potem "Apple"… Widzę, że używasz słów wytrychów :>. Nigdy nie używałem Mac OS X, ale sądząc po opowiadaniach użytkowników tego systemu, oraz po filmikach na youtube, środowisko Mac OS X to zestaw w pełni funkcjonalnych aplikacji użytkowych i systemowych, doskonale się uzupełniających i konfigurowalnych. Ten opis bardziej pasuje mi do KDE, niż do GNOME… Tym bardziej, gdy porównuję Findera z Gnomowym Nautilusem… Zresztą, jeśli mam KDE, i odpowiada mi interfejs Apple, konfiguruję sobie środowisko upodabniając je do Mac OS X wedle własnego uznania. W Mac OS X nie mogę zamienić interfejsu applowskiego na windowsowy… W kde mogę zadecydować, czy używać jako menedżera plików dolphina, Konquerora, czy jakąkolwiek inną aplikację… W Gnome musiałem zastosować pewien "hack", by wymienić nautilusa na thunara i xfce-desktop… A i tak GNOME uporczywie otwierało kosz w nautilusie, uruchamiającym także swój pulpit…

        7. Awatar mith (lstarba)
          mith (lstarba)

          Wiecie, mam naprawdę ubaw, kiedy czytam te wszystkie komentarze 😉 Wszyscy tutaj podchodzą do tego jak do religii, gotowi z płomieniem w oczach (a nie rzadko w dłoni) bronić swoich racji. Przednia rozrywka 😉

          A co do zalet GNOME. U mnie przynajmniej działa szybciej i dlatego z niego korzystam. Co nie znaczy wcale, że nie darzę uprzejmą życzliwością rozwoju KDE 4. Po wydaniu stabilnej wersji 4.2 na pewno spróbuję – szczególnie, że nVidia łaskawie wreszcie naprawiła sterownik.

        8. Awatar PiTcA
          PiTcA

          Z początku sam byłem za gnome, jednak po pojawieniu się KDE 4 postanowiłem spróbować, jednak jakoś mnie nie przekonało. KDE 4.1 także nie było wiele lepsze, głównie denerwowała mnie jego ociężałość, a raczej ociężałość sterowników nvidii. Teraz jadę na nvidia-drivers 188.22 i KDE 4.1.96 i muszę powiedzieć, że skok wydajnościowy względem wcześniejszych wydań jest ogromny, na tyle ogromny, że chyba już zostanę przy KDE, a na wersję 4.2 czekam ze zniecierpliwieniem (jeszcze tylko 5 dni :))

        9. Awatar trasz
          trasz

          @de_tox: Na odwrot. GNOME jest skierowane do uzytkownika, ktory ma cos konkretnego do zrobienia. KDE jest skierowane do mlodziezy, ktorej sie nudzi i chcialaby sobie cos pokonfigurowac.

        10. Awatar tuxmaniak
          tuxmaniak

          A może KDE jest dla tych, którzy chcą sobie skonfigurować środowisko dokładnie wedle własnych potrzeb, i używać go efektywnie, a GNOME… dla tych, którym odpowiada to co za nich "skonfigurują" (czyli zaprogramują bez możliwości zmiany) programiści GNOME, ewentualnie dla "hakierów", którzy lubią męczyć się z szalenie intuicyjnym Gconfem, albo używać jakichś "hakierskich", połowicznie skutecznych skryptów, żeby wymienić niewiele dającego, a mulącego jak zaawansowany kombajn nautilusa na thunara, który, choć podobnie "funkcjonalny", jest przynajmniej szybszy?

          Może dla tych, którym pasuje "skalowalność" i "wszechstronność" Totema? Wszak Totem rulezzzz, bo niedawno dostał szalenie ważną funkcję przeglądania filmików z youtube i BBC…, To, że nijak się ma do Kaffeine jako odtwarzacz filmów, mniej się liczy… No i Brasero…

          GNOME jest dla tych, którzy boją się, że się "skaleczą" dającym więcej możliwości środowiskiem graficznym, a KDE… KDE jest dla wszystkich, bo nie musisz go konfigurować, żeby mieć lepsze aplikacje od tych z GNOME.

          To tak jak z środkiem lokomocji… Komunikacja miejska też może w pełni wystarczyć tym, którzy chcą się dostać na drugi koniec miasta, i nie potrzebują do tego własnego samochodu. Gorzej, jeśli ktoś będzie chciał lub będzie musiał odbyć podróż do innego miasta…

        11. Awatar mini
          mini

          "jeśli ktoś będzie chciał lub będzie musiał odbyć podróż do innego miasta…"
          to wsiadzie w PKS albo pociag. To tez komunikacja publiczna.
          A jak sie wybieram do Madrytu, to samolotem jest szybciej i wygodniej, a na miejscu mozna wziac taxi.

        12. Awatar tuxmaniak
          tuxmaniak

          "to wsiadzie w PKS albo pociag. To tez komunikacja publiczna."
          pisałem o komunikacji MIEJSKIEJ. Proszę czytać uważnie to co piszą inni. Bo najczęściej jest tak, że jeśli ktoś pisze "KOMUNIKACJA MIEJSKA", nie ma na myśli będzynarodowych połączeń lotniczych, czy międzymiastowoych połączeń PKS, albo PKP.

          Podobnie jest, gdy ktoś mówi, że KDE jest konfigurowalne. Nie znaczy to, że MUSISZ je sobie skonfigurować. Jak chcesz, to możesz, jak nie chcesz to nie musisz.

        13. Awatar trasz
          trasz

          @tuxmaniak: Chce miec srodowisko, ktorego moge uzywac efektywnie bez koniecznosci spedzenia paru godzin nad sensownym skonfigurowaniem go. Samochodu tez nie mam zamiaru montowac sobie z kawalkow, bo a nuz wygodniej mi bedzie z kierownica na suficie.

        14. Awatar tuxmaniak
          tuxmaniak

          @trasz:"Chce miec srodowisko, ktorego moge uzywac efektywnie bez koniecznosci spedzenia paru godzin nad sensownym skonfigurowaniem go."

          Moja odpowiedź: patrz moje dwa ostatnie komentarze

      3. Awatar rkowal
        rkowal

        Możliwość używania biblioteki z poziomu to niewątpliwie zaleta.

        Gtk osiągnęła masę krytyczną i wymaga dużej refaktoryzacji.

        Do tego dochodzi system obiektowy związany z GObject, po prostu masakra, zaznaczam, że nie mam na myśli biblioteki glib, która jest bardzo przyjemnym narzędziem. Nie wiem dlaczego przy tworzeniu Gtk nie skorzystali z Objective-C skoro mechanizm obiektowy w obu rozwiązaniach jest podobny.

        1. Awatar trasz
          trasz

          @rkowal: Bo Objective-C zna jeszcze mniej ludzi, niz C++. Moze z dalszym upowszechnianiem sie Makow to sie zmieni, ale na razie to nadal troche egzotyka.

        2. Awatar Paweł Ciupak
          Paweł Ciupak

          Trаsz, skoro C jest takie najlepsze, to powiedz mi: czemu większość programistów GNOME i GTK woli programować w językach na wyższym poziomie, jak C♯, czy Python (biorąc pod uwagę, że większość sensownych aplikacji na GTK jest właśnie napisane w tych językach)? I dlaczego też w poważnych zastosowaniach C jest używane praktycznie tylko do niskopoziomowych rzeczy, i C++ jest tam o wiele popularniejszy?

          Zresztą, niektórzy fanatycy GTK są śmieszni – najpierw narzekali, że Qt było własnościowe, a przecież _proprietary software_ jest zUe i niedobre. Potem zas ich argumentem było, iż Qt jest złe… bo nie można na nim pisać własnościowego oprogramowania. Najpierw narzekają, że w Qt nie można pisać w czystym C. Potem sami starają się pisania w nim unikać i narzekają, iż… Qt nie ma bindingów do bardziej rozwiniętych niż C języków.

        3. Awatar AdamK
          AdamK

          C jest najlepsze do pisania bibliotek bo najłatwiej taką bibliotekę wykorzystać także w innych językach programowania. Dlatego wszystkie _biblioteki_ składające się na Gnome są napisane w C.

      4. Awatar m
        m

        Większość programistów, piszących aplikacje GUI zdecydowanie woli używać języków obiektowych. C++ i QT wraz ze swoimi sygnałami i slotami jest bardzo bliskie pracy w Javie w pewnych punktach. Ten mechanizm w porównaniu do callbacków jest… bez porównania ;] Łatwiej pisać większe projekty w oparciu o QT, pisanie rozbudowanych aplikacji okienkowych w C to archaizm! Łatwiej nauczyć się C++ jak utrzymywać skomplikowany kod w C, który wymaga zazwyczaj więcej debugowania i trudniej go rozbudowywać. C++ to żadna nowość, każdy koder winien go znać.

        1. Awatar sprae
          sprae

          Ależ sekciarstwo 😉 0 obiektywizmu…

        2. Awatar m
          m

          Sekciarstwo? o_O

        3. Awatar Królik
          Królik

          __W praktyce__ kod w C++ jest trudniejszy w utrzymaniu niż C.
          C++ jest jednym z nielicznych języków który daje bardzo silne narzędzia wspierające enkapsulację i ukrywanie, nie dając przy tym żadnego wsparcia dla bezpieczeństwa. C nie ma ani jednego ani drugiego, więc, jak to ktoś mądry kiedyś powiedział, można łatwo postrzelić się w stopę. W C++ jak już to nastąpi, odrywa całą nogę. Stąd wolę poprawiać pokaszaniony kod w C niż pokaszaniony kod w C++. Podobnie zresztą uważa Linus Torvalds.

        4. Awatar m
          m

          Królik@ Może Ty masz takie doświadczenia praktyczne, nastomiast zdaje się, że większość twórców aplikacji okienkowych wybiera języki obiektowe i zdaje się, że nie wynika to jedynie z teorii ;] Osobiście nie zauważyłem w __praktyce__ łatwości utrzymywania kodu w C. Gdyby w C tak fantastycznie utrzymywało
          się kod, to ten język byłby wybierany przez większość projektów z __praktycznych__ względów ;]

        5. Awatar Królik
          Królik

          C++ jest wybierane częściej dlatego, że się łatwiej kod pisze, nie że łatwiej utrzymuje, czy debuguje, no i że dużo osób nabiera się na to "++". Stąd w powłoce dominuje C++, ale już to co musi być stabilne i porządne czyli liby i kernel się robi w C. Bo liby żyją dłużej niż powłoka graficzna. Zresztą, gdyby C++ było takie cudowne jak piszesz, to w "stabilnym KDE 4.1.x" nie byłoby tyle bugów ile jest. Bo póki co, to dodali multum rzeczy, ale jakość jest dużo poniżej średniej (zresztą – zawsze odkąd pamiętam KDE – z utrzymaniem jakości i wydajności było słabiutko).

        6. Awatar m
          m

          Królik@ Co to znaczy nabrać się na "++"? Nie rozumiem :/ Wiesz zdaje się, że istnieje coś takiego jak inżynieria oprogramowania… a nie każdy język jest tak samo dobry w każdym zastosowaniu. Porównywanie jądra systemu do aplikacji okienkowych jest raczej nie na miejscu. Jądro ma zupełnie inne zadania, metody należące do jądra czasami muszą być pisane tak, by czas ich działania zmieścił się w odpowiednim kwancie czasu… Zresztą jądro, które ma być portowalne, musi być poprawnie kompilowane na wielu architektórach, a nie wszędzie dostępny jest kompilator C++ o tej samej jakości. Inna sprawa, że jądra, które aktualnie używamy i podstawowe biblioteki to wynik wielu lat pracy… projekty na których ich działanie jest oparte powstawały czasami nawet przed pojawieniem się języka C. Moim zdaniem nie masz obiektywnych argumentów na poparcie swoich tez. To, że KDE nie jest stabilne, jest dowodem na to, że w C++ nie da się pisać stabilnie i porządnie? Jesteś w stanie udowodnić, że KDE pisane w C miałoby się lepiej? Moim zdaniem problemy KDE wynikają raczej z rozmachu z jakim jest rozwijany i z błędów ludzkich (jak to zwykle bywa).

        7. Awatar Królik
          Królik

          Pisanie aplikacji okienkowych jest łatwiejsze i mniej wymagające niż kernel, RDBMS czy jakikolwiek kod wielokrotnie wykorzystywany (uniwersalny).

          Może w przypadku KDE jest inaczej. Ale jak porównasz kod MySQLa (C++) z kodem PostgreSQL (C), to w tym drugim jest dużo mniejszy bałagan. Wiem, wiem, oczywiście wszystko można zwalić na czynnik ludzki. Może to jest tak, że ci, którzy piszą w C, są bardziej świadomi zagrożeń i mają lepszą dyscyplinę? Moim zdaniem C++ usypia czujność – ma wszystkie wady C, ale zarazem daje narzędzia pozwalające zakopywać problemy pod dywan. A później wracają ze zdwojoną siłą.

      5. Awatar azhag
        azhag

        http://www.bash.org/?772559 😉

  4. Awatar Adam
    Adam

    Moze zmieni to tez trend obecnie panujacy na desktopach? Obecnie malo ktora dystrybucja domyslnie oferuje KDE… Oczywiscie mam na mysli sytuacje, gdy to ostatnie będzie już w pełni używalne i z kompletem niezbędnych aplikacji

  5. Awatar Paweł Ciupak
    Paweł Ciupak

    Ciekaw jestem, czy tym razem zwyciężą względy praktyczne, czy znowu zadecyduje anty-Qt ideologia…

  6. Awatar barteqx
    barteqx

    Zaczyna się dziać to co powinno. GTK ciagnie jedną liie bibliotek od chyba 2002, bez żadnych wiekszych zmian w API. Po prostu tkwi w epoce XP. Qt za to jest nowoczesne, szybko się rozwija i ma komercyjne wsparcie. jest wygodne i dla usera i dla developera. To po prostu nieuniknione…

    1. Awatar cactusik
      cactusik

      Gdyby nie prostota i wygoda qt to nie wzialbym sie za modul tlena do kadu 😉

      1. Awatar cactus
        cactus

        nie napisale ze dziala ?
        … dziwne 😀 dla niedowiarkow : fotki

    2. Awatar trasz
      trasz

      @barteqx: Co wlasciwie jest nie tak z API GTK+? Serio pytam. Qt nie znam.

      1. Awatar Paweł Ciupak
        Paweł Ciupak

        Słabo udokumentowane, oparte na zawiłym GObject, pełne niepotrzebnych zaszłości historycznych zachowywanych tylko dla kompatybilności. Pomijając to, że gtk_ma_pełno_nazw_funkcji_na_pół_ekranu ;).

        1. Awatar sprae
          sprae

          To zupełnie jak DirectX którego używa pół świata gier komputerowych 😉

        2. Awatar Paweł Ciupak
          Paweł Ciupak

          Używa, gdyż lepszej alternatywy nie ma.

        3. Awatar sprae
          sprae

          Qt też nie jest lepszą alternatywą. Jest tylko alternatywą. Jeśli lubisz Qt to go używaj, tak jak ja używam GTK. Szanuję aplikacje i ciężka prace nad kde4. Sam piszę aplikacje na GTK/maemo i bardzo mi to odpowiada. Jeśli Tobie podoba się Qt to jestem wielce zadowolony z tego.

        4. Awatar marcinsud
          marcinsud

          @Paweł Ciupak
          Jakoś brak alternatywy nie przeszkadzał i nie przeszkadza by na playstation wychodziły gry, a takiej bazy gier jak ps2 jeszcze długo żadna konsola mieć nie będzie. O tym, że tam nie ma dx nie muszę pisać?

        5. Awatar Paweł Ciupak
          Paweł Ciupak

          No dobra, źle się wyraziłem: nie ma takiej alternatywy, która by mu dorównała. A trzeba przyznać: DirectX to jedna z niewielu rzeczy, które naprawdę udały się Microsoftowi.

        6. Awatar Gen2
          Gen2

          MS robi świetne myszki i klawiatury.

        7. Awatar AdeBe
          AdeBe

          Eee tam, moja super hiper laserowa myszka padła po pół roku.

  7. Awatar Albi
    Albi

    Dobra droga, sam po zmianie licencji postanowiłem porzucić naukę wxWidgets i zacząć pisać z Qt. Na razie jest ok 😉

  8. Awatar rkowal
    rkowal

    Może ktoś wie na ile Qt jest wrażliwe na zmiany wersji kompilatora.
    W przypadku Gtk jakiś kłopotów nie zaobserwowałem (znalazłem stare małe programiki kompilowane względem Gtk 2.6), a z Qt nie mam jak teraz sprawdzić (nie mam np jakiegoś małego programiku kompilowanego w konfiguracji qt4.0 +gcc-3.3, aby spróbować go odpalić na konfiguracji bardziej współczesnej).

  9. Awatar sprae
    sprae

    Poczekamy zobaczymy. W Canonical wielokrotnie rysowano już fantastyczne mockupy, a potem wychodziło z tego coś innego. Wątpię czy mają potencjał do wykonania czegoś choćby na miarę Palm Pre. Za to desktopy przerabiają dobrze. Jeśli wykluczyć aktualizacje, są praktyczne i da się tego używać. Nie chcę mówić, że to nieudacznicy, po prostu nie ma tam dobrych bodźców. Qt może być tu tylko wymówka, że coś może się udać bo jest nowe i fajne. Ale nie przesadzajmy. Oni mieli do dyspozycji Clutter, Cairo i GTK oraz fantastyczne pomysły. Co by o tych bibliotekach nie pisać to one też mają fantastyczny potencjał i pozwalają zachwycać użytkowników. Jednak z jakiegoś powodu nie wyszło i Intel ich opuścił na rzecz Fedory.

  10. Awatar Nemeczek
    Nemeczek

    Ojej Canonical zatrudnił speców którzy mieli zmienić design systemu i jak na razie to nic nie słychać.
    Nie znam się jeszcze za bardzo na programowaniu.. Ale lubię gtk a dokładniej Gnome i tyle. Nie wiem, to chyba jakis rodzaj sentymentu.

    1. Awatar sprae
      sprae

      Oni narysują, ale kto to potem zaprogramuje?

  11. Awatar riklaunim
    riklaunim

    Maemo przechodzi na Qt, to Canonical też "musi" 🙂 A co do Qt – umie bardzo dużo i to jest zaleta. Do tego musi być to produkt wysokiej jakości bo (przynajmniej do niedawna) jego istnieje zależało ogólnie od jego sprzedaży (wersji komercyjnych, supportu, dodatku itd.). Projekty wyłącznie open-hacking-source nie są tak naprawdę poddawane gruntownej ocenie, przez co twórcy nie wiedzą co robią źle, albo nie mają "motywacji" żeby coś poprawić, ulepszyć.

    1. Awatar sprae
      sprae

      Ja bym przechodzeniem tego nie nazwał. Kolejna wersja będzie miałą Qt w repo, natomiast następna dopiero ma mieć Qt jako część platformy. Nic z tego nie gwarantuje, że Qt będzie main-api w maemo. Szczególnie, że w kolejnym wydaniu będzie to GTK/Clutter.

    2. Awatar sprae
      sprae

      Dodam jeszcze, że Qt w maemo na razie będzie grało role biblioteki oraz bardziej zintegrowanej z Hildon. Czyli będzie coraz bardziej multiplatformową biblioteką.

  12. Awatar Iwo
    Iwo

    Niech ktoś mi wytłumaczy zatem jak zupełnemu laikowi, dlaczego lekkie środowiska jak XFCE i superlekkie LXDE opierają się właśnie o GTK? Dzięki

    1. Awatar sprae
      sprae

      Bo ich autorzy programują z użyciem GTK?

    2. Awatar morsik
      morsik

      Bo GTK było lżejsze gdy prace nad XFCE/LXDE były zaczynane.
      Z mojego doświadczenia wiem, że aktualne Qt4.4 działa znacznie szybciej niż GTK i mówię tu chociażby o prostym rysowaniu okien. Różnica w szybkości jest widoczna gołym okiem.

      1. Awatar sprae
        sprae

        To masz chyba oko muchy, bo ja na Cairo w Pythonie wyciągam 60FPS przy dość skomplikowanym GUI i chyba nie muszę dodawać, że odrysowanie trwa 16ms.

        W jaki sposób dziś GTK jest cięższe? Szczególnie ze libcairo przeszło dość duże przyśpieszenie między 1.2 a 1.4.

        Qt z użyciem OpenGL rysuje bardzo szybko. Tylko ma problem bo każda aplikacja otwiera swój kontekst OpenGL, co powoduje problemy wydajnościowe. Dodatkowo QGraphicsView, które będzie poprawione w 4.5 ma problemy z optymalizacja rysowania sceny, przez co nie nadaje się np na Nokię n8xx, która ma ograniczony transfer do FB.

    3. Awatar Paweł Ciupak
      Paweł Ciupak

      Bo taki był wybór ich autorów – akurat pod względem lekkości, GTK (+ inne biblioteki obarte na GLib) i Qt to taka sama liga; z kolei strzelam, że alternatywy typu FLTK czy FOX albo były całkowicie im nieprzydatne, albo też nie użyto ich jedynie dlatego, iż były mało popularne.

    4. Awatar jarek
      jarek

      > Niech ktoś mi wytłumaczy zatem jak zupełnemu laikowi, dlaczego lekkie
      > środowiska jak XFCE i superlekkie LXDE opierają się właśnie o GTK? Dzięki

      1. XFCE to juz dawno temu przestalo byc lekkie. Tego drugiego nie uzywalem.
      2. Gdy XFCE przechodzilo na GTK, QT jeszcze nie bylo LGPL, chyba nawet
      nie bylo GPL.
      3. jak ktos juz nizej zauwazyl, wtedy GTK jeszcze byla z miare lekka.

      I to chyba tyle. Nie sadze, zeby wzgledy czysto techniczne odegraly tu role.

      1. Awatar sprae
        sprae

        Czyli co? Kto się pisze na lekkie środowisko w Qt? Są jakieś plany?

        1. Awatar AdeBe
          AdeBe

          Raczej się prędko nie doczekasz. Ogólnie w środowisku nadal dość mocno trzyma się przekonanie, że "GTK+ jest lżejsze, bo jest pisane w C" i inne tego typu bzdury.
          Powoli się to zjawisko osłabia, ale minie jeszcze kilka lat zanim całkowicie zaniknie.

        2. Awatar patpi
          patpi

          AdeBe, Ty te dane o "srodowisku"/oslabianiu_zjawiska bierzesz skad? z palca? To po prostu jest myślenie życzeniowe czy masz jakies dane statystyczne, pokażesz?

        3. Awatar jarek
          jarek

          > Czyli co? Kto się pisze na lekkie środowisko w Qt? Są jakieś plany?

          Ja sie pisze, moge nawet to pisac 🙂

          ps. Jestem wlasnie sfrustrowany "lekkoscia" XFCE z ktorego pisze tego posta.

        4. Awatar jellonek
          jellonek

          sprae: nokia

        5. Awatar gedgon
        6. Awatar AdeBe
          AdeBe

          @patpi: Z moich obserwacji i komentarzy czytanych na planetgnome i lwn.net. IMHO są to najlepsze miejsca do wyciągania takich wniosków.

  13. Awatar kris
    kris

    Ja muszę powiedzieć że gdyby ubuntu większy nacisk położyło na
    KDE a mniejszy na GNOME to na pewno wzrosła by bardzo
    jego popularność. Mogę to stwierdzić na sobie, ja jako użytkownik
    wszystkich windowsów od wersji 3.1 aż do XP muszę powiedzieć
    że jak jakieś 2 lata temu usłyszałem o ubuntu to postanowiłem
    sprawdzić co to jest. Po instalacji byłem zszokowany innością
    tego środowiska w stosunku do tego do czego przez lata
    przyzwyczaił mnie windows. Belka na górze, belka na dole,
    uruchamianie programów od góry – może dla niektórych to
    błahostka lub nawet zaleta, w każdym razie dla mnie było to
    nie do strawienia. W tej chwili używam Kubuntu i jestem
    z niego bardzo zadowolony. Wygląd podobny, środowisko
    szybkie, zamiast total komandera, który był zawsze pierwszym
    moim instalowanym programem mam tutaj prawie
    identycznego krusadera. To tylko kilka przykładów ale
    powiem to jeszcze raz niech bardziej promują KUBUNTU
    to na pewno na tym zyskają.

    1. Awatar marcinsud
      marcinsud

      Ja w GNOME mam jeden panel, ale rozumiem przyzwyczajenia z windowsa spowodowały, że nie wpadłeś na pomysł połączenia obu paneli w jeden.

  14. Awatar kris
    kris

    Muszę powiedzieć że z tego co pamiętam to właśnie przesunąłem
    górny panel na dół i efekt tego był taki że jakikolwiek uruchomiony program
    który minimalizowałem nie frunął na dolną belkę tylko znikał.
    Może to był błąd danej wersji nie wiem, teraz już nie ma to znaczenia.
    Belki były tylko przykładem który dałem, ale wierz mi wygląd
    całego środowiska był dla mnie dziwny.
    Poza tym muszę ci powiedzieć, że wszędzie właściwie czytałem, że
    GNOME jest lżejsze i szybsze od KDE.
    U mnie KDE działa wyraźnie szybciej niż GNOME i sprawdzałem to nie tak
    dawno instalując polskie (skusiła mnie reklama że jest całkowicie
    okodekowane) ubuntu 8.04 pobrane z ubuntu.pl.

    1. Awatar Paweł Ciupak
      Paweł Ciupak

      „Poza tym muszę ci powiedzieć, że wszędzie właściwie czytałem, że GNOME jest lżejsze i szybsze od KDE.”

      Głupoty ci wmówili, gdyż jest to ta sama liga ciężkości. Choć niektórzy twierdzą, iż GNOME jest o wiele cięższe w praktyce niż KDE, gdyż mała ilość kodu jest współdzielona między aplikacjami, a także aplikacje te są pisane często w językach interpretowanych czy kompilowanych do kodu pośredniego (główny powód to zapewne ominięcie niewygody pisania w C rozszerzonym o GObject, gdyż w takim Pythonie czy C♯ łatwiej się pisze, zaś języki „tłumaczone” do czystego C, takie jak Vala, często nie mają potrzebnych bindingów). Ale oczywiście do takich twierdzeń zawsze trzeba podchodzić z przymróżeniem oka.

      1. Awatar kris
        kris

        Nie znam się za bardzo na tych programistycznych
        określeniach, ale dokładnie o to mi chodziło, że sprawdziłem
        to na tym samym sprzęcie i KDE jest szybsze, tak że nie
        rozumiem ludzi zafascynowanych GNOME i twierdzących
        że to lekkie i nieprzeładowane zbędnymi dodatkami środowisko.

        1. Awatar AdamK
          AdamK

          Masz jakieś wyniki pomiarów, czy to na oko mierzone?

        2. Awatar kris
          kris

          To są tylko obserwacje dotyczące szybkości uruchamiania aplikacji
          czy płynności przesuwania okien.
          Nie wiem co i jak by zmierzyć.
          Na pewno KDE i GNOME nie jest środowiskiem na słabe maszyny.
          Takie coś ci mogę podać:
          sempron3000, 1.5 GB ram
          kubuntu 8.10 (KDE 4.1)
          włączone podstawowe efekty plus rozpadające się okna
          uruchomiony konqueror, krusader, writer z otwartymi
          2 dokumentami, monitor systemu
          pamięć 505 MB
          plik wymiany 0 B
          procesor przeważnie w granicach 20 procent.

        3. Awatar kris
          kris

          Do tego co wyżej włączyłem jeszcze
          amarok (muza mp3)
          dragon player (film avi)

          pamięć 575 MB
          plik wymiany 0 B
          procesor 65 procent

        4. Awatar kris
          kris

          System jak wyżej zaraz po uruchomieniu

          pamięć 258 MB
          plik wymiany 0B
          procesor 3 procent

      2. Awatar AdamK
        AdamK

        Akurat Vala została napisana specjalnie po to aby łatwo było robić bindingi i równocześnie łatwo programować obiektowo.

        1. Awatar sprae
          sprae

          Ktoś nawet niedawno na blogu pisał, iż Vala to takie nowe otwarcie dla tych, którzy mają pomysły, a nie mają odwagi ich realizować w C/GObject. Do mnie to trafiło.
          Dodatkowo powstaje "gjs" w rozwinięciu gobject-introspection dzięki czemu łatwiej będzie można tworzyć "theme" aplikacji z definicjami animacji (podobnie jak w E17). Czyste definicje skórek w json można już robić w Clutter. Z resztą powstaje na do tego libka którą wykorzysta się gdzie wyobraźnia zapragnie.

      3. Awatar Ark
        Ark

        I tak i nie, GNOME sam w sobie jest lżejszy od KDE4 (w przypadku KDE3 ciężko to stwierdzić obecnie, ale o ile pamiętam czasy jak jeszcze miałem kde3 to po załadowaniu systemu zajmował mi więcej pamięci niż gnome z tegoż okresu). Po starcie – to zależy jakich aplikacji się używa

        co do Pythona natomiast – to zamiast pisać w PyGTK pod KDE można użyć PyQt i efekt (większego zużycia pamięci i cpu) jest ten sam

        a większą wygodę pisania można osiągnąć używając np gtkmm

        1. Awatar AdeBe
          AdeBe

          Owszem, tylko jest pewna różnica między tym, co można zrobić, a tym co się robi w praktyce i na jaką skalę.
          Aplikacji w PyQt nie widziałem za dużo, IMHO dlatego że już wersja C++ jest wystarczająco wygodna.
          GTKmm to taki ciekawy stworek, niby jest, ale jakoś mało osób go używa.

  15. Awatar marcinsud
    marcinsud

    a ja śmiem wątpić w to, że na ubuntu mobile będzie KDE, raczej stworzą coś nowego lekkiego i szybkiego. Z puntu projektowego będzie to lepsze, bo interfejs od początku byłby tworzony na małe ekrany, a nie jak teraz przystosowywany do małych ekranów. Aplikacjami bym się nie przejmował, bo pewnie zrobią wersje najpopularniejszych programów (pidgin, przeglądarka internetowa, prosty edytor tekstu) i tyle, dużo więcej na tych urządzeniach nie jest potrzebne.

    1. Awatar jan
      jan

      jest różnica między qt a kde? chyba jest…

      1. Awatar marcinsud
        marcinsud

        ja wiem, że jest dlatego tez twierdzę, że np kadu nie jest komunikatorem na KDE tylko komunikatorem wieloplatformowym, ale większość ludzi tutaj się rozwodzi co jest lepsze GNOME, czy KDE, a może dojść do tego, że ani jedno, ani drugie nie będzie w ubuntu mobile.

  16. Awatar agheogn
    agheogn

    Czy GTK zniknie ?

    Pamiętajmy co oznacza GTK – "The GIMP Toolkit". Ta biblioteka powstała tylko po to żeby GIMP był przenośny. Okazała się jednak na tyle dobra, że się rozpowszechniła.

    Dzień, w którym GIMPa przerobią na Qt będzie _symbolicznym_ końcem GTK.

    1. Awatar mmm
      mmm

      Szczerze chcialbym choc jestem niemal pewien ze to niemozliwe 😉 Pomyslcie ile pracy… pozatym wychodza projekty takie jak krita. Najlepiej gdyby obie aplikacje mialy wspolny system wtyczek i mogly sie wymieniac funkcjonalnoscia… choc i to jest ciezkie do zorganizowania ze wzgledu na czym te aplikacje sie opieraja 😉

    2. Awatar Energizer
      Energizer

      Chętnie zobaczył bym GIMPa na Qt 🙂

  17. Awatar sprae
    sprae

    Ale kto zrobi?

  18. Awatar Energizer
    Energizer

    Jeszcze niech tylko przejdą na RPMy i zmienią kolorki (nie lubię brązu itp. 😉 ) i nazwę i już będzie fajnie 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *