Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Ubuntu Application Indicators aka KDE Status Notifier Items - historia prawdziwa

Zapewne każdy użytkownik Ubuntu zauważył troskę, jaką Canonical przejawia w stosunku do zachowania wizualnej konsystencji całego pulpitu. Szczególnie to widać po panelu i zasobniku systemowym, gdzie twórcy Ubuntu poczynili dość radykalne kroki w jego uporządkowaniu. Wszytko oczywiście w trosce o użytkownika, tak aby mógł skupić się on na codziennej pracy i aby nie rozpraszały go ikony w tray (niespójne dodajmy). Aby tego dokonać deweloperzy pracujący nad dystrybucją, wykorzystali potencjalny standard freedesktop.org, mający zastąpić starą specyfikację zasobnika systemowego. O czym mowa? Chodzi tu oczywiście o Application Indicators, przez użytkowników KDE znane jako Status Notifier Items.

Początki

Próba zmiany specyfikacji zasobnika systemowego znanego również jako XEmbed została podjęta przez deweloperów KDE na liście mailingowej xdg (freedesktop.org). Jest to miejsce gdzie omawiane są potencjalne standardy (tak istnieje coś takiego). Niestety do tanga trzeba dwojga, a drugi partner zwany GNOME jest naprawdę twardogłowy w tym względzie (łagodnie rzecz ujmując). W każdym razie Marco Martin zaproponował nową specyfikację do dyskusji klik. Od samego początku spotkała się ona z zainteresowaniem Auréliena Gâteau (zawodowo pracującego dla Canonical, prywatnie dewelopera KDE ;) ) Kilka miesięcy później dyskusja rozgorzała na nowo, ponieważ Canonical postanowił przyjąć zaproponowaną specyfikację, co można przeczytać tutaj. Twórcy Ubuntu opracowali specjalną implementację dla GNOME zwaną libappindicator. Sytuacja wydawała się jasna, KDE zaimplementowało specyfikację, Canonical tworzyło wersję dla GNOME.

GNOME - z nami tak łatwo nie pójdzie

Pozostali deweloperzy GNOME byli średnio zainteresowani cała sprawą, ale nie mówili nic otwarcie, aż do próby włączenia libappindicator do GNOME. Niestety, niechęć jaka panuje między twórcami Ubuntu a osobami prcujacymi nad GNOME sprawiła, że propozycja została odrzucona. Dodam tylko, że jednym z powodów był fakt, iż całość nie pasowała do ram projektowych GNOME Shell.

Libappindicators jako filar nowego interfejsu Ubuntu.

Chłopaki z Canonical się specjalnie nie zmartwili odrzuceniem swojej implementacji standardu bo i tak pichcili już własnego forka GNOME zwanego Unity (ale o tym dokładniej w innym wpisie), którego premiera odbyła się niespełna 3 miesiące później. Canonical ma bardzo pragmatyczne podejście i postanowiło upiec 2 pieczenie na jednym ogniu. Tak, wiec nową specyfikację zasobnika systemowego wykorzystało do stworzenia swojego własnego panelowego API. Takie zachowanie skrytykował Aron Seigo (czołowy deweloper KDE oraz współtwórca specyfikacji). Pozwolę sobie przytoczyć jego słowa:

This is fairly spectacular. Canonical has taken an attempt at improving the system tray area which has historically been crammed with everything one can imagine, and actually managed to take that new thing and make the situation worse. How? By encouraging people to use it as a general purpose panel plugin API. Take the weather item, for instance: the information is shown in a menu, as menu entries .. even though they aren't actions at all. And what category of notifier does it belong to? Applications? Sure isn't hardware, system or communications. It's a complete misuse of the UI elements from top to bottom, whether we look at it from the perspective of the system tray / message indicator area itself or the use of menus for these things. Status notifiers, or "app indicators" as Canonical re-branded them, is a hammer. Not everything is a nail. Plasma can also put the weather in your system tray if you like (to take that example again), but it isn't done by misusing status notifiers. With a reasonably decent applet API you can achieve the exact same results minus the atrociousness. Now, I agree that the current set of indicators you have make for great screenshots, but people need to use this software not hang it on their wall. :/

Co po moim skromnym tłumaczeniu brzmi tak:

To jest raczej spektakularne. Canonical podjęło próbę usprawnienia obszaru zasobnika systemowego, który historycznie był zapchany wszystkim czym tylko można sobie wyobrazić i poprzez użycie nowej rzeczy (mowa o libappindicators) udało mu się jeszcze pogorszyć sytuację. Jak? Poprzez zachęcanie ludzi do używania go jako ogólnego panelowego API. Weźmy dla przykładu element reprezentujący pogodę: informacja jest pokazana w menu, jako pozycja w menu... mimo, że nie są to w żadnym stopniu działania. I do jakiej kategorii powiadomień ono należy? Programy? No fakt, przecież nie jest to sprzęt, system czy komunikacja. Jest to kompletne nadużycie elementów interfejsu użytkownika od góry do dołu, nieważne czy patrzymy na to z perspektywy zasobnika systemowego czy używania menu do tego typu rzeczy. "Status notifiers", lub "app indicators" jak nazwało je Canonical to młotek. Jednak nie wszytko jest gwoździem. Używając pulpitu plazmy, również można umieścić informacje o pogodzie (pozwolę sobie użyć tego przykładu ponownie) w zasobniku systemowym, jednak nie jest to robione poprzez nadużywanie "status notifiers". Używając w miarę przyzwoitego "apletowego" API, możecie uzyskać dokładnie te same efekty bez wynajdywania koła od nowa. Obecny zestaw indykatorów, który stworzyliście nadaje się świetnie do pokazywania na obrazkach, jednak ludzie chcą używać oprogramowania, a nie wieszać je na ścianach.Żeby pokazać o czym mówił Aron, pozwolę sobie umieścić poniższy zrzut ekranu znaleziony w odmętach internetu:

Co więcej jest to jeden z filarów nowego, innowacyjnego (sarkazm) środowiska graficznego, przez złośliwych zwanego forkiem GNOME. Mowa oczywiście o Unity, w którym Application Indicators, takie jak te stanowią jeden z podstawowych elementów środowiska.

Jedziem z tym koksem czyli jak zachęcić deweloperów do nowego standardu

W KDE jest tak, że aplikacje które używają starego jak i nowego (jak tylko niemrawi deweloperzy GNOME go przyjmą) standardu, są wyświetlane w zasobniku systemowym. Ubuntu od wersji 11.04 poszło na całość i zgodnie z dewizą "najpierw robimy później myślimy" wyłączyło dostęp do zasobnika systemowego dla aplikacji używających starego standardu (czyli zasadnicza większość). A wszytko ku chwale wizualnej konsystencji. Stąd też aplikacje napisane na przykład w Qt, dajmy na to kadu zostały pozbawione tej możliwości. Bo i po co komunikatorowi ikona w tray. Oczywiście autorzy zostawili możliwość zmiany tej, hmm opcji. Wystarczy zmienić odpowiednia wartość w gnomowym rejestrze. Jednak chłopaki z Canonical się zreflektowali i przynajmniej dla aplikacji napisanych w Qt problem rozwiązali. O szczegółach można poczytać na blogu Auréliena Gâteau. Standard to standard, stąd też co działa w Ubuntu

działa i w KDE (przynajmniej w kubuntu)

Warto zwrócić uwagę na tooltip, który integruje się z motywem plasmy.

Rys chronologiczny

Ten wpis jest dość długi i niektórzy mogą poczuć się zagubieni w natłoku informacji, toteż poniżej przedstawiam, najważniejsze daty dotyczące historii standardu:

- wrzesień 2009 Marco Martin prezentuje pierwszy szkic (wtedy jeszcze zwany KNotificationItem) klik .
- 4 miesiące później w grudniu 2009 Aurélien Gâteau informuje, iż canonical rozpoczęło pracę nad implementacją dla GNOME (zwaną libappindicators) klik - styczeń 2010 implementacja w KDE 4.4
- luty 2010 deweloperzy GNOME odrzucają implementację standardu klik zaproponowaną przez canonical
- ubuntu 10.04 - pierwsza wersja z libappindicators
- ubuntu 11.04 - libappindicators ( Application indicators) jako podstawa nowego środowiska.

To be continued

Zapewne wielu czytelników (żarty się mnie dzisiaj trzymają) zastanawia się czemu poświęciłem temu tematowi (chyba najdłuższy) wpis. Spieszę z odpowiedzią. Otóż było to konieczne, bo następna notka będzie o bardzo skomplikowanej sytuacji panującej obecnie w GNOME.

PS. Pozdro dla Ave5 za pomoc, nazwijmy ją merytoryczną :) 

Komentarze

0 nowych
Quest-88   15 #1 31.08.2011 00:27

Czy w tym przypadku GNOME = RedHat?

lucas__   13 #2 31.08.2011 00:38

Quest-88
W przypadku GNOME Shell zdecydowanie tak.

Ave5   8 #3 31.08.2011 13:30

To wszystko jest i tak przejściowe, nie ma bata żeby Shell i Unity istniały równolegle jak w obecnej konfiguracji. Ktoś kogoś zje :)

RubasznyRumcajs   6 #4 31.08.2011 13:47

@Quest-88
RedHat byl zawsze glownym deweloperem Gnome'a. pamietasz moze Bluecurve (i raban jaki podniosly freetardy) :-)?

@Ave5
IMO- najwiecej na tym skorzysta XFCE i Windows /tj. gdy ktos dojdzie do wniosku ze wystepujacy w linuksie burdel mu nie odpowiada jednak/

lucas__   13 #5 31.08.2011 22:14

Ave5
Słuszna uwaga, to że nie ma miejsca na 2 nowe DE jest pewne jak w banku.
RubasznyRumcajs
Windows raczej nie ma z czego korzystać, jakoś nie widzę tych milionów (sarkazm) użytkowników Linuksa migrujących na Windowsa. XFCE ma konkurenta w postaci LXDE. Jedyną sensowną alternatywą jest... ;)

Druedain   14 #6 02.09.2011 11:38

Czekam na ciąg dalszy bo zapowiada się ciekawe śledztwo :)

@RR jak na mój gust, to prędzej KDE na tym skorzysta.