QDE – Cute Desktop Environment

Matthew @ 2010-07-08 — Kategorie: Open Source, Programowanie, Projekty, Qt, Techblog

Iria poruszył ciekawy temat, mianowicie stworzenia środowiska graficznego, które wzorem Xfce czy LXDE miałoby być lekkie i szybkie, a tak jak KDE oparte na Qt, jednak bez obciążania systemu sporą ilością dodatkowych bibliotek oraz dziwną architekturą KDE, czyli pakowaniem wszystkiego w środowisko (aby programy były trochę mniejsze) i dorzucaniem masy dodatkowych usług (aby były trochę bardziej funkcjonalne). (ale tworzę masakrycznie długie i złożone zdania O_o) Przypomniało mi się,  że ktoś już się kiedyś podjął takiego zadania, projekt nazywa się Antico, jednak z powodu przejścia autora na Mac OS X (teraz ktoś może napisać arta na temat tego jak Apple niszczy Open Source) projekt został zamknięty. Przejrzałem kod i… nie wygląda tak strasznie. Choć sam Antico mi się zupełnie nie podoba (szukam raczej dobrego kompromisu między Plasmą w KDE a lekkimi menedżerami okiem jak FVWM) i wolałbym wykorzystać fragmenty jego kodu do nauki i stworzenia czegoś własnego (tak wiem, pojawią się komentarze żeby rozwijać to co już jest), tym bardziej, że kiedyś zastanawiałem się nad próbą zrobienia własnego WM, ale trochę mnie to wtedy przerosło. Więc w sumie… dlaczego nie (pomysły nowych projektów są wyjątkowo tanie ;))? I tak do głowy przyszło mi QDE. Jako rozwinięcie Cute Desktop Environment (dla tych którzy jeszcze nie wiedzą, Qt czyta się jak „cute”).

Trochę poszperałem, próbując znaleźć czy już ktoś nie wpadł na podobny pomysł (a przynajmniej podobną nazwę), co mnie zaprowadziło na forum Ubuntu. Ostatnie posty są prawie sprzed roku i  chyba nic w tym kierunku nie zostało uczynione, więc raczej nikt nie będzie mnie próbował ukamienować za podprowadzenie nazwy (tym bardziej że wymyśliłem ją niezależnie). Przy okazji dotarłem też do Qlwm, który lekkim WMem napisanym w Qt2 (ale działa również na Qt3 i Qt4) z dodatkowym pagerem, paskiem zadań itp. Całość mieści się w około 5000 liniach (dla porównania fooaudio ma trochę poniżej 6000 linii)… za funkcjonalny WM? Wygląda coraz ciekawiej.

Pozwoliłem sobie stworzyć krótką listę tego jakie założenia by przyświecać miały QDE:

  • jak powiedział Linus: short, sweet and to the point
  • oparte tylko na Qt
  • płacimy (w pamięci i procesorze) tylko za to czego używamy
  • modularne oraz konfigurowalne, w połączeniu z powyższym, masz klocki, które do siebie pasują, więc złóż (dostosuj) z nich swój wygląd i funkcjonalność QDE
  • aplikacje dodatkowe (a kilka by się przydało w celu całkowitego uniezależnienia się od KDE) byłyby w rzeczywistości normalnymi aplikacjami, które mogłyby spokojnie funkcjonować poza środowiskiem (ale bez ciśnięcia na to, że musimy mieć wszystko własne), ew. z drobnymi bibliotekami dodatkowymi, które jednak dadzą wymierne korzyści funkcjonalne dla użytkownika, który nie używa samego QDE
  • (w odległej przyszłości) WM z menedżerem kompozycji
  • (chwilowo) więcej grzechów nie pamiętam

Może ktoś, już próbował zrobić coś w tej mierze? Albo chciałby współtworzyć taki projekt? Nie wiem, czy sam poprowadziłbym taki projekt (muszę pomyśleć trochę), nie tyle ze względu na brak czasu (bo ten jest) czy wiedzy (tej nie ma, ale zawsze można ją zdobyć) a na niemarnowanie czasu wolnego (czasami mam problemy ze skupieniem się nad projektami tworzonymi w czasie wolnym i tak jakoś ten czas ucieka). Jednak jeżeli projekt powstanie (czy to moim udziałem, czy kogoś innego) postaram się brać w nim aktywnie udział. Dobrze by było aby, jeżeli ktoś ma pomysł, zostawił go tutaj, w widocznym miejscu, żeby później mógł zostać spożytkowany.

