mikrocontroller.net

Forum: PC-Programmierung Progs mit GUI auf Win und Linux --> Wie?


Autor: kein_plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich brauch mal in paar Tipps von euch, damit ich da nicht stunden mit 
Programmen installieren und testen vergeude.
Die Problemstellung: ich möchte ein Programm (C++) schreiben, welches 
sowohl unter Linux wie auch unter Windows läuft (also für das jeweilige 
Betriebssystem kompiliert und nicht mit Wine oder so!).
Da stellt sich die Frage, was ich für eine Toolchain verwenden soll. Ich 
habe mir gedacht, ich installier Eclipse mit CDT und als Compiler: 
MinGW. Für die graphische Oberfläche würde ich gerne die GTK-Libs 
verwenden.
Ist es damit (problemlos) möglich solche Programme zu erstellen und 
unter einem Betriebssystem für Linux und Windows zu kompilieren? Braucht 
man da noch etwas (Cross Compiler) oder ist der schon dabei? Oder ist es 
einfacher die Toolchain auf beiden Betriebssystemen zu installieren und 
das Projekt zu öffnen im jeweiligen Betriebssystem und dort kompilieren?
Ich habe da null Erfahrung und würde gerne etwas von euch hören!

Vielen Dank!

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kein_plan wrote:

> unter einem Betriebssystem für Linux und Windows zu kompilieren? Braucht
> man da noch etwas (Cross Compiler) oder ist der schon dabei? Oder ist es
> einfacher die Toolchain auf beiden Betriebssystemen zu installieren und
> das Projekt zu öffnen im jeweiligen Betriebssystem und dort kompilieren?

Für mich war es immer einfacher auf jedem OS eine eigene Toolchain
zu haben. Schon alleine des Debuggings wegen.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wxWidgets ist wie Gtk oder auch Qt ein plattformunabhängiges 
GUI-Toolkit, aber es hilft ebensowenig beim Erzeugen von Binaries für 
andere Plattformen. Für die bräuchte es einen "Cross-Platform"-Compiler 
(keinen Crosscompiler, denn die Prozessorarchitektur bleibt ja i.d.R. 
die selbe), der sowohl die unterschiedlichen Betriebssystemlibraries 
nebst zugehöriger Headerdateien vorhält als auch unterschiedlichen 
Startupcode zu den Binaries linkt sowie die unterschiedlichen 
OS-Loaderformate unterstützt.

Es gibt wohl Systeme, die so etwas können; der Basic-Compiler 
"RealBasic" soll sowohl MacOS-, Linux- als auch Windows-Binaries 
erzeugen können.

Weniger Probleme hat man aber mit Sicherheit mit nativen Toolchains, 
alleine schon des Testens und Debuggens wegen.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Qt ist ganz schmerzlos. Es gab/gib Win32 Installer von Trolltech, welche 
gleich auch noch MinGW installierten, da hat man dann gleich alles was 
man braucht, um Qt-Software unter Windows zu kompilieren. Unter Linux 
reicht es meistens, die Qt-Pakete der jeweiligen Distribution zu 
installieren. Ich würde sowieso Qt gegenüber GTK bevorzugen, der Code 
ist weniger hässlich und der GUI-Editor ist definitiv besser, 
lizenztechnisch gibt es auch keinen Grund mehr, GTK Qt vorzuziehen.

Crosscompilieren ist häufig eher mühsamer. Mit MinGW kann man allerdings 
ganz gut auf einer Linuxkiste Windowssaftware Crosscompilieren.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und mit Wine kannst du deine crosscompilierten Win32 Binaries gleich 
auch noch auf der Linuxkiste testen. Ersetzt aber nicht wirklich Tests 
auf dem echten Windows.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> lizenztechnisch gibt es auch keinen Grund mehr, GTK Qt vorzuziehen.

Naja, QT ist GPL, d.H. um das in Komerzieller Software einzusetzen muss 
man zahlen. Ist zwar recht billig im Vergleich zur Zeitersparnis, die 
die QT mit sich bringt, ist aber trotzdem erstmal eine Investition...

Der TE wollte ja eh GTK verwenden, wahrscheinlich hat er da schon 
Erfahrung mit... in dem Fall würd ich für Windows MinGW verwenden, und 
den Rest der Entwicklungsumgebung (eclipse etc...) braucht er dann eh 
nur unter Linux.

Autor: Miu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, QT ist GPL, d.H. um das in Komerzieller Software einzusetzen muss
> man zahlen. Ist zwar recht billig im Vergleich zur Zeitersparnis, die
> die QT mit sich bringt, ist aber trotzdem erstmal eine Investition...

Schwachfug. Um QT in kommerzieller einzusetzen, muss man halt den 
Quellcode offen legen. GNU GPL Software kann verkauft werden ist also 
auch für kommerzielle Software geeignet.

