GUI so einfach wie möglich in C/C++

Warum lässt sich das Studio nicht installieren?

Wenn du schnell ein Ergebnis haben willst, solltest du dir mal .net 
anschauen. Dafür braucht man nicht zwingend das VS es reicht auch 
SharpDevelop( http://www.icsharpcode.net/opensource/sd/ ). Man braucht 
für Windows 8.1 auch nicht noch irgendwelche Frameworks installieren - 
das ist alles schon dabei.

Das ist zwar kein C++, aber dafür hat man damit schnell eine GUI 
zusammen. Serielle Schnittstelle ist auch kein Problem.

Vilex schrieb:
> ich suche eine Entwicklungsumgebung + library am besten und am
> einfachsten eine Gui schreiben kann!
> dabei wär mir am liebsten die Programmiersprache C/C++!

http://www.fltk.org/index.php

FLTK (pronounced "fulltick") is a cross-platform C++ GUI toolkit for
UNIX®/Linux® (X11), Microsoft® Windows®, and MacOS® X. FLTK provides
modern GUI functionality without the bloat and supports 3D graphics
via OpenGL® and its built-in GLUT emulation.

FLTK is designed to be small and modular enough to be statically
linked, but works fine as a shared library. FLTK also includes an
excellent UI builder called FLUID that can be used to create
applications in minutes.

FLTK is provided under the terms of the GNU Library Public License,
Version 2 with exceptions that allow for static linking.

Peter II schrieb:
> Warum lässt sich das Studio nicht installieren?

ich habe ehrlich gesagt keine ahnung.. ich lass den installer laufen .. 
aber ich bekomme keine verknüpfung zum öffnen und in den erstellten 
ordnern ist auch nix drinnen ..

Philip K. schrieb:
> Vilex schrieb:
>> QT gefällt mir jedenfalls absolut nicht...
> Geschmack muss reifen...;-)

nein .. 3.1gb große installation und dann so ein grausliches 
projektmanagement ohne zwischen 2 dateien rumswitchen zu können etc.. ne

Philip K. schrieb:
> Wie wärs mit Python + tkinter?

python naja da würde ich mir eher c# ansehn.. weil python ist doch 
wieder ziemlich anders.. und naja müsst ich mich komplett neu 
einarbeiten...

FLTK gefällt mir sehr gut! mit  dem arbeite ich zurzeit!


habe mein codeblocks auch upgedatet allerdings funktioniert gtk3 damit 
noch immer nicht ...

mit welcher IDE wird sonst gtk entwickelt? bzw. kann man entwickeln??

mfg

Vilex schrieb:
>>> QT gefällt mir jedenfalls absolut nicht...
>> Geschmack muss reifen...;-)
>
> nein .. 3.1gb große installation und dann so ein grausliches
> projektmanagement ohne zwischen 2 dateien rumswitchen zu können etc.. ne

Wow... das reicht also aus, damit dir ein ganzes Framework "absolut 
nicht" gefällt. Abgesehen davon hat Qt gar kein "Projektmanagement". 
Vielleicht meintest du Qt Creator? Den kannst du natürlich nutzen, mußt 
aber nicht.

> FLTK gefällt mir sehr gut! mit  dem arbeite ich zurzeit!

Dessen "Projektmanagement" ist also besser als das von Qt?

http://www.tecgraf.puc-rio.br/iup/

ist schlank aber etwas gewöhnungsbedürftig
ob es mit Win8 läuft?

Vilex schrieb:
> Philip K. schrieb:
>> Vilex schrieb:
>>> QT gefällt mir jedenfalls absolut nicht...
>> Geschmack muss reifen...;-)
>
> nein .. 3.1gb große installation und dann so ein grausliches
> projektmanagement ohne zwischen 2 dateien rumswitchen zu können etc.. ne
Öhm,
http://qt-project.org/downloads
hier sehe ich maximal 630MB. Und die sind alle für die Entwicklung, die 
Bibliotheken zum Ausliefern sind bei weitem kleiner.

Was für ein herumswitchen meinst du? (Welche Tastenkombination in 
welcher IDE bietet das an?) Unter dem QtCreator gibt z.B <Strg + Tab> 
oder <Strg + Mausklick>.

Dass du mit GTK unter Windows glücklich wirst... ich habe da meine 
Zweifel. Probiere lieber FLTK.

petar schrieb:
> hier sehe ich maximal 630MB.
Okay, ist klar, Installationsgröße != Installationsdateigröße, ihr könnt 
mich jetzt mit Schmutz und Schande überhäufen. ;-)

Vilex schrieb:
> QT gefällt mir jedenfalls absolut nicht

Das ist natürlich blöd, denn ein besser dokumentiertes, umfangreicheres 
und leichter zu lernendes Toolkit wirst Du kaum finden.

Man braucht für QT übrigens NICHT die mitgelieferte IDE - die ist auch 
eher zur Abschreckung geeignet, wie eigentlich alle IDEs, finde ich. 
Vorteil ist halt der integrierte Debugger und das Hilfesystem. Man kann 
aber auch ganz einfach mit jedem beliebigen Editor und Make arbeiten.

Vielleicht mal hier einen Blick drauf werfen

http://www.ultimatepp.org/

> Und wie sieht da ein Beispielcode aus?

Frage ich mich auch immer als erstes.

Für U++ scheints genug zu geben.

http://www.ultimatepp.org/www$uppweb$examples$en-us.html