Komentarze:

Ja poczekam jeszcze na to co pokaże KDE4.5. Jeśli się zawiodę, to będę zbierał użyteczne programy w samym Qt. Przeglądając Qt-apps.org, stwierdzam, że chyba najtrudniej, by było z dobrym menedżerem plików i z czymś do przeglądania dokumentów, zwłaszcza pdfów. Co do menedżera plików, to jest niby ten projekt http://qt-apps.org/content/show.php/QtFileMan?content=126862 , ale wygląda na jeszcze młody. Żeby tak Krusader był w samym Qt…

Wiem, że wspominane wcześniej Akonadi to nie jedyny problem, ale:
Wydaje mi się, że trochę wyważasz otwarte drzwi. Tylko dlatego, że jakiś dev debiliana wepchnął za dużo w paczkę (to mi zawsze najbardziej przeszkadzało w Debianie + i386 jako architektura) pisać własne środowisko? Generalnie jestem jak najbardzij za. Każdy nowy projekt open source’owy to szansa rozwoju dla wszystkich (Ty coś weźmiesz od innych, oni od Ciebie). Ale z drugiej strony, wszystko co wymieniłeś (z wyjątkiem czystości Qt) w KDE już jest. Ino trzeba je dobrze skompilować, ale to albo Gentoo/LFS albo zostań devem Debiana i przygotuj modularne paczki kde-*-light.

@piorekf: Niestety nie da się całkiem odgrodzić (bez pisania jakiegoś patcha) akonadi (patrz zależności paczek w PLD). Co więcej, akonadi coraz bardziej wchodzi z butami w KDE i niedługo cały PIM będzie od niego zależny (w tym Akregator którego używałem). Gdybym chciał wykorzystać ten mały ficzer z akonadi i kalendarzem, to samo KDE startowałoby tak samo długo jak cała reszta systemu z KDM.

Zapotrzebowanie na takie mniejsze środowisko napisane w Qt, niewątpliwie jest. Kwestia tego, że mało jest osób które chciałby się tego podjąć. Sam nie wiem czy się za to zabierać. Wolałbym, żeby zebrała się grupa w miarę doświadczonych ludzi, o spójnej wizji tego co chcą osiągnąć; przedyskutować projekt i wtedy ew. zabrać się do roboty.

@piotrekf

Twoje żale są śmieszne. Po pierwsze, pod architekturę i386, nie są kompilowane żadne paczki, posiadają tylko ją w nazwie ze względów historycznych. Elementy od których zależy wydajność od dawna są kompilowane na i686.
Po drugie, to nie deweloperzy Debiana są winni wrzuceniu Akonadi/MySQl, tylko jak wynika z tematu na forum.kde.org, plasma zależy od Akonadi. Dodatkowo deweloperzy dostrzegają problem i nie chcą by Akonadi/MySQL było domyśle, tylko chcą dostosować SQLite. W ogóle dziwne jest uwielbienie dla MySQL deweloperów KDE, bo robić np. program do odtwarzania muzyki z bazą opartą tylko na MySQL to szczyt idiotyzmu. Pomimo dysku SSD, Amarok startuje mi w okolicach 5s…

btw.

Matthew, instalujesz oczywiście Debiana bez pakietów polecanych i sugerowanych?

@iria: tak, kiedyś (jak zostało to wprowadzone domyślnie) to się nagle zdziwiłem, czemu KDE (pośrednio przez Phonona i Xine) wymaga bibliotek (i chyba gconfa) z Gnome. ;]

@iria:
z The Debian GNU/Linux FAQ:
„i386: this covers systems based on Intel and compatible processors, including Intel’s 386, 486, Pentium, Pentium Pro, Pentium II (both Klamath and Celeron), and Pentium III, and most compatible processors by AMD, Cyrix and others.”
Nie odpalisz czegoś na i386 jeśli jest skompilowane na i686. Kwestia innych instrukcji procesora (i686 ma ich dużo więcej i kompilatory z tego kożystają, a już na pewno gcc). A więc skoro piszą, że działa na i386 to musi być kompilowane pod i386.
A co do przeładowania paczek: OK, może tutaj nie da się tego obejść i w tym przypadku KDE zawsze będzie ciężkie, ale po co mi w Midnight Commanderze obsługa samby jak nie mam w domu ani jednego kompa z windą, albo po co mi do mplayera obsługa lirca, skoro żaden mój komputer nie ma pilota?

