Ostatnio dziewczyna poprosiła mnie bym napisał aplikację. W pracy musi ona bowiem pewne rzeczy robić, a dostępne oprogramowanie nie obejmuje pewnych aspektów i to właśnie do nich miałbym napisać trochę kodu. Tutaj sprawa rozbiła się o zastosowanie technologii. Aplikacja ma być typu portable - wrzuta na pendrive. Dostęp do sieci internetowej - zero. Ma być dostępna baza danych relacyjna.
Z początku więc rozważałem sqlite jako plikową i polecono mi także Adobe Air. Z tego co doczytałem (nie znam AA) to jednak chcąc, nie chcąc musiałaby aplikacja i tak mieć jakieś połączenie z serwerem, który serwowałby jej obrabiane dane. Z tutoriali itp. odniosłem bowiem wrażenie, że integrować można HTML, JS, AS, tyle że mi to się zda psu na budę, skoro AS nie znam a muszę mieć logikę biznesową jakąś, bo niestety, ale przyjdzie w tym oprogramowaniu generować raporty itp. a same JS i HTML sobie w takim wypadku nie poradzą. Tutaj po prostu język skryptowy w stylu PHP jest niemal nieodzowny, bo gołych danych nie będę słał od razu do bazy bez walidacji i obróbki, a raportów JS też sobie sam nie wygeneruje.
Trochę popracowałem z google i stanęło na XAMMP lite (php + Apache + MySQL). Sprawdziłem i taka kombinacja działa na bank zgodnie z wymaganiami. Tylko czy da się coś innego zastosować? Może jakaś alternatywa dla mojego pomysłu? Nie chciałbym bowiem się do określonego jednego rozwiązania skłaniać "bo tak mi wygodnie". Może jest jakiś inny prosty "jednoklikowy" serwer Apache+MySQL (ew. sqlite mogę dać, bo to nie problem), bo wiecie jak to jest przy XAMPP... Z pena wejść tu, kliknąć tam, potem jeszcze parę kliknięć tu, a jeśli da się wejdź i kliknij tylko raz jeden plik który postawi wszystko to i wygoda większa (wiem... mogę walnąć bata, który uruchomi odpowiednie exe, ale a nuż jest jakiś jednoklikowy ).

Wlasnie uzyles rozwiazan webowych do napisania aplikacji desktopowej, gratuluje.

Ode mnie mogę polecić PyQt4 (wymaga Pythona) lub czyste Qt4 - wbudowane sqlite i (chyba) mysql embedded, super dokumentacja i dużo widżetów. Jak skompilujesz to statycznie jako binarkę C++ to właściwie niczego nie potrzebuje (poza windowsem)

Polecam Server2Go - używałem go do prezentacji - ale osobiście napisałbym to w Accessie.

Ja pierd..
Po co tak na około jak można prościutko? wystarczy napisać aplikację desktopową a nie z pendrive odpalać serwer www, baze danych, przegladarke, i cala reszte zeby odpalić jakiś skrypcik.
C++, C#, VB, Java, Python, itd.. to wszystko umożliwia napisanie tego.

Ciekaw jak wyglądałby WinZip albo WinRar jakby jego autorzy tak podchodzili do sprawy

Tak swoją drogą, to czemu JS nie poradziłby sobie z raportami?
Moim zdaniem pomysł LBO z wykorzystaniem Accessa, jest kuszący, ale jak wiadomo zależy co dokładnie potrzebujesz.

W php tez sie da napisac desktopowke jezeli jest odporny na wiedze

Da się i w LOGO. Co nie znaczy że każdy jest masochistą

To może tak dopiszę dla Pućka i innych pokpiewających Projekt nie wymaga ode mnie pośpiechu (pisać miałbym zacząć dopiero w październiku) i rozglądam się za rozwiązaniami. Z racji dość dużego kobiecego "rozrzutu wymagań"( ) myślę by robić to w wersji mającej 2 klientów, tak na wszelki wypadek. Dokładniej to pisałbym w miarę równolegle 2 aplikacje bazujące oczywiście na tej samej bazie danych. Gdyby chciała używać przeglądarki miałaby dostęp do klienta webowego (tutaj myślałem właśnie o wspomnianym rozwiązaniu czyli Apache+PHP+RDB), ale istniałby także klient desktopowy. Co do tego drugiego to jakoś Java nigdy mi nie podchodziła, więc bardziej skłonny jestem użyć którejś z graficznych bibliotek C++, bo pisać samemu GUI w C++ to masochizm. A C++ zawsze lubiłem jako język, co bardziej do mnie przemawia i skłaniałbym się do Qt, ale że mało graficznych aplikacji pisałem i już kilka lat temu, więc nie orientuję się bardzo jak zmieniła wygoda jego użytkowania (to, że licencja się zmieniła to wiem). Z tego co doczytałem, istnieje także obsługa PHP w nim w formie projektu PHPQt, co dodatkowo byłoby fajne, gdyż zapewne (nie wiem, nie wczytałem się jeszcze w dokumentację PHPQt) różnica między desktopem i webową wersją ograniczyła by się do zaprojektowania innych widoków, GUI dla nich. Z racji jednak długiego czasu na przemyślenie (2 miesiące) mogę poczytać o ewentualnie innych rozwiązaniach, propozycjach.

Jeśli chcesz pisać aplikację desktopową, która ma działać na Windows, proponuję C#. Jeśli aplikacja nie będzie zbyt skomplikowana, to przy odrobinie wysiłku napiszesz ją w kilka tygodni. Co do bazy danych, to dużo Ci nie pomogę, niestety nie zagłębiałem się w obsługę baz danych w aplikacjach desktopowych, jednak nie powinieneś mieć problemu z zastosowaniem SQL Server w swoim projekcie (poczytaj o wersji Compact). Na upartego możesz zrobić aplikację w Silverlight, która instaluje się w systemie i nie wymaga przeglądarki internetowej.

Dlaczego skreśliłeś Adobe AIR? Możliwości oferowane przez wersję z obsługą Javascript są na prawdę duże i niewiele ustępują Action Script. Z drugiej jednak strony AS3 jest bardzo prosty do nauki i nie straciłbyś dużo czasu na naukę. Musiałbyś tylko przestawić się na programowanie oparte o zdarzenia, co wielu osobom sprawia problemy.

darmowe multi-platformowe gui dla c++ http://www.wxwidgets.org/ i darmowy wizualny edytor http://wxdsgn.sourceforge.net/ w tym możesz napisać swoją aplikację desktopową, dość szybko i sprawnie skoro java ci nie odpowiada. Zamiast bazy zastosowałbym zwykła serjalizację do pliku dla jednego użytkownika i aplikacji desktopowej.

