Na stronie Trolltecha, producenta biblioteki Qt (chyba najlepszego toolkitu dla C++, słynącego chociażby ze swojej technologii Slots&Signals), wspaniałej biblioteki Qt ;) pojawił się bardzo interesujący zwiastun. Otóż panowie i panie z Trolltecha pracują (ponoć już od października 2006) nad wersją Qt dla Windows CE.
Co to oznacza?
Przede wszystkim to, że - poza Javą - na platformy Windows Mobile pojawi się wreszcie konkurencyjna dla MFC/.net technologia (dzięki natywnym kompilacjom dla odpowiedniej platformy będzie na pewno dużo wydajniejsza od Javy), do tego otwarta, dostępna, dość znana i - przede wszystkim - potężna. Warto pamiętać, że Qt świetnie sprawdziło się już w urządzeniach mobilnych - czego dowiodła Qtopia.
Ciekaw jestem jak będzie wyglądała sprawa licencjonowania (naiwnie marzę o double-licensingu jak w wersjach desktopowych Qt, ale pewnie będzie tylko commercial).
Jakkolwiek na to nie spojrzeć - to dobra wiadomość!

Niejeden pewnie zna zalety mechanizmu DCOP. Jeszcze więcej osób używa go z pasją nawet o tym nie wiedząc. Dzięki niemu np. możliwa jest komunikacja wielu aplikacji KDE ze sobą, a także komunikacja użytkownika z aplikacjami (np. z poziomu skryptów). Mechanizm, dzięki temu, że jest dobrem ogólnym KDE, jest niesamowicie potężny. Zwłaszcza wsadowa komenda dcop.
W moim MetaMonitorze na przykład możesz ‘zdalnie’ uruchomić okno konfiguracyjne, pokazać komunikat, zamknąć go itd. Możesz wymusić sprawdzanie poczty w KMail jednym poleceniem (wpisanym np. do Crona), jeśli oczywiście chcesz, bo KMail ma własny mechanizm sprawdzania poczty co jakiś czas. ;) Możesz napisać skrypt, który wyświetla użytkownikowi pytanie o to czy np. chce przejść na stronę domową projektu, a gdy ten się zgodzi, wykonać:

dcop konqueror KonquerorIface createNewWindow http://moja.strona.net

Generalnie reklamować DCOP nie trzeba (może warto tylko dodać, że w KDE 4 będziemy mieli jeszcze lepiej za sprawą nowocześniejszego i jeszcze bardziej powszechnego D-Bus, który nie jest ograniczony tylko do KDE).

Było jednak coś, co nie pozwalało mi wykorzystywać dobrodziejstw polecenia dcop w pełni. O ile przekazywanie argumentów numerycznych było proste (wystarczy wpisać liczbę), argumentów tekstowych dość intuicyjne (stringi piszemy w apostrofach jeśli zawierają kilka słów, lub niekoniecznie z nimi, jeśli to tylko jedno słowo), o tyle przekazanie argumentu QStringList było dla mnie czarną magią.
Jak to się robi? Kombinowałem ze wszystkimi znanymi mi sposobami i nic…

Dopiero Michelle sprawiła, że zająłem się tym nieco konkretniej. Michelle używa Firefoksa, a - jak wszyscy wiemy - jego wbudowany czytnik kanałów RSS jest, delikatnie mówiąc, dość ubogi. Więc jak tylko zaraziłem Ją RSSoManią, natychmiast pożałowałem, bo przygniotła mnie sterta pytań ‘A jak ustawić, żeby…’ ;) Na pomoc przyszedł mi Akregator - niesamowity czytnik. Wygodny, konfigurowalny, szybki i… KDE’owy :) Pozostał tylko jeden problem. Jak przekazać Akregatorowi informację o URL kanału z poziomu Firefoksa? Na szczęście FF ma możliwość wykonania komendy z adresem kanału. No, ale tu właśnie pojawił się problem. Interfejs DCOP Akregatora pozwala wprawdzie na dodanie do niego kolejnego URL kanału RSS, jednak postać polecenia jest taka:

xis@hedera ~ $ dcop akregator AkregatorIface
QCStringList interfaces()
QCStringList functions()
void openStandardFeedList()
void fetchFeedUrl(QString)
void fetchAllFeeds()
void saveSettings()
void addFeedsToGroup(QStringList,QString)
void exportFile(KURL url)
void addFeed()

Łatwo się domyślić, że pierwszy parametr to lista URLi, a drugi to grupa, do jakiej mają być kanały dodane. I jak tę listę przekazać? Ano tak:

#!/bin/bash
dcop akregator AkregatorIface addFeedsToGroup [ $1 ] Michelle

Taki skrypcik zapisujemy pod postacią np. ‘addrss’, dajemy prawa wykonania, umieszczamy gdzieć na naszej $PATH i już możemy konfigurować Firefoksa wskazując mu komendę addrss do wykonania przy dodawaniu kanału informacyjnego.

Działa super :)

Dodam tylko, że aby przekazać w QStringList większą ilość stringów, wystarczy oddzielić je przecinkami.