Czy powinno się tworzyć aplikację na wiele systemów operacyjnych? – analiza przypadku komunikatora Kadu
9 lutego 2010, patpi
Coraz częściej użytkownicy komputerów mają możliwość używania tych samych aplikacji na wszystkich popularnych systemach operacyjnych. W dzisiejszym artykule spróbuje zastanowić się nad sensem takich działań. Przede wszystkim czy da się stworzyć aplikację działającą na wielu systemach operacyjnych, która byłaby w pełni zintegrowana z natywnym środowiskiem? Czy da się stworzyć wieloplatformową aplikację, która będzie wyglądać i zachowywać się „naturalnie” w różnych środowiskach operacyjnych? A jeśli nie, to czy próby tworzenia wieloplatformowych aplikacji, z góry skazanych na gorszą integrację z natywnym środowiskiem, powinny być zaniechane? By odpowiedzieć na te pytania najlepiej dokonać analizy konkretnego przypadku, wybierzmy przypadek komunikatora Kadu.
Komunikator Kadu 0.6.5.4 ze wsparciem dla sieci gadu-gadu 8 i 10 został przedwczoraj wydany. Jest to ostatnia planowana wersja Kadu bez wsparcia dla innych sieci komunikacyjnych takich jak XMPP/Jabber i Tlen. Najważniejsze zmiany, które są częścią tego wydania nie są związane ze wsparciem dla różnych systemów – bowiem główne zmiany w tym wydaniu to:
• obsługa długich opisów z możliwością wpisania do 255 znaków
• nowe statusy “Chętny do rozmowy” oraz “Nie przeszkadzać”
• możliwość kontaktu z użytkownikami z nowej puli numerów dla sieci gadu-gadu (tzw. długie numery)
• naprawione zostało wysyłanie obrazków
• naprawione zostało wysyłanie smsów przez bramkę Plus GSM
Jednakże czytając pełną listę zmian możemy znaleźć między innymi takie oto zmiany:
• zostało dodane wsparcie dla systemu Maemo (Nokia N900)
• został dodany nowy moduł Single_window – lista kontaktów i rozmowy w jednym oknie (które to moduł jest właśnie używane w systemie Maemo jako główny interfejs użytkownika)
• zostało naprawione działanie modułu Profiles pod Mac OS X.
• poprawiony został błąd w pozycjonowaniu okna rozmowy z nową osobą pod Windows
• naprawione zostało wykrywanie zestawów ikon, emotek i dźwięków w ścieżce użytkownika dla systemu Windows co umożliwia zmiany wyglądu pod tym systemem
• wprowadzono drobne poprawki związane z kompatybilnością z systemem Windows7 i Mac OS X
• poprawione zostały skrypty create_macosx_bundle.sh i create_windows_bundle.bat
• dodano drobne usprawnienia kompilacji pod Windows
Jak widać twórcy Kadu oraz osoby piszące łatki do Kadu coraz intensywniej pracują nad dostosowaniem aplikacji do lepszego działania pod różnymi systemami operacyjnymi. Pytanie tylko czy ta praca może zakończyć się sukcesem? Czy da się stworzyć wieloplatformowy komunikator dobrze działający pod wieloma systemami operacyjnymi? I czy w ogóle powinno się podejmować takie próby?
Twórcy przeglądarki Firefox pokazali, że da się stworzyć wieloplatformową przeglądarkę dobrze działającą w różnych systemach operacyjnych, przypadek komunikatora jest chyba jednak przypadkiem trudniejszym. Interakcja aplikacji do komunikacji błyskawicznej z systemem operacyjnym jest bardziej złożona i dla lepszej integracji z systemem operacyjnym wymagana jest większa liczba zmian.
Oto lista wyzwań z którymi zmaga się komunikator Kadu na różnych systemach operacyjnych.
Windows:
1. Nieukończony i wybrakowany zestaw ikon dla Windows. Domyślny zestaw ikon Kadu bazujący na ikonach Silk wydaje się nie pasować do wyglądu systemu Windows.
2. Czasami błędnie działa dokowanie w trayu
3. Nie wszystkie moduły zewnętrzne działają bez błędów pod systemem Windows
4. Moduł wielu profili działając zgodnie z “filozofią” systemu Linux działa inaczej niż tego oczekują użytkownicy Windowsa
Analiza wyzwań: Brak zestawu ikon lepiej pasującego do systemu Windows wymaga po prostu osoby chętnej do dokończenia zestawu ikon dedykowanego dla tego systemu, nie jest to problem techniczny lecz raczej problem braku chętnego do wykonania tej pracy grafika. Błędne dokowanie w trayu pod Windowsem jest już jednak błędem technicznym Qt-win32 i osoby zainteresowane Kadu-windows muszą bądź poczekać na naprawę tego błędu bądź samemu poprawić bibliotekę Qt. Dostosowanie modułów zewnętrznych do systemu Windows wymaga zaś programistów chcących dostosowywać nowe wersje zewnętrznych modułów do systemu Windows. Takie poprawki są na ogół trywialne, ale wymagają dodatkowych developerów zainteresowanych poprawa jakości działania Kadu pod danym systemem – na ogół główny developer danego modułu używa tylko jednego systemu i tylko na nim testuje swoją aplikację.
Moduł wielu profili w Kadu (moduł Profiles) jest ciekawym przypadkiem.
Kadu będąć początkowo tylko komunikatorem dla systemow unixowych zakładało, że kazdy dodatkowy uzytkownik systemu ma swoje własne konto w systemie. Dlatego moduł Profiles zakłada, że użytkownik posiada jedno konto “główne”, które zawsze zostaje uruchamione. Pozostałe profile są uruchamiane obok niego. Nie ma możliwości wybrania na starcie programu, który z profili ma zostać użyty. Jest to działanie, którego użytkownicy Windowsa nie rozumieją (niektórzy użytkownicy Linuksa także). Jakie jest wyjście z tej sytuacji? Na razie nie wiadomo 
Mac OS X:
1. Domyślny zestaw ikon Kadu bazujący na ikonach Silk wydaje się nie pasować do wyglądu systemu Mac OS X.
2. Menadżer okien w Mac OS X zachowuje się inaczej niż inne UNIXowe menadżery okien
3. Okno konfiguracji niezgodne z wytycznymi HIG dla Mac OS X
4. Szerokość okna Kadu w przypadku dużej liczby zakładek – zakładki nie chcą się kurczyć poniżej pewnego rozmiaru, strzałki się nie pokazują (prawdopodobnie bug w Qt)
5. Nie odświeżanie się ikony w trayu w przypadku przełączenia się innej aplikacji na pełny ekran i z powrotem (prawdopodobnie bug w Qt)
Analiza wyzwań: Brak zestawu ikon lepiej pasującego do systemu Mac OS X wymaga po prostu osoby chętnej do utworzenia zestawu ikon dedykowanego dla tego systemu, nie jest to problem techniczny lecz raczej problem braku chętnego do wykonania tej pracy grafika. Można na przykład częściowo wykorzystać ikonki z Firefoxa 3.6 dedykowane dla systemu Mac OS X, dorysować brakujące ikony i w ten sposób utworzyć zestaw, który komponuje się z wyglądem Mac (chodzi zarówno o styl ikon, ale także zgodne z HIG Mac OS X nie pokazywanie ikonek na przyciskach OK/Zastosuj/Anuluj). Problem dostosowania Kadu do menadżera okien Mac OS X jest dobrym przykładem problemów sukcesywnie rozwiązywanych. Użytkownicy Kadu na Mac OS X zgłaszali błędy na forum związane z zachowaniem okien, programista Kadu Tomasz Rostański po kolei je rozwiązuje. Okno konfiguracji jest jednym z tych niuansów, które mogą nie być skutecznie rozwiązane. Aktualne okno konfiguracji Kadu musiałoby być dostosowane specjalnie do HIG Mac OS X by wyglądać i zachowywać się „natywnie”. Programiści zaś, co zrozumiałe, chcą by jak najmniej kodu Kadu było pisane specjalnie dla tylko jednego systemu i by było „jak najmniej ifdef’ów w kodzie”. Można tutaj wybrać albo większą spójność kodu pomiędzy platformami albo bardziej ścisłe przestrzeganie zaleceń HIG dla danej platformy, nie ma idealnego rozwiązania.
Linux/GNOME
1. Brak integracji powiadomień Kadu ze środowiskiem GNOME
2. Niewykorzystywanie systemowego zestawu ikon używanego w GNOME
3. Brak integracji z GNOME Keyring oraz książką adresów GNOME
4. Integracja z Gnome-Shell (interfejsem GNOME3)
Analiza wyzwań: Integracja Kadu z powiadomieniami implementującymi nową specyfikacją free desktop jest dostępna już w tym wydaniu. Najbliższe wydanie Ubuntu będzie używać tej specyfikacji, w przyszłości prawdopodobnie także całe środowisko GNOME, w tym więc przypadku w niedługim czasie Kadu będzie zachowywało się jak każda inna aplikacja pisana w GTK. Jeżeli chodzi o zestawy ikon, to Kadu będzie używać zestawu ikon aktualnie używanego w GNOME dzięki implementacji Freedesktop Icons in Qt. Prawdopodobnie stanie się to za dwa wydania, gdy Kadu wymagać będzie biblioteki Qt w wersji minimum 4.6. Integracja pod względem zachowania i wyglądu z Gnome-Shell prawdopodobnie będzie wymagać zmian w plikach .desktop, oraz innych poprawek. Aktualnie z powodu braku developerów Kadu używających GNOME przydałaby się bardzo każda osoba, która może zadbać o ściślejszą integrację z tym pulpitem oraz technologiami takimi jak GNOME Keyring, książka adresów, itp.
Linux/KDE
1. Brak integracji powiadomień Kadu ze środowiskiem KDE
2. Niewykorzystywanie systemowego zestawu ikon używanego w KDE
3. Brak integracji z KWallet, Plasmą, książką adresów KDE i innymi technologiami KDE
Analiza wyzwań: Integracja Kadu z powiadomieniami implementującymi nową specyfikacją free desktop jest dostępna już w tym wydaniu, tak więc Kadu będzie zachowywało się jak każda inna aplikacja pisana specjalnie dla KDE. Jeżeli chodzi o zestawy ikon, to Kadu będzie używać zestawu ikon aktualnie używanego w KDE dzięki implementacji Freedesktop Icons in Qt. Do integracji z pozostałymi technologiami KDE trzeba by było napisać oddzielny moduł i włożyć w niego trochę pracy, ale to jest kolejna rzecz, która jest techniczne możliwa.
Maemo (Nokia N900)
1. Brak graficznego interfejsu użytkownika dedykowanego dla urządzeń mobilnych.
Analiza wyzwań: Od jakiegoś czasu można używać Kadu na Maemo (Nokia N900), dla urządzeń mobilnych interfejs powinien być jednak specjalnie zaprojektowany. Interfejs zapożyczony bezpośrednio ze stacji roboczych po prostu nie będzie wygodny w używaniu. By stworzyć Kadu w pełni zintegrowane z platformą Maemo należałoby umożliwić napisanie „alternatywnych” interfejsów graficznych dla Kadu i zaprojektować interfejs dla urządzeń mobilnych.
Haiku OS
1. Niewykorzystywanie systemowego zestawu ikon używanego w Haiku OS
2. Brak pełniejszej integracji z tym środowiskiem
Analiza wyzwań: Haiku to system dopiero zyskujący na popularności ze względnie małą liczbą zewnętrznych aplikacji. Tutaj chętni developerzy chcący pomóc w integracji Kadu z Haiku OS mieliby duże pole do popisu
Jak widać, przed aplikacją, która chce dobrze dopasować się do wielu systemów operacyjnych stoi wiele ciekawych wyzwań. Pytania czy warto podejmować wysiłek, czy użytkownicy potrzebują dobrej integracji z używanym systemem? Czy też wolą aplikacje, które działają w taki sam sposób na wielu systemach operacyjnych (czytaj: czy używają własnych rozwiązań interfejsów graficznych nie integrując się z używanym systemem)? A może integracja z systemem może ograniczyć się tylko do niektórych z w/w aspektów, których? Zapraszam do dyskusji, wasze opinie m.in pomogą developerom Kadu zdecydować na czym skupić uwagę w dalszym rozwoju tej aplikacji.
Autorem tego tekstu jest Piotr Pełzowski, odpowiedzialny za public relations Kadu i pracujący nad użytecznością projektu Kadu wraz z KaduUsability.
Liczba komentarzy: 53
W komentarzach możesz używać prostych znaczników HTML. Przykłady:
- Link: <a href="jaklinux.org">Linux dla każdego</a>,
- Wytłuszczenie: <strong>tekst pogrubiony</strong>,
- Kursywa: <em>tekst pochylony</em>,
- Przekreślenie: <strike>
tekst przekreślony</strike>, - Kod: <code>
printf("blok kodu");</code>, - Cytat: <blockquote>cytat</blockquote>
Przyznam, że dla mnie osobiście nie ma znaczenia, czy ikonki w programie pasują do reszty systemu, czy nawet nie oczekuję od komunikatora integracji z programami pokroju książek adresowych (których z resztą nie używam). W ogóle jak się zastanowić, to nie ma zbyt wielu wieloplatformowych programów, które na każdym systemie wyglądają i zachowują się idealnie. A gdy już taki program znajdziemy, to najczęściej okazuje się on wielkim projektem, za którym stoją dziesiątki programistów. Dlatego nie wiem, czy to jest dobra droga dla projektu średnich rozmiarów, jakim jest Kadu. Priorytetem chyba jednak powinno być poprawianie błędów, również tych specyficznych dla danych środowisk. Nawet jeśli dotyczą samego QT, a nie Kadu. W dalszej kolejności nowe funkcje, a próbę pełniejszej integracji do różnych środowisk zostawiłbym na koniec, kiedy już trudno będzie znaleźć cokolwiek innego. No, ale to tylko moje zdanie
Cześć,
Dzieki za opinie.
“Priorytetem chyba jednak powinno być poprawianie błędów, również tych specyficznych dla danych środowisk. (…) a próbę pełniejszej integracji do różnych środowisk zostawiłbym na koniec”
Tylko ,że te w/w błędy to właśnie błedy spec. dla poszczególnych środowisk. Innych błędów związanych z integracją z systemem raczej nie ma.
Znaczna wiekszosc kodu Kadu jest bowiem wieloplatformowa. Rozumiem wiec, ze dla Ciebie jest dobrze tak jak jest?
IMO trzeba rozróżnić błędy specyficzne dla danej platformy na ważniejsze (złe zachowywanie się interfejsu użytkownika, nawet spowodowane bugami w QT) i mniej ważne (ikonki niezintegrowane ze środowiskiem, olewanie zaleceń HIG, brak integracji z książkami adresowyi, plasmami itd). Te ważniejsze powinny być rozwiązywane nawet kosztem kilku(nastu) ifdefów więcej. Mniej ważnymi nie powinniśmy sobie zaprzątać głowy, bo większość użytkowników kadu nie zwraca na to nawet uwagi. Więc integracja ze środowiskiem – tak, ale jedynie do pewnego stopnia.
Faktycznie, napisałem w taki jakby sprzeczny sposób (późno było
). Ogółem po prostu trzeba do tych problemów podchodzić ze zdrowym rozsądkiem. Niektóre wymienione przez Ciebie są dość poważne, tzn. mogą uprzykrzyć życie końcowemu użytkownikowi (jak np. pkt. 2 z problemów w wersji windowsowej). Inne, jak np. wspomniane ikonki, to sprawa mało istotna.
Zastanawiam się, czy podejście perfekcjonistyczne do wieloplatformowości nie spowolniłoby znacząco rozwoju samego programu, a tego pewnie większość użytkowników by nie chciała. Z jednej strony, jak już się ma wersje na kilka platform, to chciałoby się, żeby przynajmniej chodziły bez jakichś poważniejszych błędów. Z drugiej strony już teraz widać, że samo to będzie się wiązało z wieloma problemami. Dodajmy do tego kwestię popularności Kadu na systemach innych, niż Linux (której właściwie nie znam, ale się domyślam). Jeśli uważacie, że znajdziecie tam rzeszę użytkowników, to w porządku. W przeciwnym wypadku powstaje pytanie – czy warto się wysilać? Poza tym niektóre porty mają większy sens, niż inne. Port na Windows, nawet pomimo konkurencji, ma sens ze względu na samą popularność Windowsa. Ale port na Mac’a, czy jeszcze bardziej na Haiku? Oczywiście dopóki pracuje nad tym jakiś nowy zapaleniec, jest w porządku. Ale gdy odrywa się kogoś ze “starej ekipy” do robienia niszowych rzeczy, to już wtedy przestaje być fajnie. Może właściwą drogą byłoby porzucenie części portów i lepsze skupienie się na pozostałych?
akurat port na maca ma ogromny sens, bo na maca brakuje JAKIEKOKOLWIEK prozadnego klienta GG. o ile sie nie myle, to jedyna konkurencja dla kadu sa Adium (czy jakos tak), ktore (ponoc) jest raczej liche z natury, oraz przegladarkowe wersje GG, ktorych komentowac nie trzeba raczej. tak wiec w tej sytuacji Kadu na OSX ma jak nabardziej ogromny sens – powiedzialbym wrecz, ze wiekszy, niz na windowsie
i podejrzewam, ze na haiku sytuacja wyglada podobnie – moze i system malo popularny, ale jego uzytkownicy pewnie chetnie by pogadali czasem na GG bez zabaw w transporty z jabbera, a konkurencja dla kadu znikoma, o ile w ogole jakas jest…
XMMP -> XMPP
Literówka
Poprawione, dzieki.
Autor uczepil sie systemowego zestawu ikon jak jakiejś najwazniejszej funkcji a jak dla mnie to jest wogole nieistotne. Czy takie znane programy jak np. Office2007, Winamp, GaduGadu, Skype uzywaja systemowego zestawu ikon? Nie uzywają, bo autorzy doszli do wniosku ze to nie ma sensu, a czasem jest wręcz paskudne…
Generalnie pisanie aplikacji wieloplatformowych, gdzie docelowym użytkownikiem jest zwykły user, taki który nie wie co to shell, i ma OS zainstalowany przez dziecko albo przez pana z komputronika, nie będzie się zastanawiał co wybrać, tylko weźmie to co ładne i prosto działa. Portowanie na OSX to słaby pomysł, bo OSX ma iChat’a i Adium (które wspiera chyba wszystko co się da, nawet czat facebooka). Pisanie na win32? Tam jest już gadu-gadu, a dla poweruser’ów jest np. Miranda. Sensowniej byłoby pracować nad jakością kodu, opcjami dostępnymi, integrowaniem kolejnych protokołów, profilowaniem wydajności i ładną integracją z Gnomem/KDE. Dobrym ruchem prawie zawsze jest praca na szeroko pojętym pozytywnym wrażeniem korzystania z programu. Portowanie na różne platformy ma sens głównie dla gier (np DoW2 dla OSX, chętnie bym ujrzał )
I tym bardziej potrzebne jest Kadu
Naprawdę bardzo dużo użytkowników GG przebąkuje, że przydałoby się takie GG Lite bez wszystkich tych bajerów i, za przeproszeniem, pierdół, za to służące do komunikacji.
Myślę, że jakby Kadu lepiej rozreklamować to na Windowsie mogłoby zyskać sporą rzeszę użytkowników.
Nie zgodzę się że pisanie pod win32 nie ma sensu. Są userzy np. ja uważający kadu za jeden z najlepszych komunikatorów. Niestety pod win32 ciężko jest znaleźć dobry komunikator spełniający _moje_ wymagania. Kiedyś takim komunikatorem był konekt, niestety jest już od bardzo dawna nierozwijany. Dlatego bardzo się ucieszyłem gdy powstał port dla win32.
Widziałes może unicoma ? Polecam. Co prawda autorstwa znajomego, ale faktycznie sensowny projekt. Gdyby nie fakt, że jestem leniem i Adium już przerobiłem według swoich upodobań, pewnie używałbym Unicoma.
warto wspomnieć, że oficjalnie wspieraną platformą jest linux, port dla windows i na inne platformy to wersje nieoficjalne (chyba, że się coś w tej kwestii zmieniło)
Jak dla mnie to ten projekt osiągnie niedługo masę krytyczną i będzie skazany na rewrite – spójrzmy prawdzie w oczy, Kadu nie było projektowane na wiele systemów, raczej wtedy używałoby wxWidgets, a nie Qt. Nie do pominięcia jest to, że Kadu po prostu nie obsługuje korzystania z wielu interfejsów użytkownika, a to by było konieczne w przypadku pełnej integracji.
Dlaczego? Qt obsługuje obecnie największą liczbę platform natywnie, ostatnio również mobilne i to nie tylko w zakresie interfejsu użytkownika, ale także pozostałe funkcjonalności (multimedia, sieć, itd.). Ok, w czasach projektowania Kadu może wxWidgets był lepszym rozwiązaniem dla dwuplatformowych aplikacji (win32+linux), ale tylko na polu UI. Qt przez ostatnie lata mocno się rozwinęło, dlaczego więc z tego nie skorzystać?
Zamiast Kadu używam innego multiplatformowego komunikatora jakim jest Pidgin. 98% czasu spędzonego przy komputerze to praca w Windows 7 64bit, Pidgina używam jeszcze z Ubuntu, tam ten komunikator działał niemal perfekcyjnie, nie było problemów pod GNOME, XFC czy KDE, pod systemem Microsoftu tragedii nie ma, jednak wersja dedykowana pod Windowsa ma jeszcze sporo braków, np. nie ma wersji 64bitowej, nie udało mi się uruchomić nigdy motywów, pod 7 zmiany wprowadzane bezpośrednio w GTK powodują natychmiastowe wykrzaczenie komunikatora. Zminimalizowanie listy wcale nie wysyła jej do traya, tylko do nowego paska zadań, nie jest uciążliwe, czasami nawet przydatne, ale Pidgin w tym czasie pobiera ok 50MB ram i obciąża niepotrzebnie procesor. Pod Windowsem także nie ma obsługi Video i Chatu (przynajmniej nie znalazłem w swoim pidginie). Gdy przychodzi dużo wiadomości na raz (wystarczy wyjechać na parę dni) uruchomienie komunikatora kończy się zwisem na starcie, niestety nie da rady odzyskać napisanych przez kogoś wiadomości. Tym sposobem nie mogę uruchomić drugiego konta GG, którego nie używałem miesiąc… Duży plus dla Pidgina za bardzo dużo protokołów, minus za brak nowego GG, kolejny plus za dość duże możliwości konfiguracji, a minus wędruje za słabe zintegrowanie z Aero. Wyglądu już się nie czepiam bo to dla mnie, mimo że jestem grafikiem ma wobec komunikatora drugorzędne znaczenie.
Z innych multiplatformowych aplikacji to Inkscape, kilka razy zdarzało mu się randomowo wykrzaczać ale tak to pracuje w miarę stabilnie. Czasami ma problem z otwarciem plików SVG lub importem CDR. Interfejs… Cóż, schemat Tango pełną gębą : )
GIMPA pominę milczeniem – NIE-POD-WINDOWSA (Mam Photoshopa)
Z aplikacji którym naprawdę nie mam nic do zarzucenia to VLC, Firefox czy Skype (aczkolwiek wersja pod GNU/Linux jest bardzo uboga – dla mnie to plus
Ma dzwonić, a nie obierać pałkę i machać chorągiewką.)
Z jednym się nie zgodzę: http://www.kadu.net/forum/viewtopic.php?p=92317
Natomiast wiadomo że każdemu i we wszystkim dogodzić się nie da. Ważne jest aby aplikacja oferowała identyczną funkcjonalność na różnych platformach a to, czy ikonki będą paskowały czy nie to już szczegół.
Da się pisać multiplatformowe aplikacje – ten język nazywa się Java
Asembler tez jest multi
Nie zgadzam się z twierdzeniem, że łatwiej zrobić przeglądarkę internetową (taką jak Firefox) dla wielu systemów niż komunikatora (taki jak Kadu).
Porównaj sobie źródła obu programów i zadaj pytanie: które łatwiej ogarnąć? Firefox jest o wiele, wiele, wiele większą i bardziej skomplikowaną aplikacją.
Problem w tym że w Kadu (jak i w innych komunikatorach) core jest dość mały – jest to obsługa wiedomości + bindingi do bibliotek protokołów. Cała reszta (kontakty, pluginy, zachowanie) jest w większym lub mniejszym stopniu uzależniona od systemu.
Co do FF to większość kodu stanowią Gecko i XULRunner (który też jest w core). Mozilla mogła sobie pozwolić na stworzenie prawdziwie deklaratywnego i niezależnego interfejsu użytkownika (XUL), ale teraz też wkładają sporo wysiłku żeby był bardziej zintegroway z systemem.
Fajnie, że ludzie od Kadu chcą sprawić, by obsługiwał inne protokoły.
Szkoda natomiast, że taki program już jest… Pidgin…
i że zamiast rozwijać w nim GG głównie rozwija się Kadu.
Wolałbym lepszą obsługę GG w Pidginie od usprawnionego Kadu.
Natomiast jeśli chodzi o wieloplatformowość… najważniejszym jest by wszystkie funkcje programu działały, a to jakie ma ikonki jest sprawą drugorzędną.
Akurat Pidgin bardzo słabo działa pod KDE… Zresztą komunikatora używam na tyle często, że nie wpadłbym na pomysł używania żadnego opartego o gtk+ … Zresztą GTK+ jest “be”
BTW poza Pidginem jest też chociażby Kopete, który też obsługuje wiele protokołów. Czemu więc Pidgin a nie Kopete? Inna osoba mogła by powiedzieć czemu nie portuje się Mirrandy na Linuksa itp itd.
Swoją drogą to ludzie pracujący nad obsługą innych protokołów w Kadu raczej nie chcieliby pracować nad obsługą GG w Pidginie. Z wielu względów… Żeby wymienić chociażby dwa: toolkit i preferowanie Qt4 niż GTK+, praca nad kadu bo akurat ten komunikator lubią i nad nim chcą pracować.
Czemu więc ani Pidgin, ani Kopete?
Finch.
A czemu nie po prostu biblioteka do obsługi gg dołączana do Pidgina, Kadu, Kopete i Mirandy?
Kadu jest dostępny na wielu platformach i na każdej z nich można mu wytknąć niedoróbki.
Jeśli będzie rozwijany tylko na jednej platformie, developerzy od innych systemów po prostu sobie pójdą gdzie indziej.
Efekt będzie taki, że kadu będzie miało niedoróbki na tej jednej wybranej platformie.
Dodatkowo, ponieważ liczba developerów będzie mniejsza, różne bugi z natury neutralne względem systemu, będą naprawiane wolniej.
Akurat IMHO Firefox to kiepski przykład. To już Kadu lepiej integruje się z Gnome i KDE. Integracja FF z KDE ? Jest wogóle jakaś ? Owszem jakiś wstępny port na Qt4 tudzież jakaś zewnętrzna integracja od OpenSuse.
Sama integracja z Gnome FF też pozostawia sporo do życzenia. Z jakiegoś powodu Gnome tworzy własną przeglądarkę opartą o Webkit
Możemy dodać do tego (słuszne) narzekania na powolność liska na linuksie w porównaniu do wersji windowsowej.
Co do wieloplatformowych aplikacji to dla mnie ciekawsze od mało znaczącego komunikatora są aplikacje typu eclipse czy azureus. Pierwszy ma bardzo rozbudowany interfejs użytkownika, a drugi w dość zaawansowany sposób integruje się z systemem operacyjnym. Oba o ile wiem są napisane w javie z użyciem natywnych kontrolek dostępnych przez SWT.
Nie znam się na bibliotekach, javach, kutekach itp.
Jestem userem.
Kadu używam od kilku lat na linuksie.
Na koniec zeszłego roku musiałem przejść na windowsa (wymagania klienta co do specyficznego softu)
I przeszedłem na windowsa
I co? I nic – kadu działa identycznie, historia rozmów przeniesiona bez problemu.
Zresztą tak samo jak thunderbird, firefox, gimp, openoffice, dropbox.
Po dwóch miesiącach korzystania z szajsu o nazwie vista udało mi się przekonać klienta co do zmiany wymagań i znowu mam ubuntu.
I co? I nic – kadu działa identycznie, historia rozmów przeniesiona bez problemu.
Zresztą tak samo jak thunderbird, firefox, gimp, openoffice, dropbox.
Dla mnie rewelacja! Cały czas korzystam z ulubionego softu zmienia się tylko platforma na spodzie.
I o to właśnie chodzi, bezproblemowa migracja między systemami – a że ikonki inne? Ikonki to są dla dzieci neo ważne, że nie ma wielu profili? Nie mam schizofrenii czy innego rozdwojenia jaźni więc korzystam z jednego profilu na gadu. Nie ma integracji z powiadomieniami gnome – też przeżyję, przecież to kolejny wodotrysk,
Dla mnie KADU jest wypas i szacun wielki dla jego deweloperów.
Mi by nie poszło tak łatwo. W windozie nie mam porządnej linii poleceń, a nie potrafię bez tego żyć.
PowerShell? A jak wolisz uniksowe rozwiązania to SUA + (opcjonalnie) doinstalowanie/kompilacja odpowiedniego sh uniksowego, bądź cygwin (czy jakoś tak).
Dla mnie jest bardzo istotna integracja z systemem.
Może to nie jest o tyle integracja wyglądem co z kontaktami które zawsze mogę też obejrzeć na Androidzie.
pracuje na GNOME i praktycznie nie uruchamiam aplikacji napisanych w Qt, no chyba żebym już musiał. Aplikacje według mnie powinny wyglądać ładnie i pasować do motywu jaki sobie wybiorę i nie straszyć wyglądem.
Używałem przez długi czas pidgina, później empathy… ale ich integracja też według mnie nie była rewelacyjna z Evolution.
Teraz używam o dziwo google talka (w przeglądarce) który ładnie się integruje z gmail, z gkalndarzem z gpicassą i innymi g..
Ale jeśli chodzi o pełną integrację to tylko mogę pozazdrościć MAC OS, bo tego akurat w linuxie jeszcze brakuje… ale jeszcze do tego dojdziemy
Ja również pracuję pod GNOME, lecz raczej na pierwszy rzut oka trudno rozróżnić, które aplikacje są pod Qt, a które pod Gtk+. Wystarczy qtconfig-qt4 i ustawić styl na GTK+ Osobiście dużo chętniej używam aplikacji napisanych przy użyciu Qt niż innych
Dla mnie argumentacja, że ikonki nie itegrują się z systemem, to jakieś nieporozumienie. Przecież w niczym to nie przeszkadza!! W dodatku jeśli wziąść środowiska linuksowe, to każdy sam może skonfigurować sobie wygląd, tak więc dostosowanie kadu, tak jak by tego sobie życzył autor(ka) jest niemożliwe. Powiadomienia kadu też w niczym nie przeszkadzają. Ich wygląd jest konfigurowalny, tak więc kazdy sobie ustawi tak jak mu się podoba. Co do pytania zasadniczego tzn. czy powinno się pisać programy wielkoplatformowe, to uważam, że jeśli są to programy komercyjne to jak najbardziej, czekał bym na Corela natywnie na Linuksie.. Jednak programy opensource, czy raczej non profit, które zostały w zamierzeniu napisane pod Unixy, powinny przede wszystkim rozwijane pod Unixy…Wolałby aby programista udoskonalał program pod system, którego uzywam, a nie pod Winde…Egoistyczne to acz prawdziwe
Ja bym chciał od Kadu małego drobiazgu…
Aby zapamiętywał więcej niż 30 ostatnich opisów. Dla osób twórczych w swych opisach 30 ostatnich to zdecydowanie za mało. Gdyby jeszcze był manager opisów, który by pozwolił usuwać / zastępować zapamiętane opisy, to już by było pięknie
Myśle, ze to jest idealny pomysł na moduł: http://www.kadu.net/w/Mechanizm_modu%C5%82%C3%B3w
Fajnie by było, gdyby ktoś stworzył i udostępnił taki moduł.
Kadu na linux-a to małe grono w Polsce osób, które chcą mieć i Pidgin i kadu i do tego używać i jednego i drugiego. Na windows mają wieksze szansę zdobyć użytkowników, i walczyć z AQQ o pozycję nawet 3 na rynku… ale musieli by zamiast wydawać 0.5.x to już w gródniu wydać wersję do testów rc wersję 0.6.6
no ale jak widać, twórcy idą powoli… ciekawe czy ich 0.6.6 nie zatanie GG11 albo mytribe2 
strasznie naciągane są te braki Kadu.
strasznie naciągane te braki w Kadu.
Kadu jest bardzo fajne, używam zarówno na Windowsa jak i na Linuksa, jeżeli będzie support dla Jabbera no to będzie już cud miód Über pr0….
Z punktu widzenia użytkownika windowsa pisanie
aplikacji wieloplatformowych jest niepotrzebne,
no bo wiadomo że na windowsa jest wszystko.
Natomiast z punktu widzenia użytkownika linuxa
pisanie takiego oprogramowania jest jak najbardziej pożądane, bo często jest to jedyny sposób żeby mieć
jakieś wartościowe i dobrze zrobione oprogramowanie.
Moim skromnym zdaniem dobrze będzie gdy aplikacji wieloplatformowych będzie coraz więcej.Umożliwiają one komunikację użytkowników między różnymi platformami takimi jak winda,czy OS.W penym sensie może to pomóc zrozumieć osobom,które chcą przejść z windy na linuksa,że barier między oprogramowaniem płatnym a free różnica się zaciera.Sam od niedawna używam linuksa i wiem jakie ma to ogromne znaczenie dla osób zaczynających swoją przygodę z pinginem.Czy wygląd aplikacji ma znaczenie?…..pewnie dla niektórych osób ma ogromne,ale dla mnie znaczenie ma funkcjonalność i bezpieczeństwo.Jak najwięcej takich programów wielośrodowiskowych powinno się znaleźć .
A ja się zastanawiam czy takie wieloplatformowe oprogramowanie nie wpłynie w przyszłości na popularyzację liniksa. Jak zwykły “juzer” będzie miał wspólny komunikator, pakiet biurowy, pocztę, przeglądarkę i coś tam jeszcze. Ale !ważne! sprawnie działające, to będzie już tylko o krok od zmiany systemu, bo właściwie przy zmianie systemu niewiele mu się zmieni.
raczej nie – Twojemu “juzerowi” nie będzie się chciało zmieniać systemu, jak wszystko to co jest ma na swoim.
Może się nie znam ale dla mnie nie jest problemem, że kadu obsługuje tylko jeden profil na raz. Zawsze można zalogować się na kilku użytkowników na raz i przeskakiwać za pomocą ctrl+alt+fX
Dwa zdania co do wersji Haiku:
“1. Niewykorzystywanie systemowego zestawu ikon używanego w Haiku OS
2. Brak pełniejszej integracji z tym środowiskiem”
Oba powyższe to prawda, ponieważ autor portu nie jest zainteresowany dogłębniejszym jego dopracowaniem. Port ten jest po prostu bardzie pokazaniem, że “się da bez większych problemów”. Ale bardziej jest to przekompilowanie kodu na inną platformę niż port, tak jak rozumiane powinno być to słowo. Niestety Qt, mimo, że natywne, jest traktowane dla userów Haiku, jako “fajnie, że jest ale wolimy używać aplikacji na API Haiku/BeOS”, co oczywiście nie oznacza, że jesli komuś potrzebna jakaś aplikacja, która jest na Qt to jej nie użyje. Oczywiście nic nie stoi na przeszkodzie by był to odpowiednio dopracowany i jak się tylko da zintegrowany z systemem port, potrzebny jest tylko programista zainteresowany takowym a tu jest na razie wakat…
Pozdrawiam.
W Kadu brakuje opcji integracji z zainstalowanym środowiskiem KDE pod Windows (dzięki temu rozwiązaniu biblioteki np. qt nie byłyby dublowane).
Akurat Kadu to taki trochę trochę mizerny przykład… Podam lepsze przykłady:
Audacity – program do nagrywania i edycji dźwięku
Code::Blocks – IDE dla języka C++ obsługujące kilka kompilatorów
Truecrypt – kto zna ten wie do czego służy…
To są właśnie programy, które świetnie oddają swoją wieloplatformowość.
Cały sęk w pisaniu programów wiloplatformowych tkwi w tym, że oprócz odpowiedniego sposobu programowania, używa się jeszcze odpowiedniego kompilatora(GCC/G++), odpowiednich bibliotek(wxWidgets) oraz gdzie nie gdzie kompilacji warunkowej w zależności od systemu/środowiska w którym się program kompiluje.
Jest jeszcze sporo innych programów wieloplatformowych takich jak np. GIMP, Blender, OpenOffice, DosBox, Vice i jeszcze sporo innych, nie licząc tu oczywiście programów działających w konsoli(wiersza poleceń) oraz bibliotek wykonawczych których jest setki.
Zawsze użytkownicy narzekają, że na określony system brakuje takiego czy innego oprogramowania, gier podczas gdy na drugi system “wszystko” jest.
Zatem wieloplatformowe programowanie jest imponującym rozwiązaniem, dzięki czemu możemy otrzymać np. 3 wersje oprogramowania na 3 systemy PRZY JEDNYM NAKŁADZIE PRACY. Tak więc jestem jak najbardziej ZA.
A ci, którzy uważają inaczej, to niech zastanowią się, czy warto oddzielnie tworzyć oprogramowanie na jeden OS a potem oddzielnie od początku te same oprogramowanie dla innego OSa?? Bo wg. mnie bez sensu.
Ktoś tam pisał, że biblioteka wxWidgets jest tylko do UI – w takim razie odsyłam do jej dokumentacji.
Przypadek winampa pokazał że raczej uzytkownicy niesą przywiązani do konkretnych rozwiązań systemu operacyjnego. Po za tym co za problem zrobić obsługę skórek jeśli uzywają Qt. Skórki rozwiążą problem wyglądu całkowicie. Z qt zaczyna się robić ciekawie za sprawą UMLa. Moim zdaniem przewróci to do góry nogami tworzenie interfejsów uzytkownika.
O ile prawidłowo rozumuję to Kadu powstało jako linuksowy odpowiednik programu Gadu-Gadu z Windowsa.Więc nie rozumiem po co robić “klon” Kadu dla użytkowników Windows skoro mają oni oryginalne GG ? Czy ten nowy twór będzie lepszy niż GG ? Bo ciągłym ulepszaniem GG już zajmuje się odpowiednia ekipa.Chodzi mi o to, żeby cała para nie poszła w gwizdek.Może lepiej wykorzystać drzemiący potencjał twórczy i ulepszać “oryginalne” Kadu, ewentualnie popracować jeszcze nad lepszą integracją Kadu z innymi środowiskami linuksowymi.Nie jestem przeciwnikiem programowania wieloplatformowego bo to może i powinno wpłynąć na zwiększenie popularności linuksa ale powtórne odkrywanie Ameryki to jest chyba bez sensu.
” Czy ten nowy twór będzie lepszy niż GG ?”
już od dawna jest lepszy.
A ja się zastanawiam czy takie wieloplatformowe oprogramowanie nie wpłynie w przyszłości na popularyzację liniksa. Jak zwykły “juzer” będzie miał wspólny komunikator, pakiet biurowy, pocztę, przeglądarkę i coś tam jeszcze. Ale !ważne! sprawnie działające, to będzie już tylko o krok od zmiany systemu, bo właściwie przy zmianie systemu niewiele mu się zmieni.