A ja przekornie zostałbym przy pierwotnym założeniu - tj. aplikacji webowej. Nie jest to optymalne rozwiązanie, ale idę o zakład, że napiszesz szybciej tą aplikację w znanych Ci technologiach niż nauczysz się czegoś nowego. Wiadomo jakie potworki wychodzą z pierwszych próba programowania w danym języku/środowisku ;-)

Także jeśli jedynym celem jest napisanie tej aplikacji to napisałbym ją w narzędziu, które znam nawet jeśli nie jest ono optymalne do tego celu.

Popieram athabusa. Choć z drugiej strony nauczyłbyś się czegoś nowego.

Co do PHP-Qt - huh.. można się rozczarować . Nie ma np. slotów i sygnałów. W sumie, nie chodzi o to, że pomysł jest nieciekawy(bo może się to przydać w przyszłosci) ale bardzo mało osbób w ogóle się tym interesuje więc społeczność jest mała.

Ze zwykłych języków mógłbym polecić C++ jednak różnice w obiektówce w porównaniu do PHP/Javy są ogromne(głównie chodzi mi o wiązanie ale nie tylko) i mogłoby to być męczące jeśli nie pisałeś dużo w c++.

Sam przygodę z programowaniem zaczynałem od C++, szybko porzuciłem go na rzecz PHP i JS.
Po pewnym czasie zainteresowałem się Javą, lecz w żaden sposób nie przemawiał do mnie ten język. Spróbowałem C# i przez kilka tygodni tylko w nim pisałem, olałem php i resztę. ;p Nie wiem właściwie czemu ten język mi się tak spodobał. Przyzwyczajony jestem do prostych języków typu php a tutaj taka zamiana, w dodatku tam jest obiektowe wszystko (Chyba), ale bardzo przyjemnie się w nim pisze.

Osobiście polecałbym C# jeżeli platformą ma być Windows, w przeciwnym wypadku (różne platformy) pozostaje tylko Java.

Z tymi językami jest o tyle problem, że C# wymaga .NET z tego co pamiętam, z resztą Java też potrzebuje środowiska w którym się uruchomi.

PHP? Do takiej aplikacji raczej w żaden sposób się nie nada. ;p
C++? Lubisz? Jesteś masochistą? Ma to swoje plusy, kod wykonuje się bardzo szybko.

fifi - c# to bardzo fajny język, zwłaszcza w połączeniu z ide od ms. Piszę się na prawdę szybko i łatwo, dlatego też taka moda teraz na niego. Sam gdybym miał coś pisać na desktopy to pewnie kierowałbym się w jego stronę.

C++ i C# nie ma co porównywać bo to trochę inne języki/zastosowania.

Natomiast co do tego, że php nie nadaje się na aplikacje desktopowe to hmm. Kiedyś też bym tak stwierdził, ale ostatnio coraz bardziej się nad tym zastanawiam. Pracuje w wolnych chwilach nad takim projektem backendu do sklepu internetowego, który zawiera:
- prosty system magazynowy z wprowadzaniem zakupów etc
- integrację z działającym sklepem - pobieranie zamówień etc
- wyszukiwanie towarów
- sprawdzanie kompletności zamówień (skaner kodów kreskowych porównuje co jest w koszyku z faktycznym zamówieniem)
- wprowadzanie faktur zakupowych
- planuje też dodać obsługę kasy fiskalnej bo podobno jest to możliwe
- wykonywanie zamówień w hurtowniach
- planowanie tras dla kurierów (tu np. zastosowałem taki fajny myk z drag&drop)

Wszystko to napisane jest w php (a dokładniej w symfony) + jquery do interfejsu. Dzięki dużej ilości jquery i ajaxu wszystko działa bardzo fajnie - interfejs w moim odczuciu w ogóle nie ustępuje pod względem wygody takiemu jaki oferują aplikacje okienkowe - mam wszystkie rzeczy takie jak: drag&drop, pola tekstowe z autocomplete, itd. Można mówić, że nie jest to technologia przeznaczona do tego typu rzeczy i z tym się zgodzę, ale przy dobrym przemyśleniu tematu spokojnie można odtworzyć w przeglądarce wszystko to co ma aplikacja desktopowa.

Wg mnie w ogóle oprogramowanie będzie trochę ewoluowało w takim kierunku (pewnie powstaną nowe technologie albo frameworki rad'owe do istniejących rozwiązań), bo programy oparte o webowe technologie mają trochę plusów np:
- brak konieczności instalacji
- praktycznie 100% przenośności między systemami

Dzięki temu np. mogę odpalić system magazynowy na iphonie gdy akurat nie ma mnie w biurze a chce coś sprawdzić.

Nie chciałbym zostać źle zrozumiany - nie uważam, że programowanie aplikacji desktopowych za pomocą technologii webowych jest najlepszym rozwiązaniem, ale jak najbardziej jest to możliwe bez utraty funkcjonalności, a nawet ma to pewne swoje plusy.Co do szybkości pisania to (sam się zdziwiłem) przy zastosowaniu frameworków (ja stosowałem symfony i jquery) wcale nie ma aż tak dużej różnicy w porównaniu z np. C#.

Co do przenośności nie zgodzę się w 100%, jak widzisz potrzeba odpalić serwer apache - to minimalne wymaganie. I po zabawie z iPhonem.

Halo, ale to jest akurat specyfika problemu theka, że musi odpalić to na komputerze bez internetu. W normalnych warunkach stawiasz przecież serwer i na nim odpalasz aplikację. Klient potrzebuje tylko przeglądarki ;-) Mój system magazynowy będzie stał na komputerze w firmie (w celu zwiększenia responsywności) + poprzez zewnętrzne ip będzie dostępny z dowolnego miejsca, tak aby można było coś "sprawdzić na szybko" np. za pomocą iphona.

Zauważ, że pojawia się coraz więcej aplikacji, które kiedyś stały na desktopach a teraz migrują do sieci właśnie ze względu na wygodę użytkowania/możliwość korzystania z kilku komputerów czy telefonów. Np. projekty tupu menadżery osobiste, listy zadań, kalendarze, aplikacje do przechowywania zdjęć, systemy do księgowości i wiele innych. Czasami pisze się też dwa frontendy - jeden desktopowy aby można było korzystać z aplikacji na co dzień i drugi webowy, który realizuje jakieś wybrane operacje - np. wsparcie dla mobilnych pracowników. Np. jedna z obsługujących mnie hurtowni ma przedstawicieli, którzy składają zamówienie poprzez przeglądarkę.

