🚀 go-pugleaf

W dniu 25.03.2017 o 19:26, Krzysztof Szyszka pisze:
> Witam,
>
> miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
> Components 1.8!
>
>

Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale zapytam
nie kusiło Cie nigdy wypuścić pakietów pod Lazarusa? Myślę że twoje
kontrolki by były dużą wartością dodatnią.(mówie to na podstawie tego co
przeczytałem o nich i słyszałem) Nie miałem nigdy okazji testować ich i
się nimi pobawić. Podejrzewam że sporo pracy by też trzeba włożyć by to
się dało zrobić. Ale tak jak już wspomniałem przeszło Ci to przez głowe?

Pozdrawiam
J-23

Użytkownik "J-23"  napisał ...
>
> W dniu 25.03.2017 o 19:26, Krzysztof Szyszka pisze:
> > Witam,
> >
> > miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
> > Components 1.8!
>
> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale zapytam nie kusiło Cie nigdy
> wypuścić pakietów pod Lazarusa? Myślę że twoje kontrolki by były dużą wartością dodatnią.(mówie to
> na podstawie tego co przeczytałem o nich i słyszałem) Nie miałem nigdy okazji testować ich i się
> nimi pobawić. Podejrzewam że sporo pracy by też trzeba włożyć by to się dało zrobić. Ale tak jak
> już wspomniałem przeszło Ci to przez głowe?

Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast najnowszych wersji Delphi,
w których dzisiaj można pisać programy na różne platformy z Linuxem włącznie (10.2 Tokyo)?
Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi kosztuje coraz więcej.

Być może przeniesienie pod Lazarusa niektórych moich pakietów byłoby wartością dodaną dla
użytkowników Lazarusa, ale czy również dla mnie? Nie sądzę, by praca, którą musiałbym wykonać
kiedykolwiek zwróciła się finansowo, szczególnie że ja nie bardzo znam Lazarusa. Wiem jednak,
że niektórych pakietów (wizualnych) nie dałoby się w ogóle przenieść z tego samego powodu,
dla którego nie zostały do tej pory przeniesione z VCL na FMX i to dotyczy nie tylko moich pakietów.

--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

W dniu 2017-03-26 o 09:30, Krzysztof Szyszka pisze:
> Użytkownik "J-23"  napisał ...
>>
>> W dniu 25.03.2017 o 19:26, Krzysztof Szyszka pisze:
>> > Witam,
>> >
>> > miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
>> > Components 1.8!
>>
>> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale
>> zapytam nie kusiło Cie nigdy
>> wypuścić pakietów pod Lazarusa?

> Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast
> najnowszych wersji Delphi,
> w których dzisiaj można pisać programy na różne platformy z Linuxem
> włącznie (10.2 Tokyo)?
> Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi
> kosztuje coraz więcej.

I w związku z tym będzie więcej użytkowników Lazarusa czy mniej?

Absolutnie nie chcę tu polemizować z Twoim modelem biznesowym - znasz go
lepiej i lepiej wiesz co dla niego dobre. Ale widzę tu pewną nieścisłość
w takim rozumowaniu.
Skoro ludzie nadal używają Lazarusa (sam teraz używam CodeTyphon)
_zamiast_ Delphi jak sam zauważyłeś, to lepiej nic nie zarobić (albo
potencjalnie przestać zarabiać w niedługiej perspektywie) na Delphi, niż
spróbować chociaż część przerobić pod Lazarusa?

Naturalnie rozumiem obawę, że nawet w przypadku całkowitej "śmierci"
Delphi, potencjalny zarobek na użytkownikach Lazurusa jest wątpliwy
(pewnie nie bez powodu poskąpili na Delphi... ;)), a może jednak te
przewidywania na temat "śmierci" Delphi są mocno przesadzone?

Rozumiem Twoje podejście również z innej perspektywy. To co mam na
pokładzie w CodeTyphon w zupełności wystarcza na moje potrzeby, więc
pomijając kwestie finansowe, zwyczajnie nie potrzebuję kupować
dodatkowych komponentów. Z innymi Lazarusowcami może być podobnie... to
raczej nie są duże projekty, wymagające wodotrysków.
Jakiś czas temu pisałem na grupie, że próbuję się przesiąść z Delphi na
VisualStudio i C# i po kilku podejściach zostałem jednak przy
CodePython. Na razie. I wątpię, że wrócę do Delphi w przewidywalnym czasie.

Pozdrawiam
Piotr

Użytkownik "Kviat"  napisał ...
>
> W dniu 2017-03-26 o 09:30, Krzysztof Szyszka pisze:
> > Użytkownik "J-23"  napisał ...
> >>
> >> W dniu 25.03.2017 o 19:26, Krzysztof Szyszka pisze:
> >> > Witam,
> >> >
> >> > miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
> >> > Components 1.8!
> >>
> >> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale
> >> zapytam nie kusiło Cie nigdy
> >> wypuścić pakietów pod Lazarusa?
>
> > Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast
> > najnowszych wersji Delphi,
> > w których dzisiaj można pisać programy na różne platformy z Linuxem
> > włącznie (10.2 Tokyo)?
> > Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi
> > kosztuje coraz więcej.
>
> Naturalnie rozumiem obawę, że nawet w przypadku całkowitej "śmierci" Delphi, potencjalny zarobek
> na użytkownikach Lazurusa jest wątpliwy (pewnie nie bez powodu poskąpili na Delphi... ;)), a może
> jednak te przewidywania na temat "śmierci" Delphi są mocno przesadzone?
>
> Rozumiem Twoje podejście również z innej perspektywy. To co mam na pokładzie w CodeTyphon w
> zupełności wystarcza na moje potrzeby, więc pomijając kwestie finansowe, zwyczajnie nie potrzebuję
> kupować dodatkowych komponentów. Z innymi Lazarusowcami może być podobnie...

Mnie nie wypada publicznie poruszać pewnych tematów,
ale Twój tok rozumowania jest zbieżny z moją oceną Lazarusa ;-)

--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

W dniu 26.03.2017 o 10:30, Krzysztof Szyszka pisze:
> Użytkownik "J-23"  napisał ...
>>
>> W dniu 25.03.2017 o 19:26, Krzysztof Szyszka pisze:
>> > Witam,
>> >
>> > miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
>> > Components 1.8!
>>
>> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale
>> zapytam nie kusiło Cie nigdy
>> wypuścić pakietów pod Lazarusa? Myślę że twoje kontrolki by były dużą
>> wartością dodatnią.(mówie to
>> na podstawie tego co przeczytałem o nich i słyszałem) Nie miałem nigdy
>> okazji testować ich i się
>> nimi pobawić. Podejrzewam że sporo pracy by też trzeba włożyć by to
>> się dało zrobić. Ale tak jak
>> już wspomniałem przeszło Ci to przez głowe?
>
> Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast
> najnowszych wersji Delphi,
> w których dzisiaj można pisać programy na różne platformy z Linuxem
> włącznie (10.2 Tokyo)?
> Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi
> kosztuje coraz więcej.

Za wszystkich nie będę odpowiadał odpowiem za siebie :) Mnie nie
odstrasza cena, uważam że dobry produkt powinien mieć swoją cenę. No i
tu teraz pada pytanie czy Delphi jest dobrym produktem? - niech
wypowiedzą się ci którzy obecnie go używają

