mikrocontroller.net

Forum: PC-Programmierung GUI-Programmierung - womit?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: GUI (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Armer Student (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VisualStudio.NET

Autor: Thomas U. (thomasu)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: René F. (therfd)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches OS? Wenn Windows => pures WinAPI + ResEdit (Ich nutze 
Codeblocks). Super einfach und keine lib Abhängigkeiten und kleine 
Executables.
Ansonsten .net bzw. Mono

Autor: Gästchen (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Lazarus Pascal..kein Scherz..für GUI das schnellste und klein

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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

Autor: marais (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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?
- ...

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zeno (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter S. (psavr)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: test (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Tonja S. schrieb:

> Pros:
...
> Cons:
....

Ich gehe jetzt mal davon aus, daß Du hiermit PureBasic meinst.

Autor: FlorenzW (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich verwende Lazarus.

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"
Ich gehe jetzt mal davon aus, daß Du hiermit PureBasic meinst."


jepp, Lazarus hätte nur Pros :-)
Lazarus Pascal ist einfach super

Autor: ... (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: zitter_ned_aso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 2⁵ (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
... 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!

Autor: René F. (therfd)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
... 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.

Autor: Ulli (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wurstrakete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Xojo.

Gibt es da eine (für Privatanwender) kostenlose Variante?
Mit welchen Programmiersprachen lässt sich das nutzen?

Autor: Bettlerwabwehr 2.0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dirk K. (merciless)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
GUIs mit Python: https://pypi.org/project/PySimpleGUI/

merciless

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: GUI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: PCEngine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: zitter_ned_aso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: marais (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wurstrakete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bettlerwabwehr 2.0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: marais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mach (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Beuttenmüller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter S. (psavr)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>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
Autor: Mini Mauis (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Heinz B. (Firma: Privat) (hbrill)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tonja S. (Firma: SVK) (tonja_st)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Heinz B. (Firma: Privat) (hbrill)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Link zu Freeprofan:
https://xprofan.net/intl/de/xprofan/freeprofan/

Autor: Tim (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Martin Beuttenmüller schrieb:
> CNC-Steuerung "Sinumeric 840D" hat Windows als Oberfläche ...

Aktuelle Sinumerik 840D sl nutzt Linux als betriebsystem.

Autor: LazarusUser (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: DPA (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.