Ja osobiście wierzę, że jest to trend, który będzie się wzmacniał - pytanie tylko jaka technologia zostania dostosowana do pisania tego typu aplikacji - php ma wszystko czego potrzeba gdy połączysz to z javascriptem. Brakuje tylko jakiegoś ide typu rad, który zintegrowałby wszystkie technologie w jedno narzędzie.

Sam napisałem swój system z prozaicznej przyczyny - na rynku nie było nic co sprostałoby moim skromnym ale wyszukanym oczekiwaniom (no może poza systemami za >100k zł), a nie czułem się na tyle dobry w rzeczach desktopowych aby pisać w nich tak skomplikowany system. Ogólnie jednak mogę powiedzieć, że udało mi się odtworzyć w przeglądarce wszystko czego potrzebuje aplikacja do zastosowań biurowych bez utraty funkcjonalności (a nawet doszło kilka zalet) i przy tym wcale nie było to takie trudne jakby mogło się wydawać. Sam znam JavaScript bardzo słabo, ale dzięki jQuery interfejs nie stanowi już problemu nawet dla osoby używającej JS od święta.

Amen. Dodam od siebie, że niektóre javascriptowe frameworki np. ExtJS oferują niemalże większość (jeśli nie wszystkie + nawet to, czego desktopy nie oferują lub oferują bardzo rzadko) dostępnych kontrolek desktopowych (edytowalne listy, drzewa, ) i generalny trend jest taki, że zarówno wygląd, jak i funkcjonalność poszczególnych elementów składowych aplikacji internetowych zmierzają do maksymalnego zbliżenia do tego, co oferują aplikacje desktopowe. Zresztą, co tu dużo pisać, wystarczy wejść na przykład tutaj - proszę kompletny desktop (symulacja pulpitu).

No to po kolei
@batman: aplikacja znając życie nie wyjdzie poza środowisko windowsa, więc c# ma szanse. Co do bazy danych z racji przenośności skłaniałbym się ku sqlite, ale postawić chodzący w tle serwer mysql nie jest trudno. W zasadzie napisałem już dziewczynie skrypt batowy, który odpala jednym kliknięciem apache, mysql i uruchamia portable firefox. Tak więc środowisko użytkowe miałaby w pełni przygotowane. AdobeAir skreśliłem z racji tego, że muszę dane walidować, obrabiać, tworzyć raporty i obawiam się, że sam AA by nie dał rady. Skoro musi się wspierać dodatkowym skryptem który mu dane przygotuje choćby do formy JSON, to już lepiej całość w PHP zrobić z pominięciem tej technologii. AA daje mi tylko uniezależnienie od przeglądarki tak naprawdę w tym wypadku jedynie. Jeśli C# wymaga .NET do działania to trochę mniej ciekawie się to zapowiada, bo nie wiem czy jest ona zainstalowana na kompach. To samo tyczy JVM w przypadku Javy i stąd właśnie te 2 języki daje na listę rezerwowych.
@emp: o wxwidgets też myślałem... Ba mam nawet książkę w domu o pisaniu pod qt i wxwidgets aplikacji z GUI, więc też nad tym myślę czy nie byłoby sięgnąć i nie zgłębić tematu lepiej. Co do serializacji to boję się o wydajność tego rozwiązania, ale są to obawy, które mógłbym skonfrontować z sqlite i mysql ostatecznie.
@athabus: miałem długi kontakt z C++ (także STL), więc to nie jest skok na głęboką wodę. A co do PHP to faktycznie wiele osob myśli php = webdeveloping, co akurat jest jak dla mnie zbytnim uproszczeniem. Wywodzi się on bowiem z C i tak jak on nie ma po prostu własnych bibliotek stricte GUI niemal od początku (qt i inne biblioteki gui to dopiero późniejsze pomysły) jak choćby Java i jej awt oraz późniejszy swing.
@SHiP: Akurat C++ się nie boję. Jak wspomniałem już kiedyś parę razy, do PHP podchodziłem z bagażem z C++ właśnie i php uznałem za taki mocno okrojony C bez wielu rzeczy znanych mi z C oraz kilkoma uproszczeniami jak brak typizacji choćby czy wielodziedziczenia i polimorfizmu. Jeśli faktycznie Php-Qt nie jest taki fajny to może rzeczywiście na samym Qt gołym bym się skupił jeśli na niego ostatecznie padnie wybór.
@fifi209: C++ nie jest obiektowy. Podobnie jak php jest obiektowo orientowany. Możesz pisać cały kod strukturalnie jeśli chcesz. Twoja wola i pomysł A co do iPhone'a to myślisz, że na MacOSX nie dałoby się odpalić jakiegoś prostego serwerka z obsługą php? Myślę, że jak najbardziej tak Poza tym to aplikacja w sumie CRUD więc coś co najczęściej właśnie php od strony webowej robi i dlatego ten język jak najbardziej tu pasuje logicznie. A co do przenośności to Athabus ma rację. Jest przenośne jeśli masz połączenie z netem. Wtedy tylko łączysz z serwerem, który przesyła całość GUI. Problemy mogą być jedynie z komórkami, które JS nie wspierają.