Tak by uprościć chodzi mi o stosunek ceny do jakości/możliwości

Ja przestałem używać Delphi bodajże w 2011 kiedy to była taka duża
częstotliwość rotacji wersji gdzie to nowe środowiska wchodziły bardzo
szybko z dużą ilością niestety bugów.

Pozdrawiam

W dniu poniedziałek, 27 marca 2017 09:30:55 UTC+2 użytkownik Roman Tyczka napisał:

> Siedzą w Delphi też dlatego, że trudno przerzucić duży projekt, więc mając
> w tyle głowy chęć migracji wciąż dokupują updaty. Poza tym zawsze jest

? A może dlatego że Delphi jest po prostu dobre? I FPC/Lazarusowi daleko jeszcze do takiej użyteczności? I nie chodzi o komponenty ale o samo środowisko. Nie po to przeniosłem się z Delphi 7 na nowsze i lepsze w użytkowaniu żeby wracać po latach do czegoś co z perspektywy czasy wydaje się archaizmem. Tak naprawdę koślawe IDE jest jednym z powodów dla których nie lubię Lazarusa.
Poza tym jest inna sprawa - czym jest cena Delphi w momencie gdy sami sprzedajemy oprogramowanie za grube pieniądze. I w stosunku do całej otoczki którą przez lata się zbudowało dla danego środowiska? Uważam że nawet darmowość Lazarusa tego nie rekompensuje.

> obawa, że zdobycie nowych przyzwyczajeń zajmie zbyt dużo czasu. Z drugiej

No właśnie. A jeśli zajmuje to dużo czasu, to dlaczego pchać się w coś co prawie nie istnieje (Delphi/Pascal) i to w słabszym wydaniu niż Delphi, skoro można iść w całkiem inną stronę - choćby VisualStudio. I tańsze i coraz wygodniejsze i z dostępnymi komponentami takimi samymi jak na Delphi (DevEx, FastReport i inne).

> pozdrawiam
> Roman Tyczka

pozdrawiam,
Przemek O.

On Sun, 26 Mar 2017 10:30:51 +0200, Krzysztof Szyszka wrote:

>>> miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
>>> Components 1.8!
>>
>> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale zapytam nie kusiło Cie nigdy
>> wypuścić pakietów pod Lazarusa? Myślę że twoje kontrolki by były dużą wartością dodatnią.(mówie to
>> na podstawie tego co przeczytałem o nich i słyszałem) Nie miałem nigdy okazji testować ich i się
>> nimi pobawić. Podejrzewam że sporo pracy by też trzeba włożyć by to się dało zrobić. Ale tak jak
>> już wspomniałem przeszło Ci to przez głowe?
>
> Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast najnowszych wersji Delphi,
> w których dzisiaj można pisać programy na różne platformy z Linuxem włącznie (10.2 Tokyo)?

Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to dość
poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery, lecz
apki desktopowe.

> Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi kosztuje coraz więcej.

Siedzą w Delphi też dlatego, że trudno przerzucić duży projekt, więc mając
w tyle głowy chęć migracji wciąż dokupują updaty. Poza tym zawsze jest
obawa, że zdobycie nowych przyzwyczajeń zajmie zbyt dużo czasu. Z drugiej
strony IDE Lazarusa mimo, że wyglądem przypomina Delphi 7 ma sporo
ciekawych ficzerów, których próżno szukać w Delphi. Tak samo sam Object
Pascal jest nieco inny, w jednym miejscu uboższy, w innym bogatszy. To
hamuje. Ale jednocześnie wiele bibliotek migruje do FPC/Lazarusa i powoli
portfolio lazarusowe puchnie. Z Delphi, poza straszliwymi cenami, wciąż
dzieją się dziwne rzeczy. W zeszłym roku zostali zwolnieni twórcy
kluczowych technologii delphiowych. Wyleciał autor FMXa i jeden z
programistów tego pakietu. Oraz co szczególnie dziwne na trawkę poszedł
autor FireDACa. Zwolnił się też jeden z kluczowych twórców kompilatora
x86/x64. Zlikwidowali oddział w Hiszpanii. To nie napawa optymizmem.

> Być może przeniesienie pod Lazarusa niektórych moich pakietów byłoby wartością dodaną dla
> użytkowników Lazarusa, ale czy również dla mnie? Nie sądzę, by praca, którą musiałbym wykonać
> kiedykolwiek zwróciła się finansowo, szczególnie że ja nie bardzo znam Lazarusa. Wiem jednak,
> że niektórych pakietów (wizualnych) nie dałoby się w ogóle przenieść z tego samego powodu,
> dla którego nie zostały do tej pory przeniesione z VCL na FMX i to dotyczy nie tylko moich pakietów.

Jakich np. pakietów nie dałoby się przenieść? Możesz podać przykład?

--
pozdrawiam
Roman Tyczka

W dniu 2017-03-27 o 10:43, immo pisze:
> W dniu poniedziałek, 27 marca 2017 09:30:55 UTC+2 użytkownik Roman Tyczka napisał:
>
>> Siedzą w Delphi też dlatego, że trudno przerzucić duży projekt, więc mając
>> w tyle głowy chęć migracji wciąż dokupują updaty. Poza tym zawsze jest
>
> ? A może dlatego że Delphi jest po prostu dobre? I FPC/Lazarusowi daleko jeszcze do takiej użyteczności? I nie chodzi o komponenty ale o samo środowisko. Nie po to przeniosłem się z Delphi 7 na nowsze i lepsze w użytkowaniu żeby wracać po latach do czegoś co z perspektywy czasy wydaje się archaizmem. Tak naprawdę koślawe IDE jest jednym z powodów dla których nie lubię Lazarusa.
> Poza tym jest inna sprawa - czym jest cena Delphi w momencie gdy sami sprzedajemy oprogramowanie za grube pieniądze. I w stosunku do całej otoczki którą przez lata się zbudowało dla danego środowiska? Uważam że nawet darmowość Lazarusa tego nie rekompensuje.

Dlatego ja używam(i kupuje ze żródlami) tylko biblioteki które działają
i w Delphi i w Lazarusie. Np.:
FastReport, UniDAC, ZEOS, mORMot, kmmmw, kbmmtable itd.

>> obawa, że zdobycie nowych przyzwyczajeń zajmie zbyt dużo czasu. Z drugiej
>
> No właśnie. A jeśli zajmuje to dużo czasu, to dlaczego pchać się w coś co prawie nie istnieje (Delphi/Pascal) i to w słabszym wydaniu niż Delphi, skoro można iść w całkiem inną stronę - choćby VisualStudio. I tańsze i coraz wygodniejsze i z dostępnymi komponentami takimi samymi jak na Delphi (DevEx, FastReport i inne).
>
>> pozdrawiam
>> Roman Tyczka
>
> pozdrawiam,
> Przemek O.
>

