Czy w 2023 ktoś używa jeszcze lazarusa do jakichś ciekawych projektów?
0
1
Pytanie jest inne - czym jest "poważny projekt"?
Ja sam jakiś czas temu się poddałem i parę desktopwych rzeczy popełniłem we Flutterze. U mnie motywacją był wygląd - bo w Lazarusie stworzysz coś, co wizualnie wygląda jakby było teleportowane z lat 90-tych, a żeby stworzyć coś wyglądające jak "nowoczesne" apki w stylu chociażby Spotify to trzeba mocno się napocić.
A, niestety, mechanizm jest taki, że ludzie oceniają jakość aplikacji także na podstawie jej wyglądu. I apka może być technicznie i biznesowo idealna, ale wygląd będzie dla wielu dyskwalifikujący.
Niemniej, jakby pominąć kwestię wyglądu, to nie kojarzę, żeby czegoś się nie dało zrobić. To bardzo wygodne środowisko (oczywiście - kilka generacji za Delphi) i nie poczułem się nigdy nim ograniczony. Społeczność także istnieje, więc można liczyć wsparcie na forach Lazarusa/Free Pascala czy nawet na 4P.
Ale nie uważam, żeby to było najlepsze środowisko do stworzenia jakiegoś mega-wielkiego kombajnu typu Comarch Optima. Dla większości przeciętnych dziubaczy to środowisko i ogólnie język dałby radę. Tylko mało kto z tego korzysta, bo nie wypada, nie jest modne, zaraz ktoś wpadnie i wyśmieje.
2
Jeżeli chodzi o desktopowe aplikacje jak najbardziej tak ale tylko jeżeli nad projektem pracują osoby potrafiące pisać w obecnej wersji FreePascal (lub też Delphi bo to podobne) a nie zatrzymały się gdzieś tam na Pascalu w wersjach jeszcze pod DOS a w najlepszym razie na Delphi 7 do teraz pisząc kod w sposób w jaki można co najwyżej prosty kalkulator napisać a i tak po powrocie za miesiąc do projektu nikt nie będzie wiedział o co chodzi. Jeżeli chodzi o środowisko to trzeba napisać wprost, że kiepskim bootcampowym "programistom" na pewno będzie bardzo brakowało różnych ficzerów bez których sobie nie poradzą podobnie jak od strony języka gotowych bibliotek, których od dłuższego czasu za wiele nie powstaje zwłaszcza jeżeli chodzi o darmowe lub nie drogie a bez tych gotowców nie są w stanie nic napisać. Tak naprawdę realnym minusem pisania w FreePascal (czyli środowisko Lazarus) czy też Delphi dla osób, które naprawdę znają język jest to, że najprawdopodobniej trzeba będzie poświęcić na projekt więcej czasu co przekłada się na koszty.
1
krzychu82a napisał(a):
Czy w 2023 ktoś używa jeszcze lazarusa do jakichś ciekawych projektów?
Najpierw należy przyjąć do wiadomości, że Free Pascal i Lazarus nie są targetowane na polski rynek, nie są projektem rządowym (na szczęście), więc określanie popularności tych technologii patrząc przez pryzmat polskiego rynku jest po prostu nieprawidłowe.
Odpowiadając na pytanie — tak, w Lazarusie są rozwijane duże systemy (podobnie jak w Delphi), najróżniejsze programy do celów naukowych, dla sektora medycznego itd., ale raczej trzeba patrzeć na rynek zachodnio-europejski, obie Ameryki, Brazylię czy Rosję, bo tam Lazarus cieszy się najwyższą popularnością.
Przy okazji udzielania się na forum Lazarusa, niejednokrotnie ich użytkownicy dyskutowali o rozwiązaniach i problemach w oprogramowaniu nad którym pracują, często opisywali jak ono działa i co potrafi, często też pokazywali zrzuty ekranu, które pokazywały, że to nie są jakieś małe narzędzia, a spore systemy.
Jeśli chciałbyś wiedzieć ile dużych i ciekawych projektów jest rozwijanych przy użyciu Lazarusa, to sugeruję przeprowadzić ankietę na forum Lazarusa. Założyć wątek i poprosić o to, aby użytkownicy pochwalili się nad czym pracują, aby napisali czy to projekty komercyjne czy hobbystyczne i aby (jeśli mogą) pokazali jakieś zrzuty ekranu. Na 4p jest garstka ludzi robiących coś większego w Lazarusie.
cerrato napisał(a):
U mnie motywacją był wygląd - bo w Lazarusie stworzysz coś, co wizualnie wygląda jakby było teleportowane z lat 90-tych, a żeby stworzyć coś wyglądające jak "nowoczesne" apki w stylu chociażby Spotify to trzeba mocno się napocić.
Natywny wygląd systemów operacyjnych nazywasz teleportowaniem do lat 90-tych? ;)
Jeśli chodzi o aplikacje desktopowe, to domyślnym wyglądem jest ten zgodny z systemem operacyjnym. Np. na Windows, bez problemu można stworzyć narzędzia wyglądające jak typowe, systemowe okienka. Na Linuksach wygląd jest inny, na macOS jeszcze inny, a na Adroidzie taki jak zwykle w mobilkach. Natomiast do tworzenia nietypowych interfejsów jest np. Custom Drawn Controls.
Jeśli potrzeba czegoś więcej, to zawsze można napisać własny komponent i renderować go jak dusza zapragnie. Kontrolki bazowe z LCL są bardzo proste do programowania, ale minusem jest to, że im bardziej fikuśną kontrolkę chcemy, tym więcej czasu trzeba na implementację (w sumie to nie jest nic nadzwyczajnego). W razie czego nie ma problemu, można sobie nawet własny widgetset napisać i podłączyć go, jedną linijką kodu, zapewniając możliwość zmiany wyglądu at runtime.
Lazarus niestety na razie nie posiada wbudowanego narzędzia do skórkowania, takiego jak od dawna ma Delphi.
Z jednej strony to źle, dlatego że w Delphi można (a przynajmniej można było) sobie wrzucić plik graficzny z elementami interfejsu i szybko zbudować dowolny wygląd aplikacji. To jest świetne narzędzie, jednak lekko posysa wydajnościowo — jeśli potrzebuję mieć np. jednolite tło okna czy kontrolek, to wypełnianie ich kolorem (np. Canvas.FillRect) jest zdecydowanie szybsze niż kopiowanie fragmentu obrazu.
Z drugiej strony nie aż tak źle, bo zawsze można sobie stworzyć kontrolkę i zoptymalizować jej działanie i renderowanie specyficznie dla efektu, jaki chcemy uzyskać. Ale to jest zaleta dla tych, którzy nie boją się klepać kodu, a samo klepanie kodu idzie im sprawnie, bo znają LCL i wiedzą jak z nim pracować.
A, niestety, mechanizm jest taki, że ludzie oceniają jakość aplikacji także na podstawie jej wyglądu. I apka może być technicznie i biznesowo idealna, ale wygląd będzie dla wielu dyskwalifikujący.
Nie wiem jak dla was, ale dla mnie dyskwalifikujący wygląd (interfejs) to taki, który jest niedbały, a nie taki, który jest zgodny z wyglądem całego systemu. Widziałem już sporo zrzutów ekranu dużych aplikacji tworzonych w Lazarusie i niestety wiele z nich wygląda tragicznie. Wiele z nich ma zupełnie niedbale rozlokowane kontrolki, a nawet powybierane własne kolory (zamiast używania systemowych), przez co interfejs wygląda wieśniacko.
W takich przypadkach nie jest to wina LCL, a twórców, którzy zdają się po prostu nie mieć gustu. IMO jeśli nie ma czasu lub możliwości stworzenia customowego renderowania całego interfejsu, to najlepszym rozwiązaniem jest skorzystanie z wyglądu systemowego. Nie dość, że jest on porządny i ładny (na wszystkich platformach), to w dodatku mamy pewność, że aplikacja zawsze będzie wyglądać poprawnie, bez względu na to jak użytkownik systemu skonfigurował sobie jego wygląd.
Ale nie uważam, żeby to było najlepsze środowisko do stworzenia jakiegoś mega-wielkiego kombajnu typu Comarch Optima.
Nie znam Comarch Optima, ale i nie widzę powodu, dla którego nie dałoby się zrobić czegoś, co ten system posiada. Pewnie w innych narzędziach wiele rzeczy dałoby się zrobić szybciej i wygodniej, ale inne być może wolniej lub gorzej/trudniej. Trudno powiedzieć, bo ani nie znam tego oprogramowania, ani też nie testowałem każdego języka i IDE pod kątem wszystkich możliwych zastosowań.
2
Natywny wygląd systemów operacyjnych nazywasz teleportowaniem do lat 90-tych?
Tak :) Nawet microsoft w swoich produktach nie może się zdecydować. Np ikona refresh w edge i eksploatorze plików, wygląd menu kontekstowego edge vs notatnik, pulpit, i 100 innych produktów. I tak można bardzo długo wymieniać.
Poza tym systemowych kontrolek nie masz za dużo. Wiec potem aby zapewnić spójność musisz przejebać cała dokumentację Fluent UI i ic filozofię.
Kontrolki bazowe z LCL są bardzo proste do programowania
Powodzenia w testowaniu accesibility. Jasne można odjebać po studencku. Ale Jeśli chodzi o apki natywne to testowanie jest w ch... bardziej czasochłonne niz na webie. + na webie wszystko opiera sie analizie html'a i wai-aria tagow.
W natywnych windowsa nie ma chociażby tabelki. Z doświadczenia wiem, że na ten komponent można spalić tygodnie/miesiące developmentu.
(tak wiem, że skomplikowana tabelka to zły UX i sie od tego odchodzi jednak cały czas popularny w korpo świecie)
Tak jeszcze polecam lekturę jak uważasz, że tak prosto się tworzy własne kontrolki przelecieć reguły design systemu dla windows 11 :P
https://learn.microsoft.com/en-us/windows/apps/design/
Tak jeszcze dodam, że mówie o accesibility bo wspomniałeś o ameryce i urzędowych aplikacjach więc wchodzi kwestia ich konstytuacji a dokładnie "section 508", "ADA Act" itd.
0
Schadoow napisał(a):
Tak :) Nawet microsoft w swoich produktach nie może się zdecydować.
Co to ma do rzeczy? Pisałem, że natywny wygląd różnych systemów nie jest brzydki, a Ty, że Microsoft stosuje kilka stylów w obrębie całego systemu i wbudowanych aplikacji. Coś Ci argumentowanie nie za bardzo wychodzi.
Np ikona refresh w edge i eksploatorze plików, wygląd menu kontekstowego edge vs notatnik, pulpit, i 100 innych produktów. I tak można bardzo długo wymieniać.
Różnica pomiędzy Edge a Notatnikiem jest taka, że Notatnik jest aplikacją korzystającą wyłącznie ze standardowego stylu systemowego, a Edge nie. Przeglądarka ta nie dość, że w większości miejsc nie wykorzystuje standardowych kontrolek, to w dodatku posiada dedykowane opcje stylowania (co załatwia się customowym interfejsem i za pomocą Chromium, bo zamiast okien potomnych są karty z zawartością w formie stron).
Edge musi mieć menu kontekstowe stylowane ręcznie, bo w systemie może być ustawiony styl jasny (białe okna), a w przeglądarce ciemny — ja tak mam ustawione. Gdyby Edge miał korzystać z systemowego wyglądu i jednocześnie zapewniać wsparcie Dark Mode, to pół przeglądardki byłoby ciemne, a pół białe (wszystko co systemowe, czyli np. belka okna, menu kontekstowe itd.).
Sugeruję nie krytykować czegoś, czego nie rozumiesz. ;)
Poza tym systemowych kontrolek nie masz za dużo.
Nie pisałem o systemowych kontrolkach, a o kontrolkach LCL-a, które renderowane są zgodnie bieżącym stylem systemu — a komponentów w LCL są setki. Poza tym, stworzenie własnej kontrolki, która ma być renderowana z wykorzystaniem systemowego wyglądu, jest banalne. Wystarczy skorzystać z ThemeServices i jego metod do malowania konkretnych elementów interfejsu (np. DrawText, DrawElement, DrawEdge, DrawIcon itd.) — nie trzeba będzie się martwić, że coś będzie źle wyglądało, skoro ThemeServices korzysta z natywnych funkcji renderujących, na każdej platformie.
Powodzenia w testowaniu accesibility.
Nie muszę niczego testować, bo wszystko jest już zrobione w bazowych klasach LCL-a. Natomiast jeśli wymyślę sobie jakieś nietypowe/fikuśne rozwiazania, to i tak trzeba je będzie przetestować, nieważne w jakiej technologii zostaną stworzone.
Ale Jeśli chodzi o apki natywne to testowanie jest w ch... bardziej czasochłonne niz na webie. + na webie wszystko opiera sie analizie html'a i wai-aria tagow.
Tak? I piszesz to z własnego, bogatego doświadczenia dotyczącego tworzenia komponentów w Lazausie?
No to tak tylko wspomnę, że apki natywne (w tym używane w nich komponenty wizualne) debuguje się tak samo szybko i wygodnie jak każdy inny kod, pełna swoboda i wszystkie funkcje debuggera/IDE. Nie wpychaj do tego tematu weba i smutnych doświadczeń z rzeźbienia w nim, bo to niemal off-topic.
W natywnych windowsa nie ma chociażby tabelki. Z doświadczenia wiem, że na ten komponent można spalić tygodnie/miesiące developmentu.
(tak wiem, że skomplikowana tabelka to zły UX i sie od tego odchodzi jednak cały czas popularny w korpo świecie)
Znów to samo — nie interesuje mnie to które kontrolki są natywnymi w Windows, bo nie używam bezpośrednio natywnych kontrolek z Windows. Po to LCL jest stworzone w formie wysokopoziomowej, wieloplatformowej abstrakcji, aby komponenty działały i wyglądały poprawnie, bez względu na platformę.
Tak jeszcze polecam lekturę jak uważasz, że tak prosto się tworzy własne kontrolki przelecieć reguły design systemu dla windows 11 :P
https://learn.microsoft.com/en-us/windows/apps/design/
Napisałem, że prosto jest pisać własne kontrolki, jeśli robi się to w Lazarusie — LCL (tak samo jak VCL) jest wybitnie proste do rozszerzania. Masz poważny problem w temacie czytania ze zrozumieniem.
Tak jeszcze dodam, że mówie o accesibility bo wspomniałeś o ameryce i urzędowych aplikacjach więc wchodzi kwestia ich konstytuacji a dokładnie "section 508", "ADA Act" itd.
Nie, nigdzie nie wspominałem o ”ameryce” i urzędowych aplikacjach. Pisałem, że Lazarus nie jest polskim projektem rządowym i że nie jest targetowany na polski rynek, a także, że Lazarus cieszy się największą popularnością głównie w obu Amerykach, zachodniej Europie i Rosji.
1
@furious programming:
Sam się gubisz w tym co piszesz
Natywny wygląd systemów operacyjnych nazywasz teleportowaniem do lat 90-tych?
To w końcu natywny wygląd czy LCL'a ?
Tak? I piszesz to z własnego, bogatego doświadczenia dotyczącego tworzenia komponentów w Lazausie?
Nie z pisania komponentów które przechodzą certyfikacje. Technologia nie ma za bardzo znaczenia.
Sugeruję nie krytykować czegoś, czego nie rozumiesz.
Cały akapit co przeglądarka musi a nie to bullshit. Sterowanie stylami to jedno a trzymanie sie system desginu to drugie a funkcjonalnosci to trzecie. Poza tym jakbyś nie wiedział to microsoft wydał nowy notatnik z light/dark mode.
więc całe to:
Edge musi mieć menu kontekstowe stylowane ręcznie, bo w systemie może być ustawiony styl jasny (białe okna), a w przeglądarce ciemny — ja tak mam ustawione. Gdyby Edge miał korzystać z systemowego wyglądu i jednocześnie zapewniać wsparcie Dark Mode, to pół przeglądardki byłoby ciemne, a pół białe (wszystko co systemowe, czyli np. belka okna, menu kontekstowe itd.).
To twoje przypuszczenia i opinia a nie fakt. Windows na ten moment ma 3 czy nawet 4 design systemy których uzywa w windowsie. W zależności kiedy ( jaki system był aktualny) był wydany update wyglada danej aplikacji systemowej.
BTW możesz podesłać mi gdzie jest przykład komponentów LCL'a zgodnyc z fluent UI ? Bo nie za bardzo mogę to znaleźć. A skoro piszesz, że zapewnia styl windowsowy to zakładam, że nie kłamiesz i istnieje gdzieś.
#EDIT
Ale ok. Chciałem tylko zwrócic uwagę, że biblioteka komponentów jest baaardzo istotna. I jeżeli nie ma zewnetrznyc to jest to zapedzanie sie w kozi róg. Możesz mieć inne zdanie nie chce robić więcej offtopu.
0
Schadoow napisał(a):
To w końcu natywny wygląd czy LCL'a ?
Natywny wygląd systemu, a więc i LCL-a.
Nie z pisania komponentów które przechodzą certyfikacje. Technologia nie ma za bardzo znaczenia.
No to skoro nie pisałeś komponentów w Lazarusie, to nie twierdź, że ich testowanie jest, cytuję: „w ch... bardziej czasochłonne”, skoro nie masz o tym żadnego pojęcia.
Cały akapit co przeglądarka musi a nie to bullshit. Sterowanie stylami to jedno a trzymanie sie system desginu to drugie a funkcjonalnosci to trzecie.
No i właśnie dlatego nie biadol o tym, że Edge wygląda inaczej niż Notatnik i systemowe narzędzia, bo skoro powodów jest wiele, to nie ma żadnego obowiązku trzymania zgodności wszędzie i w każdej aplikacji, a już tym bardziej w aplikacji, która może być stylowana w sposób dowolny.
Poza tym jakbyś nie wiedział to microsoft wydał nowy notatnik z light/dark mode.
I nie muszę wiedzieć, mając na pokładzie Windows 10, którego ta aktualizacja najwyraźniej nie dotyczy.
Windows na ten moment ma 3 czy nawet 4 design systemy których uzywa w windowsie.
W dalszym ciągu argument z tyłka — ja pisałem, że systemowy wygląd nie jest brzydki i trzymanie się go nie jest żadnym powrotem do lat 90-tych, a Ty piszesz o różnych stylach w obrębie Windows, jednocześnie nie pisząc nic o tym czy jest brzydki czy ładny. Piszesz nie na temat. Tym bardziej, że nie pisałem stricte o Windows, a o każdej platformie wspieranej przez LCL i każdym wspieranym przez niego widgetsecie.
2
LCL obsługuje standardowe kontrolki Win32: https://learn.microsoft.com/en-us/windows/win32/controls/individual-control-info
I wyglądają dokładnie tak samo jak inne standardowe kontrolki na danym systemie.
@Schadoow: Podane przez Ciebie przykłady jak CommandBar, MapControl, czy MediaPlayer nie są standardowymi kontrolkami MS Windows, tytlko UWP.
Oprócz LCL możesz użyć QT, Custom Draw Controls (jak podał @furious programming ). Są też dostępne: fpGUI MSEgui.
0
@Paweł Dmitruk: Oczywiście, że są standardowymi kontrolkami ms windows. To co podałem nie jest częścią UWP tylko Windows App SDK który zbiera wszystko jak win32, uwp itd.
Abstrahując od tego. Obowiązującym desgin systemem w nowym windowsie jest Fluent UI jeżeli coś nie jest zgodne to nie jest zgodne z nowym wyglądem windowsa nieważne skąd pochodzi. EOT i próba argumentowani czy to jest czy nie ma w win32 to jest nieporozumienie bo win32 to twór sprzed ilu lat ? Nawet nie chce mi się szukać. Poza tym tak jak wspomniałem chodzi o DS i komponent zgodne z nim.
Tak samo w przypadku Linuxa nie będziemy dyskutować w kontekście zgodnosci z QT tylko zgodności z danym DS
https://develop.kde.org/hig/
https://developer.gnome.org/hig/
itd itd....
1
Schadoow napisał(a):
Obowiązującym desgin systemem w nowym windowsie jest Fluent UI jeżeli coś nie jest zgodne to nie jest zgodne z nowym wyglądem windowsa nieważne skąd pochodzi.
No nie chcę Cię martwić, ale Windows 11 nie jest jedynym systemem używanym na świecie. Najpopularniejszą wersją Windows jest wersja 10 (około 70% uzytkowników okienek używa tej wersji), a Windows 11 jest relatywnie świeżym wynalazkiem.
EOT i próba argumentowani czy to jest czy nie ma w win32 to jest nieporozumienie bo win32 to twór sprzed ilu lat ?
Win32 to nadal obowiązująca nazwa systemowego API (Win32 API) oraz platformy dla aplikacji natywnych, niezależnie od wersji systemu i jego bitowości. Poza tym, Paweł wyjaśnił Ci dokładnie dlaczego dane komponenty są dostarczone z Lazarusem, a których nie ma — to żadne dziwne argumentowanie.
Gównoburza o LCL zaczęła się od krytyki mojej odpowiedzi na opinię @cerrato, w której stwierdziłem, że wygląd systemu nie jest brzydki — ani Windows, ani Linux, ani macOS. Nieistotne jest to z jakich komponentów LCL skorzystamy, skoro one dopasowują swój wygląd do systemu, na którym działają. Jeśli uważasz, że systemowy interfejs jest brzydki, to i każda aplikacja zbudowana ze standardowych komponentów LCL również będzie dla Ciebie brzydka.
Z drugiej strony, jeśli nie zależy nam na tym, aby nasza aplikacja miała wygląd zgodny z systemem, to zawsze można stworzyć własnoręcznie renderowany interfejs, taki sam na każdej wersji danego systemu i taki sam na różnych platformach. Są do tego pakiety odpowiednich komponentów, których renderowaniem można manipulować. A jeśli nie chcemy używać innych bibliotek, to zawsze jest możliwość budowania własnych kontrolek, rozszerzając te bazowe, istniejące w LCL. Wtedy całą podstawę mamy już gotową, możemy się skupić na samym ich renderowaniu i ew. dodatkowych ficzerach.
1
Czyli reasumując:
- Lazarus wspiera tylko wygląd taki jak domyślny systemowy, ale tylko ten najstarszy, bo np FluentUI nie. Dodatkowo, tylko jego podstawowe kontrolki, bo Ribbona nie ma. Interfejs win32 został wprowadzony w Windows 95, a Ribbon w 2007
- Lazarus nie wspiera żadnego stylowania interfejsu, chcesz coś customowego to sobie narysuj
- na Linuksach Lazarus wspiera tylko interfejs GTK2 wprowadzony w latach 90. Gtk2 jest już wycofane, bo gtk4 jest już stabilne, na forum Lazarusa płacz: https://forum.lazarus.freepascal.org/index.php?topic=52848.0 ojej bo lcl gtk3 dalej po 15 latach nie kompiluje się, a o gtk4 nikt nie myśli. Co zresztą przeczy tezie, że nowy lcl zrobić jest "tak łatwo"
Dodatkowo @furious programming znów dał jak zwykle popis niewiedzy o tym, jak działają współczesne technologie i wszytko równa i odnosi do Lazarusa i Delphi. Ciężko się dyskutuje się z kimś, kto siedzi tylko w swojej bańce i nigdy spoza niej nie wyszedł.
@cerrato: Flutter do aplikacji desktopowych to tak średnio póki co, bo nie ma natywnego wsparcia dla wielu okien w sensie oddzielnych okien systemowych. Są sposoby aby to obejść, ale wydajność jest taka sobie. FluentUI wygląda za to świetnie. Natywne wsparcie dla wielu okien jest już w drodze.
Mam wrażenie, że wszyscy używający normalnych, współczesnych technologii trochę z uśmiechem patrzą na @furious programming i nawet już nie próbują polemizować z jego twierdzeniami, niech sobie się bawi w swojej piaskownicy, w końcu nic w tym zlego.
3
gajusz800 napisał(a):
- Lazarus wspiera tylko wygląd taki jak domyślny systemowy, ale tylko ten najstarszy
tak jak napisałem w poprzednim poście wspiera np. QT
bo np FluentUI nie.
nikt nie twierdzi, że wspiera. NIe wspiera też MetoUI ani innych podobnych chUI
Dodatkowo, tylko jego podstawowe kontrolki, bo Ribbona nie ma.
ale ma zamienniki, np. https://wiki.freepascal.org/SpkToolbar czy https://www.tmssoftware.com/site/tmsfncuipack.asp
Interfejs win32 został wprowadzony w Windows 95
niesamowite, i zobacz, że nadal działa, w przeciwieństwie do tych "współczesnych" technologi, o których po kilku latach nikt już nie pamięta,
- Lazarus nie wspiera żadnego stylowania interfejsu, chcesz coś customowego to sobie narysuj
QT
- na Linuksach Lazarus wspiera tylko interfejs GTK2 wprowadzony w latach 90.
QT
Dodatkowo @furious programming znów dał jak zwykle popis niewiedzy o tym, jak działają współczesne technologie i wszytko równa i odnosi do Lazarusa i Delphi.
jak on tak może robić w wątku dotyczącym Lazarus-a
Ogólnie Lazarus jest robiony przez społeczność, nie stoi za tym żadna duża firma, która pompuje w to masę kasy. Wspieranie poszczególnych interfejsów/rozwiązań/bibliotek zależy od tego, czy jest ktoś komu zależy na oprogramowaniu tego.
Czy się nadaje do poważnych projektów - zależy od znaczenia słowa poważny w tym kontekście:
- jeżeli oznacza to duże projekty, to raczej nie ponieważ jak już zauważono popularność
pascal-a jest mała i ciężko będzie znaleźć programistów - jeżeli oznacza stabilne aplikacje wykonujące założone cele, to jak najbardziej, oczywiście o ile nie ma wymogu obsługi
FluentUI
0
@Paweł Dmitruk: A nie no to idealna technologia jak trzeba na każdym roku chodzić na ustępstwa :p. A jej rozwój zależny jest od jakiegoś randoma w piwnicy który jak wstanie lewą nogą i stwierdzi, że [CIACH!] nie robi to masz zero zapewnionego supportu.
Nic tylko w tym robić duże projekty xD xD xD.
Co do win32 i innych libek z lat 90 to tak działa i nie działa. Microsoft regularnie wycina sporo rzeczy. Np z początkiem roku przestał być wspierany ( wraz z IE) ActiveX wiec jak coś miałeś na COM to do wyjebania.
1
Schadoow napisał(a):
A jej rozwój zależny jest od jakiegoś randoma w piwnicy który jak wstanie lewą nogą i stwierdzi, że [CIACH!] nie robi to masz zero zapewnionego supportu.
Lazarus jest aktywnie rozwijany od 11 lat, a poza tym, nawet jeśli któryś z deweloperów powie pi*****ę, nie robię, to nic się nie stanie, bo nie jest jedynym deweloperem i jego pałeczkę przejmie ktoś inny — taka zaleta projektów społecznościowych.
Microsoft regularnie wycina sporo rzeczy. Np z początkiem roku przestał być wspierany ( wraz z IE) ActiveX wiec jak coś miałeś na COM to do wyjebania.
Ale nie wyciął i nie wytnie standardowych kontrolek, bo nie może. Tak więc brak argumentu.
PS: możesz zacząć się wypowiadać w sposób kulturalny, czy koniecznie musisz sprowadzać dyskusję do poziomu rynsztoka? Jeśli nie potrafisz sklecić jednego zdania bez wulgaryzmów to sugeruję przestać pisać posty.
1
Schadoow napisał(a):
@Paweł Dmitruk: A nie no to idealna technologia jak trzeba na każdym roku chodzić na ustępstwa :p.
Ale wybór technologii zależy od projektu, jak wiem, że będę do projektu potrzebował konkretnych rozwiązań, a wiem, że w Lazarus-ie tego nie zrobię, to robię to np. w C# i Visual Studio
A jej rozwój zależny jest od jakiegoś randoma w piwnicy który jak wstanie lewą nogą i stwierdzi, że [CIACH!] nie robi to masz zero zapewnionego supportu.
Tak jak np. z MetroUI robionym przez MS, który stwierdził, że ma to gdzieś i wprowadza ModernUI czy też FluentUI. Support MS (dla MetroUI) jest praktycznie taki sam jak u tego randoma, który wstał lewą nogą.
0
@Paweł Dmitruk: Ehh ale to przecież wiadomo z góry ze ze SD się zmienia się w prawie każdej wersji systemu. Tak jest wszędzie nie ważne czy weźmiesz Windows, Linux, android czy ios.
Natomiast w trakcie życia masz ten support. Każda większa firma ze sporym wyprzedzeniem informuje o EOL wiec jest czas na reakcje.
0
No właśnie — SD się zmienia, a WinAPI się praktycznie nie zmienia i deaktualizuje. Dzięki temu w Lazarusie można stworzyć aplikację, która będzie dobrze działać i wyglądać zawsze, nieważne czy jakieś *UI będzie wspierane czy zostanie porzucone. No i dzięki temu można tworzyć w Lazarusie i FPC software kompatybilny z całą linią systemów, w tym z wersjami porzuconymi, ale nadal istotnymi na rynku — jak np. Windows 7, używany przez ponad 10% użytkowników PC. Ba, wsparcie istnieje aż do Win16, więc i ZUS byłby zadowolony.
Ciekawe jak FluentUI wypada w tym temacie.
0
@furious programming:
Jak robisz jakieś sensowne oprogramowanie to raczej masz wywalone na typów co trzymają się windows 7 (chyba ze piszesz konkretnie dla takiego uzytkownika) bo i tak na nich nie zarobisz
Co do ZUS nikt w korpo świecie nie zamawia już fat klientów, wszyscy przechodzą na webserwisy więc tym bardziej tworzenie czegoś w Lazarusie dla takiego ZUS'u to pomyłka. Chyba, że masz potem pare milionów złotych na support.
Nie znam firmy która supportuje wstecznie systemy (nieważne czy to mobilne czy stacjonarne) jeśli jakiś konkretny klient lub (grupa klientów) za to nie płaci. Jasne można być fanatykiem wędkarstwa ale to jakaś nisza dla piwniczaków którzy robią projekty do szuflady i utrzymują je z nudów.
FluentUI będzie aktualny az nie wyjdzie kolejny.
Design System to nie tylko wygląd per se ale filozofia obsługi. Jakbym ci zrobił aplikację według guida ios na androida to bys ją odinstalował od razu bo byś się tylko wkurwiał i na odwrót.
BTW tak jeszcze wspomnę. Software House w Polsce odrzucają klientów z lagacy systemami czy to w Delphi czy to w Lazarusie. (Sytuacja z zycia). Jasne istnieja SH które w tym robię. Ale jeżeli nieświadomy klient dostanie zrobiony system w tych technologiach to jest trochę w dupie. Bo jest związany z danym SH albo musi spalić w ciul czasu na znalezienie nowego dostawcy. Dlatego nikt nie pozwoli zrobić "poważnego systemu" w tych technologiach jesli jest swiadomy.
1
Ja osobiście nie używam Lazarusa, nie mam nic do niego samego ani do osób, które z niego korzystają. Jakiś czas temu wypróbowałem i ma dwie niedoceniane cechy, które próżno szukać w większości środowisk i kompilatorów:
- Zunifikowana biblioteka GUI, która jest nakładką na różne biblioteki systemowe. Na przykład w Windows, mogą być kontrolki natywne, GTK+ i Qt. Oczywiście najlepiej, jak są natywne, ale wystarczy tylko w ustawieniach coś przestawić i przekompilować, a ten sam program będzie w stylu GTK+. Przydałoby się coś takiego, np. do .NET, gdzie jest zunifikowana biblioteka formatki, która pod spodem korzysta z WinForms, WPF, Avalonia, GTK#, MAUI, które za pośrednictwem biblioteki oprogramowuje się na jeden sposób. Oczywiście, WPF ma dużo większe możliwości niż WinForms, ale to nie problem, że by to, czego brakuje w Winform było zasymulowane okrężnie, albo wywalało wyjątek, o ile skorzysta się z czegoś, czego nie ma w WinFormsach czy GTK#.
- O ile dobrze pamiętam, Lazarus i FreePascal ma możliwość cross-kompilacji. Dzięki temu, teoretycznie (bo nie sprawdzałem w praktyce) wystarczy, że mam jeden komputer i jeden OS, a mogę skompilować na Windows, na Linux, na OSX M1, na OSX x86, po prostu na jakikolwiek system, który jest obsługiwany, mimo, że ja go nie mam.
0
andrzejlisek napisał(a):
- O ile dobrze pamiętam, Lazarus i FreePascal ma możliwość cross-kompilacji. Dzięki temu, teoretycznie (bo nie sprawdzałem w praktyce) wystarczy, że mam jeden komputer i jeden OS, a mogę skompilować na Windows, na Linux, na OSX M1, na OSX x86, po prostu na jakikolwiek system, który jest obsługiwany, mimo, że ja go nie mam.
Jeśli ma się zainstalowany cross-compiler, to potem wystarczy tylko wskazać platformę docelową kilkoma kliknięciami i odpalić kompilację. Jednak najwygodniej jest wejść w opcje projektu, stworzyć sobie listę buildów i potem albo wskazać build do kompilacji (z poziomu toolbara głównego okna lub inspektora projektu), albo z menu głównego wybrać Compile many Modes i automatycznie skompilować wszystkie interesujące, jeden po drugim.
Do wygodnej instalacji Lazarusów, kompilatorów i cross-kompilatorów, warto skorzystać z apki fpcupdeluxe, bo wszystko w niej można sobie wyklikać.
0
Schadoow napisał(a):
@furious programming:
Jak robisz jakieś sensowne oprogramowanie to raczej masz wywalone na typów co trzymają się windows 7 (chyba ze piszesz konkretnie dla takiego uzytkownika) bo i tak na nich nie zarobisz
Co do ZUS nikt w korpo świecie nie zamawia już fat klientów, wszyscy przechodzą na webserwisy więc tym bardziej tworzenie czegoś w Lazarusie dla takiego ZUS'u to pomyłka. Chyba, że masz potem pare milionów złotych na support.
Słusznie, że masz wywalone, ale z drugiej strony, w typowym biznesie, czy CRUD, jakie są szanse, że użyje się czegoś, czego nie ma w Win XP i przez to apka nie będzie działać? Jak jakieś bardzo specjalistyczne, które korzystają z cech Win10 bądź Win11, których próżno szukać w starszych, to ok, nie ma sensu zawracać sobie głowy kompatybilnością z Win <=8.1. Ale w typowych zastosowania, to jaki byłby sens na siłę wpychać takie cechy?
FluentUI będzie aktualny az nie wyjdzie kolejny.
Design System to nie tylko wygląd per se ale filozofia obsługi. Jakbym ci zrobił aplikację według guida ios na androida to bys ją odinstalował od razu bo byś się tylko wkurwiał i na odwrót.
Przecież telefon powiedzmy Huawei z Androidem i IPhone wyglądają i działają bardzo podobnie, przynajmniej na pierwszy rzut oka. Jaki miałby sens różnicować GUI zwłaszcza w przypadku, gdy obydwa telefony są podobnej wielkości i mają wyświetlacz podobnej rozdzielczośći? Jeżeli mam telefon Huawei, który prędzej czy później wyzionie ducha, potem zdecyduję się kupić telefon Apple, to przecież moja intuicja i procesy myślowe pozostaną bez zmian, więc skąd zalecenie, że aplikacja pełniąca tą samą funkcję musi mieć inaczej zrobiony interfejs w zależności od producenta telefonu?
0
Schadoow napisał(a):
Design System to nie tylko wygląd per se ale filozofia obsługi. Jakbym ci zrobił aplikację według guida ios na androida to bys ją odinstalował od razu bo byś się tylko wkurwiał i na odwrót.
To nie jest prawda. Istnieje masa aplikacji z taką samą filozofią obsługi na iOS i Androida i nikt nie płacze, np:
https://play.google.com/store/apps/details?id=pl.pkobp.iko
https://apps.apple.com/pl/app/iko/id597657968?l=pl
Jak widać ten sam ui jest na Androidzie i na iOS i jest bardziej Androidowy, a nikt z użytkowników iPhone się specjalnie nie skarży. Możesz znaleźć takich przykładów więcej.
Co do samego tematu wątku - nie, nie ma sensu. W ogóle jakiekolwiek poświęcenie czasu temu produktowi nie na sensu i jest to czas stracony.
0
gajusz800 napisał(a):
Schadoow napisał(a):
Design System to nie tylko wygląd per se ale filozofia obsługi. Jakbym ci zrobił aplikację według guida ios na androida to bys ją odinstalował od razu bo byś się tylko wkurwiał i na odwrót.
To nie jest prawda. Istnieje masa aplikacji z taką samą filozofią obsługi na iOS i Androida i nikt nie płacze, np:
https://play.google.com/store/apps/details?id=pl.pkobp.iko
https://apps.apple.com/pl/app/iko/id597657968?l=plJak widać ten sam ui jest na Androidzie i na iOS i jest bardziej Androidowy, a nikt z użytkowników iPhone się specjalnie nie skarży. Możesz znaleźć takich przykładów więcej.
Ja nawet popieram pomysł, żeby był taki sam UI na każdym systemie mobilnym, tym bardziej, że apka pracuje na pełnym ekranie tak, jak lwia większość. Jakie to ma znaczenie, kto wyprodukował telefon lub kto napisał system operacyjny? Tym bardziej, że w biznesie większość apek pracuje w przeglądarce, więc siłą rzeczy będzie wyglądać i działać tak samo na każdym telefonie. Dla mnie to byłoby kompletnie bez sensu, że zmieniam telefon na innego producenta i nagle okazuje się, że inaczej robi się przelew w teoretycznie tej samej apce, od tego samego banku.
Gdyby się uprzeć, to da się zrobić dwie wersje apki webowej, wybierana na podstawie UserAgent, ale to jest podwójna robota i sens jest wątpliwy. Jednak kilkanaście lat temu byłem świadkiem takiego wymysłu, pamiętam, że to był Allegro.pl. Nie miałem telefonów, ale podmieniałem UserAgent w przeglądarce na komputerze na różne, charakterystyczne dla różnych telefonów i patrzyłem, co to zmienia. Wtedy RWD nie było popularne, tylko robiło się osobną wersję dla komputera i osobną dla telefonu, przy czym w tym wypadku były dwie wersje dla telefonu, jedna dla IPhone, druga na innego niż IPhone.
Jak komuś się nudzi, ma za dużo czasu wolnego, to niech się bawi, niech zrobi nawet 10 wersji dla poszczególnych modeli telefonów i dla poszczególnych systemów i przeglądarek na komputer, ale sens biznesowy jest bardzo wątpliwy i trudniej utrzymać taki projekt.
0
gajusz800 napisał(a):
Co do samego tematu wątku - nie, nie ma sensu. W ogóle jakiekolwiek poświęcenie czasu temu produktowi nie na sensu i jest to czas stracony.
Własnie sobie stukam edytor fontów do swojej gry — przyjemna robota. Tydzień roboty za mną, jeszcze kilka dni i będzie gotowy. Zostało mi oprogramować wypełnianie drzewka plików (po lewej), renderowanie gridu glifów (w środku) i podgląd tekstury atlasu (po prawej). Uwielbiam tracić czas na programowanie w Lazarusie, bo to takie niewygodne, czasochłonne, zabugowane, staroświeckie i w ogóle ani nie będzie działać, ani wyglądać. ;)
0
Ale to to twoja gra, a nie żaden poważny projekt. To tak, jakbyś napisał że bawisz się w piaskownicy i tak fajnie i przyjemnie tracić ci czas na stawianie babek w piaskownicy. To nic złego nawet, nie zaprzeczam że przyjemnie ci się pracuje. Co nie stoi w żadnej sprzeczności z tym co napisałem wcześniej. Do zabawy sobie samemu dla funu wystarczy i Lazarus
0
To jest poważny projekt — docelowo komercyjny.
Może kiedyś dorośniesz i w końcu zrozumiesz, że nie liczy się technolgia, a skill. Jak to mówią — dobry lotnik i na drzwiach od stodoły poleci. Gdybym nie był w 100% pewny, że Lazarus nadaje się do tego przedsięwzięcia, to wybrałbym Visual Studio Code i czyste C.
0
Pewnie Lazarus nadaje się do twojego projektu. Co nie znaczny, że planując swoją karierę warto wyspecjalizować się akurat w Lazarusie. Więc w zasadzie tak czy inaczej nauka Lazarusa to strata czasu.
0
Ten wątek nie dotyczy nauki i obierania ścieżki zawodowej, ani bycia wyspecjalizowanym w Lazarusie, a określenia czy ta technologia nadaje się do poważniejszych projektów, do których stworzenia jest przystosowana. I do tworzenia wszelkiej maści natywnych narzędzi i gier na pecety się nadaje, tak samo jak C/C++, bo ta sama półka.
1
Jeśli za miarę powagi projektu przyjąć końcową cenę produktu to tu masz przykład, że jak najbardziej można.