Jak na razie więc byłoby:
Baza danych: sqlite, mysql (konieczne postawienie serwera) bądź serializacja do pliku
Klient webowy: php+JS+CSS (ogólnie standard z koniecznością postawienia serwera Apache'a)
Klient desktopowy: na razie pierwsze miejsce idzie ku C++ z biblioteką Qt jako GUI, dalej wxWidgets i rezerwa C#

Jeśli mimo wszystko zdecydowałbyś się na jakiś język interpretowany to przemyśl kilka razy Pythona (do gui np. PyQt4 lub inne bindy - PyGtk). Niesamowicie wygodny obiektowy język. Z mojego punktu widzenia wymusza chyba najczytelniejszy układ kodu (wcięcia). W dodatku jak osiądziesz w Pythonie to możesz później przeskoczyć na jego webowe frameworki (np. Django). Nie jest on tak popularny jak PHP-owe frameworki, ale ostatnio konkurencja na tym polu jest duża

Adobe AIR ma duże możliwości, wystarczy spojrzeć na e-Deklaracje oraz aplikację dostępową do konta banku Raiffeisen. AS3 ma duże możliwości i sądzę, że w Twoim przypadku da radę.

Z kolei jeśli skusisz się na C#, to polecam przeczytać http://www.maciejaniserowicz.com/post/2010...10-i-MySQL.aspx
Autor krótko i na temat opisuje sposób korzystania z MySQL w Visual Studio 2010.

Ok... Pythona sobie w domu w chwili późniejszej obadam Mogę w każdym razie dodać na listę rezerwową wraz z C# na ten moment.

P.S.: Swoją drogą ciekawi mnie jedno tak off-topem. Jest to chyba jak na razie jeden z nielicznych tematów, gdzie są poruszane kwestie różnych języków do jakiegoś zadania, gdzie nie widzę w sumie flame-wara co lepsze i wypowiedzi są stonowane. Cieszy mnie to i mam nadzieję, że tak się utrzyma długo. Jednak normalna rozmowa może dać więcej niż jakieś idiotyczne wojny. Swoja drogą ten przykład z ExtJS pokazuje pewien trend od już jakiegoś czasu trwający, który dąży do coraz szerszego stosowania web-based apps, czego przykładem może być choćby Google, który coraz więcej aplikacji lokuje na swoich serwerach i do części podstawowych rzeczy w sumie nie potrzeba już nic więcej niż przeglądarka i połączenie z netem. Jeśli na tej samej zasadzie będzie działać ChromeOS (jedyna aplikacja to przeglądarka, a reszta to pluginy, widżety z nią zintegrowane) to w sumie może być to specyficzna alternatywa dla klasycznych systemów operacyjnych.

@batman: to że ma możliwości to widzę. Problemem jaki widzę byłoby dokładanie kolejnego softu. Rozumiem, że AAir zastąpiłby przeglądarkę, tylko tu się zastanawiam co będzie wydajniejsze, szybsze jako efekt końcowy: użycie AAir czy może przeglądarki (nieopluginowany Firefox - jest szybki, a ja przecież nie potrzebuję żadnego pluginu w takim wypadku do niego) ? Co do C# to mnie ten .NET boli trochę, bo z tego co czytałem connectory do sqlite i mysql istnieją, więc to problemu nie sprawia.

A może powiedz jaka to ma być aplikacja. Co ona ma robić.

Z Air to trzeba uważać, tak samo jak z SilverLight. Nie wiem jak to jest teraz na Apple ale chyba wypowiedziało ono wojnę flashowej technologii w ogóle. Inni wielcy też kręcą na to nosem. Prędzej przyjmą się rozwiązania bazujące na HTML5 (JS+HTML/XML+cholera wie co jeszcze). Tak więc uczmy się JSa! .

(Flame on) A najoszczędniejszym rozwiązaniem i tak pozostaje czyste Qt4 - wszystkie biblio wbudowane i skompilowane. Tylko uruchamiasz (flame off)

W sumie wybór technologii powinien zależeć nie od tego w czym będzie szybciej/łatwiej napisać, a od przyszłości jaka przed daną technologią się maluje. W chwili obecnej takimi technologiami są .NET oraz Flex (AIR). Nie twierdzę, że są to jedyne rozwijające się technologie, ale w nich chyba rozwój jest "najgłośniejszy". Poza tym zarówno .NET jaki i Flex posiadają bardzo dobre środowiska do tworzenia aplikacji, które bardzo pomagają w tworzeniu aplikacji.

Jeśli chodzi o trend przenoszenia wszystkiego do sieci to mam taką swoją teorię, że wszystko zależy od kosztu mocy obliczeniowej. Obecnie taniej jest wyprodukować 5 słabych procesorów niż jeden mocny, ale granica ta się bardzo szybko przenosi. Teraz gdyby sobie wyobrazić sytuację, że osiągniemy moment gdzie dla domowego użytkownika nie da się już sensownie stworzyć aplikacji, które będą wymagały ciągle nowszych procesorów czy innego sprzętu to okaże się, że tak na prawdę taniej będzie produkować super wydajne maszyny a użytkownikom dać tylko interfejs do łączenia się z nimi. Ten trend już widać - na razie są to proste aplikacje nie wymagające dużych mocy obliczeniowych, ale wraz z wzrostem mocy coraz więcej aplikacji będzie opłacało się trzymać na zewnątrz.

Wg. mnie technologie webowe doskonale zastępują już dzisiaj 95% zastosowań desktopowych, brakuje tylko czegoś co ułatwiałoby pisanie takich aplikacji. Zobaczcie, że Google wypuszcza co chwila coś po czym ludzie przecierają oczy ze zdumienia (mapy, pakiet biurowy, kalendarz etc), ale oni nie używają w tym celu niczego nowego - pokazują tylko inne od szeroko uświadamianego zastosowanie dla istniejących technologii.

Ja dla przykładu 2 lata temu próbowałem napisać aplikację biurową, która w zasadzie powinna być desktopowa, ale chciałem ją zrobić "w przeglądarce". Wtedy poległem właśnie na js - już wtedy dało się to zrobić, ale było to kopanie się z koniem. Obecnie symulowanie aplikacji desktopowych jest dziecinnie proste.

Tak już na koniec to powiem, że mam taką dziwną obserwację, że pisanie w technologiach webowych daje większą swobodę w konstruowaniu interfejsu. W takim c# wszystko jest już tak zestandaryzowane, że każda aplikacja wygląda tak samo. Prawie nikomu nie chce się dopisywać dodatkowych funkcjonalności wychodzących poza standardowe kontrolki. Prawie każda aplikacja biurowa stosuje utartą kolorystykę bazującą na ustawieniach systemu - jednym słowem monotonia.
W przypadku aplikacji webowych wszystko nie okrzepło jeszcze na tyle aby był "gotowy zestaw do wszystkiego" i często pojawiają się różnego typu umilacze przez co często takie aplikacje są bardziej interaktywne, wygląd aplikacji webowych jest znacznie bardziej atrakcyjny dla użytkownika.
Oczywiście wiem, że można w c# zrobić fajny interfejs - tyle tylko, że prawie nikt go nie robi.
I kończy się tak, że aplikacja napisana w c# wygląda tak a webowy odpowiednik tak.
Nie wiem czy rozumiecie o co mi chodzi, ale musiałem to z siebie wyrzucić ;-)

Dlatego też Qt4 po integracji z Webkitem umożliwia stylowanie interfejsu za pomocą CSSa. Nigdy co prawda nie było mi to za bardzo potrzebne (ja wolę jak mi działa a nie mruga i błyska), jednak daje olbrzymie narzędzie do modyfikowania właściwie wyglądu każdego widżetu. Ale i tak muszę przyznać że webowo jest to prostsze.