W dniu 2017-03-27 o 11:00, miab pisze:
> W dniu 2017-03-27 o 10:43, immo pisze:
>> W dniu poniedziałek, 27 marca 2017 09:30:55 UTC+2 użytkownik Roman
>> Tyczka napisał:
>>
>>> Siedzą w Delphi też dlatego, że trudno przerzucić duży projekt, więc
>>> mając
>>> w tyle głowy chęć migracji wciąż dokupują updaty. Poza tym zawsze jest
>>
>> ? A może dlatego że Delphi jest po prostu dobre? I FPC/Lazarusowi
>> daleko jeszcze do takiej użyteczności? I nie chodzi o komponenty ale o
>> samo środowisko. Nie po to przeniosłem się z Delphi 7 na nowsze i
>> lepsze w użytkowaniu żeby wracać po latach do czegoś co z perspektywy
>> czasy wydaje się archaizmem. Tak naprawdę koślawe IDE jest jednym z
>> powodów dla których nie lubię Lazarusa.
>> Poza tym jest inna sprawa - czym jest cena Delphi w momencie gdy sami
>> sprzedajemy oprogramowanie za grube pieniądze. I w stosunku do całej
>> otoczki którą przez lata się zbudowało dla danego środowiska? Uważam
>> że nawet darmowość Lazarusa tego nie rekompensuje.
>
> Dlatego ja używam(i kupuje ze żródlami) tylko biblioteki które działają
> i w Delphi i w Lazarusie. Np.:
> FastReport, UniDAC, ZEOS, mORMot, kmmmw, kbmmtable itd.

czy TMS Aurelius i reszta Business paku.

maib

W dniu 2017-03-27 o 09:30, Roman Tyczka pisze:
> On Sun, 26 Mar 2017 10:30:51 +0200, Krzysztof Szyszka wrote:
>
>>>> miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
>>>> Components 1.8!
>>>
>>> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale zapytam nie kusiło Cie nigdy
>>> wypuścić pakietów pod Lazarusa? Myślę że twoje kontrolki by były dużą wartością dodatnią.(mówie to
>>> na podstawie tego co przeczytałem o nich i słyszałem) Nie miałem nigdy okazji testować ich i się
>>> nimi pobawić. Podejrzewam że sporo pracy by też trzeba włożyć by to się dało zrobić. Ale tak jak
>>> już wspomniałem przeszło Ci to przez głowe?
>>
>> Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast najnowszych wersji Delphi,
>> w których dzisiaj można pisać programy na różne platformy z Linuxem włącznie (10.2 Tokyo)?
>
> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to dość
> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery, lecz
> apki desktopowe.
>
>> Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi kosztuje coraz więcej.
>
> Siedzą w Delphi też dlatego, że trudno przerzucić duży projekt, więc mając
> w tyle głowy chęć migracji wciąż dokupują updaty. Poza tym zawsze jest
> obawa, że zdobycie nowych przyzwyczajeń zajmie zbyt dużo czasu. Z drugiej
> strony IDE Lazarusa mimo, że wyglądem przypomina Delphi 7 ma sporo
> ciekawych ficzerów, których próżno szukać w Delphi. Tak samo sam Object
> Pascal jest nieco inny, w jednym miejscu uboższy, w innym bogatszy. To
> hamuje. Ale jednocześnie wiele bibliotek migruje do FPC/Lazarusa i powoli
> portfolio lazarusowe puchnie. Z Delphi, poza straszliwymi cenami, wciąż
> dzieją się dziwne rzeczy. W zeszłym roku zostali zwolnieni twórcy
> kluczowych technologii delphiowych. Wyleciał autor FMXa i jeden z
> programistów tego pakietu.

Teraz chyba hakują/crossują VCL-a do OSX-a:
http://www.crossvcl.com/index.html

miab

On Mon, 27 Mar 2017 11:13:56 +0200, miab wrote:

>> kluczowych technologii delphiowych. Wyleciał autor FMXa i jeden z
>> programistów tego pakietu.
>
> Teraz chyba hakują/crossują VCL-a do OSX-a:
> http://www.crossvcl.com/index.html
>
> miab

Tak, wiem. Mało tego, hackują FMXa do Linuxa! :-)
Co nie zmienia faktu, że Emba wykonuje dziwne ruchy, które każą rozglądać
się wokół by mieć tratwę ratunkową w zanadrzu.

--
pozdrawiam
Roman Tyczka

> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to dość
> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery, lecz
> apki desktopowe.
>
Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja już
fmx dla linux-a , patrząc jednak od innej strony to nie widzę aby
klienci potrzebowali uruchamiać na linux, bo system jest tak niszowy ze
nie znam nikogo kto używa linux-a w trybie graficznym.

Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
da się zrobić tylko koszty mogą być niewspółmierne do zysków.

M

On Tue, 28 Mar 2017 11:08:06 +0200, mmm wrote:

>> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to dość
>> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery, lecz
>> apki desktopowe.
>>
> Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja już
> fmx dla linux-a ,

Wszystkie pytania do Emby jakie do tej pory widziałem o to czy będzie
wsparcie desktopa linuksowego dostawały odpowiedź negatywną, nawet nie
padało "być może", tylko konkretnie: nie ma w planach.

> patrząc jednak od innej strony to nie widzę aby
> klienci potrzebowali uruchamiać na linux, bo system jest tak niszowy ze
> nie znam nikogo kto używa linux-a w trybie graficznym.

A ja nikogo kto używa desktopa z MacOS, czy to znaczy, że nie istnieje? ;-)

> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
> da się zrobić tylko koszty mogą być niewspółmierne do zysków.

Ideą FMXa jest właśnie niezależność od powłok, bo rysuje się sam.

--
pozdrawiam
Roman Tyczka

On Sat, 25 Mar 2017 19:26:38 +0100, Krzysztof Szyszka wrote:

>    Komponenty zawarte z tym pakiecie pozwalają korzystać z: array of TObject,
>    TList of TObject, TObjectList, TStringList, TWideStringList, TCollection,
>    TArray<T: class>, TList<T: class>, TObjectList<T: class> i klas potomnych.
>    Korzystając z data providerów można również obsłużyć dowolne indeksowane
>    właściwości takie jak Fields, Controls, Components, Pages, Buttons, Forms, itp.

Czy są wspierane kolekcje interfejsów?

--
pozdrawiam
Roman Tyczka

W dniu 28.03.2017 o 11:08, mmm pisze:
>> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to
>> dość
>> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery, lecz
>> apki desktopowe.
>>
> Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja już
> fmx dla linux-a , patrząc jednak od innej strony to nie widzę aby
> klienci potrzebowali uruchamiać na linux, bo system jest tak niszowy ze
> nie znam nikogo kto używa linux-a w trybie graficznym.
>

System niszowy? hmm zależy pod jakim względem na to patrzeć?

- Serwery, rozwiązania za pomocą której mamy sieć zwaną popularnie
internetem - tu uniksy w tym duża cześć linuxów. Rozwiązania
Microsoftowe zostają w tyle pod względem ilości użytkowanych

- Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
oczywiście Windows - W dużej części dla tego że ludzie nie znają
alternatyw, ponadto nie ma oprogramowania na to. Znalezienie programu za
pomocą którego byśmy wystawiali faktury, który nam pozwoli
na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows

To się powoli zaczyna jednak zmieniać i dobrze. Szkoda jednak że tak powoli

> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>

Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
jednak dużo pracy by przystosować GUI by działało w obu środowiskach
mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows

Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
ale ten jest pisany w Lazarus

Szkoda tylko że autor nie poszedł za ciosem i nie rozwija go dalej

Pozdrawiam
J-23

