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.
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?
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.
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
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
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/xojohttps://www.youtube.com/playlist?list=PLPoq910Q9jXiYHemQHGYv3CO7vQWYt7Gz
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.
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.
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
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?
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, 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.
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.
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.
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!?
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
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