Philip K. schrieb:
> radiostar schrieb:
>> Man braucht für QT übrigens NICHT die mitgelieferte IDE - die ist auch
>> eher zur Abschreckung geeignet
> Kann ich absolut nicht nachvollziehen. Für mich gibt es keine bessere...
Sehe ich auch so, also dass der QtCreator ziemlich gut ist. Mit dem 
letzten Satzteil wird aber auch klar, das radiostar anscheinend 
überhaupt nichts mit IDEs anfangen kann, dann kann ich es 
nachvollziehen. ;-)
Siehe fettgedrucktes:
radiostar schrieb:
> Man braucht für QT übrigens NICHT die mitgelieferte IDE - die ist auch
> eher zur Abschreckung geeignet, wie eigentlich alle IDEs, finde ich.

Die Abneigung gegenüber Qt verstehe ich nicht. Das ist doch eins der 
besten Frameworks, die es auf dem Markt gibt.

Solche Schmalspur-Toolkits wie FLTK oder TKinter sollte man sich auf 
keinen Fall antun. Die sind technisch einfach nicht auf dem aktuellen 
Stand. Wenn beispielsweise ein UI-Toolkit im Jahre 2014 keine anständige 
Unicode-Unterstützung bietet (trifft auf o.g. zu), ist es wertlos.

Es gibt genug leistungsfähige Standard-Toolkits: Qt, GTK+ und WxWidgets 
für C/C++, WinForms für .NET, Swing für Java. Plus einige 
Plattform-native Toolkits. Wenn man nicht ernsthafte Gründe hat, die die 
Nutzung eines Standard-Toolkits verbieten, dann sollte man bei den 
Standard-Toolkits bleiben. Schon allein wegen Support und 
Zukunftssicherheit.

Abdul K. (ehydra) schrieb:

> Offensichtlich ist die Frage nach einer geeigneten
> Software-Entwicklungsumgebung noch um Längen schwieriger zu beantworten
> als die allfällige Version welches Platinenlayoutprogramm.

Auch mein Eindruck.

> Ich kenne nun einige dieser ähnlichen Threads. Jedesmal geht es so aus,
> daß sich die Leute in die Haare kriegen und ich am Ende wieder denke: Da
> war nix für mich dabei.

hehe :) SO ist das Leben.

> Wobei U++ in meiner Abneigungsliste ziemlich gnädig platziert wird.
> Macht erstmal einen guten Eindruck.

Gelle! Hab aber selber damit noch nix gemacht (U++ hat aber mein 
Interesse geweckt). Wiki führt da so eine Liste der GUI-Bibliotheken. Da 
ist U++ dabei bzw. da fiel mir's auf.

http://de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken

Die Stable Releases bei U++ sind zwar nicht ganz so aktuell. Aber in den 
Nightly Builds sieht man das es weitergeht. Was ich schön finde sind die 
zahlreichen Beispiele. Die sucht man bei anderen (nicht so bekannten) 
FWs auch mal vergebens bzw. bekommt dann einfach nur den 
Definitionsklüngel vorgesetzt. Das ärgert mich immer. Da muss ich immer 
an Borland denken, wieviel Mühe die sich damals gaben guten Beispielcode 
beizustellen.

Das umfangreichste FW scheint mir aber .NET und QT zu sein. Beide sind 
enorm ausgebaut, wobei ich .NET mit C# für zugänglicher halte für 
Einsteiger ins objektorientierte "Millieu" :) und QT halt eher was für 
die innigen Liebhaber von C++ (mit der Betonung auf ++, weil mit C 
alleine scheint QT nicht verwendbar zu sein. Wohl aber meine gute alte 
Win32-API. Die begnügt sich auch mit C und wer den Petzold kennt .. 
findet es auch nicht so schwer wie immer moniert wird).

Abdul K. (ehydra) schrieb:

> Kannst du den letzten Absatz mal genauer ausführen? Was heißt
> 'ausgebaut', daß ich damit unter Umständen nicht alles was Windoof
> bietet, auch nutzen kann? File-Auswahldialog ohne Resize und ähnlichen
> 'Annehmlichkeiten'??

War das jetzt eine ernsthafte Frage oder eine polemische Anmerkung? Der 
Umfang des .NET FW sollte doch inzwischen bekannt sein. Das ist einiges 
mehr als so ein FLTK zu bieten hat. Bei QT ist es ähnlich. Das sind doch 
beides schiere FW-Monster. Aber auch die haben ihre Lücken, die 
kommerzielle Anbieter aber gerne mit ihrem Knoff-Hoff gegen einen Obolus 
füllen.

> Und die Aussicht auf nur wenige 100KB große Programme sollte
> perspektisch auch noch vorhanden sein.

Da wirst du aber mit QT schon glaube ich ins schleudern kommen. Wenn ich 
mir mein FreeCAD so betrachte mit seinen 200 MB (davon allein 90 MB QT 
DLLs im bin Verzeichnis).

Vergess das mit den paar 100 kB lieber wieder ganz schnell.

Mark Brandis (markbrandis) schrieb:

> Du meinst wohl die schlechte alte Win32 API. Noch viel unnötig
> komplizierter hätte man die Parameterübergabe an die API-Funktionen wohl
> nicht machen können. ;-)

Ja genau die meine ich. Die gute schlechte alte WinAPI. Ich mag sie halt 
trotz aller Unkenrufe so wie andere PC-Assembler mögen (auch wenns 
keiner mehr braucht).

Ist doch erstaunlich wie schnell man immer wieder bei der API-Syntax 
landet. Sogar das oft verpöhnte BASIC stößt einen mit der Nase darauf

http://www.freebasic-portal.de/code-beispiele/windows-gui/fenster-118.html

http://www.freebasic-portal.de/code-beispiele/elektronikansteuerung/statusleitungen-comport-winapi-78.html

FreeBASIC finde ich erstaunlich vielfältig.

Dann führ halt mal aus worauf es dir ankommt.