> Użytkownik "Roman Tyczka"  napisał ...
>
> On Sat, 25 Mar 2017 19:26:38 +0100, Krzysztof Szyszka wrote:
>
> >    Komponenty zawarte z tym pakiecie pozwalają korzystać z: array of TObject,
> >    TList of TObject, TObjectList, TStringList, TWideStringList, TCollection,
> >    TArray<T: class>, TList<T: class>, TObjectList<T: class> i klas potomnych.
> >    Korzystając z data providerów można również obsłużyć dowolne indeksowane
> >    właściwości takie jak Fields, Controls, Components, Pages, Buttons, Forms, itp.
>
> Czy są wspierane kolekcje interfejsów?

Już tu kiedyś odpowiadałem na podobne pytanie:
Pakiet X-DBData wspiera każdą strukturę danych, do której potrafisz napisać prostego data providera.

W Delphi nie ma takiej gotowej struktury, jak "kolekcja interfejsów", więc w pakiecie nie ma również
gotowego data providera, ale jeśli korzystasz ze Springa, to możesz go dopisać do każdej potrzebnej
Ci
struktury danych zawartej w modułach Springa.

Poniżej załączam przykładowy moduł XDBList.Spring.pas do obsługi springowego TList<T>.
W analogiczny sposób można dopisać data providera do każdej innej springowej struktury danych.

unit XDBList.Spring;

interface

uses Classes, Spring.Collections.Lists, XDBList;

type
  TXDBListProvider<T: class> = class(TXDBCustomListProvider)
  public
    type
      TInstance = TList<T>;
  private
    function GetInstance: TInstance; inline;
  protected
    property Instance: TInstance read GetInstance;
    function GetDataClass: TClass; override;
    function GetItemClass: TClass; override;
    function GetItemCount: Integer; override;
    function GetItemValue(Index: Integer): TObject; override;
    function GetOwnsObjects: Boolean; override;
    function IsOwnsObjectsStored: Boolean; virtual;
    procedure InsertItem(Index: Integer); override;
    procedure DeleteItem(Index: Integer); override;
  published
    property ExactMatch;
    property OwnsObjects stored IsOwnsObjectsStored;
    property AddClassField;
    property AddIndexField;
    property AddRecNoField;
    property ClassFieldName;
    property ClassFieldSize;
    property IndexFieldName;
    property RecNoFieldName;
    property StringFieldSize;
  end;

implementation

uses SysUtils;

{ TXDBListProvider<T> }

function TXDBListProvider<T>.GetInstance: TInstance;
begin
  Result := TInstance(inherited Instance);
end;

{ protected }

function TXDBListProvider<T>.GetDataClass: TClass;
begin
  Result := TInstance;
end;

function TXDBListProvider<T>.GetItemClass: TClass;
begin
  Result := T;
end;

function TXDBListProvider<T>.GetItemCount: Integer;
begin
  Result := Instance.Count;
end;

function TXDBListProvider<T>.GetItemValue(Index: Integer): TObject;
begin
  Result := Instance[Index];
end;

function TXDBListProvider<T>.GetOwnsObjects: Boolean;
begin
  if Instance is TObjectList<T> then
    Result := TObjectList<T>(Instance).OwnsObjects
  else Result := inherited GetOwnsObjects;
end;

function TXDBListProvider<T>.IsOwnsObjectsStored: Boolean;
begin
  if Instance is TObjectList<T> then Result := False
  else Result := inherited GetOwnsObjects;
end;

procedure TXDBListProvider<T>.InsertItem(Index: Integer);
begin
  if OwnsObjects then
    if ItemClass.InheritsFrom(TComponent) then
      Instance.Insert(Index, TComponentClass(ItemClass).Create(nil))
    else Instance.Insert(Index, ItemClass.Create)
  else Abort;
end;

procedure TXDBListProvider<T>.DeleteItem(Index: Integer);
var
  Item: T;
begin
  if OwnsObjects and not (Instance is TObjectList<T>) then
  begin
    Item := Instance[Index];
    Instance.Delete(Index);
    Item.Free;
  end
  else Instance.Delete(Index);
end;

end.


--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

On Tue, 28 Mar 2017 19:00:18 +0200, J-23 wrote:

>> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
>> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>>
>
> Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
> jednak dużo pracy by przystosować GUI by działało w obu środowiskach
> mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
>
> Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
> zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
> ale ten jest pisany w Lazarus

O jakim GUI piszesz? To kontrolki dostępowe do firebirda.

--
pozdrawiam
Roman Tyczka

On Tue, 28 Mar 2017 19:47:32 +0200, Krzysztof Szyszka wrote:

>> Czy są wspierane kolekcje interfejsów?
>
> Już tu kiedyś odpowiadałem na podobne pytanie:
> Pakiet X-DBData wspiera każdą strukturę danych, do której potrafisz napisać prostego data providera.
>
> W Delphi nie ma takiej gotowej struktury, jak "kolekcja interfejsów", więc w pakiecie nie ma również
> gotowego data providera,

Jak to nie ma?

http://docwiki.embarcadero.com/Libraries/XE2/en/System.Classes.TInterfaceList

> ale jeśli korzystasz ze Springa, to możesz go dopisać do każdej potrzebnej
> Ci struktury danych zawartej w modułach Springa.
>
> Poniżej załączam przykładowy moduł XDBList.Spring.pas do obsługi springowego TList<T>.
> W analogiczny sposób można dopisać data providera do każdej innej springowej struktury danych.
>
> unit XDBList.Spring;

Dzięki za informacje.

--
pozdrawiam
Roman Tyczka

W dniu 2017-03-28 o 19:00, J-23 pisze:
> W dniu 28.03.2017 o 11:08, mmm pisze:
>>> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to
>>> dość
>>> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery,
>>> lecz
>>> apki desktopowe.
>>>
>> Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja już
>> fmx dla linux-a , patrząc jednak od innej strony to nie widzę aby
>> klienci potrzebowali uruchamiać na linux, bo system jest tak niszowy ze
>> nie znam nikogo kto używa linux-a w trybie graficznym.
>>
>
> System niszowy? hmm zależy pod jakim względem na to patrzeć?
>
> - Serwery, rozwiązania za pomocą której mamy sieć zwaną popularnie
> internetem - tu uniksy w tym duża cześć linuxów. Rozwiązania
> Microsoftowe zostają w tyle pod względem ilości użytkowanych
>
> - Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
> oczywiście Windows - W dużej części dla tego że ludzie nie znają
> alternatyw, ponadto nie ma oprogramowania na to. Znalezienie programu za
> pomocą którego byśmy wystawiali faktury, który nam pozwoli
> na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows
>
> To się powoli zaczyna jednak zmieniać i dobrze. Szkoda jednak że tak powoli
>
>> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
>> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>>
>
> Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
> jednak dużo pracy by przystosować GUI by działało w obu środowiskach
> mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
>
> Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
> zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
> ale ten jest pisany w Lazarus

O czym ty piszesz?
Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE jak
i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi jak
i Lazarus:
UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
kbmmw, kbmmtable, mORMot.

miab

>- Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
>oczywiście Windows - W dużej części dla tego że ludzie nie znają
>alternatyw, ponadto nie ma oprogramowania na to. Znalezienie programu za
>pomocą którego byśmy wystawiali faktury, który nam pozwoli
>na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows

Wcale nie jest takie trudne. Jeśli zastosować WIne pod Linuxa wtedy mamy
do dyspozycji całkiem sporą ilość oprogramowania. Moje programy całkiem
fajnie
chodzą i pod Linuxem i pod iMac właśnie dzięki Wine.  I nie muszę pisać
specjalnego
oprogramowania dla Linuxa