@piorekf: Co innego jest przeładowanie paczki, gdy musisz dociągnąć całe dwie dodatkowe usługi, niż gdy musisz tylko dodatkową bibliotekę. Jeżeli nie masz słabego sprzętu, to w tym wypadku możesz sobie pozwolić na lekką ekstrawagancję, tym bardziej, że możesz trafić na sytuację gdzie może Ci się to przydać (dlatego nie boli mnie to aż tak na laptopie (chociaż nadal nie wiem po co tam akonadi), ale na stacjonarnym już do szału doprowadza).

@Matthew
No to różni nas w zasadzie tylko to, że mnie zawsze doprowadza do szału. ;) Ja każdy swój komputer traktuję tak jak Ty desktopa.
Po to używam linuksa, żeby mieć system po mojemu. Tak jak ja chcę. Wiedząc co, dlaczego i po co tam jest, a do tego mogę sobie sprawdzić z czego się składa i jak jest zrobione jeśli będę miał taką potrzebę, a czasem mam.

SierraPapa @ 10 lipca 2010 o 13:50:

W zasadzie pisanie całego środowiska nie miałoby sensu, gdyż mamy do dyspozycji fluxboxa, który jest de facto toolkit-independent. Za to _bardzo_ chciałbym mieć takie narzędzie jak xfe (file manager, edytor i przeglądarka grafiki na foxtk) w wersji qt, oczywiście bez drawbacków oryginału.To, co na chwilę obecną proponuje beesoft commander jest imho odrobinkę za ubogie do codziennego użytkowania. Co do pozostałych aplikacji na qt ale bez kde- to one już są i to całkiem niezłej jakości (tea, smplayer, lyx i inne), a gtk na mojej maszynie gości już tylko z uwagi na flasha.

@piotekf

Tak jak mówiłem ważne rzeczy jak kernel, libc6, można zainstalować kompilowane na i686. Reszty nie ma sensu kompilować na jedynie i686, „szybsze” aplikacje uzyskasz właśnie usuwając niepotrzebne dodatki do nich. Nie jestem znawcą kompilacji, ale chyba bez problemu można ustawić w kompilatorze, by program jeśli będzie używany na i686 używał dodatkowych instrukcji.

Testował już ktoś ten Qlwm? Da się tego używać?

@piorekf

Wybacz literówkę w nicku.

@SierraPapa: nie mam nic przeciwko zależności do Qt (bo i tak z niego korzystam), ale chodzi o pewną wygodę użytkowania i dostarczanych funkcjonalności. Pod tym względem fluxbox po prostu leży. Już lepszym rozwiązaniem byłby fvwm. Problemem jest istnienie środowiska, która by było łatwe w użytkowaniu i w miarę lekkie (a napisane w Qt).

@iria: ja może dzisiaj spróbuję, tylko jeszcze nie wiem czy testować to na Debianie (w myśl przygotowania środowiska pod rozwijanie QDE) czy na jakimś innym distrze (bo całość pójdzie przez wirtualkę). Chociaż nie sądzę żeby jako takie było to środowisko szczególnie godne uwagi. Jego poziom funkcjonalności jest gdzieś na poziomie IceWM czy fluxboxa.

Antico jest rozwijane dalej tutaj: http://github.com/gustavosbarreto/antico

QDE juz istnieje: http://github.com/meponenlaschicascongafas/qde z zalozenia
mial nie uzywac X11.

Tylko szkoda, że link w jego podpisie prowadzi do tekstu:

„Blog (jak i wszystkie projekty, kursy, itp) zamknięty. Nie mam już siły i celu cokolwiek dalej robić.” :P

@cactus: no to trzeba będzie zmienić nazwę. ;P

@MadMike44: bo strona leży na joggerze jeszcze z czasów kiedy mi się zupełnie nic nie chciało. Jak wprowadzę multilanguage do tego bloga to pewnie się to zmieni lekko.

@iria:
„Nie jestem znawcą kompilacji, ale chyba bez problemu można ustawić w kompilatorze, by program jeśli będzie używany na i686 używał dodatkowych instrukcji.”
Nie można. Program kompilujesz na daną architekturę i już. A należy pamiętać, że i386 i i686 to dwie osobne architekturą, tylko i686 dla wstecznej kompatybilności umie uruchamiać kod z i386.
Pomysł, żeby system wykonująć binarkę wybierał sobie kod dla architektury jako pierwszy chyba wymyślił Apple w swoich Universal Binaries. Teraz jest pomysł, żeby to przenieśc na linuksa. Ma się to nazywać FatELF.

