JarekMk, nie slyszales o takim stylu zycia jak domator? niektorzy wola tak
Ja wracam.... niestety do roboty z rana :/

Widze, ze kilka osob juz sie dosc powaznie wypowiada i rzuca luzne idee, moze jakos skonkretyzowac nasze wizje?
To moze niech kazdy skrobnie jak wyobraza sobie, ze taka aplikacja mialaby powstac. Ja proponuje cos takiego:

kod: otwarty, na licencji typu gpl czy cos podobnego

systemy: windows (od 2000 w gore, co do 98 - no coz... kwestia dyskusyjna), linux, a jak sie znajda developerzy to mac i *bsd tez, czemu nie:)

jezyk: c++, bez zadnych 'rozszerzen' typowych dla danego kompilatora itp, w silnym oparciu o stl (stlport?) i biblioteki boost

srodowisko: najbardziej uniwersalne jest chyba eclipse, ale moze np. code::blocks? Albo w ogole uniezaleznic sie i oprzec np. na boost.build, tak, zeby kazdy mogl 'podpiac' sie pod ulubiony soft? Tyle, ze oficjalne binarki trzeba by bylo zawsze z tego samego srodowiska tworzyc, i, jesli bedzie to vs200x, to trzeba bedzie prawdopodobnie rozprowadzac tez redistributable package, trzeba wziac takie rzeczy pod uwage:) Jest to kwestia do przegadania:]

gui: prawdopodobnie gui bedzie pisane jako plugin (moze komus sie zechce, i napisze ui w trybie konsolowym, jako alternatywa? jest to jeden z wielu powodow, dla ktorych ui powinno byc jako plugin). Podstawowe gui powinno byc oparte na tej samej bibliotece na kazdy system, ale nic nie stoi na przeszkodzie, zeby powstal np. plugin specyficznie pod dajmy na to freebsd, w oparciu o jakas inna biblioteke;) Co do bibliotek - wybor pewnie padnie miedzy qt, wxwidgets i gtk+ z gtkmm. Sciagnac kazda, pobawic sie, zdecydowac? Inaczej chyba nie wybierzemy:)

dzwieki: podobnie, jak w gui - jedna biblioteka pod wszystkie systemy, itpitd.

kod systemo-zalezny (watki, net): piszemy sami, albo moze w czesci oprzec sie o boost? Ktos mial do czynienia np. z boost::asio?

Co o tym sadzicie?

P.S. Przyszedl mi do glowy taki pomysl, jeszcze dobrze nie przemyslany, na razie jako luzna idea. Program skladalby sie z 2 czesci (i tym samym oddzielnych procesow). Glowna czesc mialaby zaladowane pluginy protokolow, zapisywalaby historie, kontakty, jakas czesc konfiguracji itd. Druga czesc bylaby czescia uzytkownika - wyswietlalaby gui, grala dzwieki itd. Komunikacja miedzy nimi po czystym tcp lub ssl. Obie czesci odpalone na jednym pc dalyby w sumie normalny komunikator. Ale ktos przeciez moze odpalic sobie czesc 'serwerowa' np na routerze w domu Wtedy z kazdego komputera mamy dostep do swojego komunikatora, ustawien, listy kontaktow... Powstaloby cos jakby ekg + screen;> I ta przenosnosc kodu - czesc 'serwerowa' moglaby smigac na freebsd, a 'kliencka' na mac'u na balkonie, windzie w pracy... ;> Jak myslicie?

Nie da rady - na Windows ma WinAPI, na OSX CoreAudio czy jakoś tak, a na Linuksie możesz się odwołać od razu do sterowników (do ALSA-y) lub prawidłowo - do serwera dźwięku jak PulseAudio. Generalnie na Linuksie jest malutki bajzel - dla KDE Qt do GUI, a Phonon do dźwięków, a na GNOME GTK do GUI, a GStreamer do dźwięków.

to moze ja sobie skrobne wizje w miare idealnego rozplanowania projektu (jak dla mnie)