Pozdrowienia
MR_FLASH
Mirosław Rogula

W dniu 2017-03-28 o 21:20, miab pisze:
> W dniu 2017-03-28 o 19:00, J-23 pisze:

>> Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
>> zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
>> ale ten jest pisany w Lazarus
>
> O czym ty piszesz?
> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
> desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE jak
> i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi jak
> i Lazarus:
> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
> kbmmw, kbmmtable, mORMot.
>

Tu obrazaki(stare):
http://wiki.lazarus.freepascal.org/Screenshots

miab

> Użytkownik "Roman Tyczka"  napisał ...
>
> On Tue, 28 Mar 2017 19:47:32 +0200, Krzysztof Szyszka wrote:
>
> >> Czy są wspierane kolekcje interfejsów?
> >
> > Już tu kiedyś odpowiadałem na podobne pytanie:
> > Pakiet X-DBData wspiera każdą strukturę danych, do której potrafisz napisać prostego data
> > providera.
> >
> > W Delphi nie ma takiej gotowej struktury, jak "kolekcja interfejsów", więc w pakiecie nie ma
> > również
> > gotowego data providera,
>
> Jak to nie ma?
>
> http://docwiki.embarcadero.com/Libraries/XE2/en/System.Classes.TInterfaceList

No popatrz, nawet nie wiedziałem, że w Delphi jest taka klasa. Postaram się dopisać kolejnego
providera,
ale na podstawie załączonego przykładu możesz go od ręki sam sobie napisać, jeśli Ci na tym zależy.

P.S Na przyszłość postaraj się wyrażać jaśniej, bo klasy TInterfaceList nie nazwałbym "kolekcją
interfejsów".

--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

> Użytkownik "miab"  napisał ...
> >> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
> >> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
> >
> > Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
> > jednak dużo pracy by przystosować GUI by działało w obu środowiskach
> > mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
> >
> > Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
> > zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
> > ale ten jest pisany w Lazarus
>
> O czym ty piszesz?
> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji desktopowych na Windows Win32/64 i
> Linux-32/64  i to zarówno na KDE jak i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi jak i Lazarus:
> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business, kbmmw, kbmmtable, mORMot.

Zwróć uwagę, że są to głównie biblioteki niewizualne, które nie korzystają
z WinAPI i żeby je przenieść na inną platformę wystarczy zgodność języka
lub występowanie podstawowych kontrolek wizualnych na każdej platformie.

W przypadku takich komponentów jak TXDBGrid, czy też innych, które mocno
wykorzystują WinAPI, przeniesienie na inną platformę staję się problemem,
bo kluczowe funkcjonalności są niedostępne lub wymagają przeprojektowania
całego rozbudowanego komponentu dla osiągnięcia podobnego efektu.

Zobacz, ile poważnych firm nie zdecydowało się przez kilka lat na przeniesienie
swoich komponentów wizualnych z VCL na FMX, a co dopiero mówić o Lazarusie.

--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

On Tue, 28 Mar 2017 21:37:06 +0200, Krzysztof Szyszka wrote:

>>> W Delphi nie ma takiej gotowej struktury, jak "kolekcja interfejsów", więc w pakiecie nie ma
>>> również gotowego data providera,
>>
>> Jak to nie ma?
>>
>> http://docwiki.embarcadero.com/Libraries/XE2/en/System.Classes.TInterfaceList
>
> No popatrz, nawet nie wiedziałem, że w Delphi jest taka klasa. Postaram się dopisać kolejnego
> providera, ale na podstawie załączonego przykładu możesz go od ręki sam sobie napisać, jeśli Ci na tym zależy.

Cieszę się, że mogłem pomóc ;-)

> P.S Na przyszłość postaraj się wyrażać jaśniej, bo klasy TInterfaceList nie nazwałbym "kolekcją
> interfejsów".

Słowo kolekcja nie musi koniecznie oznaczać TCollection ;-)

https://en.wikipedia.org/wiki/Collection_(abstract_data_type)

--
pozdrawiam
Roman Tyczka

W dniu 2017-03-28 o 22:03, Krzysztof Szyszka pisze:
>> Użytkownik "miab"  napisał ...
>> >> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a,
>> wszystko
>> >> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>> >
>> > Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
>> > jednak dużo pracy by przystosować GUI by działało w obu środowiskach
>> > mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
>> >
>> > Jako przykład podam link do http://fblib.altervista.org/ jest jedeno
>> GUI
>> > zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
>> > ale ten jest pisany w Lazarus
>>
>> O czym ty piszesz?
>> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
>> desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE
>> jak i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
>> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi
>> jak i Lazarus:
>> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
>> kbmmw, kbmmtable, mORMot.
>
> Zwróć uwagę, że są to głównie biblioteki niewizualne, które nie korzystają
> z WinAPI i żeby je przenieść na inną platformę wystarczy zgodność języka
> lub występowanie podstawowych kontrolek wizualnych na każdej platformie.
>
> W przypadku takich komponentów jak TXDBGrid, czy też innych, które mocno
> wykorzystują WinAPI, przeniesienie na inną platformę staję się problemem,
> bo kluczowe funkcjonalności są niedostępne lub wymagają przeprojektowania
> całego rozbudowanego komponentu dla osiągnięcia podobnego efektu.
>
> Zobacz, ile poważnych firm nie zdecydowało się przez kilka lat na
> przeniesienie
> swoich komponentów wizualnych z VCL na FMX, a co dopiero mówić o Lazarusie.
>

Dlatego przydał by się jakiś wypasiony dbGrid. Bo te co są to raczej
porażka.
Podejrzewam ze nie było by tak trudno w końcu Lazarus-owy dbGrid
wzorowany jest na Delphi-anym.

miab

Tu masz na przykład adaptacie rx-ów w tym rxdbgid do Lazarusa:
https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/components/rx/trunk/rxdb/

miab

> Użytkownik "Roman Tyczka"  napisał w wiadomości grup dyskusyjnych:1x64ush45wmh8$.dlg@tyczka.com...
>
> On Tue, 28 Mar 2017 21:37:06 +0200, Krzysztof Szyszka wrote:
>
> >>> W Delphi nie ma takiej gotowej struktury, jak "kolekcja interfejsów", więc w pakiecie nie ma
> >>> również gotowego data providera,
> >>
> >> Jak to nie ma?
> >>
> >> http://docwiki.embarcadero.com/Libraries/XE2/en/System.Classes.TInterfaceList
> >
> > No popatrz, nawet nie wiedziałem, że w Delphi jest taka klasa. Postaram się dopisać kolejnego
> > providera, ale na podstawie załączonego przykładu możesz go od ręki sam sobie napisać, jeśli Ci
> > na tym zależy.
>
> Cieszę się, że mogłem pomóc ;-)
>
> > P.S Na przyszłość postaraj się wyrażać jaśniej, bo klasy TInterfaceList nie nazwałbym "kolekcją
> > interfejsów".
>
> Słowo kolekcja nie musi koniecznie oznaczać TCollection ;-)
>
> https://en.wikipedia.org/wiki/Collection_(abstract_data_type)

Masz rację, ale w Delphi kolekcja występuje jedynie jako potomek TCollection,
dlatego uznałem, że korzystasz ze Springa :-)