Abdul K. schrieb:
> Kleine schnelle Entwicklungsumgebung, kleiner erzeugter Code,
> ausführliche Beispiel-Doku,
Da hast du nicht viel Auswahl. Unter Windows wird dir da nur notepad.exe 
+ cmd.exe + gcc.exe und dann Win32-API bleiben. Natürlich hast du dann 
massive Einschränkungen, sowas wie ein vollständiges TreeView Widget 
gibts da glaube ich nicht. Aber schließlich sind GB-große Festplatten 
teuer, oder?!

C#.NET Programme sind zwar klein wenn man das .NET Framework schon 
installiert hat, aber Visual Studio ist nicht klein. Alle anderen 
Frameworks wird man mit ausliefern müssen, und klein ist keins davon.

Unter Linux, wenn das Programm Open Source sein darf kann man Qt oder 
Gtk nehmen, da die quasi jeder schon installiert hat und die zu 
installierende Anwendung dann recht klein sein kann. Zum Entwickeln dann 
nano und gcc.

Alternativ wünsche dir eine 1TB Festplatte zu Weihnachten...

Richtig. Du hast das "Nr. 1 Argument" vergessen, das an bei solchen 
Diskussionen stets genannt wird. Fängt mit P an und endet mit t.

Abdul K. schrieb:
> Ich kenne nun einige dieser ähnlichen Threads. Jedesmal geht es so aus,
> daß sich die Leute in die Haare kriegen und ich am Ende wieder denke: Da
> war nix für mich dabei.
Ach komm, eagle vs diptrace vs target vs kicad vs xxx sind auch 
ausufernde Threads. Das Thema ist ein anderes, das endlose Diskutieren 
bleibt. Der TO hat sowieso alles was er braucht, er muss sich nun 
einfach nur entscheiden.

Dr. Sommer schrieb:
> C#.NET Programme sind zwar klein wenn man das .NET Framework schon
> installiert hat, aber Visual Studio ist nicht klein.

meist reicht für .net schon das SharpDevelop. Das ist kleiner als 
30Mbyte.

Abdul K. schrieb:
> Kannst du den letzten Absatz mal genauer ausführen? Was heißt
> 'ausgebaut', daß ich damit unter Umständen nicht alles was Windoof
> bietet, auch nutzen kann? File-Auswahldialog ohne Resize und ähnlichen
> 'Annehmlichkeiten'??
>
> Und die Aussicht auf nur wenige 100KB große Programme sollte
> perspektisch auch noch vorhanden sein.

Ich verstehe nicht ganz, warum das heute noch wichtig ist. Kommt halt 
auch auf die Perspektive an. Für Qt braucht man halt ein paar MB Platz 
für die Bibliotheken, bei .NET ein paar Hundert MB für das Framework. Da 
fällt das dann halt nicht so auf, weil's irgendwo in der 20 GB großen 
Windows-Systeminstallation versteckt ist.

Abdul K. (ehydra) schrieb:

> Ich bin gerade über ein Tool, geschrieben in PowerBASIC, gestolpert.
> Kannte ich nicht, also mal nachgesehen. Die schaffen es doch auch kleine
> Programme zu erzeugen. LTspice ist auch ein Beispiel relativ kleiner
> Größte (Es kommt ja auch drauf an, wieviel drin steckt).

Hast du mal auf der Wiki Seite über PB nachgelesen? Ist eher für rein 
Text basierte Anwendungen als Win32 Konsolenprogrammen. Billig ist das 
auch nicht gerade (deutlich teurer als PureBASIC, um mal ähnliches zu 
vergleichen). Forms gibt's nur extra gegen Aufpreis. Ehrlich gesagt als 
jemand der gerne in C programmiert für einen BASIC Dialekt überhaupt 
Geld locker zu machen ist schon so eine Sache.

LTSpice dürfte meinetwegen ruhig ein bisschen attraktiver fürs Auge 
daherkommen. Wenn das 10 MB "schwerer" wäre, dafür aber mit einem 
schönes Schaltplanmodul wie man es vom EDA her kennt, hätte ich nichts 
dagegen. Oder wenn die Hilfe noch besser mit Beispielen ausgebaut wäre 
(was ja nicht viel Platz kostet).

Mehmet Kendi (mkmk) schrieb:

> @Leute, Leute (Gast)
> Danke für den Tipp mit U++.
> Werde es mir auf alle Faelle mal naeher anschauen.

Das freut mich. Es ist immer wieder erstaunlich was es doch so alles im 
Netz gibt, worüber man doch nur per zufälligem Klick stolpert. ;)

> XProfan Eine Programmiersprache, die ohne jede Zusatzbibliotheken nicht
> nur alle graphischen und multimedialen Möglichkeiten aktueller
> Windowsversionen unterstützt, sondern zusätzlich auch mit dBase-Dateien,
> beliebigen ODBC-SQL-Datenbanken und dem FTP-Protokoll (Internet) umgehen
> kann.
...
> XProfan Eine Programmiersprache, die direkt für die ereignisorientierte
> Programmierung graphischer Oberflächen geschaffen wurde. Andere
> Programmiersprachen, wie etwa PASCAL, BASIC, oder C erhalten diese
> Fähigkeiten nur durch zusätzliche DLLs oder Bibliotheken.
Viele sehen es ja als positive Eigenschaft an, wenn eine 
Programmiersprache sehr einfach ist und solche Zusatzfunktion durch 
Bibliotheken nach Bedarf hinzugefügt werden kann. XProfan scheinbar 
nicht.
Und für jeden Zweck seine eigene Programmiersprache zu erfinden hat den 
schlagenden Vorteil, dass man nicht mehrere dieser Dinge in einem 
Projekt vereinen kann... Zum Glück gibt es allgemeine Sprachen wie C++ 
...