podzial na 2 czesci - core i gui
1. core
- czysty stl z tr1, czyli nie inaczej jak stlport + boost
- inteligentne wskazniki jak tylko sie da
- byloby milo z supportem dla unicode (chociaz nowy standard ma wprowadzic kilka typow char z tego co pamietam)
- obsluga wszystkich "common" dla sieci, czyli np: historia, ustawienia etc
- integracja z sqlite najlepiej
- udostepnienie obslugi wszelkich 'eventow' np za pomoca sygnalow z boost
- api dla wtyczek (kontrola wersji, ladowanie)
- "subbiblioteka" czyli nastepne "common" dla wtyczek, cos ala staminalib, ktora zawieralaby implementacje np socketow etc dla ujednolicenia kodu wtyczek
- mile widziane projektowanie klas w taki sposob, aby moznaby bylo potem robic na nich wrappery np dla lua/pythona

2. gui (za wiele tu powiedziec nie moge, bo na razie kozystam tylko z wtl'a, ale...)
- jak dla mnie, to qt4 to jedyna opcja
- ogolnie bardzo skromnie, podstawowe funkcje, ustawienia etc

srodowisko: (c++)
mingw + code::blocks (calkiem fajne)
mingw + scons (calkiem wygodne - tu bym sie bardziej przychylal)
tak na poczatek

Z tymi dzwiekami - jedyne moje doswiadczenie to kiedystam zabawa z directsound, wiec malutkie;) Ale slyszalem cos o openal - nie nadawaloby sie?
A co do grafiki - tez dokladnie nie wiem, jak to jest pod linuchem, nie wspominajac o *bsd i mac. Bylbym bardzo wdzieczny, gdybys nakierowal mnie na jakies info dot. tego problemu, np. dlaczego aplikacja gtk mialaby problemy pod kde, a oparta na qt mialaby sie krzaczyc na gnome? Zreszta, przeciez na gnome i kde swiat sie nie konczy - co z innymi mozliwosciami? Pisanie bezposrednio pod x'y?)) Kojarzy mi sie tylko cos, ze kde i gnome maja zupelnie inaczej rozwiazane ipc, zdaje sie dcop pod kde i corba pod gnome?

Krzaczyć się nie będą, nie o to chodzi.
Po prostu KDE bazuje na Qt a Gnome i coraz popularniejsze Xfce na GTK i dla przykładu użytkownik KDE myśli o programach wykorzystujących Qt jak o natywnych, które:

• będą się ładnie komponowały z resztą środowiska
• będą oszczędnością pamięci / szybciej się ładowały, bo Qt już i tak jest wykorzystywane

W drugą stronę też to działa - używam Xfce, jak szukam programu to najlepiej, żeby był oparty na GTK, te Qt-based wybieram w ostateczności.

Jako end-user wolałbym GTK, a jako programista myślę, że lepszym wyborem jest jednak Qt.

Rozwiązać ten problem można pisząc wrapper, który w zależności od wartości jakiejś stałej wykonuje daną rzecz pod GTK albo Qt (a z jednego na drugi da się stosunkowo łatwo tłumaczyć). można też dorzucić jakąś trzecią windowsową bibliotekę, która tam lepiej działa.
Ale komu by się chciało robić coś takiego dla 1% użytkowników.

A co do innych linuksowych środowisk.. Użytkownicy fluxboxa, icewm, windowmakera i innych takich nie mają swoich 'natywnych' toolkitów i są przyzwyczajeni do odpalania softu na GTK i Qt. Zresztą oni by pewnie woleli wersję konsolową.

suche propozycje na forum nic nie dadzą, bez meetingu ja tego jakoś nie widzę.

Dobra dobra, te 'farmazony' piszcie w gronie programistów bo większość z nas równie dobrze mogłaby czytać chińskie forum

Moim zdaniem potrzebna jest jedna osoba, która to OGARNIE i Was zbierze (nawet wirtualnie; Jarek? :-) ) np. na kanał IRC i/lub na np. TeamSpeaka, żeby się jakoś dogadać...

Przestańcie już marudzić i pouczać innych Bez obrazy, ale znowu zaczyna się "trajkotanie"...

Osoba która wszystkich zbierze i "ogarnie" już od początku się tu udziela, więc po co te porady? Akcja zacząła się kilka dni temu, dajcie chłopakowi trochę czasu na zgranie ekipy.....