Natomiast z TInterfaceList jest taki problem, że elementami listy są obiekty IInterface,
a one nie posiadają żadnych danych (properties), które można by pokazać jako pola w DataSet.
Nie znalazłem również żadnego odpowiednika wśród generyków (TInterfaceList<T>), więc nie
bardzo widzę sens tworzenia TXDBInterfaceListProvider :-(

--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

> Użytkownik "miab"  napisał ...
> >> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
> >> desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE
> >> jak i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
> >> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi
> >> jak i Lazarus:
> >> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
> >> kbmmw, kbmmtable, mORMot.
> >
> > Zwróć uwagę, że są to głównie biblioteki niewizualne, które nie korzystają
> > z WinAPI i żeby je przenieść na inną platformę wystarczy zgodność języka
> > lub występowanie podstawowych kontrolek wizualnych na każdej platformie.
> >
> > W przypadku takich komponentów jak TXDBGrid, czy też innych, które mocno
> > wykorzystują WinAPI, przeniesienie na inną platformę staję się problemem,
> > bo kluczowe funkcjonalności są niedostępne lub wymagają przeprojektowania
> > całego rozbudowanego komponentu dla osiągnięcia podobnego efektu.
> >
> > Zobacz, ile poważnych firm nie zdecydowało się przez kilka lat na przeniesienie
> > swoich komponentów wizualnych z VCL na FMX, a co dopiero mówić o Lazarusie.
>
> Dlatego przydał by się jakiś wypasiony dbGrid. Bo te co są to raczej porażka.
> Podejrzewam ze nie było by tak trudno w końcu Lazarus-owy dbGrid wzorowany jest na Delphi-anym.

Tylko, że oryginalny TDBGrid to jest dzisiaj może 10% kodu TXDBGrida :-)
Jak do tego dołożyć moduły  XDBEditor, XDBFilter, XDBSearch, XDBDataList,
które stanowią integralną część TXDBGrida i wymagają zgodności z WinAPI,
żeby je w ogóle można było wykorzystać, to przeniesienie ich pod Lazarusa
staje się nie lada wyzwaniem.

--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547

On Tue, 28 Mar 2017 22:46:31 +0200, Krzysztof Szyszka wrote:

>>> Zobacz, ile poważnych firm nie zdecydowało się przez kilka lat na przeniesienie
>>> swoich komponentów wizualnych z VCL na FMX, a co dopiero mówić o Lazarusie.
>>
>> Dlatego przydał by się jakiś wypasiony dbGrid. Bo te co są to raczej porażka.
>> Podejrzewam ze nie było by tak trudno w końcu Lazarus-owy dbGrid wzorowany jest na Delphi-anym.

A ten nie da rady?

https://github.com/Steema/TeeGrid

> Tylko, że oryginalny TDBGrid to jest dzisiaj może 10% kodu TXDBGrida :-)
> Jak do tego dołożyć moduły  XDBEditor, XDBFilter, XDBSearch, XDBDataList,
> które stanowią integralną część TXDBGrida i wymagają zgodności z WinAPI,
> żeby je w ogóle można było wykorzystać, to przeniesienie ich pod Lazarusa
> staje się nie lada wyzwaniem.

A potem przyjdzie pan Kryukov i nie lada wyzwanie stanie się pestką ;-)

--
pozdrawiam
Roman Tyczka

W dniu 28.03.2017 o 21:05, Roman Tyczka pisze:
> On Tue, 28 Mar 2017 19:00:18 +0200, J-23 wrote:
>
>>> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
>>> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>>>
>>
>> Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
>> jednak dużo pracy by przystosować GUI by działało w obu środowiskach
>> mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
>>
>> Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
>> zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
>> ale ten jest pisany w Lazarus
>
> O jakim GUI piszesz? To kontrolki dostępowe do firebirda.

Nie kontrolki tylko program do zarządzania bazą Firebird coś jak
FlameRobin, a ten program posiada jedno i to samo GUI dla Linux i Windows

Pozdrawiam
J-23

W dniu 28.03.2017 o 21:20, miab pisze:
> W dniu 2017-03-28 o 19:00, J-23 pisze:
>> W dniu 28.03.2017 o 11:08, mmm pisze:
>>>> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to
>>>> dość
>>>> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery,
>>>> lecz
>>>> apki desktopowe.
>>>>
>>> Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja już
>>> fmx dla linux-a , patrząc jednak od innej strony to nie widzę aby
>>> klienci potrzebowali uruchamiać na linux, bo system jest tak niszowy ze
>>> nie znam nikogo kto używa linux-a w trybie graficznym.
>>>
>>
>> System niszowy? hmm zależy pod jakim względem na to patrzeć?
>>
>> - Serwery, rozwiązania za pomocą której mamy sieć zwaną popularnie
>> internetem - tu uniksy w tym duża cześć linuxów. Rozwiązania
>> Microsoftowe zostają w tyle pod względem ilości użytkowanych
>>
>> - Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
>> oczywiście Windows - W dużej części dla tego że ludzie nie znają
>> alternatyw, ponadto nie ma oprogramowania na to. Znalezienie programu za
>> pomocą którego byśmy wystawiali faktury, który nam pozwoli
>> na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows
>>
>> To się powoli zaczyna jednak zmieniać i dobrze. Szkoda jednak że tak
>> powoli
>>
>>> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a, wszystko
>>> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>>>
>>
>> Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
>> jednak dużo pracy by przystosować GUI by działało w obu środowiskach
>> mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
>>
>> Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
>> zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
>> ale ten jest pisany w Lazarus
>
> O czym ty piszesz?
> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
> desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE jak
> i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi jak
> i Lazarus:
> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
> kbmmw, kbmmtable, mORMot.
>

Miab a gdzie ja napisałem że Lazarus ma problemy? Właśnie ich nie ma
potrafi ten sam kod prze kompilować dla Windows i Linux zarówno w
aplikacji konsolowej jak i okienkowej

A jako przykład takiego działania podałem link do programu napisanego w
Lazarusie.

Pozdrawiam
J-23

W dniu 28.03.2017 o 21:20, Mirosław Rogula pisze:
>
>
>> - Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
>> oczywiście Windows - W dużej części dla tego że ludzie nie znają
>> alternatyw, ponadto nie ma oprogramowania na to. Znalezienie programu
>> za pomocą którego byśmy wystawiali faktury, który nam pozwoli
>> na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows
>
> Wcale nie jest takie trudne. Jeśli zastosować WIne pod Linuxa wtedy mamy
> do dyspozycji całkiem sporą ilość oprogramowania. Moje programy całkiem
> fajnie
> chodzą i pod Linuxem i pod iMac właśnie dzięki Wine.  I nie muszę pisać
> specjalnego
> oprogramowania dla Linuxa

Owszem da się, odpalisz nawet sporo takich programów ale nie zmienia to
faktu że natywnego oprogramowania o jakim wspomniałem jest jak na
lekarstwo. To po pierwsze.

Po drugie czy aplikacja tak odpalona da 100% tego co natywna?

Wine jest fajne jednak ono nie sprawi że aplikacja Windowsowa stanie się
Linuxową. Jest to dalej aplikacja Windowsowa odpalona w nie naturalnym
środowisku dla siebie.

Żebyś mnie dobrze zrozumiał nie piszę tego złośliwe i tylko po to by
udowodnić swoją racje, ale po to by pokazać że za aplikacje odpaloną na
Wine nie można dać klientowi 100% pewności

