Kadu Case study: Czy należy tworzyć aplikację na wiele systemów operacyjnych?

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ę zachowywującą się „naturalnie” w różnych środowiskach operacyjnych? Zapraszamy do dyskusji, wasze opinie pomogą developerom Kadu zdecydować jak rozwijać dalej aplikację.

Powiązane (7)

  pokaż (6) 
  • Reklamy Google

  • lukaszg84 +11  

    Kiedyś była taka reklama: jak coś jest do wszystkiego to jest do niczego. Mimo tego, że kadu jest najpopularniejszym klientem gg na Linuksa, to używa go względnie niewiele osób - Windows jest po prostu bardziej popularny. Developerzy kadu chcą zwiększyć zasięg swojego programu właśnie przez przygotowanie go pod Windowsa. Wydaje mi się, że może to być trochę niepotrzebna praca, bo:

    1) wielu użytkowników gg nie wie że istnieją inne komunikatory, wydanie kadu na Windows niczego nie zmieni
    2) Ci, którzy wiedzą o istnieniu innych klientów mają naprawdę duży wybór
    3) używałem pod Windowsem GIMPa i Pidgina. GIMPa zamieniłem na Paint.net (z powodu długiego czasu uruchamiania GIMPa), Pidgin często zachowywał się źle - problemy z dockowaniem, ustawianiem focusu dla bieżącego okienka
    4) pisanie na wiele systemów za pomocą natywnie kompilowanego kodu (jak C/C++) jest męczące - lepszym rozwiązaniem byłoby użycie Javy lub .net/mono - developerzy skupiają się na swoim produkcie a kwestią integracji z systemem zajmują się inne osoby.

    pokaż komentarz
    lukaszg84
  • Raffael +7  

    _pisanie na wiele systemów za pomocą natywnie kompilowanego kodu (jak C/C++) jest męczące _

    E tam męczące. Qt Designer i po sprawie :)

    pokaż komentarz
    Raffael
  • merilius +2  

    Tylko, że Java działa "jak burza", a status prawny Mono jest nie określony (Microsoft ma patenty na .NET i protestował przeciw Mono, z niektórych linuksów usunięto po tym Mono)

    pokaż komentarz
    merilius
  • Juzef +9  

    Nadmienię tylko, że developerzy Kadu oficjalnie wspierają Kadu pod Linuksami, a port na Windowsa jest nieoficjalną inicjatywą prywatną.

    pokaż komentarz
    Juzef
  • bondzio17 +2  

    Mono to calkiem to dobre rozwiazanie, testowalem pare aplikacji .NET na Linuksie i pare aplikacji MONO na Windowsie i wszystko dziala OK.

    pokaż komentarz
    bondzio17
  • lukaszg84 0  

    @merilius

    Też tak mi się wydawało dopóki nie porównałem sobie szybkości działania dla jakiegoś prostego algorytmu. Java była szybsza - optymalizowanie w tle najwyraźniej pomaga.

    pokaż komentarz
    lukaszg84
  • Barrt +4  

    Też zmieniłem GIMPa na Paint.NET z tego powodu. Nie jest mi potrzebny bardzo zaawansowany edytor grafiki, a jednak windowsowy Paint to śmieszność (chociaż można w nim zrobić gradienty :D).
    Pidgina (czy GAIMa) zmieniłem właśnie na Kadu, bo pamiętałem, że na Linuksie fajnie mi się z niego korzystało. Z początku używałem Mirandy (jeszcze nie było portu Kadu), po prostu nienawidzę konfigurowania jej, poza tym rozłączało mnie cały czas. Moim zdaniem jest za dużo opcji i jakoś dziwnie poupychane.
    W międzyczasie było jeszcze psi z transportem gg na jabbera, ale jakoś dziwnie działał. Do GG, Tlena, AQQ, Konnekta czy innych wymysłów zawsze miałem awersję (chociaż w tym towarzystwie Tlen najlepszy, ale nie korzystam z o2, więc po co?).
    Ostatnio nawet robiłem podejście do GTalka i być może w późniejszym czasie się na niego skuszę, jak więcej znajomych będzie używać gmail i buzz.
    Reasumując, artykuł jest durny, bo Kadu spisuje mi się bardzo dobrze, a zarzuty o braku integracji z systemem są bez sensu. Komunikator ma stabilnie działać, a nie świecić się jak psu jajca.
    Dla przykładu wygląd mojego Kadu:
    http://i49.tinypic.com/n5saic.png

    pokaż komentarz
    Barrt
  • mathix +4  

    @merilius: Możesz rzucić jakimś artykułem odnośnie tej burzy? Sam jestem programistą korzystającym z .NET-a, ale jakoś ta sprawa mi umknęła. Zawsze wydawało mi się, że skoro MS brata się Novellem, to nie będą robić problemów.

    pokaż komentarz
    mathix
  • lukaszg84 +2  

    @Barrt
    Ja używam GTalka właśnie ze względu na prostotę - spędzenie ponad dnia na skonfigurowaniu tak prostej rzeczy jak komunikator jest bez sensu. Udało mi się całkiem zrezygnować z gg - chyba wszyscy znajomi mają jabbera lub konto na gmailu więc z poziomu gtalka łatwo można wysłać wiadomość (jeśli ktoś nie używa gtalka, to dochodzi do niego jako email).

    pokaż komentarz
    lukaszg84
  • KochanekModeratora +2  

    Twórcom polecam się zapoznać z biblioteką JUCE:

    http://www.rawmaterialsoftware.com/juce.php

    Gwarantuje ona identyczne (na ile to mozliwe) zachowanie się i wygląd aplikacji na Windows, OSX, Linux, iPhone.
    Jest tez darmowa dla zastosowan niekomercyjnych (GPL)

    http://www.rawmaterialsoftware.com/downloads.php

    Jest tam do sciagniecia przykladowa aplikacja.

    pokaż komentarz
    KochanekModeratora
  • arag0rn +6  

    > Jest tez darmowa dla zastosowan niekomercyjnych (GPL)

    Nigdzie w licencji GPL nie ma nic o zastosowaniach - wymagania dotyczą tylko konieczności dołączania źródeł do rozpowszechnianych binarek.

    pokaż komentarz
    arag0rn
  • DaZ +2  

    Tak, licencja ktora nakazuje rozdawanie zrodel i zezwala na ich dalsze rozpowszechnianei jest cudowna dla biznesu [;

    pokaż komentarz
    DaZ
  • sssso +5  

    Kiedy się robi porządny biznes - że rzeczywiście nam zależy na nierozpowszechnianiu źródeł, to nie żałuje się kilkuset funtów za licencję na dobrą, multiplatformową bibliotekę (jeżeli się takowej potrzebuje oczywiście). Takie zaś właśnie możliwości przy JUCE są - albo płacisz, albo rozpowszechniasz wraz z kodem źródłowym - moim zdaniem uczciwe i dobre rozwiązanie.

    pokaż komentarz
    sssso
  • wakacje +1  

    sam uzywam linuksa oraz kadu 0.6.5.3 i nie widzę sensu w tym wykopie ;)

    pokaż komentarz
    wakacje
  • dave8x +4  

    tez nie widze w tym sensu. Autor uwaza ze pisanie wieloplatformowych programow jest złe, a argumenty ma wręcz śmieszne. Pewnie M$ mu zaplacil za artukuł. Według mnie multiplatformowość to jedyna słuszna droga dla aplikacji...

    pokaż komentarz
    dave8x
  • Articles +1  

    To juz raczej jest fanatykiem Linuxa i nie podoba mu się pomysł na przenoszenie pingwinkowego dorobku na zło wcielone pod postacią komercyjnych systemów kosztem oryginalnych OSów :)

    Ale artykuł ciekawy, dobrze by było, jakby poszedł w świat i dał motywacje developerom qt - w wypadku tej biblioteki świetnie by było dostać dobrą multiplatformowość - ułatwiło by to portowanie wielu ciekawych aplikacji

    pokaż komentarz
    Articles
  • patpi +7  

    @dave8x, @Articles: Ani jedno, ani drugie ;) Tak naprawdę dobrze by było dowiedzieć się czego brakuje w kadu-mac, kadu-kde, kadu-gnome, kadu-win, kadu-haiku itp najbardziej naszym użytkownikom. Poprzez dyskusje o tym artykule liczyłem, że dowiemy się czego Wam brakuje w Kadu pod względem integracji z systemem. (jeżeli czegoś brakuje)

    pokaż komentarz
    patpi
  • Juzef +8  

    Gdzie wy takie rzeczy wyczytali? Kadu ma docelowo opanować świat, więc przenoszenie na wszelkie OS'y jest nieuniknione i pożądane. Jeśli ktoś widzi zuo w komercyjnych systemach, może się przypiąć do kaloryfera i oflagować. Przedmiotem artykułu nie jest dyskusja nad sprawą: wieloplatformowość czy nie, tylko jaki stopień integracji z daną platformą jest przez userów preferowany.

    pokaż komentarz
    Juzef
  • nonline +5  

    Przeczytać artykuł, a nie p%$####ić głupoty. Autor pisze o błędach i problemach, nie neguje pisania na wiele platform. To tak jak ja bym pisał, że auta na energię elektryczną mają słaby zasięg, a co poniektórzy z was wypociliby zdania w stylu "On pisze z pewnością dla mafii paliwowej" czy "Harem szejka zrobił mu dobrze".

    pokaż komentarz
    nonline
  • lubczasopisma 0  

    Widzę że zagląda tu sporo linuksiarzy, zaczynam przygodę z linuksem desktopowym, możecie mi polecić coś poza amarokiem do odtwarzania mp3/flaców w KDE, takiego małego i zgrabnego jak winamp ?

    pokaż komentarz
    lubczasopisma
  • Some +4  

    audacious? ;)

    pokaż komentarz
    Some
  • matrick +4  

    Jak nawet tego nie umiesz sam poszukać to twoja przygoda z Linuksem raczej szybko się skończy.

    pokaż komentarz
    matrick
  • szymon_g -4  

    foobar2k + wine

    pokaż komentarz
    szymon_g
  • Matkasiedziztylu +3  

    @matrick
    Słusznie prawisz, bo przygoda z linuksem polega głównie na wyszukiwaniu oprogramowania, "testowaniu" go, konfiguracji i "dostosowywania do własnych potrzeb", a nie na używaniu go - jak ktoś tego nie rozumie jest oczywistym idiotą niegodnym linuksa.

    pokaż komentarz
    Matkasiedziztylu
  • badboy +14  

    mpd + ncmpcpp

    pokaż komentarz
    badboy
  • wujekbogdan 0  

    @lubczasopisma
    xmms przypomina winampa, ale ja podobnie jak szymon_g polecam foobar+wine
    testowałem wszystkie sensowne odtwarzacze, ale żaden nie dorównuje foobarowi, który pod wine działa bardzo dobrze i jest bardziej żwawy niż amarok.
    a jeśli chodzi o linuksowe odtwarzacze to tak jak pisze wyżej badboy niezłe jest też połączenie mpd + jakiś frontend (np. sonata).

    pokaż komentarz
    wujekbogdan
  • lubczasopisma +1  

    Wiedziałem że dobrze trafiłem :) Dziękuję wszystkim, zwłaszcza wujkowibogdanowi, spróbuję to co polecacie, wine w ostateczności.

    pokaż komentarz
    lubczasopisma
  • henk -5  

    skoro biblioteki qt powoduję tyle problemów, to może czas z nich zrezygnować? wiem, że te biblioteki są wygodne, ale jak chce się naprawdę pisać aplikacje system independent, to trzeba się postarać. poza tym nie wydaje mi się aby napisanie niezależnej od systemu operacyjnego przeglądarki było w jakiś sposób łatwiejsze niż napisanie komunikatora.

    pokaż komentarz
    henk
  • chudzielec +12  

    Może lepiej znaleźć te błędy i je naprawić?

    pokaż komentarz
    chudzielec
  • ziom666 +32  

    biblioteka qt jak narazie jest najlepsza dla wieloplatformowych projektów.

    pokaż komentarz
    ziom666
  • merilius +6  

    Błędy Kadu pod windowsem (np. głupieje przy dwóch moniotrach) ponoć wynikają tylko ze złego portu QT pod windowsa. Oni o tym w projekcie kadu wiedzą, ale nie ma lepszych bibliotek...
    Trzeba szturchać tych od QT...

    pokaż komentarz
    merilius
  • chudzielec +24  

    Widzę, że już lecą minusiki, co daje poznać, że dużo osób nie orientuje się w realiach pisania oprogramowania w dzisiejszych czasach. Ludzie co potrafią to krzyczeć, że aplikacja dużo zżera procesora, ramu. Najlepiej jakby zabierała nie więcej niż 2 mega w pamięci i miała to czy tamto.
    Lekkie i starannie aplikacje są dobre, ale czas ich tworzenia jest nieporównywalnie dłuższy niż gdyby pisać opierając się na sprawdzonych bibliotekach, których autorzy rozwiązali wiele problemów za nas. Gdyby pisać interfejs Kadu na WinAPI, Qt (KDE), GTK2 (Gnome, Xfce) i Cocoa (Mac OS X) z osobna, należało by stworzyć warstwę abstrakcji, a następnie implementacje dla każdego z tych systemów z osobna. Byłby to ogromny kawałek kodu, który trza było by utrzymywać równolegle z kodem reszty aplikacji .Wszakże działanie wymienionych bibliotek często ulega zmianie w wersji na wersję, a także czasem chciało by się dodać nową funkcjonalność. Tą całą pracę bardzo dobrze wykonują developerzy Qt, a od błędów nigdy nie można się ustrzec. Zamiast by pisać wszystko od nowa lepiej wesprzeć projekt swoim doświadczeniem, wyśledzić błąd i po prostu pomóc w naprawie.

    Qt to naprawdę świetna biblioteka. Polecam ją każdemu, kto chce pisać aplikacje multiplatformowe w C++, a także w Javie.

    pokaż komentarz
    chudzielec
  • koziolek666 +6  

    @ziom666, a widziałeś SWT? Znacznie lepsze bo wykorzystuje natywne komponenty systemu operacyjnego, które są przesłonięte fasadą w postaci API Javy. Popatrz jak wygląda Ecliopse. Jak normalna aplikacja dla danego systemu operacyjnego.

    //edit:
    @chudzielec, skoro taka duperela jak zmiana wyglądu powoduje, że trzeba by trzymać n-dziesiąt różnych wersji to znaczy, że program jest zaprojektowany do dupy. GUI powinno być projektowane jako moduł z którym gadasz za pomocą adaptera, tłumaczącego to co chcesz zrobić na język systemu. Utrzymujesz wtedy tak naprawdę niewielka ilość kodu tłumaczącego.

    pokaż komentarz
    koziolek666
  • wrednyAnonim +4  

    A czy SWT pozbyło siętego "drobnego" problemu jakim był nieustanny wyciek zasobów? Język z GC w którym nie mamy pewności kiedy zostanie wywołany destruktor trudno zmusić do współpracy z z natywnym API które GC nie używa. I dochodzi ideologia, dla wielu jest to takie niekoszerne rozwiązanie xD

    pokaż komentarz
    wrednyAnonim
  • prostynick +2  

    chudzielec: a także w Pythonie.

    koziolek666: z tym Eclipsem, to bym się nie zgodził, że wygląda normalnie, a na ciut starszych kompach chodzi koszmarnie. Trzeba jednak przyznać, że to świetne środowisko.

    pokaż komentarz
    prostynick
  • mantrid +1  

    @wrednyAnonim: "nie mamy pewności kiedy zostanie wywołany destruktor trudno zmusić do współpracy z z natywnym API które GC nie używa"

    dlatego SWT posiada mechanizm "void dispose()" który jest odpowiednikiem destruktora z C++ i innych. wywoływany jest dokładnie wtedy, gdy zasoby nie są już potrzebne i natywna warstwa w tym momencie je zwalnia. ewentualne wycieki są najczęściej efektem lenistwa programistów, którym nie chce się nauczyć poprawnego korzystania z tego mechanizmu :(

    sam używam Eclipse nonstop pn-pt i nie powoduje to żadnych problemów z pamięcią. naprawdę polecam Eclipse RCP! :)

    pokaż komentarz
    mantrid
  • koziolek666 0  

    @prostynick, bo to bardziej wina pluginów niż samego eclipse. nawet jak masz nowoczesnego kompa i zapakujesz w Eclipse wszystko co jest dostępne i jeszcze trochę to też mocno zwolni. Zdrowa granica to około setki rozszerzeń na raz. Dla kompa z 4GB ramu i 32 bitowym systemem.

    pokaż komentarz
    koziolek666
  • luckyboy -3  

    Nokia wydała Qt 4.6 niedawno - wiele usterek dla Windows poprawiono. Nie wiem. Pierwsze pytanie: po co Kadu na Windows? Przecież oni mają swoje Nowe Gadu Gadu.

    pokaż komentarz
    luckyboy
  • wujekbogdan +3  

    ...i wiele innych dobrych komunikatorów. poza tym nowe gadu, też używa biblioteki QT i prędzej czy później pojawi się w wersjach na inne niż windows platformy.

    a jeśli chodzi o kadu, to port na windows to wersja nieoficjalna. na forum kadu dawno temu był wątek, w którym deweloperzy stwiedzili, że palcem nie kiwną, aby taka wersja powstała, chyba, że znajdzie się chętny to rozwijania wersji dla win. jak widać chętny się znalazł.
    a po co? zapytaj autora wersji dla win. widocznie miał ochotę i zrobił.

    pokaż komentarz
    wujekbogdan
  • danielo86 -1  

    nowego gadu na win to jedynie gimnazjaliści którzy nie mają pojęcia o świecie używają :P

    pokaż komentarz
    danielo86
  • matrick -2  

    Oczywiście, że się da! Dobrym przykładem jest tutaj komunikator tlen.

    pokaż komentarz
    matrick
  • DaZ 0  

    lolwut?

    pokaż komentarz
    DaZ
  • wujekbogdan +5  

    tlen jest akurat wybitnie złym przykładem. co prawda obecnie tlen7 to beta, ale na żadnej platformie nie działa dobrze. z tym, że w przypadku tlenu, to nie wynika to z multiplatformowości ;)

    pokaż komentarz
    wujekbogdan
  • cyrylk +1  

    Taki Skype też działa u mnie pod Mac OS'em pięknie. Z tym, że Skype generuje raczej niezłe zyski.

    pokaż komentarz
    cyrylk
  • danielo86 -5  

    dla mnie ta multiplatformowość to głupota, bo podejrzewam, że na żadnym systemie nie będzie to działać tak jak powinno, nie prościej i łatwiej dopracowywać kilka wersji na poszczególne systemy ???

    pokaż komentarz
    danielo86
  • patpi +3  

    Oczywiście że nie łatwiej, dlatego m.in portowanie openoffica na macosx zajęło lata. Wymagałoby to kilka razy więcej programistów ;)
    W/w w artykule rzeczy do poprawy to nie są jakieś trudne zadania dla programistów. Wymagają po prostu chęci poprawiania takich szczegółów i położenia nacisku na większe dopieszczenie aplikacji dla konkretnej platformy.
    Może po tym artykule ktoś zechciałby usprawnić działanie komunikatora Kadu na którejkolwiek z czterech platform? (me hopes so)

    pokaż komentarz
    patpi
  • dave8x +4  

    @danielo86 nie wiesz co piszesz. Wieloplatformowosc to takze tworzenie kilku wersji na poszczególne systemy, z tym ze kazdej wersji nie pisze sie od nowa w innym języku, tylko trzeba pomyslec juz troche wczesniej na etapie projektu jak zrobić, zeby dało się łatwo przeniesc...

    pokaż komentarz
    dave8x
  • danielo86 +1  

    @dave8x
    na końcu mojej wypowiedzi były znaki zapytania, więc nie była to opinia, a pytanie, ale miło z twojej strony że mnie wyprowadziłeś z błędu :P

    pokaż komentarz
    danielo86
  • Keraj 0  

    Zależy co ta aplikacja ma robić...
    Myślę, że coś takiego jak zwykły komunikator można bezproblemowo napisać w Javie - mając pewność, że wszędzie będzie działało tak samo. Jeśli chodzi o wydajność... cóż, komunikator to żadne wyzwanie dla Javy. Myślę, że w Javie można stworzyć przyjemny i wydajny komunikator.. w sumie wszystkie funkcje komunikatora jakie mi nachodzą na myśl są z poziomu Javy osiągalne bez natywnych rozwiązań i nie wymagają "bukwiejakih" pamięciożernych rozwiązań...

    pokaż komentarz
    Keraj
  • T-DeX 0  

    @Keraj
    "Jeśli chodzi o wydajność... cóż, komunikator to żadne wyzwanie dla Javy."

    Hello World to spore wyzwanie dla wydajnosci Javy.

    pokaż komentarz
    T-DeX
  • Keraj +1  

    Hello World to spore wyzwanie dla wydajnosci Javy.
    W dupie byłeś, gówno widziałeś...

    pokaż komentarz
    Keraj
  • matrick +3  

    Nie każdy lubi wino.

    pokaż komentarz
    matrick
  • JezdziecBezNicka -2  

    Matkasiedziztylu:
    "Słusznie prawisz, bo przygoda z linuksem polega głównie na wyszukiwaniu oprogramowania, "testowaniu" go, konfiguracji i 'dostosowywania do własnych potrzeb', a nie na używaniu go - jak ktoś tego nie rozumie jest oczywistym idiotą niegodnym linuksa."

    Nie rozumiem, po co takie komentarze? Dowartościowałeś się?

    Na temat: taki już urok wieloplatformowych aplikacji, że nie będą działać wszędzie idealnie. Ale jestem w stanie tyle poświęcić w imię wolności wyboru.

    pokaż komentarz
    JezdziecBezNicka
  • afterworks -5  

    Multiplatformowość to ogromna wada. Mówcie co chcecie, ale żaden porządny program nie jest multiplatformowy. Wszelkie Javy i tego typu wynalazki to marnowanie zasobów. Gry są tu całkiem niezłym przykładem. Wersja na konsolę zawsze jest lepsza od PC bo jest dedykowana wyłącznie jednemu urządzeniu o niezmiennej konfiguracji. Wyobraźcie sobie Crysis w Javie ;)

    pokaż komentarz
    afterworks
  • DaZ +2  

    To konsolowe gry pisza w javie? :o

    pokaż komentarz
    DaZ
  • kwahoo +1  

    E tam Crysis. Quake 2 w Javie działa całkiem dobrze http://bytonic.de/html/benchmarks.html

    pokaż komentarz
    kwahoo
  • dave8x -2  

    Gier nie robi sie w javie. Gry pisze sie w C++, ktorego kompilatory są na kazdy system, oraz w wieloplatformowych technologiach takich jak OpenGL, Openal itp... Oczywiscie mozna stosować DirectX i ograniczac sie tylko do M$ i Window$a, ale nie tędy droga...

    pokaż komentarz
    dave8x
pokaż 

Wykopali i zakopali (202 / 9)