Ps. Wyskakiwanie z tekstami "nic nie umiem, ale moge być testerem" jest zbędne. W odpowiednim czasie zapewne twórcy zwrócą się do userów z prośbą o testowanie, ale obecnie nie ma czego testować, dlatego szukają programistów... Proste, nie?

Witam.

Trafilem tutaj z ogloszenia na 4p.

Chcialbym przylaczyc sie do projektu jako programista C# (jesli oczywiscie zostanie wybrany ten jezyk). W C# programuje od roku (jestem samoukiem). Prowadze tez maly projekcik open source (www.codeplex.com/DotBeer). C# jest moim pierwszym jezykiem, ktorego zaczolem sie uczyc na powaznie. Obecnie jestem na III roku informatyki.

Prosilbym o kontakt na gg/email jesli bym sie nadawal do projektu Zarejestrowalem sie tez na http://forum.kfaq.info/index.php

Ja wszystko czytam, staram się jak mogę na razie ale wbrew pozorom jest to ogromny temat, a nie chciał bym podejść do niego nieprzygotowany...

Tak jak już kolega wspomniał na razie szukamy programistów, szczególnie C++

@flo4tingmus3um czytam Twoje wypowiedzi i piszesz sensownie, czujesz się na siłach w C++? Jeśli tam zapraszam na PW

Co do spotkania na IRCu postaram się dzisiaj podać kiedy się zbierzemy, oraz podam specjalny kanał dla wszystkich.

Pzdr!