piotrekf: ale i tak to wszyscy zlali i sie nie przyjmie

@piorekf

Tak jak mówiłem nie jestem znawcą kompilacji, opierałem się na informacjach przeczytanych w internecie przez te wszystkie lata. ;) Możliwe, że były błędne i masz rację. Co do FatELF, to mi raczej chodziło o http://liboil.freedesktop.org/wiki/

Przepraszam, że tak przed Twoimi kolegami, ale w ogóle nie rozumiem o czym mówicie a strasznie podoba mi się pomysł na nazwę.

;D.

@Cactus:
Wiem że wszyscy to zlali i bardzo mnie to cieszy, bo uważam pomysł (przynajmniej w takim kształcie jak go przedstawiono) za kiepski.

@iria:
To jest trochę co innego. To jest kod którego fragmenty do skompilowania są wybierane na podstawie architektury na którą jest kompilowane. Tak samo robi np. ffmpeg. Jeśli kompilujesz na procesor obsługujący SSE4 to na podstawie odpowiednich instrukcji (np. #ifdef) kompilowana jest pętla zoptymalizowana pod SSE4, zamiast pętli zoptymalizowanej pod MMX, która to z kolei była by wybrana gdybyś kompilował na np. Pentium II.
Tutaj odpowiednie fragmenty kodu są wybierane zależnie od procesora, ale jeszcze na etapie kompilacji, tak aby binarka była możliwie najlepiej dopasowana do procka na którym będzie używana. Także jeśli masz np. ffmpeg skompilowane pod nawet i686 to Twój Core2 nie jest w pełni wykożystywany. A robi to mniej więcej taką różnicę, że przy kiepskiej optymalizacji filmy HD 720p kodowane h264 nie chodza na moim MSI Wind z procesorkiem Intel Atom, a po optymalizacji już da się oglądać. :)

Hi,
I liked his ideas. Currently I have a fork of Antico WM. This is a nice project with good ideas but the architecture and code are bad. Take a look at the „wm” branch which is a new code. (http://github.com/gustavosbarreto/antico).

@iria Pomimo dysku SSD, Amarok startuje mi w okolicach 5s…
To mi przy ~5 tys mp3 czasami nie wystartuje, musze 2 raz uruchomic, poza tym startuje w granicy 30s :D

@cojack

Cóż mogę powiedzieć, gdy się albo nie umie skonfigurować sobie systemu…
Uruchom sobie w ten sposób:
amarok –debug –nofork

i zobacz co tak długo trwa. Stawiam na playlisty.

Hmm, interesujący pomysł. Sam myślałem nad podobnym projekcie, który też miał się nazywać QDE ;) Z tym, że ja nie myślałem o pisaniu WM’a jako takiego – jako WM miał działać Openbox albo FVWM :D W mojej wizji chodziło o napisanie aplikacji w czystym Qt, których obecnie brakuje – czytnik RSS, menedżer plików (ostatnio znalazłem qtFM), coś jak Krusader, może panel, zarządca grafiki (coś jak DigiKam), kalendarz (a’la Orage) itp itd. Wtedy każdy mógłby sobie złożyć to w jedną całość. Czekam na jakieś informacje, czy Twój projekt rusza ;)

Kermit.

ten chyba nieco lepszy
http://qtcmd.nes.pl/

Cześć. Dokładnie rok temu miałem jednakowe wątpliwości. Chciałem zabrać się za modyfikacje Antico i jakieś wizualne wprowadziłem (w ramach wgryzienia się w kod). Czy coś więcej? Nie. Brak czasu jest tutaj najważniejszym problemem.

Obecnie najpopularniejszymi środowiskami graficznymi na Linuksie są Gnome oraz KDE. Gnome odrzuca mnie swoim prymitywizem. KDE natomiast robi się ociężałe. Panowie ładują dodatkowe funkcjonalności tam gdzie ich nie trzeba zapominając o usability czy responsywności.
Akonandi, Plasma (i jej dataengines), Nepomuk. Wszystkie te technologie mają szczytne cele ale są niezrozumiałe przez zwykłych użytkowników/niewykorzystywane/przerośnięte/słabo wdrożone. Zapomina się tutaj o najważniejszym USABILITY na każdym kroku. Ostatnio waham się nad testami Mac OS X a właściwie hackintosh-a.

Gdybym miał zmieniać środowisko z pewnością będzie mi brakowało KIO.