~athabus
Nie zgodzę się, że w C# tworzy się brzydkie aplikacje. Oto dlaczego:
1. Screen aplikacji C# - stara aplikacja, na oko około 5 letnia. Aplikacja www nie więcej niż rok.
2. Obecnie mamy do dyspozycji WPF, który daje ogromne możliwości, jeśli chodzi o wygląd. Stare brzydkie formularze odchodzą powoli w niepamięć.
3. Należy pamiętać, że programista najczęściej nie jest grafikiem. Zdejmij grafikę z aplikacji www i oprzyj ją jedynie na domyślnym wyglądzie, to będziesz miał taką samą "kupę".

batman - rozumiem twój punkt widzenia.
Tyle tylko, że bazując na swoim doświadczeniu:
- tworząc aplikację webową nie mam ŻADNEJ prezentacji - zazwyczaj ściągam jakiś darmowy szablon i go stosuję więc uzyskuję ładną grafikę
- tworząc aplikacje desktopową mam od razu i logikę i prezentację - fajnie bo jak piszesz programista to nie grafik, ale wiele prostych aplikacji kończy właśnie w takim stadium. Nie piszę, że to źle/dobrze - ot taka moja obserwacja, że aplikacje webowe często są atrakcyjniejsze/mniej sztampowe od aplikacji desktopowych.

Tak jak sobie teraz o tym myślę, to aplikacje webowe tworzą ludzie, którzy robili strony i chcąc nie chcąc mają trochę wiedzy/doświadczania na temat grafiki - taki zwyczaj, że strona musi ładnie wyglądać ;-)

//PS nie traktuję tego jako przewagę technologii webowej - bo w zasadzie to technologie desktopowe oferują więcej (tą bazową prezentację) - natomiast rezultat ostateczny to już wypadkowa tego czy programiście desktopowemu się chce czy nie

@athabus i @batman:
Mi akurat taki surowy wygląd aplikacji (jak przedstawiona w C#) odpowiada hehe. Styl Windowsa XP mam ustawiony na klasyczny, nie XP

PS: sorry za wtrącenie się

To może z innej strony jeszcze - bo uczepiliśmy się tylko tego wyglądu. Jak już pisałem, w aplikacjach webowych pojawiają się też "niesztampowe" rozwiązania. Przykładowo w swoim systemie pracowałem nad zarządzaniem dostawami. Problem jest taki macie x kurierów, którym trzeba przydzielić dostawy, ustalić każdemu kolejność, zadzwonić do każdej osoby i umówić dostawę, przypisać godzinę do dostawy i ewentualne komentarze klienta (np. trudny dojazd/niedziałający domofon).

- W aplikacji desktopowej próbowałbym odtworzyć te zachowania za pomocą pewnych utartych schematów - czyli gotowe formularze +wyskakujące okienka do edycji etc. Ogólnie da się to rozwiązać jakoś fajnie, ale gotowe kontrolki trochę ograniczają, a nikomu nie chce się dorobić czegoś samemu.

- W aplikacji webowej zrobiłem cały fajny interfejs oparty o przeciąganie divów w odpowiednie miejsca, co przydziela w bazie dostawę dla kuriera i ustala jej kolejność (jQuery ui sortable) - w divach oczywiście możliwość ustawienia godziny dostawy, dopisania komentarzy etc. Tak fajnie to wyszło, że momentami sprawia mi przyjemność zabawa tymi dostawami.

Do czego zmierzam - technologie webowe są obecnie bardziej generyczne przez co ludzie bardzo często robią w nich niestandardowe rzeczy. Jest to i wada (pewnie dłużej się pisze) ale i zaleta bo aplikacje są bardziej "przyjazne". Programowanie webowe przypomina mi zajęcia z kreatywności w biznesie na studiach, gdzie mieliśmy wymyślić np. 10 zastosowań dla zużytego wkładu do długopisu ;-)

Mówiąc jeszcze prościej - znacznie częściej zaskakują mnie rozwiązania w aplikacjach webowych niż desktopowych.

Mi się wydaje, że aplikacje webowe wyglądają jak wyglądają, ponieważ chcą się upodobnić do aplikacji desktopowych (drag and drop i inne bajery). Co nie oznacza, że są gorsze. W wielu zastosowaniach są o wiele.
Żyjemy w czasach, w których granica między aplikacją webową, a aplikacją desktopową zaciera się, a to co instalujemy na dysku jest jedynie interfejsem do danych znajdujących się "gdzieś tam". Aby nadążyć za coraz to nowymi urządzeniami, na których można uruchomić aplikacje, technologie muszą stać się uniwersalne, a taką uniwersalność oferuje aplikacja webowa. Widać jednak ruch w drugą stronę. Zamiast tworzyć aplikacje www i dostosowywać je różnych urządzeń, lepiej stworzyć coś, co będzie przenośne. I tutaj dochodzimy do RIA, czyli Flex/Flash oraz Silverlight. Obie technologie umożliwiają tworzenie aplikacje www oraz desktopowe. Do tego czytałem gdzieś, że AIR działa na Androidzie. Silverlight z kolei będzie podstawowym narzędziem do tworzenia aplikacji na telefony Windows Phone 7. Ponadto trwają prace (i już są sukcesy) nad zaadaptowaniem tej technologii na telefony Nokii.

Najważniejsze jest jednak to, nie w jakiej technologii dana aplikacja jest wykonana, a w jaki sposób możne synchronizować dane. I to jest aktualnie największy problem.

Chyba zapomniałeś o xml i SyncML (=Synchronization Markup Language), które częściowo rozwiązują problem synchronizacji danych pomiędzy różnymi urządzeniami. Jest nawet framework http://www.opensync.org/.