> XProfan Die Programmiersparache, die OpenGL komplett integriert hat und
> das Programmieren atemberaubender 3D-Anwendungen und -Spiele so einfach
> macht, wie nie zuvor!
> XProfan Das erweiterte Profan: Zahlreiche neue Dialogelemente, wie
> Datumseingabe, Spinedit, Tooltips, Statuszeile oder Gridbox.
> Druckerauswahldialog beim Drucken. Objektorientiertes Programmieren in
> Profan! Zahlreiche Detailverbesserungen, die das Programmiererleben
> leichter machen.
Das sind ja eigentlich Features von Windows... Die dann als eigene 
Entwicklung verkauft werden. Dreist! Wenn ich in C #include <GL/gl.h> 
schreibe ist OpenGL auch komplett integriert.

Heinz Brill schrieb:
> WhileNot ende%
>  Waitinput
>    If clicked(button&)
>     ende% = 1
>    ElseIf @Clicked(Add&)
>       @AddString(listbox&, GetText$(edit&))
>    ElseIf @Clicked(open&)
Ähm... DAS soll ereignisbasierte Programmierung sein? Das ist die 
gammelige 08/15 Event-Loop wie man sie in jedem ollen Win32 Programm 
findet, und zwar ohne dass man dafür eine Library bräuchte (macht 
Windows).

Dann auch nich diese prozedurale Schreibweise. OOP ist doch quasi 
prädestiniert & perfekt für GUI's.


Heinz Brill schrieb:
> Hat zwar keinen Designer dabei, aber leicht zu erlernen.
VS und 100 andere GUI-Frameworks haben einen...

... Leider kann man die "Vollversion" nicht mehr kaufen, d.h. man kann 
den Preis nicht mehr mit dem einer 1TB-Festplatte vergleichen, auf die 
man sich dann 100x Visual Studio o.ä. installieren könnte.

Insgesamt erscheint mir dieses XProfan wie Audio-Goldkabel und 
Atomstromfilter - leichtgläubigen Idioten wird Scheiße als Gold verkauft 
und sich damit eine goldene Nase verdient, während es einen Klick weiter 
im Internet viel mächtigere Lösungen gratis gibt. Bei diesen hängt man 
außerdem nicht davon ab dass jedes weitere Feature vom Autor persönlich 
hinzugefügt wird; denn sinnvolle Programmiersprachen kann jeder um 
eigene Bibliotheken erweitern.

PS: Die XProfan Seite verursacht Augebkrebs und sollte vom 
Gesundheitsamt geschlossen werden.

FreeProfan32 ist mit FreePascal 32-Bit compiliert. Ob ich das so toll 
finde, darüber muss ich nochmal nachdenken. ;)

http://xprofan.com/intl/de/freeprofan/freeprofan32-stellt-sich-vor-download/?&pg=9

Abdul K. (ehydra) schrieb:

> In welcher Sprache der Compiler übersetzt wurde, interessiert doch nicht
> die Bohne. Solang es nicht eine wichtige Einschränkung impliziert.

Da bin ich anderer Meinung. Ich lesen öfter auch mal in den Pascal, 
Delphi, Lazarus Foren. Da bekommt man mit wie viele Bugs und Probleme es 
mit den Compilaten gibt. Das geht zum Teil soweit, dass Alteingesessene 
Delphianer sich über darüber beklagen, wie sie vom Zug der allgemeinen 
Entwicklung abgehängt sind und bereits C# schielen (als Nachfolger von 
Delphi) und auch in Embarcaderro eher weiteren Verfall als Hoffnung 
sehen. Und wenn jetzt einer glaubt, Lazarus sei der Ausweg. Ne, damit 
darfste einem der mal Geld für eine Delphi Lizenz ausgeben hat dort gar 
nicht kommen. Das läuft bei denen alten Delphianern unter ferner liefen.

Ist nur mein subjektiver Eindruck über das was ich dort las. Die Delphi 
Fans mögen es mir nachsehen.

Ich fürchte Profan trägt etliche Bugs oder Beschränkungen von FreePASCAL 
selbst in sich. Man kann sich auch fragen, ob man dann nicht lieber 
gleich FreePascal selber oder eben Delphi nimmt, statt einer daraus 
entwickelten Programmiersprache, die wiederum nur auf den verwendeten 
Libs beruht und zudem noch durch immer mehr spezielle Befehle das 
wettmachen muss, was eine allgemeine Programmiersprache sich über 
Bilbliotheken verschafft.

> Bei Profan stößt mir die Bandstruktur der Sourcetexte auf. Sieht total
> unübersichtlich aus.

Auch mein Eindruck, obwohl das Beispiel hier zeigt, dass es auch (ein 
wenig) anders geht

http://xprofan.com/intl/de/quelltexte/cramersche-determinantenmethode-gleichungssystemen-loesen-regeln/

Sowas hier
 whileloop If(a&,d!,1),If(a&,If(d!=2,2,1),If(d!=2,1,d!)),If(a&,-1,1)'
finde ich jetzt auch nicht gerade so prikelnd

> Mit objektorientiert kann ich nix anfangen
> und C ist mir ein Graus.