Hmmm co do nowego środowiska, moje propozycje:
– desktop: standardowy pulpit oparty o technologie Qt. Jeśli miały by w nim być widgety to tylko pisane w JS (QScript), sama wizualizacja QML, osobny widget=osobny wątek;
– „dock”: coś pomiędzy Ubuntu Unity a Docky. Docky ma świetne „inteligentne” chowanie się paska; unity natomiast sprawdza się z panelem ułożonym z boku; wskazany byłby tutaj kompromis;
– „global menu”: standardowo wkomponowane w górny pasek, którego nie można by przemieszczać
– WM: obramowania okien w oparciu o CSS (QStyle: http://wiki.github.com/gustavosbarreto/antico/creating-decorations)

Aplikacje tworzone na to środowisko nie miały by absolutnie żadnych zależności z dodatkowymi bibliotekami. Lepsza integracja ze środowiskiem następowała by poprzez wtyczki (wtyczka mogła by mieć zależność z biblioteką środowiskową).
Dzięki temu aplikacje miałby by większy potencjał rozwoju. Weźmy KDE. Zanim zaczniesz rozwijać jakąś aplikację musisz dociągnąć dużo dev-ów. Na Windwosie jest to pewnie jeszcze bardziej zakręcone.
W „naszym” wariancie popierało by się tylko qt-dev i jazda ;)

@Marcin Baszczewski: jakiś czas temu pisałem z Gustavo o dalszym rozwoju Antico/QDE, ale na razie muszę zająć się fooaudio, inżynierką i sesją wrześniową. Jeżeli wszystko pójdzie dobrze, to koło października powinienem się włączyć w ten projekt.

Chociaż mam odmienną wizję tego jak powinien wyglądać desktop (gnomowe ułożenie paneli, na dole taskbar, u góry menu, ikony, pulpity, tray, zegarek i inne aplety).

No właśnie ja też mam dużo pracy :(
Silnik do gier w ramach pracy magisterskiej (dla zainteresowanych w Qt), projekt grupowy na uczelnie, małą poprawkę i własne projekty komercyjne… tak, tak… z czegoś żyć trzeba;
Mam nadzieje, że jakiś z moich pomysłów wypali; gdybym miał bezpieczeństwo finansowe z głowy mógłbym zajmować się programistycznym wolontariatem w pełnym wymiarze (kręci mnie tworzenie ciekawych, pożądanych rzeczy na które mam duży wpływ).

Co do prac nad takim środowiskiem, mimo iż programowanie od ręki jest bardzo romantyczne przydało by się wiele mockupów oraz założeń, których to „trzymalibyśmy” się do końca. Najpierw projekt, później prace.

Ahhh i jeszcze jedna uwaga; strasznie nie podoba mi się w dystrybucjach Linuksowych KDM oraz GDM. Te aplikacje wyglądają zazwyczaj brzydko i nie integrują się ze środowiskiem. Ja wyobrażam sobie tego typu aplikację napisaną w Qt, która jeszcze przed zalogowaniem się – w chwili wpisywania hasła, wczytuje podstawowe moduły środowiska.

Tak, wiem teraz jest to niewykonywalne (z kdm/gdm), bo nie wiemy kto właśnie się loguje i do czego (kde/gnome).

Odpowiednik powinien obsługiwać tylko nowe środowisko i obligatoryjne elementy środowiska preloadować. Najwyżej tuż po poprawnym zalogowaniu „dosysać” dla preloadowanych aplikacji dodatkowe ustawienia (np dla zegarka format wyświetlania, dla dock-a ułożenie elementów).

@Marcin Baszczewski: załóżmy fundację finansującą deweloperów rozwijających Open Source. :D Ja bym tak mógł pracować nawet na dwa etaty. ^_^

Dzisiaj pojawił się news o lekkim środowisku opartym na Qt. Może one ci przypadnie do gustu http://osnews.pl/antico-light-lekkie-srodowisko-graficzne-oprate-o-bibliotek-qt

@godlark: i sam w komentarzach poddałem to lekkiej krytyce. Jeżeli z czegoś już korzystać to to co robi Gustavo albo stworzyć coś zupełnie nowego (albo się podzielić robotą, bo na razie Gustavo robi sam WM).

@Matthew: W sumie cokolwiek tylko, żeby miało to szanse dojrzeć zanim powstanie fork

Przecież Antico Gustava i Antico Light pewnie się połączą. Przynajmniej tak wynika z komentarzy na qt-apps pod Antico Light.

Dodaj komentarz:

 

Subscribe without commenting