Widzę, że moja nieobecność dała pole do wymiany poglądów
@wookieb: jak wspomniałem, będzie to typowy CRUD: baza w tle, formularze do wprowadzania danych i ich edycji, generowanie raportów. Chyba nie stanie się nic jeśli powiem, że to będzie obsługa księgowa kasy pożyczkowej. Tak więc kontrola wkładów, wpłat i wypłat, deklaracji przystąpienia do i wypisania z, czy po prostu podjęcia ich. Szczegóły z dziewczyną sobie omawiam w chwilach wolnych czasem.
@batman: wszystko na początku jest głośne Problem z tym, czy potem sie przyjmuje. O ile z AdobeAir można mieć nadzieję na okrzepnięcie jak było z Flashem czy AS ogólnie, to Silverlight wywołuje u mnie mieszane uczucia co do możliwego sukcesu. Owszem, jest fajny, tylko czy to wystarczy? C# i .NET maja już w miarę ugruntowana pozycję, więc o nie się nie boję Aczkolwiek C# ma raczej opinię takiego przyrodniego, nieco ekstrawaganckiego, brata C++
@athabus: rozwój idący w ilość procków zamiast ich moc to coś co przewidywano już od początku. Zdawano sobie bowiem sprawę z granicy procesów technologicznych. Co pewien czas granicę się przesuwa, ale na pewno nie przekroczy się dla elektroniki bariery atomowej, bo to elektrony są nośnikami informacji. Są badania nad innymi (białkowe, kwantowe), ale i one będą miały swoje granice. Wielordzeniowośc i wieloprocesorowość są nieuniknione tak czy inaczej. Byłem wiele lat temu na uczelni na wykładzie Intela na temat Hyper-Threadingu (był to okres gdy były przecieki o Centrino, czyli jakieś 2002-2003 ) i tam już mówiono o technologicznej barierze 10nm dla procesorów. Na razie jesteśmy na etapie 32, więc jeszcze mamy trochę czasu, ale zobaczcie co już się dzieje. Mocniejsze i7 o szybszych rdzeniach nie są robione w 32nm, ale na powrót w 45nm(!) i Intel wie, że tylko kierunek idący w ilość a nie prędkość rdzeni jest jedynym sensownym rozwiązaniem na przyszłość i kierunek ku architekturze RISC z odchodzeniem od dotychczasowego CISC by sobie ułatwić synchronizowanie wszystkiego
@phpion: rozumiem Cię... sam mam wszystko na classic i wodotryski możliwe off. Jak wydajność to wydajność. Ale czasem jest tak że człowiek chce zaszaleć, zrobić coś nieco inaczej niż zazwyczaj.

Batman w moim odczuciu dotknął tego z czym ja mam właśnie nieco dylemat. "W którą stronę iść?" Czy pisać aplikację desktopową stricte, czy może ukierunkowywać się na stronę webową, bo oba kierunki coraz bardziej upodabniają się do siebie, czy też bardziej prawdziwie - webowe aplikacje zaczynają przeskakiwać desktopowe pod względem estetyki interfejsu, choć wciąż są w tyle z wydajnością. A że akurat o synchronizacje nie muszę się martwić (tylko dziewczyna to będzie obsługiwać i nie będzie sytuacji gdy więcej niż 1 osoba w tym samym czasie) to tak naprawdę mam pełną swobodę wyboru z języków dostępnych.

Swoją drogą kierunek dyskusji, mimo że odbiega nieco od głównego tematu, to uważam za o tyle ciekawy, że dobrze byłoby kontynuować. Takie swoiste: "Desktop vs Web" developing. Zebranie plusów i minusów różnych języków w obu wariantach z zarysowaniem sensu stosowania, kierunków i przewidywań rozwoju. W necie jest bowiem wiele, ale czesto jest to rozwalone na wielu stronach i myślę, że zebranie tego do kupy byłoby jakimś punktem wyjścia dla niektórych. Nie chodzi mi tutaj jednak o coś w stylu "Który język lepszy", bo to typowy flame. Bardziej bym się skupił na perspektywicznym podejściu do nowo powstających rozwiązań czy też świeżych gałęziach w tych już okrzepłych.

Odnośnie samego wyboru języka to moim zdaniem dobrze byłoby się skupić bardziej na wymaganiach samej aplikacji. Trzeba sobie odpowiedzieć co jest najważniejsze. W niektórych przypadkach istotne będą przenośność, dostępność dla wielu systemów, możliwość korzystania z różnych lokalizacji, czy różnych urządzeń końcowych. W innych nic z w/w nie będzie wykorzystywane.
Drugim ważnym elementem jest sama baza danych, czy ma być tylko lokalna, czy zdalna, jeśli zdalna to czy ze stałym dostępem on-line, czy tylko z jednorazowym celem synchronizacji.

Wybór samego języka, czy technologii powinien przyjść raczej sam. Przykładowo ja bardzo lubię mieć dostęp do swoich ulubionych aplikacji gdziekolwiek jestem. Opcje mam w zasadzie 3: webowe, portable, własny system na pendrive. Aplikacje w wersji portable rozwiązują problem przenośności pomiędzy lokalizacjami (dom - praca). Nie załatwiają natomiast tej pomiędzy systemami (win - lin), tu z pomocą przychodzą aplikacje webowe - jednak te nie działają off-line. Idealnym rozwiązaniem okazują się być aplikacje, które są w stylu portable, ale z własną bazą danych z możliwością synchronizacji z bazą główną. To tak pode mnie, moje wymagania, preferencje.

Wracając do tematu, jeśli to ma być program do obsługi księgowej kasy pożyczkowej to takich wymagań raczej mieć nie będzie. Dzięki temu możliwości jest więcej. Ważne przy wyborze będzie:
- czy program będzie jednostanowiskowy
- jaka forma bazy (lokalna, zdalna)
- czy komputer ma stałe łącze internetowe
- czy będzie potrzebny zdalny dostęp do danych zgromadzonych w programie
- jakie są możliwe przypadki użycia systemu i przez kogo
- na jakim OS
- przewidywane przeprowadzki OS (aktualizacje: win xp -> win7, zmiany na inny: win -> lin)
- możliwość instalacji środowisk uruchomieniowych (AA, .NET)

To kilka kwestii. Odpowiadając na takie pytania możesz nieźle zawęzić (metodą eliminacji) możliwe do wykorzystania technologie. Bo jeśli np z systemu mają korzystać wszyscy pracownicy punktu, to już wiesz, że ma być baza centralna. Jeśli np okaże się, że inny punkt w innym mieście też, albo szefostwo chce popatrzeć na raporty - to może opłaca się aplikację webową nad stacjonarną. Jeśli okazuje się, że mamy wielu użytkowników aplikacji w terenie z różnymi telefonami (ajfony, nokie czy inne palmtopy) - każdy z innym systemem operacyjnym - może warto aplikację webową. Może wystarczy aplikację stacjonarną z własną bazą lokalną +aktualizacja bazy głównej na żądanie (bez stałego dostępu on-line), napisaną w dostępnym na wiele platform systemowych/sprzętowych środowisku uruchomieniowym. Albo, gdy zależy na szybkości działania, a program będzie uruchomiony tylko na jednym stanowisku - aplikacja desktopowa np w C#.

Jestem zwolennikiem aplikacji maksymalnie przenośnych. Lubię, gdy po synchronizacji opery na win w pracy wracam do domu, siadam np na Mint'a, tam robię synchronizację i wszystko mam. Albo biorę na pendrive pidgina i zbieram historię rozmów w jednym miejscu. Albo gdy moje to-do-lists mogę sprawdzić w telefonie, w domu, pracy etc.