c++/juce (http://www.rawmaterialsoftware.com/juce)

bo

- linux, windows, os x (gdzies po drodze temat mac'a sie nie pojawil co dziwne)
- bo wlasne gui custom niezalezne od poczatku do konca
- bo stabilne, juce sluzy do robienia mocno wydajnych aplikacji audio (Tracktion, MAX MSP, masa wtyczek)
- szybkie, wielowatkowe, latwe, spojne
- dobrze udokumentowane

chetnie przy czyms takim pomoge, to co juz zrobilem http://code.google.com/u/kubiak.roman

Nie znam dobrego komunikatora WIELOPLATFORMOWEGO.
I jako zapalony uzytkownik Maca mowie Wam - PIEPRZYC niszowe systemy:>

Zrobcie porzadny komunikator pod Viste tylko chocby. i bedzie naprawde pieknie.


Co do charakteru to ja bym bardzo powaznie stawiala na mobilnosc jesli juz chcecie rozpatrywac inna wersje programu. Rynek praktycznie goly wiec mozna poszalec.
A innymi platformami bym sie nie przejmowala. Zawsze mozna na sile sobie poemulowac.

Powiem tak, fajnie że zaczyna się coś dziać i będę się temu przyglądał, ale również będę się przyglądał rozwojowi kadu, bo właśnie powstała jego instalka na windowsa (jest oparty o Qt 4.4), a od następnej wersji (czyli 0.7) ma stać się multikomunikatorem.

@Ved: jak nie Mac, to teraz Vista.. naprawdę trzyma się Ciebie dobry humor...




Biorąc pod uwagę, że zdecydowana większość użytkowników PCtów woli XP, to właśnie Vistę bym nazwał niszowym systemem...

Ja też nie. Czy to powód, żeby takiego nie robić? Po mojemu wręcz przeciwnie

No i nikt tu nie mówi o odpalaniu tego na tosterze, amidze czy mikrofalówce. Windows, OS X i Linux wystarczą, a wcale nie trzeba się specjalnie wysilać, żeby program działał na tych platformach - wystarczy dobry wybór toolkita. Qt byłoby ładne, poszłoby na wymienionych platformach i na urządzeniach mobilnych.

Wielu próbowało uratować konnekta i jeszcze nikomu się to nie udało nawet za pomocą zbiórki pieniędzy. Mam nadzieję, że tym razem coś z tego wyjdzie, ktoś zabrał się za zbieranie ludzi do tworzenia projektu i ci ludzie są i chcą pomóc. Ale nadal mam wątpliwości co do przyszłości konnekta, mam nadzieję tylko, że nie zabraknie wam chęci do tworzenia szybciej, niż zaczniecie coś działać.

Co do wieloplatformowości to dobrze by było żeby wasze wspólne dzieło działało chociaż na jednym systemie, żeby nie było sytuacji, że chcecie zrobić konnekta na kilka platform, a w końcu nie skończycie na żadną

Ktoś tam coś mówił o kadu?

Od dziś działające pod windowsem na qt 4.4

Małe porównanie wydajności:
Kadu: Puste, z moją listą kontaktów, obsługa tylko jednego numeru:
Konnekt: z 40 włączonych wtyczek, zmieny graficzne, podłączony do aqq, tlena, jabbera, gg, klan....

Czyli dokładniej porównanie winapi do qt

nie pisz głupot, bo źle będzie jak ktoś do czegoś Ciebie porówna

rozumiem, ze testowales oficjalne wydanie, zadna tam bete? ^^

.... jakbym miał poważny test zrobić, to czytalibyście go jako artykuł na thg (._.')

Robienie w tej chwili programu ktory bedzie dzialal tylko pod XP a pod Vista robil problemy jak Konnekt mija sie raczej z celem.
Chodzilo mi o to zeby sie skupic na jednym systemie a nie brylowac wieloplatformoscia, za ktora musza pojsc male usterki tu i owdzie.

Ale to juz decyzja samych piszacych.

Nalezy siazc na dupie, przejrzec wsyztskie inne komunikatory i sobie ladna liste zorbic co musi nowy miec a czego unikac.

Witam!

Jakiś czas temu korzystałem z dotGADU - biblioteki dla platformy .NET obsługującej protokół GG. Bardzo fajnie napisana (łącznie z podpowiaczami inteli-sense) i chyba wciąż rozwijana. Na jej podstawie i opisie protokołu GG napisałem (czyt. przepisałem) prosty komunikator obsługujący protokół GG w VB. Nie mam nic do C# a tym bardziej C++, po prostu w Basicu piszę najdłużej więc było mi najwygodniej i najszybciej napisać klienta GG "do testowania", docelowo chciałem stworzyć klienta GG dla Symbiana S60, bo oryginalny jest trialowy (!) a wersja JAVA dostarczana przez Erę jakoś nie powala na kolana :/
Z tego co pamiętam dotGADU jest chyba na licencji GPL i oryginalnie było napisane właśnie w C#.

IMO C# to dobry wybór, bo proste aplikacje takie jak komunikator będzie się tworzyć szybko i efektywnie co w brew pozorom w przypadku projektu non-profit tworzonego przez entuzjastów jest bardzo ważne.

Jeśli zaś chodzi o przenoszenie aplikacji na inny system, to prawda jest taka, że do komunikacji klient-serwer trzeba używać soketów TCP, które z tego co zauważyłem obsługuje się bardzo podobnie w znanych mi systemach, a to będzie tak naprawdę 30% całej aplikacji reszta to obsługa GUI, zarządzanie kontaktami itp. itd. a to już nie jest tak łatwo stworzyć w uniwersalnej postaci "strawnej" dla każdego OSa. Wiem, że są uniwersalne biblioteki jak np. FLTK ale ja zawsze wyznaję zasadę, że jak coś jest do wszystkiego to jest do niczego.
Dlatego chyba najlepiej byłoby zdecydować się na jedną platformę, albo towrzyć równolegle dwa lub więcej projektów.

Uff to tyle mojego przynudzania
Jeśli to komuś potrzebne to mogę podzielić się swoimi doświadczeniami z pisania komunikatora, bo swój projekt GG dla S60 chwilowo z braku wolnego czasu musiałem "odłożyć na półkę".

Pozdrawiam
BikeRk6

jeśli chceta serwer, grafiki itd pisać do mnie

powtorze sie o JUCE

a dlaczego nie C#, bo to technologia jednej firmy, bo to straszny memory hog, i masakra zaleznosci.

glupio jest pisac program ktory zalezy od czegos czego nie mozna spakowac w archiwum zip, dlatego lubie mirande i dlatego proponuje JUCE bo mozna to spakowac e jeden plik EXE wszsytko jest w jednej statycznej bibliotece, a jest tego duzo i jest bardzo dobrze napisane.

i gui i siec i watki, pana ktory zaproponowal ten temat namawiam do zobaczenia http://www.rawmaterialsoftware.com/juce/do...ds/jucedemo.exe
i sprawdzenia.

Zastanawiam się tylko dlaczego jest ograniczony dostęp do tego nowego forum (ja tam nic nie widzę), skoro ma być to projekt otwarty?

Otwarty, ale dla nich...
Podobno mamy mieć tam dostęp wkrótce

matrixik - projekt ma być open source, ale forum ma być .... zwykłe o.O

Po co Ci forum czegoś, co nie istnieje? To juz lepiej na chrześcijańskie iść i spytać kiedy zobaczymy Boga v20008.4 stabilną...

Bedzie co komentować to na pewno i forum będzie otarte ; )

witam

Nazywam się Dominik Cebula programowaniem zjamuje się praktycznie od dziecka - od 6 klasy szkoły podstawowej, języki: Pascal, Delphi, C/C++, C#, Java, od paru miesięcy prowadzę projekt DotGadu - http://dotgadu.sourceforge.net/, jest to wolna implementacja protokolu Gadu-Gadu w .NET.

Konnekta używam jeżeli jestem na windows, moim głównym systemem operacyjnym jest linux - dlatego również DotGadu jest rozwijany pod paltformę Novell MONO.

Pomysł napisania nowego komunikatora jest fajny, chętnie się włączę, trzeba jednak ustalić parę kwesti:
- kto zajmie się dekompozycją obiektową i stworzeniem dobrego diagramu UML?
- jak zamierzacie się zorganizować?
- chcecie napisać komunikator tylko dla windows czy również dla linuxa? jeśli chodzi o linuxa to dobrze byłoby zbudować natywny interfejs w gtk#
- potrzebny będzie oczywiście jakiś hosting oraz server SVN - o tym już chyba pisano w tym temacie
- jeżeli chcecie port na linuxa to nie warto jeszcze wchodzić w .net 3.5
- w zależności od tego czy chcecie aby nowy komunikator był lekki lub miał pełno fajerwerków warto zastanowić się nad WPF - ale wtedy raczej port na linuxa odpada...

Ja bardzo chętnie włącze sie w projekt więc osoby, które chcą pisać komunikator mogą do mnie napisać, umówimy sie na konferencje skype i wszystko obgadamy...

Tylko pewnie nazwę będziecie musieli nową wymyślić bo nazwa konnekt jest chyba zastrzeżona.

W skład nowej ekipy wchodzą też starzy programiści, a z tego co mi wiadomo na konferencji, która na początku tego wszystkiego miała miejsce, zjawił się także Hao, czyli pomysłodawca i pierwotny twórca Konnekta. Tak więc o prawa autorskie bym się nie bał.

A czy stara czy nowa nazwa... w zasadzie są 2 strony medalu:
- wielu ludzi kojarzy Konnekta z bardzo dobrym komunikatorem
- wielu ludzi kojarzy Konnekta z błędami krytycznymi, kłótniami na forum i "oszustwem" finansowym

Ja tam mogę mieć jakąkolwiek nazwę ; P Klonnekt ładnie brzmi i nawiązuje do faktu sklonowania Konnekta ; d

ja mógłbym zaproponować Konnekt.NET albo Konnetk# ;-)

Jak będziecie potrzebowali beta testerów to z chęcią się zgłaszam do testowania i zgłaszania błędów

Mój typ: ReKonn

Skoro był Hao, to może zamiast tworzyć nowy projekt, skończą konnekta (marzenie) ?




Mi to za bardzo kojarzy się z Kornem ;P.

Można sobie też literki poprzestawiać, w wyniku czego powstaje tzw. anagram stosowany często przy tworzeniu pseudonimów przez artystów, czyli np. Konnekt -> Ketonn (kojarzy się trochę z chemią, ale to chyba ostatnio modne, bo taki Intel wprowadził rodzinę procesorów dla urządzeń mobilnych o nazwie Atom). :D

konnekted ale i tak najlepiej by było jakby po prostu to był konnekt, miło że w końcu coś zaczyna się dziać, chętnie bym pomógł wam w tworzeniu komunikatora, ale nie mam o tym bladego pojęcia, więc życzę wam powodzenia

Konnekt 2.0

Kto Wam takich bzdur naopowiadał? Ja zorganizowałem te spotkanie i zaręczam że tej osoby tam nie było nawet przez ułamek sekundy...

Oj Jarek, wiesz z jakim uśmiechem się to czytało? . Żartuje oczywiście, hao nie był obecny i nie był przez nas ściągany

A nie jesteście chociaż ciekawi co on na to? Bo ja tak.

Nie będę podpisywał, kto mi takiego newsa zdradził. W każdym razie ta osoba była na tym 'zebraniu" obecna...

co by nie bylo - Jarek zdementowal te pogloski i to sie liczy. Jakos tak sie lepiej czlowiekowi robi po takich newsach, pamietajac zachowanie Siji... tj. jego milczenie

PS >> Jarek uraczysz nas jakas informacja ? bo mysle, ze nie tylko ja jestem taki ciekawski
PS_2 >> Dex a co on moze na to? jedynie moze miec do gadania jesli chodzi o nazwe nowego IM... chcialbym jedynie, zeby nie przeszkadzalo mu przejecie nazwy Konnekt'a, bo wiele ludzi wraz ze mna dobrze ta nazwe kojarzy

@joj_sport - w nazwie nie zostanie użyta fraza *konnekt* - jako że nie mamy do niej praw - nie użyjemy jej.
Co do szczegółów nie bardzo jest co ujawniać - nie ma co jeszcze. Mogę powiedzieć jedynie że na dzień dzisiejszy ekipa liczy ~~ 50 osób z czego 40 to sami programiści - ilu z nich zostanie po wakacjach? Mam nadzieje że jak najwięcej.

Postaramy się aby sam program był jak najbardziej modularny - jak Linuks czy Drupal.
W ekipie są bardzo dobrzy graficy więc po za funkcjonalnością postaramy się aby program przyciągał wzrok.

Program oczywiście nie będzie zawierał żądnych reklam, nie będzie za nim stałą żadna firma oraz jak najbardziej będzie bezpłatny na licencji GPL tudzież pokrewnej.

Pzdr!

Może warto zainteresować sie C#.Imho na potrzeby komunikatora język zdałby egzamin.Pozatym oferuje dużą przenośność, dzieki czemu komunikator uzyskałby większą popularność.

Keep it up guys! Don't f**k this up! Oby się udało! Trzymam kciuki!

Również trzymam kciuki, ale widzę Jarek, że wspomniałeś o grafice.
I tutaj bardzo istotna rzecz.
Nie wiem czy ja mam jakieś zboczenie na tym punkcie, ale komunikatory typu miranda, tlen, aqq sprawiały wrażenie (przynajmniej u mnie), że lista kontaktów jest strasznie... sztuczna? plastikowa? Nie mam pojęcia jak to nazwać.
A w Konnekcie była... była inna. Była prosta, przejrzysta (defaultowo, bo takiego 'czystego' używałem). Był prosty, ale zarazem piękny.
Proponuję jak najbardziej wzorować się na wyglądzie Konnekta i dodać ewentualne skórki zupełnie zmieniające wygląd, ale nie zróbcie z niego jakiegoś potwora.
Dodam, że Miranda chodziła u mnie zarówno na Viście jak i na XP strasznie wolno, nawet sama rozmowa. Widziałem ułamki sekund zanim tekst, który napisałem pojawił się w oknie rozmowy. W Konnekcie nigdy nie było takiego problemu, na Tlenie też jest lepiej.

PS. Opera też wydaje mi się taka toporna i strasznie "sztuczna" - co widać szczególnie w polach tekstowych, paskach przewijania itp. Nie mam pojęcia jak to opisać, ale może ktoś zrozumie o co mi chodzi...
Dlatego używam FF. Także na Linuksie pod KDE jak i GNOME.

szkoda ze nie zostanie uzyte *konnekt* bo przyzwyczailem sie do tej nazwy jak do imienia swojej kobiety xD mozna powiedziec, ze od kiedy jestem z nia, to i konnekt jest ze mna (pare lat ) xDDD

Nie no, mogli by tamto forum chociaż do odczytu dać, bez możliwości pisania...