Autor: AVRli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, dann werde ich wohl auf den beiden Systemen eine eigene Toolchein 
vorsehen. Das mit GTK war eigentlich nur mal ein Vorschlag, damit man 
eine Diskussionsgrundlage hat. Aber ich sehe, dass ich eher QT nehmen 
sollte.
Ich habe (wie auch jemand vorgeschlagen hat) auch was von wxWidgets 
gehört. Wie ist das denn im Vergleich zu QT?
Dann würde ich Eclipse + CDT (IDE), MinGW (Compiler) und QT für die 
Oberfläche nehmen, kommt das gut? Gibts ja alles für Windows und 
Linux...
Vielen Dank bis hie hin für die tolle Unterstützung

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus:
>wxWidgets ist wie Gtk oder auch Qt ein plattformunabhängiges
>GUI-Toolkit, aber es hilft ebensowenig beim Erzeugen von Binaries für
>andere Plattformen. Für die bräuchte es einen "Cross-Platform"-Compiler
>(keinen Crosscompiler, denn die Prozessorarchitektur bleibt ja i.d.R.
>die selbe), der sowohl die unterschiedlichen Betriebssystemlibraries
>nebst zugehöriger Headerdateien vorhält als auch unterschiedlichen
>Startupcode zu den Binaries linkt sowie die unterschiedlichen
>OS-Loaderformate unterstützt.


Zwei Anmerkungen:

1. Crosscompiler ist nicht fest definiert" Meistens wird damit aber ein 
Compiler bezeichnet, der für eine andere Plattform, also durchaus auch 
den gleichen Prozessor, compiliert.

2. Weder wxWidgets noch Gtk noch Qt sind plattformunabhängig, sie sind 
plattformübergreifend, also nicht auf allen Plattformen lauffähig, 
sondern nur auf einigen.

Bitte etwas präziser!

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es einen besonderen Grund, dass Du C++ verwenden mußt?
Mit JAVA hättest Du dieses Problem gar nicht!

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann würde ich Eclipse + CDT (IDE), MinGW (Compiler) und QT für die
> Oberfläche nehmen, kommt das gut? Gibts ja alles für Windows und
> Linux..

MinGW brauchst du nur für Windows. Für Linux nimmst du den normalen gcc. 
Was Eclipse betrifft, keine Ahnung, benutze ich nicht.

> Naja, QT ist GPL, d.H. um das in Komerzieller Software einzusetzen muss
> man zahlen.

Aha. Muss ich wohl die (L)GPL nochmals genau durchlesen.

Autor: madler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Miu schon meinte: GPL heisst nicht, dass man das nicht kommerziell 
einsetzen kann.
Man kann das auch verkaufen. Nur muss man dann den Quellcode kostenfrei 
zur Verfügung stellen, sobald Du das Programm verkaufst /  öffentlich 
verfügbar machst.
Wenn man das nicht will gibt es von Qt auch eine Version die nicht unter 
der GPL steht, dann kannst Du Deinen Quellcode geheimhalten.
Die meisten Firmen bei denen Du arbeitest werden Dir nicht erlauben, den 
Quellcode offenzulegen, wegen Firmengeheimnissen, KnowHow soll bewahrt 
werden etc.