Kończąc ten przydługi wpis. Wiele różnych rożnych przypadków, każdy inaczej rozwiązany. Każdą aplikację można rozwiązać na wiele działających z powodzeniem sposobów. Jeśli napiszesz swoją w c# będzie pewnie ok, jeśli zrobisz ją w AA - też, dostępna przez www również będzie działała. Wybór technologii powinien zależeć od tych czasem drobnych szczegółów późniejszego korzystania.

I tu jest własnie zabawa vokiel bo w zasadzie wszystko co zastosuję będzie dobre Czemu? Odpowiem na postawione przez Ciebie pytania:
- czy program będzie jednostanowiskowy -> w gruncie rzeczy tak. Dostęp do niego będzie miała tylko moja dziewczyna. Nawet osoby ją zastępujące w czasie urlopu nie będą miały do niej dostępu, bo jej fizycznie na kompie nie zostawi. To taka przenośna aplikacja "for your eyes only". Pewne bowiem rzeczy do księgowania nie są objęte działającym tam oprogramowaniem. Konkretnie to obsługa przez kasę osób emerytowanych, rencistów i rodzin zmarłych pracowników, na których przeszły świadczenia pracownicze. Ktoś nie pomyślał pisząc soft o takich przypadkach, przez co księgować je trzeba, bo tego wymaga prawo, ale program nie ma takiej opcji i właśnie tę lukę zapełniam. A dziewczyna tego nie rozpowszechni i stąd nie będzie instalatora tylko wersja portable, by nikt nie korzystał z tego rozwiązania poza nią. Nawet osoby z nią siedzące w biurze.
- jaka forma bazy (lokalna, zdalna) -> baza lokalna, także bez instalatora i dodatkowo przenośna.
- czy komputer ma stałe łącze internetowe -> zazwyczaj ma ( ) ale z racji przenośności chcę by aplikacja była uniezależniona od sieci. Nigdy nie wiadomo czy akurat nie będzie musiała pracować na kompie bez dostępu do netu lub nie będzie wykonywała tej pracy z aplikacją w chwili niedostępności sieci.
- czy będzie potrzebny zdalny dostęp do danych zgromadzonych w programie -> jak już z opisu widać, nie będzie potrzebny. Baza powinna sama w sobie być przenośna, a nie zdalna. W zasadzie zdalny dostęp to potencjalna luka bezpieczeństwa grożąca wyciekiem danych.
- jakie są możliwe przypadki użycia systemu i przez kogo -> poprzednie punkty wyjaśniły wszystko nader jasno chyba. System jednoosobowy, jednostanowiskowy, przenośny itp., itd.
- na jakim OS -> pewnie tylko windows, jak to w firmach państwowych
- przewidywane przeprowadzki OS (aktualizacje: win xp -> win7, zmiany na inny: win -> lin) -> możliwość niby jest, ale znając życie to skończyło by się na ewentualnym upgrade między wersjami windowsa
- możliwość instalacji środowisk uruchomieniowych (AA, .NET) -> tu nie ma problemu. Kontrola tego co jest na kompach pracowników jest niemal zerowa. Jedyne ograniczenie ma wejść niedługo - czajenie tego kto, ile i jak korzysta z sieci Internet. To nie wpłynie w żaden sposób na aplikację więc w jakiejkolwiek postaci.

Mam po prostu możliwości multum, nie muszę trzymać niemal żadnych wytycznych. To po prostu ma działać i nieważne w jakiej technologii czy jakim języku. Brak wymagań wydajnościowych i chyba jakichkolwiek innych. Po prostu projekt-marzenie. Poza tym, że robię go dla dziewczyny, z którą biorę ślub za 1.5 miesiąca, więc jest on z góry non-profit Gdyby mi jeszcze za to zapłacono, to żyć nie umierać.

@everth: ja CSS w QT stosowałem i wcale nie jest tak kolorowo. To nie jest tak, że da się wszystko ostylować tak jak się chce. Jest ogromna ilość ograniczeń. Bez użycia SVG jest ciężko. Zresztą aby to miało ręce i nogi często trzeba edytować kod programu.

@athabus: rozumiem twoje podejście do wyglądu ale zobacz jak to jest ładnie w linuksach zrobione. Tutaj aplikacje mają jedynie działać a ich wyglądem zajmuje się menadżer okien. Dzięki temu jeśli ktoś nie zastosuje własnej skórki to program wygląda ładnie, w windowsach jest pewnie podobnie. Osobiście wolę zdecydowanie jednolity wygląd i liczę, że podobne będzie działo się w internecie(zresztą już cześć ludzi marudzi, że złe jest stylowanie formularzy).


@thek: ja bym został przy wersji serwer+php na pendrive ewentualnie dla rozrywki możesz pomęczyć się z php bez serwera. Napisz prosty interface w czymkolwiek, a całe bebechy w php + sqllite. Stworzenie jakichś kontrolek to kwestia kilku kliknięć w QT Creatorze. Później jedynie przekazywanie danych do aplikacji php i gotowe.

Zresztą jeśli to nie jest zbyt skomplikowane to i php-qt wystarczy.

PS: pozdrów narzeczoną

pierwsze co mi przyszło do głowy: kupić lasce netbooka + modem GSM i postaw wszystko na serwerze, będziesz miał święty spokój
jeśli już koniecznie ma być na penie, to najbardziej minimalistyczne rozwiązanie to czyste WinAPI + SQLite.
Weź jeszcze pod uwagę, że pendrivy czasem się gubią - stracisz wtedy całą bazę a jeszcze kwestia danych osobowych w niepowołanych rękach ...

@SHiP: aplikacja PHP bez serwera? Zaciekawiłeś mnie. Rozumiem, że oczywiście interpreter musi być i do niego całość posyłam, ale przeglądając net nie widziałem wzmianki/artykułu/podstrony jak uruchomić aplikację w tym języku bez pośrednictwa serwera typu Apache. Mógłbyś czymś bliżej zarzucić bym mógł zobaczyć z czym to się je? Zobaczyłbym choćb czy to rozwiązanie efektywne, a zrzuciło by konieczność uruchamiania serwera. Jeśli bym zastosował do tego sqlite to pozostała by jedynie sama aplikacja jako front i połączenie tego z interpreterem oraz sqlite, czyli jedynie uruchomieniówka, bez konieczności włączania dodatkowych usług czy procesów. A to by było fajne rozwiązanie.

Uruchamiasz z wiersza poleceń, np