Pozdrawiam
J-23

W dniu 28.03.2017 o 22:46, Krzysztof Szyszka pisze:
>> Użytkownik "miab"  napisał ...
>> >> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
>> >> desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE
>> >> jak i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
>> >> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi
>> >> jak i Lazarus:
>> >> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
>> >> kbmmw, kbmmtable, mORMot.
>> >
>> > Zwróć uwagę, że są to głównie biblioteki niewizualne, które nie
>> korzystają
>> > z WinAPI i żeby je przenieść na inną platformę wystarczy zgodność
>> języka
>> > lub występowanie podstawowych kontrolek wizualnych na każdej
>> platformie.
>> >
>> > W przypadku takich komponentów jak TXDBGrid, czy też innych, które
>> mocno
>> > wykorzystują WinAPI, przeniesienie na inną platformę staję się
>> problemem,
>> > bo kluczowe funkcjonalności są niedostępne lub wymagają
>> przeprojektowania
>> > całego rozbudowanego komponentu dla osiągnięcia podobnego efektu.
>> >
>> > Zobacz, ile poważnych firm nie zdecydowało się przez kilka lat na
>> przeniesienie
>> > swoich komponentów wizualnych z VCL na FMX, a co dopiero mówić o
>> Lazarusie.
>>
>> Dlatego przydał by się jakiś wypasiony dbGrid. Bo te co są to raczej
>> porażka.
>> Podejrzewam ze nie było by tak trudno w końcu Lazarus-owy dbGrid
>> wzorowany jest na Delphi-anym.
>
> Tylko, że oryginalny TDBGrid to jest dzisiaj może 10% kodu TXDBGrida :-)
> Jak do tego dołożyć moduły  XDBEditor, XDBFilter, XDBSearch, XDBDataList,
> które stanowią integralną część TXDBGrida i wymagają zgodności z WinAPI,
> żeby je w ogóle można było wykorzystać, to przeniesienie ich pod Lazarusa
> staje się nie lada wyzwaniem.
>
A może są odpowiedniki tych bibliotek, Interesowałeś się tym?
Mówię tu o WinAPI (tego co konkretnie używasz)

Pozdrawiam
J-23

W dniu 2017-03-28 o 23:21, J-23 pisze:
> W dniu 28.03.2017 o 21:20, miab pisze:
>> W dniu 2017-03-28 o 19:00, J-23 pisze:
>>> W dniu 28.03.2017 o 11:08, mmm pisze:
>>>>> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez GUI, to
>>>>> dość
>>>>> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery,
>>>>> lecz
>>>>> apki desktopowe.
>>>>>
>>>> Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja
>>>> już
>>>> fmx dla linux-a , patrząc jednak od innej strony to nie widzę aby
>>>> klienci potrzebowali uruchamiać na linux, bo system jest tak niszowy ze
>>>> nie znam nikogo kto używa linux-a w trybie graficznym.
>>>>
>>>
>>> System niszowy? hmm zależy pod jakim względem na to patrzeć?
>>>
>>> - Serwery, rozwiązania za pomocą której mamy sieć zwaną popularnie
>>> internetem - tu uniksy w tym duża cześć linuxów. Rozwiązania
>>> Microsoftowe zostają w tyle pod względem ilości użytkowanych
>>>
>>> - Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
>>> oczywiście Windows - W dużej części dla tego że ludzie nie znają
>>> alternatyw, ponadto nie ma oprogramowania na to. Znalezienie programu za
>>> pomocą którego byśmy wystawiali faktury, który nam pozwoli
>>> na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows
>>>
>>> To się powoli zaczyna jednak zmieniać i dobrze. Szkoda jednak że tak
>>> powoli
>>>
>>>> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a,
>>>> wszystko
>>>> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>>>>
>>>
>>> Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
>>> jednak dużo pracy by przystosować GUI by działało w obu środowiskach
>>> mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows

O jakim staraniu piszesz?

>>> Jako przykład podam link do http://fblib.altervista.org/ jest jedeno GUI
>>> zaprojektowane dla linux i windows jest jeszcze sporo takich przykładów
>>> ale ten jest pisany w Lazarus
>>
>> O czym ty piszesz?
>> Lazarus nie ma najmniejszych problemów z generowaniem aplikacji
>> desktopowych na Windows Win32/64 i Linux-32/64  i to zarówno na KDE jak
>> i pochodne Gnome(qt/gtk), tudzież OSX (Carbon/Cocoa).
>> Istnieje szereg poważnych bibliotek które działaja zarówno na Delphi jak
>> i Lazarus:
>> UniDAC, ZEOS, FastReport, TMS Aurelius i pozostałe z rodziny Business,
>> kbmmw, kbmmtable, mORMot.
>>
>
> Miab a gdzie ja napisałem że Lazarus ma problemy? Właśnie ich nie ma
> potrafi ten sam kod prze kompilować dla Windows i Linux zarówno w
> aplikacji konsolowej jak i okienkowej
>
> A jako przykład takiego działania podałem link do programu napisanego w
> Lazarusie.

Ale to jest akurat słaby przykład dla Lazarusa.
Bo nie trzeba o nic się starać tylko bierzesz i kompilujesz ten sam kod
na n-platform i procesorów albo crooss-kompilujesz jak nie chce ci się
przełączać czy przechodzić między systemami.

miab

>> Wcale nie jest takie trudne. Jeśli zastosować WIne pod Linuxa wtedy mamy
>> do dyspozycji całkiem sporą ilość oprogramowania. Moje programy całkiem
>> fajnie
>> chodzą i pod Linuxem i pod iMac właśnie dzięki Wine.  I nie muszę pisać
>> specjalnego
>> oprogramowania dla Linuxa

>Owszem da się, odpalisz nawet sporo takich programów ale nie zmienia to
>faktu że natywnego oprogramowania o jakim wspomniałem jest jak na
>lekarstwo. To po pierwsze.

>Po drugie czy aplikacja tak odpalona da 100% tego co natywna?

>Wine jest fajne jednak ono nie sprawi że aplikacja Windowsowa stanie się
>Linuxową. Jest to dalej aplikacja Windowsowa odpalona w nie naturalnym
>środowisku dla siebie.

>Żebyś mnie dobrze zrozumiał nie piszę tego złośliwe i tylko po to by
>udowodnić swoją racje, ale po to by pokazać że za aplikacje odpaloną na
>Wine nie można dać klientowi 100% pewności

>Pozdrawiam
>J-23
Powiedziawszy szczerze to użytkownikowi wisi jaką ma aplikację i czy jest
ona natywna czy nie. Na ogół większość użytkowników nie ma o tym pojęcia.
Ona ma chodzić  to dobrze i tyle. Jeśli program jest w miarę dobrze napisany
to będzie chodzić bez większych problemów. Moje programy chodzą i błędy
jakie się ewentualnie pokazują to nie są te wynikające z pracy w środowisku
Wine. Niestety nikt nie da 100% pewności że program będzie pracował
poprawnie. No chyba że program jest banalnie  prosty. A trzeba przyznać że
nad Wine pracuje ekipa cały czas. I chodzi to całkiem fajnie.

Mirosław Rogula
MR_FLASH