Autor: Christoph __ (chris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GTKmm haette noch den Vorteil, dass es relativ modernes C++ ist.

Damit wuerde dein Programm uebrigens auch unter Mac OS X laufen. Die 
groesste Gefahr die dann noch besteht, ist, dass du aus Versehen 
Datentypen die groesser als 1 Byte sind byte-weise liest oder schreibst, 
also sowas wie

int n = 42;
write(reinterpret_cast<char*>(&n), sizeof(n));

Wenn du plattformuebergreifend programmieren moechtest, musst du sowas 
vermeiden, weil die Byte-Reihenfolge in C++ unspezifiziert ist 
(Stichworte sind Big endian, Little Endian).

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, wie wäre es mit FLTK?

Ich selbst verwende es sehr gerne. Eigene GUI-Objekte lassen sich 
überraschend einfach erstellen.

Vorteil=Nachteil: die GUI sieht unter WIN genau so aus wie unter Linux

Nachteil: es sind nicht sooo viele GUI-Elemente vorhanden
-> Vorteil: standalone EXE zwischen 300-500kB (unter Windows)


www.fltk.org

mfg Weinga-Unity

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 2. Weder wxWidgets noch Gtk noch Qt sind plattformunabhängig, sie sind
> plattformübergreifend, also nicht auf allen Plattformen lauffähig,
> sondern nur auf einigen.

Es gibt keine Software, die auf allen Plattformen lauffähig ist, also 
braucht man dafür auch keinen eigenen Begriff.

> GTKmm haette noch den Vorteil, dass es relativ modernes C++ ist.
>
> Damit wuerde dein Programm uebrigens auch unter Mac OS X laufen.

Das würde es mit Qt aber auch.

Schön bei Qt ist, daß es sich sehr gut in den jeweiligen Desktop 
einpasst, sowohl optisch, als auch funktional. Es ist auch recht 
einfach, Programme zu schreiben, die unter Linux, Windows und MacOS 
laufen, da Qt viele Plattformeigenschaften hinter entsprechenden Klassen 
wegkapselt. Ich schreibe mit Qt Software, die unter Linux und Windows 
laufen soll und habe mir dazu eine cross-build-Umgebung aufgesetzt. So 
kann ich unter Linux das Programm mit einem einzigen make-Aufruf sowohl 
für Linux, als auch für Windows übersetzen. Das geht durchaus.
mingw ist zumindest bei Debian und den darauf basierenden Distros (ich 
verwende Kubuntu) schon als fertiges Paket verfügbar, sodaß man das 
nicht selbst bauen muß. Dann muß man sich, wenn man qmake (den 
Makefile-Generator von Qt) verwendet, noch ein qmake-Spec-File für die 
Cross-Übersetzung bauen. Die Windows-Version von Qt kann man sich bei 
www.trolltech.com als fertigen Installer runterladen und dann in Wine 
installieren, damit man alle Header und libs hat. Man muß nur darauf 
achten, unter Linux dieselbe Qt-Version zu verwenden, da ja einige Tools 
dabei sind wie uic und moc. Wenn man unter Linux baut, werden die dort 
installierten Tools dann auch für das Übersetzen für Windows verwendet, 
und das klappt u.U. nicht, wenn die Versionen da nicht gleich sind.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe mir gedacht, ich installier Eclipse mit CDT und als
> Compiler: MinGW. Für die graphische Oberfläche würde ich gerne die
> GTK-Libs verwenden.

Ich habe mit GTK+, GTKmm und GCC gute Erfahrungen gemacht. GTKmm ist
ein sehr sauber gemachter C++-Wrapper für GTK+ und hält die oft
kritisierten Castereien und Voidpointerkonstruktionen des C-APIs von
GTK+ vom Programmierer komplett fern.

> Braucht man da noch etwas (Cross Compiler) oder ist der schon dabei?

Crossentwicklung habe ich nicht probiert. Die Linux-Version wird unter
Linux kompiliert, die Windows-Version und Windows. Als Compiler unter
Windows habe ich MinGW benutzt.

Ich entwickle primär unter Linux, das Testen unter Windows ist aber
kein Problem, da die unter Linux getestete Software praktisch immer
auf Anhieb auch unter Windows lief.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du könntest auch Java + SWT nehmen...

Java ist wie C++, in einigen Sachen sogar besser.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit Tcl/Tk für die Oberfläche?

Das läuft problemlos auf Win/Linux/Mac und vor allem unter BSD-Lizenz.

GUIs in C oder C++ zu schreiben, halte ich für viel zu umständlich und 
fehleranfällig.
Einfach ist genial :-)

Christoph - der praktisch nur noch in Tcl/Tk programmiert (auch 
Mikrocontroller)

Autor: E. B. (roquema) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Christoph - der praktisch nur noch in Tcl/Tk programmiert (auch
> Mikrocontroller)

Ja Tcl/Tk ist cool und einfach! (alles ist ein string:-) )
Aber wie programmierst Du Mikrocontroller damit?

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Emanuel B. wrote:
>> Christoph - der praktisch nur noch in Tcl/Tk programmiert (auch
>> Mikrocontroller)
>
> Ja Tcl/Tk ist cool und einfach! (alles ist ein string:-) )
> Aber wie programmierst Du Mikrocontroller damit?

Ich habe im Prinzip einen kleinen, auf AVR-Controller zugeschnittenen 
Interpreter  gebaut, der dann beliebigen Tcl-Code (sowohl im 
ControllerFlash, aber eben auch in externem Flash/RAM) ausführen kann.
Port-Befehle etc. sind dann eben Tcl-Befehle, ebenso wie Interrupts.

Das Schöne ist, dass man wirklich hervorragend Debuggen kann. Ebenso 
sind Eingriffe und komplette Änderungen des Codes "on-the-fly" möglich. 
Ich habe so deutlich reduzierte Entwicklungszeiten gegenüber C 
(alleine schon durch die entfallende Neukompilierung).

Die wenigen wirklich zeitkritischen Dinge (und man ist erstaunt, wie 
wenig das sind :-) kann man Tcl-gewohnt kinderleicht als C-Funktionen 
einbinden.

Die Ausführungsgeschwindigkeit ist selbst ohne vorcompilierten Code mehr 
als ausreichend und ich kann nun 99% aller Programme (PC UND Controller) 
im geliebten Tcl/Tk schreiben :-)

Außerdem ist es angenehm, wenn man nicht auf jedes Byte Programmcode 
achten muss (z.B. mit nem AT45 mit 4MB Flash :-)

Christoph - Einfach ist genial

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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