[DOS] pobierz, plaintext 
php jakis_skrypt.php parametry przekazane do skryptu
[DOS] pobierz, plaintext 

Tak działa właśnie PHP for Android. Wszystko leci przez PHP CLI. A komunikacja z Androidem odbywa się przez sockety

@JohnnyB: lapka będzie ona mieć za jakiś czas mojego zapewne. Co do zgubienia pendrive to się nie obawiam akurat, dziewczyna nie należy do osób gubiących drobiazgi. No i backupy bazy co jakiś czas będę robił z automatu. Baza nie jest bardzo obszerna więc powinno wszystko śmigać ładnie.

jest coś takiego jak PHP-GTK, ale osobiście nie próbowałem



ja też a ostatnio zgubiłem / zostawiłem u klienta, i to oczywiście tego z najważniejszymi danymi
to trochę optymistyczne założenie

jeszcze odnośnie wad pendrive - nie każdy lubi jak mu się odpala jakieś programy na kompie, a tym bardziej wymagające instalowanie różnych dodatkowych komponentów,
że już nie wspomnę, że taki pen wędrujący po ludziach to ulubione siedlisko wirusów

Php-gtk jak sama nazwa mówi wymaga środowiska, bibliotek gtk obecnych w systemie. Są one rozprowadzane, ale dla windy z tego co pamiętam nie są one szczególnie stabilnym rozwiązaniem (wywodzą się z linuxowego gnome'a z tego co kojarzę a używane są m.in. w windowsowej wersji GIMP-a)

Co do zgubienia/zostawienia, to dziewczyna nie ma tego uruchomionego non-stop. Operacje robi sporadycznie, a poza tymi chwilami leży sobie pen grzecznie w plecaczku. Co do wtykania do USB to akurat pracujące tam osoby nie martwią się tym. Sam kiedyś przyszedłem ze swoim "patykiem" i miałem dostęp do kompów oraz ich terminali bo chciały zobaczyć kilka zdjęć. O nieufność więc bym nie podejrzewał. To że wiry mogą latać jak szalone to fakt, ale to jest nieuniknione jeśli podejście do wtykania wszystkiego wszędzie jest uznawane za normę Zwyczajnie muszę jakieś zabezpieczenia choćby proste zrobić.

Co do php bez apache'a to wystarczyło mi powiedzieć: "php command line". Nie jestem typem osoby, której trzeba tłumaczyć jak krowie na rowie Pierwsze linki zaprowadziły od razu do manuala na stronie domowej projektu Przejrzę w wolnej chwili, tylko obawiam się jak będzie reagować skrypt na wiele długich parametrów tekstowych w linii komend, bo i komentarze z tego co pamiętam miały by być. A z tego co pamiętam to linia komend spacje traktuje jako separatory argumentów (przynajmniej tak pamiętam z C, który niedawno mi nieco kuzyn odświeżył - poszedł na robotykę do Wrocka).

Dobrze pamiętasz. Spacja jest separatorem. Nie pamiętam jednak by były jakieś ograniczenia na ilość danych przekazywanych w takich parametrach.

Moim zdaniem przekombinowujecie. Ale to tylko moje zdanie

Ale wystarczy parametr ze spacjami w treści ubrać w podwójne uszy i jest traktowane jako jeden.


Pod Uniksem każdy configure sprawdza to każdorazowo. Windows: http://support.microsoft.com/kb/830473

Zawsze pozostaje jeszcze stdin, tam już nie ma limitów.


PHP jest do dvpy, to tylko moje zdanie. Bez argumentów, to sobie można. Czyżby odpowiedź bo tak?

Daleko szukać nie trzeba:
Temat: %5BPHP%5DKonsolowe php wprowadzenie wartosci

Po Twoich dodatkowych wyjaśnieniach thek to ja stawiałbym albo na coś "desktopowego" do zainstalowania albo aplikację webową. Pomysł z pendrivem jest dla mnie kiepski - każdy od czasu do czasu coś gubi - po co sobie zawracać głowę jakimiś kopiami bezpieczeństwa. Konto na dobrym hostingu zapewnia kopie bezpieczeństwa bazy danych/plików. Jeśli masz dostęp do internetu to w zasadzie prosta aplikacja www oparta o jakiś framework i po sprawie.

Oczywiście możesz w celach edukacyjnych bawić się w jakieś desktopowe sprawy, ale jeśli po prostu chcesz to napisać i zapomnieć to rób w php z obsługą przez przeglądarkę.

Hehe, powiedzmy. Robienie GUI w jednym języku - przekazywanie parametrów przez CLI (sic!) do interpretera innego języka, w sytuacji gdy możemy po prostu napisać sobie bibliotekę robiącą to samo (lub w sytuacji klient-serwer pokusić się o SOAP). Zastanawianie się nad użyciem WinApi (to ktoś jeszcze tego używa?) w sytuacji gdy .NET jest domyślny w systemach powyżej XP (a pewnie występuje masowo w XP) zakrawa o masochizm. To możemy napiszmy GUI w winapi, skorzystajmy przy tym z bazy danych w Accesie, dodajmy do tego silnik w PHP i dla pełnego obrazu rysowanie interfejsu w Direct3D (bo daje dowolność w stylowaniu). Jeśli to dla kogoś to brzmi sensownie to ja się poddaję i zamykam w sobie

Masz do napisania prostą aplikację - PROSTĄ. Potrzebujesz do tego bazy danych. Aplikacja ma być przenośna co wyklucza stawianie serwerów bazodanowych. Zostaje sqlite, mysql embedded, lub coś co windowsy mają w zestawie (nie wiem jak to wygląda z Accesem). Wyklucza też doinstalowanie specyficznych elementów (tak, piję do PHP). Jak przeraża cię użeranie z c++ (obudowane choćby Qt, które ma wbudowany sqlite) to masz C# i całą platformę .NET (w tym ADO - eliminuje problem bazy danych). Więc podtrzymuję swoją opinię - przekombinowujecie.

@everth: ok, pod warunkiem, że thek ma czas i chęci aby uczyć się nowych języków... Napisanie tego w języku, który on świetnie zna(php) będzie po prostu szybsze nawet jeśli to będzie przekombinowane lub na około(a może być w końcu to tylko projekt dla dziewczyny więc ważne aby po prostu wszystko działało).


Ja bym został przy QT i nawet jeśli niektórym c++ kojarzy się z męką to imho pisanie w QT jest banalnie proste. Ale do tego trzeba się pokusić o przeczytanie kilku artykułów/poradników. Zresztą z C# lub Javą jest podobnie.