W dniu 29.03.2017 o 00:43, miab pisze:
> W dniu 2017-03-28 o 23:21, J-23 pisze:
>> W dniu 28.03.2017 o 21:20, miab pisze:
>>> W dniu 2017-03-28 o 19:00, J-23 pisze:
>>>> W dniu 28.03.2017 o 11:08, mmm pisze:
>>>>>> Warto zaznaczyć, że na Linuksa można pisać tylko aplikacje bez
>>>>>> GUI, to
>>>>>> dość
>>>>>> poważny bloker, bo jednak gros aplikacji delphiowych to nie serwery,
>>>>>> lecz
>>>>>> apki desktopowe.
>>>>>>
>>>>> Mam nadzieje ze taki jest plan: teraz tylko konsola, następna wersja
>>>>> już
>>>>> fmx dla linux-a , patrząc jednak od innej strony to nie widzę aby
>>>>> klienci potrzebowali uruchamiać na linux, bo system jest tak
>>>>> niszowy ze
>>>>> nie znam nikogo kto używa linux-a w trybie graficznym.
>>>>>
>>>>
>>>> System niszowy? hmm zależy pod jakim względem na to patrzeć?
>>>>
>>>> - Serwery, rozwiązania za pomocą której mamy sieć zwaną popularnie
>>>> internetem - tu uniksy w tym duża cześć linuxów. Rozwiązania
>>>> Microsoftowe zostają w tyle pod względem ilości użytkowanych
>>>>
>>>> - Komputer użytkowy, wykorzystywany w małych i średnich firmach tu
>>>> oczywiście Windows - W dużej części dla tego że ludzie nie znają
>>>> alternatyw, ponadto nie ma oprogramowania na to. Znalezienie
>>>> programu za
>>>> pomocą którego byśmy wystawiali faktury, który nam pozwoli
>>>> na prowadzenie małej/średniej firmy jest trudniejsze niż na Windows
>>>>
>>>> To się powoli zaczyna jednak zmieniać i dobrze. Szkoda jednak że tak
>>>> powoli
>>>>
>>>>> Kolejna sprawa to mnogość rozwiązań powłok graficznych linux-a,
>>>>> wszystko
>>>>> da się zrobić tylko koszty mogą być niewspółmierne do zysków.
>>>>>
>>>>
>>>> Prym wiodą głownie KDE i GNOME są też inne ale mniej popularne. Nie ma
>>>> jednak dużo pracy by przystosować GUI by działało w obu środowiskach
>>>> mało tego gdy się postaramy możemy mieć to samo GUI nawet na Windows
>
> O jakim staraniu piszesz?

Po pierwsze, widziałem napisane GUI w lazarusie a rozjeżdżało się pod
pod jednym albo drugim systemem fakt że to było lata temu ale...
zdarzało się

Nie było to fakt faktem mój kod, Teraz Lazarusa dotknąłem po dłuższej
przerwie i masz rację teraz jest to praktycznie "połóż kontrolkę i
zapomnij" nie jest to jakiś gigantyczny projekt ten nad którym teraz
pracuje ale działa bez zarzutu.

Podsumowując dla mnie Lazarus jest jak najbardziej dobrą alternatywą

Pozdrawiam
J-23

>
> Ideą FMXa jest właśnie niezależność od powłok, bo rysuje się sam.
>

A to nie jest tak ze "OpenGL Context" wymaga jakiegoś okna w którym
bedzie rysowany OpenGL , czy to na linux czy to na windows ?

M

W dniu 2017-03-30 o 10:11, mmm pisze:
>>
>> Ideą FMXa jest właśnie niezależność od powłok, bo rysuje się sam.
>>
>
> A to nie jest tak ze "OpenGL Context" wymaga jakiegoś okna w którym
> bedzie rysowany OpenGL , czy to na linux czy to na windows ?
>

Jest mniej więcej tak.FMX-y wykrywaja jaki jest podsystem graficzny w
danym systemie(czy jakiś DirectX czy któraś z mutacji OpenGL) i go
wykorzystują.

miab

W dniu 2017-03-26 o 13:39, Kviat pisze:
> W dniu 2017-03-26 o 09:30, Krzysztof Szyszka pisze:
>> Użytkownik "J-23"  napisał ...
>>>
>>> W dniu 25.03.2017 o 19:26, Krzysztof Szyszka pisze:
>>> > Witam,
>>> >
>>> > miło mi poinformować, że ukazała się nowa wersja pakietu X-DBData
>>> > Components 1.8!
>>>
>>> Mały ruch na grupie. Ja sam dotykam Delphi już sporadycznie. Ale
>>> zapytam nie kusiło Cie nigdy
>>> wypuścić pakietów pod Lazarusa?
>
>> Napisz mi najpierw, dlaczego ludzie nadal używają Lazarusa zamiast
>> najnowszych wersji Delphi,
>> w których dzisiaj można pisać programy na różne platformy z Linuxem
>> włącznie (10.2 Tokyo)?
>> Ja widzę tylko jeden powód - Lazarus i FPC są dostępne za free, a Delphi
>> kosztuje coraz więcej.
>
> I w związku z tym będzie więcej użytkowników Lazarusa czy mniej?
>
> Absolutnie nie chcę tu polemizować z Twoim modelem biznesowym - znasz go
> lepiej i lepiej wiesz co dla niego dobre. Ale widzę tu pewną nieścisłość
> w takim rozumowaniu.
> Skoro ludzie nadal używają Lazarusa (sam teraz używam CodeTyphon)
> _zamiast_ Delphi jak sam zauważyłeś, to lepiej nic nie zarobić (albo
> potencjalnie przestać zarabiać w niedługiej perspektywie) na Delphi, niż
> spróbować chociaż część przerobić pod Lazarusa?
>
> Naturalnie rozumiem obawę, że nawet w przypadku całkowitej "śmierci"
> Delphi, potencjalny zarobek na użytkownikach Lazurusa jest wątpliwy
> (pewnie nie bez powodu poskąpili na Delphi... ;)), a może jednak te
> przewidywania na temat "śmierci" Delphi są mocno przesadzone?
>
> Rozumiem Twoje podejście również z innej perspektywy. To co mam na
> pokładzie w CodeTyphon w zupełności wystarcza na moje potrzeby, więc
> pomijając kwestie finansowe, zwyczajnie nie potrzebuję kupować
> dodatkowych komponentów. Z innymi Lazarusowcami może być podobnie... to
> raczej nie są duże projekty, wymagające wodotrysków.
> Jakiś czas temu pisałem na grupie, że próbuję się przesiąść z Delphi na
> VisualStudio i C# i po kilku podejściach zostałem jednak przy
> CodePython. Na razie. I wątpię, że wrócę do Delphi w przewidywalnym czasie.
>
> Pozdrawiam
> Piotr
Wrzuce swoje 3grosze+vat. Do pracy kupiłem dawno temu D2005 a po kilku
latach XE2 prof. Sam w domu przesiadłem się na Lazarusa. Potwierdzam, to
co ktoś już przede mną zaznaczył, że do wielu aplikacji, czasem wcale
nie takich prostych, a jednak nie trzeba miliona fjuczerów. Sam się
zajmuję pisaniem oprogramowania na maszyny produkcyjne i świadomie
pomijam wodotryski na rzecz prostoty i łatwości obsługi. Przykład super
hiper bajerów ma TMS - dam królestwo za helpa do tych kontrolek. Dlatego
wygrał Lazarus.

Pzdr.