ლ(`◉◞౪◟◉‵ლ)

Warum sollte man auch nur eine Sekunde Zeit an irgendwelchen 
proprietären Frickelsprachen verschwenden? Das lohnt sich wirklich 
nicht.

Hallo Philip,

Philip K. schrieb:
> Vilex schrieb:
>> QT gefällt mir jedenfalls absolut nicht...
> Geschmack muss reifen...;-)
>
> Wie wärs mit Python + tkinter?

Das wäre auch meine erste Empfehlung... oder eben Python + Qt. ;-)

LG,
Karl

Hallo greg,

greg schrieb:
> Die Abneigung gegenüber Qt verstehe ich nicht. Das ist doch eins der
> besten Frameworks, die es auf dem Markt gibt.

Du siehst doch, daß der OP die Qualität eines Frameworks nicht anhand 
von dessen Konzepten, Fähigkeiten und Dokumentation beurteilt, sondern 
anhand ihrer Installationsgröße und der mitgelieferten IDE.

> Solche Schmalspur-Toolkits wie FLTK oder TKinter sollte man sich auf
> keinen Fall antun. Die sind technisch einfach nicht auf dem aktuellen
> Stand. Wenn beispielsweise ein UI-Toolkit im Jahre 2014 keine anständige
> Unicode-Unterstützung bietet (trifft auf o.g. zu), ist es wertlos.

Tkinter/Tix und Python haben selbstverständlich eine anständige 
Unicode-Unterstützung.

Liebe Grüße,
Karl

Karl Käfer schrieb:
> Du siehst doch, daß der OP die Qualität eines Frameworks nicht anhand
> von dessen Konzepten, Fähigkeiten und Dokumentation beurteilt, sondern
> anhand ihrer Installationsgröße und der mitgelieferten IDE.

Schon, aber wie kurzsichtig kann man bloß sein?

> Tkinter/Tix und Python haben selbstverständlich eine anständige
> Unicode-Unterstützung.

Leider nicht. Die können nur das Minimal-Level, also gerade mal mit 
Unicode-Encodings umgehen. Und bei FLTK gilt sogar diese einfachste 
Unterstützung noch als "incomplete"! Bidirektionales Layout und Shaping 
können diese Toolkits nicht. Damit schließt man auf einen Schlag 
Arabisch, Hebräisch, die indischen Sprachen, Thai und einiges mehr aus. 
Aber hey, es sind ja nur die Muttersprachen von ca. 2 Milliarden 
Menschen. ;)

Da wo FLTK & co in Sachen Internationalisierung jetzt sind, waren Qt und 
GTK+ vor 15 Jahren.

Hallo greg,

greg schrieb:
> Karl Käfer schrieb:
>> Du siehst doch, daß der OP die Qualität eines Frameworks nicht anhand
>> von dessen Konzepten, Fähigkeiten und Dokumentation beurteilt, sondern
>> anhand ihrer Installationsgröße und der mitgelieferten IDE.
>
> Schon, aber wie kurzsichtig kann man bloß sein?

Das sehe ich zwar genauso,

> Leider nicht. Die können nur das Minimal-Level, also gerade mal mit
> Unicode-Encodings umgehen. Und bei FLTK gilt sogar diese einfachste
> Unterstützung noch als "incomplete"! Bidirektionales Layout und Shaping
> können diese Toolkits nicht. Damit schließt man auf einen Schlag
> Arabisch, Hebräisch, die indischen Sprachen, Thai und einiges mehr aus.
> Aber hey, es sind ja nur die Muttersprachen von ca. 2 Milliarden
> Menschen. ;)

Trotzdem ist das auch in der professionellen Softwareentwicklung ein 
eher akademisches Problem, und erst recht für die hier gestellte 
Aufgabe.

LG,
Karl

Ja dann eben FreePascal/Lazarus, oder sogar Java mit NetBeans. Da gibt 
es doch genug ordentliche, etablierte, einfach zu benutzende und fertige 
Lösungen. Die brauchen alle keine Ultrabytes auf der HDD.

Karl Käfer schrieb:
> Trotzdem ist das auch in der professionellen Softwareentwicklung ein
> eher akademisches Problem, und erst recht für die hier gestellte
> Aufgabe.

Seh ich nicht so. Es ist doch nichts Ungewöhnliches, wenn Software in 
10-20 Sprachen übersetzt wird. Und auch wenn nicht, soll fremdsprachiger 
Text korrekt angezeigt werden.

Abdul K. schrieb:
> Mit objektorientiert kann ich nix anfangen
> und C ist mir ein Graus.

Das klingt leider ein bisschen so wie: Ich kann mit Schraubendrehern nix 
anfangen und Löten ist mir ein Graus. In so einem Fall ist Elektronik 
nicht unbedingt das Richtige, oder man muss seine Einstellung ändern.

Hi Jörg,

Jörg Wunsch schrieb:
> Den Creator mag ich auch nicht sonderlich, nehme ihn aber zuweilen
> trotzdem.

Und ich hatte Dir doch als angeboten die Addins für Qt 4.8 und 5.0 für 
Dich rauszurücken für Eclipse :-P
JA Eclipse ist nit fix, aber ich will es nicht missen mit all den tolen 
Features.
Schon allein das überfahren einer Funktion und dem öffnen der Box mit 
dem Quellcode, vermisse ich bei jeder anderen IDE :-)

my 2 Cents , Fabi :-)))

Leute, Leute schrieb:
> Das ärgert mich immer. Da muss ich immer
> an Borland denken, wieviel Mühe die sich damals gaben guten Beispielcode
> beizustellen.

Omg :-)
Ich muss zwangsweise alten Code in einer grossen Firma derzeitig mit 
Borland Builder 6.0 erweitern und traurigerweise jede Menge 
Speicherlecks beseitigen....
Habe mit Borland Jahre lange Erfahrung und würde jedem von dem (meine 
Meinung) Mist abraten...
OOP ist fast nicht möglich, da die TObjects nur auf Forms funktionieren 
ohne Bugs :-)
Bin seit langem QT geschädigt und würde (meine Meinung) auch jedem dazu 
raten, der C++ gut kann.

Alles geschriebene spiegelt meine Erfahrungen...
Nicht beachten :-)))
Mfg Fabi

Hi,

Jörg Wunsch schrieb:
> Emacs rulez. :-))

Endlich normale Leute.

SCNR,
Karl

Hi Jörg

Jörg Wunsch schrieb:
> Naja, ich kann mich mit Eclipse auch nicht so recht anfreunden.  Einen
> alten Emacser verpflanzt man nicht so schnell. ;)

Ich sehe schon ich muss Überzeugungsmassnahmen treffen :-P
Obwohl das ziemlich leicht wird .....
Nenene Ihr Apfelianer :-)))

>
> Vielleicht sollte ich mir ja mal den Qt-Mode für Emacs ansehen …

Um Himmels Willen^^.
Das ist wirklich ei kraus, lieber programmiere ich dann PHP.
Ups ich hoffe ich breche jetzt keine PHP warflame aus :-P

Mfg Fabi

Mark Brandis schrieb:
> Jörg Wunsch schrieb:
>> Emacs rulez. :-))
>
> Sicher meintest Du "vi rulez" :)

vi ist doch Mist. vim rulez!

> Kannst du noch ein paar Worte dazu verlieren, was man in Profan NICHT
> machen kann? Wie sieht es z.B. mit Treiberprogrammierung aus.
Multithreading, Metaprogrammierung, C, Java, .NET-Libraries verwenden, 
Exceptions, Speicher-Management, mächtige GUI-Elemente wie zB 
voll-funktionsfähige TreeViews, Serielle Schnittstellen zugreifen, 
statische Typisierung, Typ-Abstraktion, vernünftige 
Plattform-unabhängigkeit...
> Visual Basic sieht auch ganz nett aus. Dort könnte man auch problemlos
> auf C++ umsteigen, wenn man das Bedürfnis bekommen sollte. Die IDE
> bleibt ja gleich.
Das ist auf jeden Fall die bessere Wahl, Visual Studio ist eine 
mächtige, etablierte weit verbreitete IDE. Wobei ich diese Fixierung auf 
IDE's irgendwie komisch finde.

Heinz Brill schrieb:
> XProfan soll ja sowohl für Anfänger und Einsteiger
> als auch für etwas Fortgeschrittene sein. Es ist halt
> für das gedacht, das man früher mal 'mittlere Datentechnik'
> genannt hat. Also für den Hausgebrauch und für kleine
> und mittlere Firmen, die sich keine teure und fertige Software
> bzw. extra Programmierer leisten können.

Wenn man nicht ordentlich programmieren kann, sollte man nicht im 
professionellen Umfeld versuchen zu programmieren, bzw. es sich richtig 
aneignen.

In praktisch allen technischen Bereichen wird eine gewisse Kompetenz 
vorausgesetzt, warum sollte das beim Programmieren anders sein?

Niemand mit gesundem Menschenverstand lässt z.B. BWLer ohne weitere 
Kenntnisse elektronische Schaltungen zusammenfrickeln. Warum sollte das 
beim Programmieren anders sein? Bei Software wird viel zu häufig 
gepfuscht, obwohl das eine sehr komplexe und wichtige Angelegenheit ist. 
Ich frage mich, woher das kommt.

Heinz Brill schrieb:
> Dr. Sommer :
> einiges geht wohl auch mit XProfan.
> z.B. : Thread-Programmierung mit pExec(),
Das ist dann aber keine Shared-Memory-Parallelität, wie sie in vielen 
Sprachen geht.
> TreeViews gehen,
Ja, aber sie können nix, d.h. keine beliebigen Widgets einbinden wie zB 
Checkboxen
> Befehle für die ser. Schnittstelle,
> und Fehler - Behandlung.
Ja C kann auch sowas wie "Fehler-Behandlung" aber es ist trotzdem Mist. 
Ein vereinheitlichter Fehler-Behandlungs-Mechanismus wie Exceptions ist 
da sehr viel praktischer & mächtiger.
> Was fehlt, kann man mit Includedateien, die in
> den Foren zu finden sind, teilweise nachrüsten.
Stark. In C oder Java kann man alles nachrüsten.
> Auch eine als Freeware erhältliche Listview.dll, die
> das Editieren in Zellen, drucken  u.v.m. kann, kann
> man downloaden.
Jedes Steuerelement einzeln hinzufügen? Warum nicht Qt oder Gtk oder WPF 
verwenden, die gleich einen umfrangreichen mächtigen Satz an 
Steuerelementen bieten (und gratis sind).
> XProfan soll ja sowohl für Anfänger und Einsteiger
> als auch für etwas Fortgeschrittene sein. Es ist halt
> für das gedacht, das man früher mal 'mittlere Datentechnik'
> genannt hat. Also für den Hausgebrauch und für kleine
> und mittlere Firmen, die sich keine teure und fertige Software
> bzw. extra Programmierer leisten können.
Es gibt eine Reihe sehr guter, skalierbarer kostenloser 
Entwicklungsumgebungen & Sprachen, z.B. Clang,GCC (hauptsächlich C,C++), 
Visual Studio (C++,Basic,C#,...), Java (eclipse), die für alles von 
Hausgebrauch bis Riesen-Programme verwendbar sind. Warum sich also mit 
sowas obskurem beschränktem zufrieden geben? Jeder Depp kann z.B. in VS 
und C# eine GUI zusammenklicken, aber damit gehen auch noch ganz andere 
Sachen.

Und wer sich keine Programmierer leisten will wird am Ende sehr viel 
mehr Geld ausgeben, wenn die Software ersteinmal so gründlich vermurkst 
ist dass man alles neu machen muss.

> Wenn man also keine ausgefallenen Sachen, die auch nicht
> mit der Windows-API zu realisieren sind, machen will,
> ist XProfan schon zu gebrauchen.
Der Schlüssel bei viel Technologie ist Skalierbarkeit - d.h. dass die 
Technologie auch bei wachsenden Anforderungen zu gebrauchen ist. Auf 
sinnvolle Programmiersprachen trifft das zu, auf XProfan kaum.

Dr. Sommer (Gast) schrieb:

> Es gibt eine Reihe sehr guter, skalierbarer kostenloser
> Entwicklungsumgebungen & Sprachen, z.B. Clang,GCC (hauptsächlich C,C++),
> Visual Studio (C++,Basic,C#,...), Java (eclipse), die für alles von
> Hausgebrauch bis Riesen-Programme verwendbar sind. Warum sich also mit
> sowas obskurem beschränktem zufrieden geben? Jeder Depp kann z.B. in VS
> und C# eine GUI zusammenklicken, aber damit gehen auch noch ganz andere
> Sachen.

> Und wer sich keine Programmierer leisten will wird am Ende sehr viel
> mehr Geld ausgeben, wenn die Software ersteinmal so gründlich vermurkst
> ist dass man alles neu machen muss.

Wie erklärst du dir denn das z.T. grottig ausgeführte Benutzerinterface 
von LTSpice? Da funktioniert doch nicht mal ein einfacher Zoom anständig 
(Flackermodus). Und auch sonst wirkt LTSpice an vielen Ecken eher so als 
ob jemand seine ausgefuchste Spice-Engine mit "etwas Oberfläche" (GUI) 
versehen (aufpeppen) wollte, damit sie für andere einigermaßen benutzbar 
ist. Sowas hätte der gute Mann doch auch locker in BASIC oder Profan 
oder sonst irgend einer weniger bekannten "zweitrangigen" 
Programmier-Sprache oder -Umgebung hinbekommen. Programmiert ist LTC 
aber sogar in MS VC++ 6.0. Ich unterstelle mal er möchte die GUI von LTC 
nicht bewusst primitiv halten. Waum also geht er so vor wie er vorgeht? 
Wo doch alles "so einfach" mit den Platzhirschen (VS, JAVA) 
zusammenklickbar und ruckzuck perfekt hinzubekommen wäre? Offensichtlich 
gibt es da eine Hürde, die auch er nicht so einfach überwinden mag oder 
kann. Oder welchen Grund siehst du hier wirken?

Als weiteres Beispiel könnte man KiCAD heranziehen. Die GUI dort bricht 
doch mit vielen Konventionen und wirkt alles andere als in sich 
konsistent, eher wie von Leuten (Freizeitprogrammierer) 
"zusammengefrickelt", bei aller grundsätzlichen Hochachtung für deren 
privates Engagement. Und so denke ich gibt es viele Beispiele von 
Softwaren, die so gar nicht in das Schema passen, wie SW aus 
professioneller Vorstellung heraus betrachtet so zu sein hat und (von 
deren Vorstellung aus) von Programmen wie Profan oder BASIC Dialekten 
angeblich nicht erfüllt werden kann.

Bitte nicht falsch verstehen. Das ist kein Plädoyer jetzt mit old MS 
QBASIC ein AutoCAD stricken zu wollen. Eher eine Art (kurze) 
Bestandsaufnahme, ein Hingucker. Es gibt aber auch immer öfter SW 
heutzutage, die ist derart aufgebläht, dass man sie kaum mehr gescheit 
benutzen kann. Die Oberfläche wirkt träge, sobald man mal etwas mehr 
damit macht als nur ein bisschen Herunklicken. Und genau das ist dann 
auch noch C++ SW, die vollgepflastert mit QT DLLs, Python Schnittstellen 
usw. Hier gibt es anscheinend einen Widerspruch swischen der 
Vorstellung, dass gerade diese (C++) Programme grundsätzlich 
"rattenschnell" in der Ausführungszeit sein müssten. Theorie und Praxis 
gehen hier auseinander bzw. irgend etwas scheint da falsch zu laufen.

Abduls Wunsch nach einem "Alles-sorglos-rundum-Programmier-Paket" mit 
den Eingenschaften

+Treiberprogrammierung
+simples Prozedere eine ansprechende GUI hinzubekommen
+gute intuitive IDE
+einfache Programmiersprache
+schnelle Ausführungsgeschwindigkeit
+kleine Programmgröße
+keine Abhängigkeiten von Laufzeitumgebungen
+geringe Kosten, Freeware oder OpenSource
+zukunfstsicher

wird kaum unter den gemeinsamen Deckel einer einzigen Sofware bringen zu 
sein, ohne spürbare Abstriche bzw. Kompromisse einzugehen.

Leute, Leute schrieb:
> Wie erklärst du dir denn das z.T. grottig ausgeführte Benutzerinterface
> von LTSpice? Da funktioniert doch nicht mal ein einfacher Zoom anständig
> (Flackermodus).
Die Grafikanzeige von LTspice ist auch nicht vom Toolkit, sondern von 
LTspice selber gemacht. Und das kann man in allen 
Programmiersprachen/Frameworks vermurksen.
> Sowas hätte der gute Mann doch auch locker in BASIC oder Profan
> oder sonst irgend einer weniger bekannten "zweitrangigen"
> Programmier-Sprache oder -Umgebung hinbekommen.
Vielleicht irgendwie zusammengefrickelt; ich kenne LTSpice jetzt nicht 
genug aber man eckt dann bestimmt an genug Stellen an wo diese Sprachen 
nicht ausgereift genug sind.

> Programmiert ist LTC
> aber sogar in MS VC++ 6.0. Ich unterstelle mal er möchte die GUI von LTC
> nicht bewusst primitiv halten. Waum also geht er so vor wie er vorgeht?
Weil er wohl ETechniker und nicht Informatiker ist :-/
> Wo doch alles "so einfach" mit den Platzhirschen (VS, JAVA)
> zusammenklickbar und ruckzuck perfekt hinzubekommen wäre? Offensichtlich
> gibt es da eine Hürde, die auch er nicht so einfach überwinden mag oder
> kann. Oder welchen Grund siehst du hier wirken?
Und in XProfan wäre das ordentliche Zoomen viel einfacher? Da habe ich 
meine ZWeifel. Seine Algorithmen kennen muss man in allen Umgebungen.
> Als weiteres Beispiel könnte man KiCAD heranziehen.
Ja, mit Negativbeispielen habe ich leider selber genug zu tun. Eine gute 
Umgebung ist kein Garant für ein gutes Programm; aber weniger 
Einschränkungen begünstigen weniger hässliche Frickelei.
> Die GUI dort bricht
> doch mit vielen Konventionen und wirkt alles andere als in sich
> konsistent, eher wie von Leuten (Freizeitprogrammierer)
> "zusammengefrickelt", bei aller grundsätzlichen Hochachtung für deren
> privates Engagement. Und so denke ich gibt es viele Beispiele von
> Softwaren, die so gar nicht in das Schema passen, wie SW aus
> professioneller Vorstellung heraus betrachtet so zu sein hat und (von
> deren Vorstellung aus) von Programmen wie Profan oder BASIC Dialekten
> angeblich nicht erfüllt werden kann.
Dann bau doch mal einen schönen Datei-Tree-Browser in Profan. In Visual 
Basic geht das vermutlich dank .NET und WPF.

Die Argumentation, dass man ein schlechtes Programm mit schlechter GUI 
schreibt und daher ein schlechtes Framework nehmen sollte, finde ich 
gewagt.

> Hier gibt es anscheinend einen Widerspruch swischen der
> Vorstellung, dass gerade diese (C++) Programme grundsätzlich
> "rattenschnell" in der Ausführungszeit sein müssten. Theorie und Praxis
> gehen hier auseinander bzw. irgend etwas scheint da falsch zu laufen.
Ja, wie gesagt, seine Algorithmen kann man überall verbocken. Eine GUI 
in Qt ist grundsätzlich nicht langsam. Die Tatsache dass man DLL's mit 
ausliefern muss ist Windows' Mangel an vernünftigem Deployment 
geschuldet. Unter Linux schreibt man in sein Package File dass "Qt" 
installiert sein soll und der Rest geht von alleine; Qt wird dann genau 
1x auf dem System installiert für alle Anwendungen, und das ist es 
onehin schon bei den meisten Installationen.
> Abduls Wunsch nach einem "Alles-sorglos-rundum-Programmier-Paket" mit
> den Eingenschaften
> ...
> wird kaum unter den gemeinsamen Deckel einer einzigen Sofware bringen zu
> sein, ohne spürbare Abstriche bzw. Kompromisse einzugehen.
Ja, auch nicht bei XProfan.

Dr. Sommer (Gast) schrieb:

> Dann bau doch mal einen schönen Datei-Tree-Browser in Profan.

Das mit dem Profan stammt nicht von mir. Ich habe mir Profan nur mal 
kurz angesehen und bin schon mit den Bezeichnungen (ähnlich wie Abdul es 
erging) ins Schleudern gekommen. Was ich dann noch gelesen habe hier von 
ihm

http://xprofan.com/intl/de/freeprofan/freeprofan32-stellt-sich-vor-download/?&pg=9

hat mich eher dazu gebracht, dass Profan momentan nichts für mich ist.

> In Visual
> Basic geht das vermutlich dank .NET und WPF.

C# wirkt da auf mich insgesamt viel ausreifer. Forms finde ich einfacher 
zu verstehen und anzuwenden als WPF. So schnell kommt man gar nicht mit 
wie MS die Pferde wechselt. Eigentlich müsste man gleich auf WinRT 
umschwenken, aber das gibt es ja nicht rückwirkend für W7. Auf der 
anderen Seite, was soll an Win Forms schlecht sein, wenn andere noch mit 
den alten Foundation Classes herumhantieren?

Momentan lese ich aus Interesse halber bei U++ und das ist recht 
spannend.

Abdul K. schrieb:
> Dr. Sommer, wie soll man sonst Source-Level Debugging betreiben?
Mit GDB zB. Abee das meinte ich gar nicht, ich bezog mich auf die 
Fixierung auf eine bestimmte IDE... Wenn schon auf eine 
Programmiersprache...

Abdul K. schrieb:
> Hm, dieser GDB (Du meinst wohl http://www.sourceware.org/gdb/), wie kann
> der auf andere Programme zugreifen wenn doch Windoof die Programme
> gegeneinander schützt?

Ein Superuser/root kann (fast) alles.

> Wie kommt er auf die notwendigen Infos aus der
> Source, z.B. Variablenname?

Dafür muss der Compiler Debugging-Informationen in die Objektdateien 
einbetten. Dafür gibt es Standards.

Abdul K. schrieb:
> Eine IDE hatte ich nicht festgelegt.
Ok das klingt immer so.
> Hm, dieser GDB (Du meinst wohl http://www.sourceware.org/gdb/), wie kann
> der auf andere Programme zugreifen wenn doch Windoof die Programme
> gegeneinander schützt? Wie kommt er auf die notwendigen Infos aus der
> Source, z.B. Variablenname

Vom OS gibts da irgendein Tracing API. Auf den Debugger wie gdb greift 
dann die IDE zu - die kann das auch nicht dank Zauberei. Und mit 
Debug-Informationen kompilierte Programme (-g beim GCC) enthalten die 
nötigen informationem um die sourcen zu finden.

Wahnsinn!
habe mich die letzten Monate mit QT beschäftigt und muss sagen ich bin 
begeistert! eine Gui ist wirklich in minuten zusammengeschustert und 
funktioniert alles easy!
danke!