Hallo, ich habe schon mit mehreren Frameworks gearbeitet, von Qt zu GTK war eigentlich alles dabei. Ich muss aber zugeben, dass ich mich wieder dabei ertappe, Electron zu nehmen. Es geht einfach schneller, mit HTML da was zu machen, als mit Qt aufwändig was zu erstellen. Dazu kann man seine Anwendung dann auch noch mit CSS hübsch machen. Aber: Schon ein HelloWorld-Programm ist mit Electron 50MB groß und von der Performance her, ist ein Browser unter der Haube natürlich auch nicht das Gelbe vom Ei.. Wie handhabt ihr das?
Armer Student schrieb: > VisualStudio.NET Darauf würde ich nicht setzen, bzw die Finger lassen. QT oder wxWidgets sind einfacher und vielseitiger. Vor allem nicht auf die Firma Kleinstweich festgelegt.
Für nicht ressourcenkritische GUI-Anwendungen benutze ich Java, normalerweise mit Swing. Das braucht zwar auch ziemlich viel Speicher, aber deutlich unter 50 MB sollte es normalerweise bleiben.
Naja es kommt durchaus drauf an wie komplex die Applikation werden soll und ob sie plattformunabhängig sein soll. Ich habe zum Beispiel mal eine Applikation geschrieben (kleines Util um ein Gerät zu parametrieren, bedeutet ein paar Textfelder, Buttons und ein Dropdown Feld) nur mit der alten Windows API, die Applikation war selbst nur ein paar hundert KB groß und lief unter Windows ohne irgendwelche Frameworks oder Runtime Packages. Habe damals ein Tool gefunden, nannte sich VISG, damit konnte man GUIs in Visual Basic Manier zusammen klicken und das Tool spuckte dann ein Code-Grundgerüst für die GUI aus.
GUI schrieb: > Hallo, > ich habe schon mit mehreren Frameworks gearbeitet, von Qt zu GTK war > eigentlich alles dabei. Ich muss aber zugeben, dass ich mich wieder > dabei ertappe, Electron zu nehmen. Es geht einfach schneller, mit HTML > da was zu machen, als mit Qt aufwändig was zu erstellen. Dazu kann man > seine Anwendung dann auch noch mit CSS hübsch machen. Qt unterstützt auch CSS. Du kannst deine Widgets damit auch komplett umdesignen. Siehe https://doc.qt.io/Qt-5/stylesheet-syntax.html Oder alternativ kannst du bei Qt auch mit QML arbeiten, wenn's z.B. animiert und gut für touch geeignet sein soll. Die deklarative Sprache erfordert etwas umdenken, ist aber eigentlich sehr leicht zu erlernen, und man kann sich schnell was basteln.
Welches OS? Wenn Windows => pures WinAPI + ResEdit (Ich nutze Codeblocks). Super einfach und keine lib Abhängigkeiten und kleine Executables. Ansonsten .net bzw. Mono
GUI schrieb: > Aber: Schon ein > HelloWorld-Programm ist mit Electron 50MB groß und von der Performance > her, ist ein Browser unter der Haube natürlich auch nicht das Gelbe vom > Ei.. > > Wie handhabt ihr das? Einfach eine kleineres Toolkit nehmen. GUIs programmiere ich unter C/C++ eigentlich fast nur mit FLTK(2). Ein passender GUI-Builder ist auch bei FLTK mit dabei wenn man es Drag-and-Drop haben will. Aber ist die GUI-Entwicklung unter QT wirklich so zeitraubend oder aufwendig wie Du sagst? Will man fast gar nicht glauben.
Tonja S. schrieb: > Lazarus Pascal..kein Scherz..für GUI das schnellste und klein Genau und es läßt sich auch noch für die unterschiedlichsten Plattformen compilieren. Und auch wenn das einige nicht glauben: Das heute aktuelle Objektpascal hat mit der ursprünglichen Lernsprache nicht mehr viel zu tun.
René F. schrieb: > nannte sich VISG, damit konnte man GUIs in Visual Basic Manier zusammen > klicken und das Tool spuckte dann ein Code-Grundgerüst für die GUI aus. Das ist für uns PureBasic-ler und XProfan-er absoluter Standard! Und auch Tonja S. schrieb: > Lazarus Pascal sieht interessant aus Andreas B. schrieb: > und es läßt sich auch noch für die unterschiedlichsten Plattformen > compilieren. Sowie PureBasic auch! Gruss Chregu
Ich hab's neulich schon mal in einem anderen thread geschrieben: Für Windows-Anwendungen halte ich Visual Studio für die beste Wahl - bei trivialen Anwendungen, wie hier bereits genannt, direkt mit Win32 API, sonst mit den MFC. In beiden Fällen bleibt das EXE sehr klein; die MFC können statisch gelinkt werden, so dass keinerlei externe Abhängigkeiten von dlls entstehen. Ich mache das so, dass der eigentliche Arbeitscode in C++ plattformunabhängig erstellt wird, und das GUI dann eine Applikationsklasse, die den Rest nachzieht, instanziiert und dort Methodenaufrufe macht. Falls auch das GUI plattformunabhängig sein soll, ist das natürlich keine Lösung. Aber jedesmal, wenn hier nach GUI gefragt wird, vergessen die Fragesteller, ihre Anforderungen anzugeben: - Windows, Linux, MacOS, oder mehrere oder gar alles? - C++ oder eine andere Sprache? - trivial, einfach oder komplex? - Nur Text, 2D Grafik oder auch 3D benötigt? - ...
N ich denek eigentlich is alles klar.. plattformunabhängig meint Windows/linux, Mac wird wohl eher selten gefragtsein, aber wenn auch kein Dramam GUI, wird also wenn ++ gemeint seine etc.pp Aber völlig wurscht mit Lazarus ist alles abgedeckt:-) Ich hatte mir gerade PureBasic angesehen, scheint auch gar nicht schlecht zu sein, obwohl die Amazon Kritik von einem nicht wirklich so toll ist. Lazarus Freepascal scheint konsistenter zu sein, aber vermutlich ist das jammern auf hohem Niveau Icb in imer wider verwundert, weshalb solche wie PureBasic und Lazarus/Freepascal 1a Oberflächen gebacken bekommen und es in C nur Frickellösungen gibt, obwohl die C Community sicher um Größenordnungen größer ist
Armer Student schrieb: > VisualStudio.NET .Net braucht auch viel Ressourcen, dazu ist es im Vergleich zu einer nativen Exe schnarchlangsam, weil es erst zu Runtime kompiliert wird und alle nasenlang DLL's nachladen muß die zudem auch erst kompiliert werden müssen. Wenn man WPF nutzt um die GUI zu machen, dann gibt es keinen vernünftigen Designer der auch darstellt was man macht man muß es erst kompilieren. Für mich der entscheidente Nachteil : Auf dem Zielsystem muß das passende .NET Framework (oder auch mehrere) installiert sein, welche durchaus selbst mehrere 100MB groß ist. I.d.R. sind ist zwar auf den aktuellen Rechnern das .NET Framework installiert, aber wenn man in einem Projekt an einer einzigen Stelle was Aktuelleres benutzt, muß auf dem Zielsystem das passende Framework insralliert sein sein. Notfalls muß man es mit seinem Programm mitgeben und installieren. Empfinde ich als äußerst grottig. Nimm lieber wie schon mehrfach empfohlen Qt, tk oder eben eine zu Deiner gewünschten Programmiersprache passende IDE mit der man die GUI zusammen klicken kann. Für Java wäre noch Java Swing zu nennen.
Tonja S. schrieb: > Icb in imer wider verwundert, weshalb solche wie PureBasic und > Lazarus/Freepascal 1a Oberflächen gebacken bekommen und es in C nur > Frickellösungen gibt, obwohl die C Community sicher um Größenordnungen > größer ist Mit C/C++ werden halt auch viele Sachen gemacht die keine GUI benötigen, dementsprechend ist Interesse der Entwickler da was passables für die GUI-Entwicklung zu machen nicht so stark. Borland hatte mal mit seinem C++ Builder was gemacht, mit dem man seine GUI schnell machen konnte. Vom Bedienkomfort war das wie Delphi/Lazarus. Ich mache meine GUI-Programme meist mit Dephi 7 oder XE3, wobei mir das Handling von Delphi 7 besser gefällt, ist aber Ansichtskarte. Für die Firma muß ich mich leider mit .NET(C#) und WPF rumschlagen, weil man das eine Etage höher schick findet.
PureBasic habe ich rausgeschmissen, weil sich an vielen Executabels der MacAffee Virenscanner stört bzw verbeisst. Habe das dem Purebasic Team gemeldet, die haben aber keine Anstalten gemacht, dem Problem auf den Grund zu gehen bzw. was zu verbessern...
Peter S. schrieb: > Habe das dem Purebasic Team gemeldet, die haben aber keine Anstalten > gemacht, dem Problem auf den Grund zu gehen bzw. was zu verbessern... Können die doch auch gar nicht. Wenn der MacAffee Virenscanner kaputt ist, dann musst du das den MacAffee Entwicklern sagen ;-)
Peter S. schrieb: > PureBasic habe ich rausgeschmissen, weil sich an vielen Executabels der > MacAffee Virenscanner stört bzw verbeisst. Also ich bin ja kein PureBasic Fan, aber eine SW rauswerfen weil sich da irgendein Virenscanner dran stört, finde ich schon etwas schräg.
Tonja S. schrieb: > PureBasic angesehen, scheint auch gar nicht schlecht zu sein, obwohl die > Amazon Kritik von einem nicht wirklich so toll ist Oh, interessant, hast du einen Link oder Zitat? Gruss Chregu
Demnach würde ich doch eher auf Lazarus FreePascal setzen abgesehen davon das es frei von jeglichen Lizenzen nutzbar und völlig kosten,os sit und mehr Bücher gibt und Tutorials(Alles zu Turbo Pascal 6 bzw 7 und Delphi) https://www.amazon.de/PureBasic-Professional-Edition-Programming-Language/dp/B000BI80DA/ref=sr_1_2?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=purebasic&qid=1560692047&s=gateway&sr=8-2 Pros: - Die mitgelieferten Bibliotheken ist gut dokumentiert. - Kompiliert in eine traditionelle Win32- oder Linux-Anwendung, die keine Laufzeitbibliotheken zur Ausführung benötigt - Direkter Zugriff auf die API des Betriebssystems möglich Cons: 1. Keine objektorientierte Programmierung möglich 2. Viele Bugs in den mitgelieferten Bbliotheken, die viele Workarounds benötigen 3. Das Versprechen, denselben Quelltext unter Linux kompilieren zu können, wird nicht eingehalten, da die Linux-Version einfach zu viele Fehler enthält, wodurch die Programmiersprache teilweise gänzlich unbrauchbar ist, da das Programm einfach nicht funktioniert. Zudem sind viele undurchdachte Eigenarten vorhanden. Unter anderem besonders nervig: 1. Um eine Unsigned-Word-Variable zu erhalten, muss man eine Variable vom Typ Unicode-Character "missbrauchen" und Unsigned-Long-Variablen sind nur durch umständliche Tricksereien vorhanden 2. Konsolen-Anwendungen für Linux sind nur bedingt POSIX-tauglich hinzubekommen. Das fängt bereits damit an, dass das Darstellen farbiger Texte sehr fehlerhaft (und damit gänzlich unbrauchbar) ist. 3. Die Bibliotheken verwenden teilweise ein (sinnfreies) proprietäres System, um Zeigervariablen für Fenster usw. zu verwalten. Wenn man zum Beispiel mit Hilfe der mitgelieferten Bibliotheken ein Fenster erstellt, erhält man nicht die übliche Zeigervariable ("hwnd"), sondern eine ID, mit der nur PureBasic etwas anzufangen weiß. Dies eschwert die sprachübergreifende Verwendung erheblich (So kann z.B. ein Fenster, welches von einer eingebundenen Bibliothek aus erstellt und dessen Zeiger an das eigene PureBasic-Programm zwecks Weiterverarbeitung übergeben wird, nur umständlich oder gar nicht über die Funktionen der mitgelieferten Bibliotheken angesprochen werden, da dieses Fenster ja nicht im internen System von PureBasic eingebunden ist und der Befehl fehlt, um dieses nachholen zu können.) 4. Die Bibliotheken sind vom Funktionsumfang stark eingeschränkt, so dass man mit direkten API-Zugriffen ergänzen muss, was die Portabilität gänzlich kaputt macht. Mit nur einmal programmieren und dann auf Windows und Linux kompilieren zu können, ist spätestens hier endgültig vorbei. 5. Arrays sind nur schwer nutzbar. Unter anderem fehlt hier die Möglichkeit, ein Array mit vorgegebenen Werten zu initialisieren, wie es in den meisten Programmiersprachen mit einem "meinArray[4] = [1,2,3,4]" möglich ist. Man muss zuerst das Array erstellen und nachträglich mittels FOR-Schleife befüllen. 6. UTF-8 wird unter Linux teilweise fehlerhaft verarbeitet (auch wenn man explizit angibt, dass diese Zeichenkodierung anzuwenden ist) - Ein No-Go 7. Die Bibliothek zum Wiedergeben von Sound spielt mache WAV-Dateien einfach nicht ab, obwohl die enthaltenen Audiodaten in einem Format vorliegen, das laut Dokumentation unterstützt wird. 8. Schlechte Unterstützung von gängigen Multimediaformaten, dafür jedoch beste Unterstützung für exotische FastTracker-Uraltformate, die schon lange niemand mehr verwendet. 9. In den Sprite-Bibliotheken, die für 2D-Spiele gedacht sind, wird z.B. die Transparenz auf manchen Systemen ignoriert. Solche Fehler macht es komplett Unbrauchbar, da außer Verzicht auf diese Bibliotheken keinerlei Chance besteht, dieses Problem zu umgehen. 10. Manche GetXXXX()-Befehle neigen dazu, sporadisch völligen Unsinn zurückzugeben, was die Fehleranfälligkeit erhöht (z.B. ein negativer Wert für die Spieldauer einer Musikdatei oder eine völlig falsche Mausposition) 11. Mache Befehle erwirken gar nichts. Wenn man z.B. die Hintergrundfarbe eines Fensters mittels SetWindowColor() festlegt, ändert sich die Farbe einfach nicht. Fazit: Die Fehler treten auch bei den mitgelieferten Beispiel-Quelltexten auf, so dass ich mir sicher bin, dass es nicht an mir liegt. Die Programmiersprache ist einfach nicht mehr das, was sie mal war. Dieser Ärger hat mich mal etwa 80 Euro gekostet (so viel kostet diese Programmiersprache). Damals funktiionierte sie noch gut und man hat ein lebenslanges Recht auf Updates. Aber die Zeiten haben sich halt geändert und selbst alte und bekannte Fehler werden nicht behoben. Ich habe inzwischen sämtliche Projekte auf andere Programmiersprachen migiriert, welche solche Fehler nicht haben, und den Schlussstrich gezogen, was PureBasic betrifft. Da unter PureBasic vieles nur noch halb funktioniert und dieser Zustand mit jeder Version verschlimmert wird, kann ich diese Programmiersprache nichtmal einem Anfänger empfehlen, da viel Frust vorprogrammiert ist, der nicht in den eigenen Programmierfähigkeiten geschuldet ist. Spätestens dann, wenn der Compiler völlig stillschweigend seinen Dienst verweigert. Da viele der mitgebrachten Bibliotheken mehr oder weniger kaputt sind, geht der Funktionsumfang kaum mehr über klassisches C hinaus. Damit ist der Vorteil, mit nur wenigen Befehlen vieles erreichen zu können, gänzlich dahin. Dann lieber mit C oder Java anfangen und die Finger von PureBasic lassen.
:
Bearbeitet durch User
Xojo. Aus dem gleichen Sourcecode aus der gleichen IDE auf Knopfdruck Compilate für Win, Mac, Linux (auch Raspi), iOS und demnächst auch Android. Was will man mehr?
Tonja S. schrieb: > Pros: ... > Cons: .... Ich gehe jetzt mal davon aus, daß Du hiermit PureBasic meinst.
" Ich gehe jetzt mal davon aus, daß Du hiermit PureBasic meinst." jepp, Lazarus hätte nur Pros :-) Lazarus Pascal ist einfach super
Wer hier ernsthaft noch MFC oder Windows API empfiehlt ist irgendwo im letzten Jahrhundert hängen geblieben und sollte besser niemanden mehr Tipps geben. Und diese Argumente, dass aber die Programme dadurch schön klein sind könnt ihr auch langsam mal stecken lassen. Heutzutage hat jedes Mittelklasse Handy einen Quadcore Prozessor und 2 GB und mehr RAM. Wer denkt er hat einmal was gelernt und braucht den Rest seines Lebens nichts neues mehr dazulernen ist bei der Softwareentwicklung fehl am Platze. Meiner Meinung nach hängt es sehr davon ab, was man vorhat. Kleine Programme kann man praktisch mit jedem GUI Toolkit programmieren. QT, GTK usw. Aber bitte nicht mit C++. Damit macht ihr euch das Leben unnötig schwer. Für große Programme mit sauberer Trennung zwischen GUI und Code würde ich für reine Windows Software C# und WPF empfehlen. MVVM ist schon eine feine Sache und man kann die GUI schön einfach stylen. Für platformunabhängige Programme empfehle ich C# und Avalonia.
Zeno schrieb: > Tonja S. schrieb: >> Icb in imer wider verwundert, weshalb solche wie PureBasic und >> Lazarus/Freepascal 1a Oberflächen gebacken bekommen und es in C nur >> Frickellösungen gibt, obwohl die C Community sicher um Größenordnungen >> größer ist > > Mit C/C++ werden halt auch viele Sachen gemacht die keine GUI benötigen, > dementsprechend ist Interesse der Entwickler da was passables für die > GUI-Entwicklung zu machen nicht so stark. Und wenn sie es dennoch machen, dann bekommen diese Frameworks eigene String-/Thread-/Network-/ec.-Klassen. Warum?
... schrieb: > Wer hier ernsthaft noch MFC oder Windows API empfiehlt ist irgendwo im > letzten Jahrhundert hängen geblieben und sollte besser niemanden mehr > Tipps geben. [...] > QT, GTK usw. Aber bitte nicht mit C++. Finde den Fehler!
... schrieb: > Wer hier ernsthaft noch MFC oder Windows API empfiehlt ist irgendwo im > letzten Jahrhundert hängen geblieben und sollte besser niemanden mehr > Tipps geben. Und diese Argumente, dass aber die Programme dadurch schön > klein sind könnt ihr auch langsam mal stecken lassen. Heutzutage hat > jedes Mittelklasse Handy einen Quadcore Prozessor und 2 GB und mehr RAM. Ich habe hier keine klare Empfehlung der Win API im Thread gesehen. Möchte aber ein bisschen hier gegenrudern. Genau diese Überzeugung, ist meines Erachtens der dümmste Fehler überhaupt. Natürlich sind heutige Systeme viel performanter als früher, das bedeutet nicht automatisch das man nun unperformante Software entwickeln muss. Wenn die GUI relativ anspruchslos ist, spricht überhaupt nichts dagegen die Win API noch zu verwenden, die Geschwindigkeit und der geringe Speicherbedarf sind unschlagbar.
Arbeitet hier eigentlich jemand in einem real existierenden industriellen Unternehmen in der Softwareentwicklung? Falls ja, womit arbeitet ihr? PureBasic? Wohl kaum. Freepascal? Vermutlich auch nicht. Lazarus wird es auch nicht sein. Qt? Glaube ich nicht. Es wird ganz einfach MS Visual Studio sein, je nachdem wie alt euer Projekt ist, mit MFC oder halt Windows Forms, wenn es schon auf #NET ist. Ich freue mich schon auf die empörten Experten, die ganz spezielle Dinge mit ganz, ganz speziellen Bibliotheken und IDEs entwickeln. In welcher Firma entwickelt ihr angeblich Windows-Applikationen mit einer anderen Umgebung als MS Visual Studio? Würde mich wirklich interessieren.
zitter_ned_aso schrieb: >> Mit C/C++ werden halt auch viele Sachen gemacht die keine GUI benötigen, >> dementsprechend ist Interesse der Entwickler da was passables für die >> GUI-Entwicklung zu machen nicht so stark. > > Und wenn sie es dennoch machen, dann bekommen diese Frameworks eigene > String-/Thread-/Network-/ec.-Klassen. Weil diese Frameworks einer Zeit entstammen, in der C++ sowas nicht mitgebracht hat bzw. auch auf Compilern verwendbar sein sollen, die noch einer solchen Zeit entstammen. Abgesehen davon finde ich sie oft angenehmer und einfacher zu verwenden als die Standard-Klassen. René F. schrieb: > Ich habe hier keine klare Empfehlung der Win API im Thread gesehen. Dann solltest du ihn nochmal lesen: Timmo H. schrieb: > Welches OS? Wenn Windows => pures WinAPI + ResEdit (Ich nutze > Codeblocks). marais schrieb: > Ich hab's neulich schon mal in einem anderen thread geschrieben: Für > Windows-Anwendungen halte ich Visual Studio für die beste Wahl - bei > trivialen Anwendungen, wie hier bereits genannt, direkt mit Win32 API, > sonst mit den MFC. > Möchte aber ein bisschen hier gegenrudern. Genau diese Überzeugung, ist > meines Erachtens der dümmste Fehler überhaupt. Natürlich sind heutige > Systeme viel performanter als früher, das bedeutet nicht automatisch das > man nun unperformante Software entwickeln muss. Es geht nicht darum, dass man unperformante Software schreiben soll, sondern darum, dass es Toolkits gibt, die einem das Leben einfacher machen, weil man nicht jedes Detail mehr zu Fuß machen muss. Die Performance kommt dann erst dadurch ins Spiel, dass diese Toolkits meist mehr oder weniger Performance kosten, was aber selbst auf einem Raspi meist keine große Rolle mehr spielt. Die Win32-API und MFC sind ursprünglich mal gemacht worden, um auch auf einem 386er mit 25 Mhz Takt und 2 MB RAM vernünftig benutzbar zu sein.
Frank E. schrieb: > Xojo. Gibt es da eine (für Privatanwender) kostenlose Variante? Mit welchen Programmiersprachen lässt sich das nutzen?
Wie ist eigentlich Lazarus im Vergleich zu einem aktuellen Delphi von Embarcadero? Ist Lazarus eher so ne Art Delphi 7 Klon und dort steckengeblieben oder ist das inzwischen was eigenes das mal ursprünglich zu Delphi-Uraltversion/TP kompatibel war bzw. zu diesen alten Versionen immer noch ist?
Bettlerwabwehr 2.0 schrieb: > Ist Lazarus eher so ne Art Delphi 7 Klon und dort steckengeblieben oder > ist das inzwischen was eigenes das mal ursprünglich zu > Delphi-Uraltversion/TP kompatibel war bzw. zu diesen alten Versionen > immer noch ist? Lazarus war mal wohl mal ein Delphi Klon, hat sich aber unabhängig davon weiterentwickelt. Sowohl die Entwicklung als auch die Community ist sehr aktiv.
Danke schonmal für eure Antworten. Lazarus werde ich mir auf jeden Fall mal angucken, das klingt ja schon ziemlich gut. Ich möchte bestenfalls plattformunabhängig entwickeln, da die meisten Windows benutzen, ich das Fenster aber soweit es iegend mögluch ist, meide.
... schrieb: > Für große Programme mit sauberer Trennung zwischen GUI und Code würde > ich für reine Windows Software C# und WPF empfehlen. MVVM ist schon eine > feine Sache und man kann die GUI schön einfach stylen. > Für platformunabhängige Programme empfehle ich C# und Avalonia. Aufgebläht und wenig performant. Ja die Rechner werden alle schneller und haben immer mehr Speicher, aber die bereitgestellte Performance wird durch diesen Kram wieder komplett aufgebraucht. Auch wenn sich das JIT Compiler nennt, kann das Ganze mit einer nativen Exe bei weitem nicht mithalten. Man schaue sich nur mal das neue Office an - schnarchlangsam.
Zeno schrieb: > ... schrieb: >> Für große Programme mit sauberer Trennung zwischen GUI und Code würde >> ich für reine Windows Software C# und WPF empfehlen. MVVM ist schon eine >> feine Sache und man kann die GUI schön einfach stylen. >> Für platformunabhängige Programme empfehle ich C# und Avalonia. > > Aufgebläht und wenig performant. Ja die Rechner werden alle schneller > und haben immer mehr Speicher, aber die bereitgestellte Performance wird > durch diesen Kram wieder komplett aufgebraucht. Gerade bei dem zitierten Beispiel mit C#/WPF ist die Aussage ein wenig absurd. Denn WPF benutzt zum Rendern kein langsames GDI (CPU Rendered) sondern Direct3D. So passiert es schnell, dass die umfangreiche UI in C ruckelt (gerade beim Vergrößern/Verkleinern des Fensters), während die C#/WPF Variante butterweich läuft. Gerade bei Multimedia-Applikationen wird es einiges an Aufwand kosten, eine ähnlich performante Oberfläche wie mit WPF zu implementieren. > Auch wenn sich das JIT > Compiler nennt, kann das Ganze mit einer nativen Exe bei weitem nicht > mithalten. Das hat überhaupt nichts mit JIT oder ahead-of-time Kompilierung zu tun. Ein C JIT Compiler kann dir genau den gleichen Maschinencode erzeugen, nur die Latenz des Übersetzungsvorgangs beim ersten Ausführen der entsprechenden Routine oder Startup macht den Unterschied aus. Das Problem ist, dass Sprachen die hauptsächlich auf JIT-Compiler setzen (wegen Ökosystemen wie JVM, CLI), Eigenschaften haben und auf Konzepte setzen, welche nicht performant sind (haben dafür aber andere Vorteile). Die "Referenz-Orgien" bei Java/C# verschlechtern beispielsweise die Speicherzugriffszeiten und produzieren mehr Cache-Misses, dafür ist das Programmieren angenehmer. Bei der UI-Entwicklung ist Performanz insofern nur wichtig, als dass es die UI-Reaktionszeit beeinflusst. Ist der Ablauf zäh und behindert den Nutzer, macht das die Benutzerfreundlichkeit kaputt und senkt die Akzeptanz des Benutzers gegenüber der Applikation. Ansonsten ist das Thema vernachlässigbar, denn Menschen sind ziemlich langsam. Viel wichtiger ist, dass die UI lesbar, intuitiv, übersichtlich ist und gut aussieht. Das Toolkit sollte man also danach auswählen, wie sehr mir das Toolkit beim Design und bei der Entwicklung hilft, die genannten Anforderungen umzusetzen. Der Workflow des Toolkits ist dabei auch sehr wichtig, denn je mehr Zeit ich bei der Umsetzung aufwenden muss, desto weniger Zeit habe ich, mich mit dem Design und meinem Bedienkonzept auseinander zusetzen. WPF ist dabei gut, WinAPI wohl eher weniger...
Ich freue mich wieder jemanden von Lazarus überzeugt zu haben. Ich sehe hier irgendwie fast nur Vorteile. Ich nutze das auch gewerblich für kleinere Aufgaben, und bin absolut zufrieden damit Die Einzige Alternative für daheim wäre MS Visual C++..und das ist eher oft keien Alternative. Alle anderen Systeme sind kostenpflichtig. Insbesondere die Lizenzpolitik von Lazarus FreePascal ist einfach nur vorbildlich. Man muss sich nicht lange einlesen unter welchen Bedingungen man es wozu nutzen darf. Man darf es einfach für alles ohne Einschränkungen nutzen..kosten.. Das wars. Einzig natürlich wenn man externe Libs benutzt sind natürlich die Bedingungen der Libs zu beachten, was aber logisch ist
:
Bearbeitet durch User
Tonja S. schrieb: > Man darf es einfach für alles ohne Einschränkungen nutzen..kosten.. > Das wars. > > Einzig natürlich wenn man externe Libs benutzt sind natürlich die > Bedingungen der Libs zu beachten, was aber logisch ist wixwid ähm wxWidgets auch.
Tonja S. schrieb: > Man darf es einfach für alles ohne Einschränkungen nutzen..kosten.. > Das wars. Gut, dann habe ich die Fragestellung nicht verstanden. Ich dachte, wir reden hier von professioneller Softwareentwicklung. Visual Studio Pro kostet natürlich Geld.
und was ist mit gcc etc? Da gibt es doch eine Lange Doku wann es wie unter welchen Umständen genutzt werden darf wann der Quellcode mitgeliefert werden oder ausgehändigt werden muss etc pp. Gibt es bei Lazarus / FreePascal alles nicht
Was hält dich davon ab Lazarus professionell zu nutzen? Wie gesagt, nutze ich es auch für meine Produkte und es gibt einige kommerzielle Produkte die mit Lazarus Freepascal erstellt sind.also alles gut;-) Und naürlich kostet Lazarus nichts auch wenn Du es professionell nutzt
:
Bearbeitet durch User
PCEngine schrieb: >> Auch wenn sich das JIT >> Compiler nennt, kann das Ganze mit einer nativen Exe bei weitem nicht >> mithalten. > > Das hat überhaupt nichts mit JIT oder ahead-of-time Kompilierung zu tun. > Ein C JIT Compiler kann dir genau den gleichen Maschinencode erzeugen, > nur die Latenz des Übersetzungsvorgangs beim ersten Ausführen der > entsprechenden Routine oder Startup macht den Unterschied aus ... Es ist langsam, weil es erst in lauffähigen Code übersetzt werden muß. Ich arbeite derzeit an einem Projekt mit, welches ein vorhandenes Programm (native Exe) auf Wunsch der Vorgesetzten in C#/WPF neu implementiert. Da beide Programme auch die gleichen Funktionen bereitstellen (sollten) kann man recht gut vergleichen und da schneidet die Neuimplementierung deutlich schlechter ab, obwohl sie derzeit nur 10% der Funktionalität abbildet. Zudem ist das neue Programm um ca. das 5-6 fache größer als das Alte. Gerade bei größeren Projekten ist es üblich die Funktionen auf mehrere Projekte, sprich DLL's, aufzuteilen. Diese werden zur Laufzeit erst dazu geladen und müssen dann natürlich auch erst einmal in lauffähigen Code übersetzt werden. Ob der Compiler den gleichen Code erzeugt oder nicht ist überhaupt nicht relevant. Entscheident für die Performance ist wann der Code erzeugt wird. Passier das erst zur Laufzeit, dann wird es halt langsam.
Meine letzten beiden Projekte mit (kleiner) GUI habe ich in Python mit Tkinter gebaut. Nicht unbedingt wunderschön, aber man kann damit halbwegs arbeiten. Gibt auch größere Projekte damit. Ansonsten habe ich auch GTK und Perl schon zusammen benutzt. Die Programmiersprache hat ihre Schwächen, aber die GTK-Bindings sind sehr angenehm zu benutzen - besser als das C-Interface. Da Tkinter zu Python gehört, zieht man sich keine zusätzlichen Abhängigkeiten ins Projekt rein und ist damit prinzipiell so plattformunabhängig wie mit normalem Python auch.
Zeno schrieb: > Armer Student schrieb: >> VisualStudio.NET > > .Net braucht auch viel Ressourcen, dazu ist es im Vergleich zu einer > nativen Exe schnarchlangsam, weil es erst zu Runtime kompiliert wird und > alle nasenlang DLL's nachladen muß die zudem auch erst kompiliert werden > müssen. Langsam? Wenn der Rechner nicht gerade aus dem letzten Jahrzehnt stammt, eigentlich nicht. > Wenn man WPF nutzt um die GUI zu machen, dann gibt es keinen > vernünftigen Designer der auch darstellt was man macht man muß es erst > kompilieren. Programm debuggen und dann die Sachen ändern ;) Ansonsten gibt's auch noch Blend for Visual Studio... > Für mich der entscheidente Nachteil : Auf dem Zielsystem muß das > passende .NET Framework (oder auch mehrere) installiert sein, welche > durchaus selbst mehrere 100MB groß ist. I.d.R. sind ist zwar auf den > aktuellen Rechnern das .NET Framework installiert, aber wenn man in > einem Projekt an einer einzigen Stelle was Aktuelleres benutzt, muß auf > dem Zielsystem das passende Framework insralliert sein sein. Notfalls > muß man es mit seinem Programm mitgeben und installieren. Empfinde ich > als äußerst grottig. Wo ist das nicht der Fall? Entweder es wird vorher das/die minimale Framework/Version festgelegt oder die Zielrechner brauchen die entsprechenden Frameworks, Libs/DLLs... Oder .Net Core nehmen, da lassen sich auch Anwendung + nötiges Zeug zusammenpacken und verteilen unabhängig davon, ob das auf den Zielsystemen vorhanden ist oder nicht. Komplett plattformunabhängig wird's, wenn statt WPF bspw. das schon erwähnte AvaloniaUI mit .Net Core genutzt wird. > Nimm lieber wie schon mehrfach empfohlen Qt, tk oder eben eine zu Deiner > gewünschten Programmiersprache passende IDE mit der man die GUI zusammen > klicken kann. Für Java wäre noch Java Swing zu nennen. Wer gerne Html + CSS mit C/C++ oder Go, C#, Rust oder Delphi nutzen will, kann sich auch mal Sciter ansehen (https://sciter.com/). Plattformunabhängig (Linux, Mac, Win), Quelltexte und statisches Linken gibt's allerdings nur gegen Geld
marais schrieb: > Gut, dann habe ich die Fragestellung nicht verstanden. Ich dachte, wir > reden hier von professioneller Softwareentwicklung. Visual Studio Pro > kostet natürlich Geld. Ja, toll. Jetzt mußt Du uns nur noch erzählen, was denn jetzt der Vorteil von Visual Studio gegenüber Lazarus ist. Und bitte nicht die alte Leier: Kost nix, taugt nix. Arc N. schrieb: > Wo ist das nicht der Fall? Entweder es wird vorher das/die minimale > Framework/Version festgelegt oder die Zielrechner brauchen die > entsprechenden Frameworks, Libs/DLLs... Bei Lazarus werden alle benötigten libs in die .exe mit eingebunden. Sprich: Kopieren und läuft. Und benötigt dabei noch gar nicht mal so viel Speicher (jedenfalls wenn die Debug Infos nicht mehr in der .exe sind). z.B. eine Anwendung mit ca. 10 verschiedenen Fenstern kommt auf etwas mehr als 3MB.
Zeno schrieb: > Ob der Compiler den gleichen Code erzeugt oder nicht ist überhaupt nicht > relevant. Entscheident für die Performance ist wann der Code erzeugt > wird. Passier das erst zur Laufzeit, dann wird es halt langsam. Du weißt aber schon, dass man die auch vorkompilieren kann? Siehe NGEN. Damit entfällt der JIT komplett.
S. R. schrieb: > Ansonsten habe ich auch GTK und Perl schon zusammen benutzt. Die > Programmiersprache hat ihre Schwächen, aber die GTK-Bindings sind sehr > angenehm zu benutzen - besser als das C-Interface. Ja kann ich bestätigen, Perl + Gtk habe ich auch eine Zeit lang verwendet. Freepascal hat auch gtk2-Support, geht einwandfrei. Allerdings hat man unter Freepascal/Lazarus die FCL mit dem grafischen Editor, da will man nix anderes mehr. GUIs von Hand coden ist einfach lästig, das frisst Unmengen an Zeit, selbst mit so Misch-Lösungen wo man mit einem separaten GUI-Editor die GUI zusammenklöppelt (Glade für Gtk, unter Qt und JavaFX gibts auch sowas) und dann die XML oder was auch immer in seinem Source einbindet und von dort aus wieder anspricht und bei Änderungen ständig hin und her wechselt ist, fühlt sich das immer noch murksig an. GUI-Entwicklung wie unter Delphi (und alle die es von dort übernommen haben) ist da einfach DIE Referenz, weil man damit massiv Zeit spart. Von Hand ne GUI stricken dauert einfach viel zu lange, ein Layout will man grafisch machen, da sehe ich sofort ob es passt und nicht erst nach zig Compilerdurchlaufen oder Interpreterstart.
Zeno schrieb: > Ob der Compiler den gleichen Code erzeugt oder nicht ist überhaupt nicht > relevant. Entscheident für die Performance ist wann der Code erzeugt > wird. Passier das erst zur Laufzeit, dann wird es halt langsam. So pauschal ist das nicht richtig. Die Startzeit wird länger, die Geschwindigkeit zur Laufzeit hängt davon nicht ab. Und außerdem kann man ngen benutzen, damit das Programm nicht bei jedem Aufruf neu kompiliert werden muss. Oder in einigen Fällen auch .NET Native. Die Performance zur Laufzeit hängt von ganz anderen Faktoren ab. Wenn man z.B. häufig Reflection oder List<>.Contains() statt HashTable.ContainsKey() benutzt, sinkt die Performance. Aber solche Effekte hat man bei allen Programmierumgebungen und Libraries.
Wurstrakete schrieb: > Frank E. schrieb: >> Xojo. > > Gibt es da eine (für Privatanwender) kostenlose Variante? > Mit welchen Programmiersprachen lässt sich das nutzen? Xojo IST die Programmiersprache - erinnert ein wenig an eine Mischung aus Java und VisualBasic. Man kann die Software kostenlos zum Lernen nutzen, aber ohne Lizenz nicht für externe Computer compilieren, sondern nur aus der GUI heraus starten. Hier gibts noch einige Details in Deutsch dazu: https://www.jakoubek.net/xojo https://www.youtube.com/playlist?list=PLPoq910Q9jXiYHemQHGYv3CO7vQWYt7Gz
:
Bearbeitet durch User
Wurstrakete schrieb: > Du weißt aber schon, dass man die auch vorkompilieren kann? Siehe NGEN. > Damit entfällt der JIT komplett. Vorkompiliert ist auch nur halb gar.
Hallo, Bettlerwabwehr 2.0 schrieb: > Von Hand ne GUI stricken dauert einfach viel zu lange, ein Layout > will man grafisch machen, da sehe ich sofort ob es passt und nicht > erst nach zig Compilerdurchlaufen oder Interpreterstart. Dafür hat eine programmatisch erzeugte GUI eine höhere Wahrscheinlichkeit, mit unüblichen Auflösungen oder Fenstergrößen klarzukommen. Zumindest ist meine Erfahrung mit Delphi oder Visual Basic, dass man sehr schnell für die Bildschirmauflösung auf dem Entwicklungsrechner entwickelt und nicht für beliebige Auflösungen. Klaus P. schrieb: > So pauschal ist das nicht richtig. Die Startzeit wird länger, > die Geschwindigkeit zur Laufzeit hängt davon nicht ab. Ein JIT-Compiler produziert prinzipiell schlechteren Code als ein AOT-Compiler, weil Compiledauer und damit die maximale Optimierbarkeit beschränkt sind. Das betrifft auch AOT-Compiler für JIT-Sprachen, weil die nur den Compilevorgang vorziehen, aber nicht wesentlich anders optimieren. > Die Performance zur Laufzeit hängt von ganz anderen Faktoren ab. > Wenn man z.B. häufig Reflection oder List<>.Contains() statt > HashTable.ContainsKey() benutzt, sinkt die Performance. Logisch, wenn man einen langsamen oder schlecht skalierenden Algorithmus benutzt, wird das Programm langsamer. Das ändert aber nichts daran, dass man sich schon mit dem Öffnen des Programmierwerkzeugs für eine geringere Effizienz entschieden hat.
:
Bearbeitet durch User
S. R. schrieb: > Dafür hat eine programmatisch erzeugte GUI eine höhere > Wahrscheinlichkeit, mit unüblichen Auflösungen oder Fenstergrößen > klarzukommen. Zumindest ist meine Erfahrung mit Delphi oder Visual > Basic, dass man sehr schnell für die Bildschirmauflösung auf dem > Entwicklungsrechner entwickelt und nicht für beliebige Auflösungen. Da gebe ich Dir prinzipiell recht. Bei Delphi kann bei den Formularen das Scaling Property gesetzt werden, welches da etwas mehr Flexibilität rein bringen soll. Mich hat das nicht überzeugt, weshalb ich dieses Feature nicht benutze. Dann bleibt einem allerdings nichts anderes übrig als ein paar Kompromisse einzugehen. Man muß es halt für eine Auflösung optimieren. Bessere (höhere) Auflösungen schaden dann nicht. WPF z.B. versucht die GUI an die Auflösung anzupassen, indem es die Objekte entsprechend skaliert. Aber es skaliert eben auch um jeden Preis. Da gehen dann irgendwann die Beschriftungen über die Buttons hinaus oder Objekte die ursprünglich nebeneinander angeordnet waren, sind dann plötzlich untereinander. Wirklich schön ist das nicht wirklich. Letzendlich wird es keine optimale Lösung geben.
S. R. schrieb: > Dafür hat eine programmatisch erzeugte GUI eine höhere > Wahrscheinlichkeit, mit unüblichen Auflösungen oder Fenstergrößen > klarzukommen. Zumindest ist meine Erfahrung mit Delphi oder Visual > Basic, dass man sehr schnell für die Bildschirmauflösung auf dem > Entwicklungsrechner entwickelt und nicht für beliebige Auflösungen. Also gerade dieser Punkt ist bei den MFC mit den Ribbons sehr gut gelöst. Es gibt ein paar Punkte, an denen man aufpassen muss, aber insgesamt nimmt einem das System die meisten Probleme mit der Skalierbarkeit ab. Da gibt es zwei sets von icons für sehr hochauflösende und normale Monitore, falls man 4K voll ausreizen möchte. Mit WPF geht's inzwischen auch - für diejenigen von Euch, die schon im 21. Jahrhundert angekommen sind (wie ... treffend anmerkte). >Ja, toll. Jetzt mußt Du uns nur noch erzählen, was denn jetzt der >Vorteil von Visual Studio gegenüber Lazarus ist. >Und bitte nicht die alte Leier: Kost nix, taugt nix. Nein, das Problem ist Pascal. Delphi/Lazarus ist ein Pascal-Dialekt, während C++ eine standardisierte Sprache ist. Da finde ich sowohl Compiler-Alternativen als auch haufenweise Bibliotheken, und die Hochschulabsolventen beherrschen das auch alle. Für eine Software, die u.U. 20 Jahre läuft, ist das wichtig (Ich weiss schon, dass man Bibliotheken mit C-Binding mit Lazarus aufrufen kann). Nicht falsch verstehen: Ich habe auch mal mit Pascal angefangen, und finde die Sprache zum Lernen auch wirklich gut. Aber in Sachen Investitionssicherheit ist C++ einfach besser.
marais schrieb: n von Euch, die schon im > Nein, das Problem ist Pascal. Delphi/Lazarus ist ein Pascal-Dialekt, > während C++ eine standardisierte Sprache ist. Da finde ich sowohl > Compiler-Alternativen als auch haufenweise Bibliotheken, und die > Hochschulabsolventen beherrschen das auch alle. Für eine Software, die > u.U. 20 Jahre läuft, ist das wichtig (Ich weiss schon, dass man > Bibliotheken mit C-Binding mit Lazarus aufrufen kann). > > Nicht falsch verstehen: Ich habe auch mal mit Pascal angefangen, und > finde die Sprache zum Lernen auch wirklich gut. Aber in Sachen > Investitionssicherheit ist C++ einfach besser. Irgendwelche Hochschuldullis sollen C++ beherrschen können? Verzeihung, das kaufe ich dir nicht ab.
marais schrieb: > Nein, das Problem ist Pascal. Delphi/Lazarus ist ein Pascal-Dialekt, > während C++ eine standardisierte Sprache ist. Hää? Was soll der Käse. Für Pascal gibt sehr wohl Standards und wenn man selbige beachtet, dann kann man das Programm mit TP, BP, fpc, oder eben auch Delphi compilieren und es wird funktionieren. Und ja wenn ich z.B. TForm in meinem Programm benutze, kann ich es natürlich nicht mit TP/BP compilieren, weil beide selbiges Objekt nicht. Ist bei C/C++ nicht anders. Den Standard (Ansi C z.B.) unterstützen alle Compiler, aber es gibt durch aus Sachen die von Compiler zu Compiler unterschiedlich sind. marais schrieb: > Da finde ich sowohl > Compiler-Alternativen als auch haufenweise Bibliotheken Ein paar Compileralternativen nannte ich ja bereits. Bibliotheken gibt es für Pascal mehr als genug. marais schrieb: > Aber in Sachen > Investitionssicherheit ist C++ einfach besser. Na das begründe mal. Im Desktopbereich redet in unserer Firma niemand mehr von C/C++. Da ist das schon lange durch. Da setzt man seit mehreren Jahren auf C#/WPF. Ob ich das gut finde steht auf einem anderen Blatt.
marais schrieb: > Aber in Sachen > Investitionssicherheit ist C++ einfach besser. > während C++ eine standardisierte Sprache ist. Bei der GUI-Programmierung muss man sich sowieso festlegen. Wenn man auf QT setzt ist es auch vollends wurscht, ob man theoretisch den Compiler wechseln kann. > WPF > MSC Ob das noch 20 Jahre durchhaelt? Letztlich ist die GUI-Programmierung nicht so bestaendig wie das die zugrundeliegenden Programmiersprachen sind. Delphi/Lazarus gibts schon lange und wird es auch noch solange geben, wie es Desktopcomputer gibt (zumindest Lazarus). > während C++ Es wurde ja nicht nur Freepascal in den Ring geworfen, sondern auch noch Java, C#, Visualbasic usw. Alles Eintagsfliegen?
S. R. schrieb: > Zumindest ist meine Erfahrung mit Delphi oder Visual > Basic, dass man sehr schnell für die Bildschirmauflösung auf dem > Entwicklungsrechner entwickelt und nicht für beliebige Auflösungen. Lazarus hat Einstellungen um dies automatisch zu skalieren. Funktioniert prima. marais schrieb: > Nicht falsch verstehen: Ich habe auch mal mit Pascal angefangen, und > finde die Sprache zum Lernen auch wirklich gut. Aber in Sachen > Investitionssicherheit ist C++ einfach besser. Pascal ist älter als C++ und wird auch das noch überleben. Und wer nicht imstande ist eine Programmiersprache zu lernen, sollte eh nicht professionell programmieren. Und wie ich schon oben erwähnte, hat das heutige Objectpascal mit der Lernsprache Pascal, wie sie früher verwendet wurde, nicht mehr viel zu tun.
Moin-moin ! @Ulli Deine Frage nach professioneller/industrieller Programmierung mit GUI: Die Fa. "Fluke" ist für ihre Meßtechnik bekannt. Welches OS dort werkelt kann ich nur raten, doch die grafischen Oberflächen haben (alle) ein QT-Logo ... CNC-Steuerung "Sinumeric 840D" hat Windows als Oberfläche ... Die Werbesäulen in unseren Arcaden benutzen zwar Linux als Antrieb, welches Grafiksystem dort für "bunt" sorgt konnte ich leider nicht erkennen ... --- Ich mag ncurses ;-) --- Gruß aus Berlin Martin
Christian M. schrieb: > Sowie PureBasic auch! Leider nicht für ARM Linux, sprich Raspberry Pi. Freepascal mit Lazarus läuft auf dem Pi, und kann Crosscompile vom PC (Win oder Linux) zum Pi.
Tonja S. schrieb: > https://www.amazon.de/PureBasic-Professional-Edition-Programming-Language Oha, Du beziehst Dich jetzt aber nicht auf eine PureBasic-CD von vor 15 Jahren? Hol Dir das aktuelle PB von der Webseite, gibts als Testversion mit begrenzter Codegröße - die immer noch riesig ist. > 1. Keine objektorientierte Programmierung möglich Doch, wohl, geht irgendwie, hab ich aber nie gemacht. > 2. Viele Bugs in den mitgelieferten Bbliotheken, die viele Workarounds > benötigen Du redest aber nicht von einer einigermaßen aktuellen Version? > 3. Das Versprechen, denselben Quelltext unter Linux kompilieren zu > können, wird nicht eingehalten Doch, wohl, hol Dir eine aktuelle Version. > 1. Um eine Unsigned-Word-Variable zu erhalten, muss man eine Variable > vom Typ Unicode-Character "missbrauchen" und Unsigned-Long-Variablen > sind nur durch umständliche Tricksereien vorhanden Uninteressant, man verwende immer Integer (es sei denn man braucht Quad), weil der Compiler eh alle kleineren Variablen auf die Bitbreite des OS erweitert. Das ist bei FreePascal übrigens auch so. > 3. Die Bibliotheken verwenden teilweise ein (sinnfreies) proprietäres > System, um Zeigervariablen für Fenster usw. zu verwalten. Wenn man zum > Beispiel mit Hilfe der mitgelieferten Bibliotheken ein Fenster erstellt, > erhält man nicht die übliche Zeigervariable ("hwnd"), sondern eine ID, > mit der nur PureBasic etwas anzufangen weiß. Das wird gemacht, um Win / Linux kombatibel zu sein und berücksichtigt das unterschiedliche Fensterhandling von Win und Linux. > 4. Die Bibliotheken sind vom Funktionsumfang stark eingeschränkt, so > dass man mit direkten API-Zugriffen ergänzen muss, was die Portabilität > gänzlich kaputt macht. Mit nur einmal programmieren und dann auf Windows > und Linux kompilieren zu können, ist spätestens hier endgültig vorbei. Das ist leider so, ich hab mit viel Krampf API-Funktionen in PB nachgebaut, die in FreePascal einfach gehen. > 6. UTF-8 wird unter Linux teilweise fehlerhaft verarbeitet (auch wenn > man explizit angibt, dass diese Zeichenkodierung anzuwenden ist) - Ein > No-Go Uui, nenne mir eine Sprache, die UTF fehlerfrei und dann noch plattformübergreifend beherrscht. Das kann auch FreePascal nur mit Kopfständen. > 8. Schlechte Unterstützung von gängigen Multimediaformaten, dafür jedoch > beste Unterstützung für exotische FastTracker-Uraltformate, die schon > lange niemand mehr verwendet. Ja, leider, und da ändert sich schon seit Jahren nichts. > 11. Mache Befehle erwirken gar nichts. Wenn man z.B. die > Hintergrundfarbe eines Fensters mittels SetWindowColor() festlegt, > ändert sich die Farbe einfach nicht. Doch wohl, warum soll das nicht gehen? > Fazit: Man merkt PureBasic leider an, dass das quasi eine One-Man-Show ist. Zwar gibt es einige Leute, die sich um Übersetzung und Bugfixing kümmern, aber die Weiterentwicklung hängt halt an dem einen Franzosen. Und wenn der nicht mehr will, weil Familie oder ein anderes Projekt wichtiger sind... Da schneidet FreePascal als OpenSource-Projekt deutlich besser ab.
Karl K. schrieb: > aber die Weiterentwicklung hängt halt an dem einen Franzosen. Und wenn > der nicht mehr will, weil Familie oder ein anderes Projekt wichtiger > sind... Ja, aber ich habe ihm 79€ gegeben! Gruss Chregu
Christian M. schrieb: > Ja, aber ich habe ihm 79€ gegeben! Und hast dafür ein funktionierendes Programm erworben. Auch wenn PB Dich weiterhin mit Updates und zukünftigen Versionen versorgt, ein Anrecht darauf hast Du nicht. Wenn Frédéric morgen sagt: Keine Lust mehr, dann kannst Du nur hoffen, dass er den Quellcode rausrückt und OpenSource macht und dass sich genug andere finden, die PB dann weiterpflegen. Ich finde die Updatepolitik von PB für ClosedSource schon fortschrittlich, bei anderen bist Du drauf angewiesen, jedesmal eine neue Version oder ein Upgrade zu kaufen. Bei FreePascal als OpenSource sieht das halt komplett anders aus. Dennoch kannst Du da nicht verlangen, dass bestimmte von Dir gewünschte Features eingebaut werden. Aber Du kannst sie selbst reinprogrammieren. Allerdings ist FreePascal echt flott in der Fehlerbehebung. Meine Bugreports zum AVR wurden immer innerhalb weniger Stunden umgesetzt, das ist schon beeindruckend.
>Peter S. schrieb: >> PureBasic habe ich rausgeschmissen, weil sich an vielen Executabels der >> MacAffee Virenscanner stört bzw verbeisst. > >Also ich bin ja kein PureBasic Fan, aber eine SW rauswerfen weil sich da >irgendein Virenscanner dran stört, finde ich schon etwas schräg. Und ich bin kein MacAffee Fan! Trotzdem kann ich den Benutzern meiner Programme nicht vorschreiben, welche VirenScanner sie benützen sollen, insbesondere wenn dieser bei vielen Firmen von der IT und festgelegt wird, bzw. der Angestellte diesbezüglich keine Wahl hat.
:
Bearbeitet durch User
Jepp, man merkt die Freepascal /LAzarus Leute haben echt Spaß an dem Projekt, auch im Forum merkt man das. Da gibt es keine Streitereien, JEDEM wird geholfen und nie kommen Antworten wie nutz doch Google, sondern es wird immer ausführlich und erschöpfend geantwortet oft sogar gleich fertige Codebeispiele angehängt die 1zu 1 verwendet werden können, kein "Lies es dir selber an" oder "finde es doch selber raus" etc. Wie gesagt, die Leute haben dort richtig Spaß am Arbeiten mit Pascal, niemand ist sich da zu schade, schnell Codeschnipsel zu schreiben. Wirklich vorbildlich
Für kleine Tools bzw. Programme liebe ich immer noch mein XProfan. Ist zwar ein Bytecode-Compiler, der eine Runtime mit einbindet, braucht aber sonst keine Abhängigkeiten wie DLLs usw. Und ist auch leicht zu erlernen. Ein Hello World Programm hat ca. 1,6 MB, was aber heutzutage kein Problem mehr ist (früher mit Disketten). CLS [RGB(r, g, b)] ' mit RGB, wenn es bunt sein soll PRINT "HELLO WORLD !" WAITKEY END
hier ein schönes Beispiel für die Hilfsbereitschaft Der Pascal/Lazarus Benutzer...wäre toll wenn das hier in diesem Forum auch nur im Ansatz so sein könnte https://www.coding-board.de/threads/laufschrift-in-pascal.33779/
Martin Beuttenmüller schrieb: > CNC-Steuerung "Sinumeric 840D" hat Windows als Oberfläche ... Aktuelle Sinumerik 840D sl nutzt Linux als betriebsystem.
Andreas B. schrieb: > Bettlerwabwehr 2.0 schrieb: > > Lazarus war mal wohl mal ein Delphi Klon, hat sich aber unabhängig davon > weiterentwickelt. > Sowohl die Entwicklung als auch die Community ist sehr aktiv. Stimmt teilweise. Ich verwende Lazarus privat, da ich noch eine sehr breite Code-Basis von Delphi5 habe/hatte. Plattform Win, Linux x86, Raspberry. Vorteil: GUI-Erstellung ist sehr komfortabel, gleichzeitig hat man eine sehr mächtige Programmiersprache drunter. Freepascal ist auch nicht mehr das Pascal, an das sich viele noch aus Schulzeiten erinnern. Über Nachteile bin ich aber mittlerweile auch schon gestolpert: Die GUI-Komponenten sind bei weitem nicht so flexibel wie sie es noch bei Delphi5 waren. Manches mag der Portierbarkeit geschuldet sein. Manches wie z.B. Transparenz ist einfach nur kaputt. Viel schlimmer finde ich aber die Header und die völlige Starre der "Entwickler", da mal nachzuarbeiten. In den Headern sind i.d.R. alle per Zeiger übergebenen Parameter stur mit var definiert. Ist in der Praxis maximal dämlich. Schreiben auf serielle Schnittstelle oder Socket braucht keinen VAR-Parameter für die zu schreibenden Daten sondern ein const. Da muß man teilweise ziemlich tricksen. FillByte hingegen (Pendant zu memset) mosert beim Kompilieren immer, daß der übergebene Parameter nicht initialisiert ist (Hund->Schwanz) - da wäre OUT die passende Übergabe gewesen. Und damit zum größten Murks dieser "Open-Source"-Software: Selbst ändern und pushen ist nicht. Nur Ticket schreiben. Bei den socket-Headern habe ich das vor 1 Jahr gemacht. Seitdem gibt es ein Ticket ... Teilweise sind auch die Header zwischen den Plattformen inkonsistent (z.B. var vs Pointer). Egal. Dafür hat man sehr sehr viel Muse in der Mailing-List für irgendwelchen Javascript-Kram...
LazarusUser schrieb: > Und damit zum größten Murks dieser "Open-Source"-Software: Selbst ändern > und pushen ist nicht. Nur Ticket schreiben. Das ist ja wohl bei allen OSS Projekten der Fall wo man nicht selber der Maintainer ist. In der Praxis schreibst Du den Bugfix oder das Feature und parallel dazu machst Du ein Ticket auf (falls noch kein Ticket zu dem Thema existiert) und lieferst das diff. Einer der Zuständigen wirds kritisieren oder mergen. Bei absolut trivialem Zeug kann man auch mal ein kleines diff unbürokratisch auf der Mailingliste zur Diskussion stellen und wenns offensichtlich ist wirds einer mergen ohne großes Aufheben drum zu machen.
LazarusUser schrieb: > Viel schlimmer finde ich aber die Header und die völlige Starre der > "Entwickler", da mal nachzuarbeiten. Wenn da keiner was machen will, dann forke es doch einfach, und übernimm es selbst. Dann kannst du es besser machen.
LazarusUser schrieb: > Und damit zum größten Murks dieser "Open-Source"-Software: Selbst ändern > und pushen ist nicht. Nur Ticket schreiben. Bei den socket-Headern habe > ich das vor 1 Jahr gemacht. Ich hab da schon Bugreports für AVR embedded geschrieben, die waren innerhalb von 3 Stunden bearbeitet.
Am einfachsten ist und bleibt Tcl/Tk. Alles, was man braucht, sind ein Editor und ein "Tclkit", das ist eine One-file-distro von Tcl(Tk) - mehr als einige Megabyte muss ein Tclkit nicht groß sein, aber es gibt auch sehr grosse mit hunderten von integrierten Bibliotheken. Immer noch alles in einer Datei (.exe), versteht sich. Zudem kann man sein Skript ganz einfach zu einer .EXE einpacken (ein "Starpack"). Über die meisten Beispiele für GUIs in anderen Sprachen lache ich mich kaputt: 99% Metainformationen und drumherum, 50 Zeilen für HelloWorld (oder 1 Terabyte große IDEs). Zugegeben, visuelle Designer für Tcl/Tk sind alle völlig out-of-date, doch nach kurzer Einarbeitung erkennt man, das man die eigentlich auch gar nicht benötigt....
Ulli schrieb: > Arbeitet hier eigentlich jemand in einem real existierenden > industriellen Unternehmen in der Softwareentwicklung? > Falls ja, womit arbeitet ihr? PureBasic? Wohl kaum. Freepascal? > Vermutlich auch nicht. Lazarus wird es auch nicht sein. Qt? Glaube ich > nicht. Wie schreiben komplexe Steuerungssoftware. Sprachen sind C++, Python, Java, je nach Anwendungsfall. GUIs in Qt üblicherweise via Python. Spezielle Sachen/Widgets evtl. in C++ und dann mit generierten bindings in Python eingebunden.
Das Problem bei QT ist leider immer die Lizenz. Veröffentlicht ihr euren Code? Ich weiß, dass vieles unter die LGPL fällt, aber viele wichtige Sachen eben nicht, insbesondere im Plotting Bereich. Da ist alles GPL. Habt ihr eine commercial Lizenz?
Open Source heisst nicht, daß man die Software außer Haus geben muß. Für den Eigenbedarf ist die GPL immer vollumfänglich erfüllt. Oliver
Tonja S. schrieb: > Icb in imer wider verwundert, weshalb solche wie PureBasic und > Lazarus/Freepascal 1a Oberflächen gebacken bekommen und es in C nur > Frickellösungen gibt, obwohl die C Community sicher um Größenordnungen > größer ist bei C würde sich GTK+ anbieten ... da lernen nicht jedermann's Sache ist, gilt das natürlich als Frickellösung ;-)
Oliver S. schrieb: > Open Source heisst nicht, daß man die Software außer Haus geben muß. Und wenn einer das Programm weitergibt? Kann ihm die Firma was vorwerfen / ihn dafür bestraffen? Das interne Knowhow wird einfach rausgeschmuggelt. Und dann? Kann ich dann zu der Firma gehen und (falls mir ein paar Dateien fehlen) restlichen Quellcode verlangen? ;-)
interessant schrieb: > Und wenn einer das Programm weitergibt? Kann ihm die Firma was vorwerfen > / ihn dafür bestraffen? das ist dann eine juristische Frage bzw. abhängig von den Vereinbarungen der OpenSource Software, denen die Firma dann ja durch den Einsatz der Software zustimmt. > Das interne Knowhow wird einfach rausgeschmuggelt. Und dann? Kann ich > dann zu der Firma gehen und (falls mir ein paar Dateien fehlen) > restlichen Quellcode verlangen? ;-) Firmen setzen in der Regel keine OpenSource Software ein, weil für die Geld keine Rolle spielt, Support dagegen schon und im Falle von GNU die rechtlichen Bedingungen inakzeptabel sind. Also eine sehr konstruierte Fragestellung.
ohne Account schrieb: > Firmen setzen in der Regel keine OpenSource Software ein Was du nicht alles weisst... Oliver
ohne Account schrieb: > Firmen setzen in der Regel keine OpenSource Software ein, weil für die > Geld keine Rolle spielt, Hmm, interessante Firma für die Du arbeitest. Gilt das auch für Dein Gehalt?
Andreas B. schrieb: > Hmm, interessante Firma für die Du arbeitest. Gilt das auch für Dein > Gehalt? Die Frage müßte eher umgekehrt lauten - in welcher Klitschen-Firma arbeitest Du denn ??? Fast jede Firma benutzt Microsoft und die übliche Software. Open Source, GNU, Linux, usw. ist was für Frickler und Privatleute, die kein Geld haben oder ausgeben wollen (was privat vernünftig ist und als Firma nicht). Selbst privat wird Microsoft und Co. für Geld gekauft ... also bitte ):
>> Das interne Knowhow wird einfach rausgeschmuggelt. Und dann? Kann ich >> dann zu der Firma gehen und (falls mir ein paar Dateien fehlen) >> restlichen Quellcode verlangen? ;-) ganz ehrlich, wenn eine Firma lizenzfreie Software einsetzt oder auch GNU, die ausdrücklich die Weitergabe vorsieht ... dann sollte sich der Firmengründer vielleicht etwas mehr mit Wirtschaft beschäftigen ): Privat ist das was anderes, aber Du redest hier von einer Firma.
ohne Account schrieb: > Firmengründer vielleicht etwas mehr mit Wirtschaft beschäftigen Vielleicht solltest du das Brett vor deinem Kopf entfernen
Jan K. schrieb: > Das Problem bei QT ist leider immer die Lizenz. Irgendwie habe ich damit äußerst selten ein Problem. > Veröffentlicht ihr euren Code? Ich weiß, dass vieles unter die LGPL fällt, > aber viele wichtige Sachen eben nicht, insbesondere im Plotting Bereich. Da > ist alles GPL. Dann nimm doch einfach Qwt. > Habt ihr eine commercial Lizenz? Also ich nicht. Die kostet mehrere Tausend Euro pro Jahr. interessant schrieb: > Oliver S. schrieb: >> Open Source heisst nicht, daß man die Software außer Haus geben muß. > > Und wenn einer das Programm weitergibt? Kann ihm die Firma was vorwerfen > / ihn dafür bestraffen? Wie wäre es es denn, wenn er den Lizenzschlüssel einer gekauften Software weitergibt? > Das interne Knowhow wird einfach rausgeschmuggelt. Und dann? Es ist anzunehmen, dass der Mitarbeiter mit seinem Arbeitsvertrag auch eine Geheimhaltungserklärung unterschrieben hat. Ein Verstoß dagegen wäre schätzungsweise ein Kündigungsgrund. > Kann ich dann zu der Firma gehen und (falls mir ein paar Dateien fehlen) > restlichen Quellcode verlangen? ;-) Wenn die Firma es nicht offiziell veröffentlicht hat, sondern es auf illegalem Weg an die Öffentlichkeit gekommen ist, eher nicht. Ich denke, da werden die da eher auf dich zukommen mit der Frage, wie du da eigentlich dran gekommen bist. ohne Account schrieb: > Fast jede Firma benutzt Microsoft und die übliche Software. > Open Source, GNU, Linux, usw. ist was für Frickler und Privatleute, die > kein Geld haben oder ausgeben wollen (was privat vernünftig ist und als > Firma nicht). Ziemlich realtiätsfern. Firmen nutzen Linux nicht aus Kostengründen, sondern weil es Dinge bietet, die man anders so nicht oder nur deutlich schwerer bekommt. > Selbst privat wird Microsoft und Co. für Geld gekauft ... also bitte ): Derweil bei Microsoft: https://build5nines.com/linux-is-most-used-os-in-microsoft-azure-over-50-percent-fo-vm-cores/
"Ohne Account" hat einfach überhaupt gar keine Ahnung, wie viel Open Source auch in kommerzieller Software eingesetzt wird... Die Lizenz sagt erstmal nichts über die Leistungsfähigkeit eines Programmes oder einer Lib aus. @Ohne Account, du benutzt kein Linux? Kein Git? Kein Visual Studio Code? Kein Kubernetes? Kein AI (tensor flow et al)? Kein Python? Uuuuund so weiter. Rolf M. schrieb: > Also ich nicht. Die kostet mehrere Tausend Euro pro Jahr. Eben ;) Rolf M. schrieb: > Irgendwie habe ich damit äußerst selten ein Problem. Für privat oder die Firma? Das Problem ist einfach bei GPL, dass man jegliche Sourcen, die Qt Module, die GPL lizensiert sind auch zur Verfügung stellen muss, wenn die App verteilt wird. In meinem konkreten Fall ist das z.B. eine Qt-3D Anwendung, die zwar in Python geschrieben wurde, aber eben (kleine) Teile von Qt 3d verwendet, die GPL sind. Ich kann die App aber nicht zum DL bereitstellen obwohl sie für viele Kunden interssant wäre (ist von der Firma), da sie auch proprietäre Anteile enthält, die man, da sie zur selben Applikation gehören nicht auslagern darf. Also bleibt sie intern. Denn die vielen tausend $$$ für eine kleine Applikation lohnen dann eben doch nicht. Rolf M. schrieb: > Dann nimm doch einfach Qwt. Das ist ein sinnvoller Tipp, danke! Momentan spiele ich mit http://www.pyqtgraph.org/ rum, scheint auch sehr mächtig zu sein.
Jan K. schrieb: > "Ohne Account" hat einfach überhaupt gar keine Ahnung, wie viel Open > Source auch in kommerzieller Software eingesetzt wird... ach ja, wie denn? Erzähle mal und wieso dann das hier: interessant schrieb: > Oliver S. schrieb: >> Open Source heisst nicht, daß man die Software außer Haus geben muß. > > Und wenn einer das Programm weitergibt? Kann ihm die Firma was vorwerfen > / ihn dafür bestraffen? > > Das interne Knowhow wird einfach rausgeschmuggelt. Und dann? Den Open Source Part kannst Du immer weiterreichen. Lediglich die firmen-interne Geheimnisklausel wird daran vielleicht hindern - aber ansonsten ist es bei open source sogar vorgesehen. Jan K. schrieb: > @Ohne Account, du benutzt kein Linux? Kein Git? Kein Visual Studio Code? > Kein Kubernetes? Kein AI (tensor flow et al)? Kein Python? Uuuuund so > weiter. privat schon, aber was die Firma macht ist deren Ding. Jan K. schrieb: > Rolf M. schrieb: >> Also ich nicht. Die kostet mehrere Tausend Euro pro Jahr. > > Eben ;) warum kosten die wohl mehrere Tausend Euro pro Jahr? Alles hat seinen Sinn ... das kann dann als Firma auch Sparen am falschen Ende sein :-) Jan K. schrieb: > Ich kann die App aber nicht zum DL bereitstellen obwohl > sie für viele Kunden interssant wäre (ist von der Firma), da sie auch > proprietäre Anteile enthält, die man, da sie zur selben Applikation > gehören nicht auslagern darf. haha, dann macht man copy&paste ohne die proprietären Anteile oder modded diese Anteile etwas und schon kann man sie raushauen. Und genau da greift ja auch der obige berechtigte Einwand! Natürlich kann Dir immer noch die Geheimnisklausel um die Ohren fliegen und deswegen die Kündigung, etc. drohen - aber ansonsten droht Dir rechtlich weitaus weniger als bei lizensierter Software ... da würde es dann richtig teuer. Den Quellcode dieser Software bekommst Du anders bei open Source auch gar nicht zu Gesicht - d.h. wenn kommerzielle Software möglicherweise open Source Fragmente benutzt, braucht Dich das nicht bei Deinem Programm zu interessieren und Du wirst den Sourcecode der kommerziellen Software auch niemals sehen, wenn Du nicht gerade für diese Firma arbeitest. Genau deshalb und wegen des Supports kostet das mehrere Tausend Euro pro Jahr - und für eine große Firma ist kommerzielle Software überhaupt kein Thema, sondern eine zusätzliche Sicherheit , außer bei einer Klitschenfirma. Die kann dann noch auf Ihre Geheimnisklausel pochen und hoffen.
Beitrag #6387860 wurde von einem Moderator gelöscht.
Hallo. Hab lange Weile und habe schon seit längeren die Idee mit Java ein kleines Tool zu entwickeln. Hab aber noch nie was programmiert außer 1000 IF und Else-Scripte mit einem Maus/Tastatur-Automations-tool, was auch echt bock macht. Das Tool was ich aber erstellen möchte soll ein kleines Fensterchen mit einem einzeiligen Textfeld für ca 10 Ziffern, die automatisch aus der Zwischenablage dort eingefügt werden, nachdem man das Fenster mit einem shortcut aufgerufen hat. Unter und über jeder Ziffer sind Pfeil-knöpfe um die Werte in 1er-schritten zu ändern. Bei Klick auf übernehmen, soll dieser wert der Zahlenreihe in das eingabefeld eines anderen Programms (Bitwig Studio) eingefügt werden, wobei dieses Eingabefeld in Bitwig auch erst geöffnet werden muss, und mit "Enter" dann geschlossen. Meine Frage ist jetzt ob jemand ein Tip für ein Entwicklungstool hat was nicht unbedingt Kenntnisse von Programmiersprache vorraussetzen muss. Also er ein tool mit vorgefertigten Ansteuerungen zum wählen von Elementen und zum ändern derer Eigenschaften wie Farbe, Größe oder Platzierung.
:
Bearbeitet durch User
Mit Verlaub, aber dann wird es langsam Zeit eine Programmiersprache zu lernen.
Danke, ich denke ich verstehe dich :). Ich habe zwar schon in Java-tutorials auf youtube reingeschaut, aber irgendwie erklären die das da nur anhand von Zahlen. Also keine Beispiele was man denn nach diesem erklärten Prinzipien so als Grafik erreichen kann. Das wirkt auf mich echt motivationshemmend.
Maik N. schrieb: > Meine Frage ist jetzt ob jemand ein Tip für ein Entwicklungstool hat was > nicht unbedingt Kenntnisse von Programmiersprache vorraussetzen muss. > Also er ein tool mit vorgefertigten Ansteuerungen zum wählen von > Elementen und zum ändern derer Eigenschaften wie Farbe, Größe oder > Platzierung. Für Windows: AutoIt Allerdings wirst du so oder so die Skriptsprache lernen müssen
Maik N. schrieb: > Danke, ich denke ich verstehe dich :). > > Ich habe zwar schon in Java-tutorials auf youtube reingeschaut, aber > irgendwie erklären die das da nur anhand von Zahlen. Also keine > Beispiele was man denn nach diesem erklärten Prinzipien so als Grafik > erreichen kann. Das wirkt auf mich echt motivationshemmend. Du musst Java Tutorials zu z.B. SWING anschauen. Da erfährst du wie man GUIs baut.
Ich muss sagen Qt+Qt DesignStudio+Photoshop und Qml kriegt man schnell sein Mockup fertig. Ich finde die Trennung zwischen HMI und Backend sogar noch eine Nummer besser/einfacher als mit WPF und MVVM Pattern.
Kommt darauf an, was für eine Anwendung man schreiben möchte. Aber ich bin mit den Preis/Leistungsverhältnis von FreePascal/Lazarus mehr als zufrieden.
Rotsch schrieb: > bin mit den Preis/Leistungsverhältnis von FreePascal/Lazarus mehr als > zufrieden. Da Preis = 0 ist das Preis/Leistungsverhältnis demnach unendlich. Ich finde FreePascal/Lazarus ja auch super aber man muß es ja nicht gleich so übertreiben. ;-)
Rotsch schrieb: > Kommt darauf an, was für eine Anwendung man schreiben möchte. Aber ich > bin mit den Preis/Leistungsverhältnis von FreePascal/Lazarus mehr als > zufrieden. Ne sorry, wer heute noch Pascal empfiehlt den kann man auch sonst für nicht ganz zurechnungsfähig halten. Du stehst hoffentlich unter Betreuung!?
:
Bearbeitet durch User
Ich glaube, alle momentanen Frameworks, um GUIs zu erstellen, sind scheisse, wenn auch aus unterschiedlichen gründen. GTK und QT sind immerhin aber nicht unbedingt die unvorteilhaftesten Frameworks.
Cyblord -. schrieb: > Ne sorry, wer heute noch Pascal empfiehlt den kann man auch sonst für > nicht ganz zurechnungsfähig halten. Du stehst hoffentlich unter > Betreuung!? Wieder mal schwafeln ohne zu wissen wovon.
Andreas B. schrieb: > Ich finde FreePascal/Lazarus ja auch super Empfinde ich auch so! Cyblord -. schrieb: > Ne sorry, wer heute noch Pascal empfiehlt den kann man auch sonst für > nicht ganz zurechnungsfähig halten. Du stehst hoffentlich unter > Betreuung!? Jeder der über FreePascal/Lazarus schimpft, kennt es schlichtweg nicht - bzw. hat sich nicht länger als 1 Std, damit beschäftigt. Alle anderen, die sich dafür öffnen, sind begeistert.
Cyblord -. schrieb: > Maik N. schrieb: >> Danke, ich denke ich verstehe dich :). >> >> Ich habe zwar schon in Java-tutorials auf youtube reingeschaut, aber >> irgendwie erklären die das da nur anhand von Zahlen. Also keine >> Beispiele was man denn nach diesem erklärten Prinzipien so als Grafik >> erreichen kann. Das wirkt auf mich echt motivationshemmend. > > Du musst Java Tutorials zu z.B. SWING anschauen. Da erfährst du wie man > GUIs baut. Jo hab mir mal so swing tutorials darüber angeschaut. Das ist genau das richtige. Schönes weekend euch allen. weiß jetzt nicht ob jemand noch n paar insiderlinks dazu hat die man nicht so verlockend auf den ersten youtube-seiten zum thema findet. würd mich freuen. Danke euch
Probiere doch einmal Lisp, genauer Common Lisp https://common-lisp.net/project/mcclim/excite.html https://lispcookbook.github.io/cl-cookbook/gui.html "Lisp has a long and rich history and so does the development of Graphical User Interfaces in Lisp. In fact, the first GUI builder was written in Lisp (and sold to Apple. It is now Interface Builder)."
Cyblord -. schrieb: > Ne sorry, wer heute noch Pascal empfiehlt den kann man auch sonst für > nicht ganz zurechnungsfähig halten. Du stehst hoffentlich unter > Betreuung!? na ja, es gibt ja auch Leute, die finden Ihren C64,etc. ganz zeitgemäß ... :-) SCNR
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.