ubuntuusers.de

Hallo

Ich habe unter Windows schon etwas mit der API gearbeitet und auch kleine graphische Oberflächen erstellt. Nun möchte ich auf ubuntu umsteigen, und habe mich gefragt, ob es da ein ähnliches System gibt, das mit der Windows API vergleichbar ist?

Es gibt ja, so einige Bibliotheken zb. GTK, Qt, usw. aber Bibliotheken können ja im Prinzip auch nur auf etwas zurückgreifen, dass der Linux Kernel schon bietet, oder?

Wie erstellt man unter ubuntu grundsätzlich einfache Programme auch mit einfacher graphischer Oberfäche?
Kennt ihr da vielleicht gute Bücher? (nicht allzu dicke)
Welche Entwicklungstools eignen sich da?

mfg appleman

Lies mal den Thread, der direkt unter deinem ist (zumindest gerade noch war) 😉

Ich denke du solltest dir erst mal klar werden welche Sprache du lernen möchtest, dann kann man über das Framework reden 😉
Kleinere Sachen kann man aber auch sehr gut mit JAVA machen.

Oder in Perl und Gtk, oder Python und Tkinter, oder Ruby und…

war ja klar 😬

Ich programmiere nicht selbst aber vielleicht wäre ja das was für dich:

Mono-Projekt

Im Prinzip ist es das Gegenstück zu .NET

uname hat geschrieben:

Mono-Projekt

Im Prinzip ist es das Gegenstück zu .NET

Mono ist eher alternative Implementierung Portierung der .NET-Spezifikationen. Es ist ja vollständig kompatibel zu .NET. Das Gegenstück wäre eher Java: Die Ideen sind gleich, die Umsetzung aber grundverschieden und inkompatibel.

@appleman
Der Linux-Kernel selbst stellt nur die fundamentalsten Dinge bereit. Dazu gehören Hardwarezugriff, Prozessmanagment und andere Dinge. Außerdem werden diese Features auf ziemlich niedrigem Level abgebildet, so dass das Interface aus nicht mal 100 Funktionen besteht. Manche Dinge werden von Kernel auch gar nicht bereitgestellt. Die graphische Oberfläche z.B. läuft über Xorg, welches mit den Kernel nur zum Zugriff auf die Grafikhardware nutzt.

Über dem Kernel liegen dann Bibliotheken, von denen die glibc wohl die einzige ist, die man als "Standard" bezeichen kann. Sie wird von jeden Programm direkt oder indirekt verwendet, und ist zudem durch den C Standard spezifiziert. In manchen Bereichen haben sich dann bestimmte Bibliotheken und Dienste durchgesetzt, und fungieren nun als Quasi-Standard. So ist HAL in Verbindung mit udev heute für das Hardware-Management zuständig, während X.org Grafikprimitve bereitstellt. SDL ist im Spielebereich weit verbreitet, und OpenGL hat sich im 3D-Bereich durchgesetzt. An anderen Stellen dagegen gibt es konkurrierende, nahezu vollständig inkompatible Bibliotheken, die aber beide von starken Nutzercommunities getragen werden. Am deutlichsten zeigt sich dies an den GUI-Toolkits, wo es mit Qt und Gtk und den dazugehörigen Desktopumgebungen KDE und Gnome zwei inkompatible Platzhirsche gibt. Programme sind zwischen diesen beiden Bibliotheken nicht portabel.

Unter Linux gibt es schlichtweg keine "offizielle" API, wie du sie von Windows kennst. Ein Feature wird meist von mehreren Bibliotheken implementiert, und es ist deine Aufgabe als Programmierer, die für dich geeigneste Bibliothek herauszufinden. Das ist ganz unabhängig von der Sprache. So gibt es für Java auch Bindings für Gtk und Qt, noch dazu die drei Java-spezifischen Toolkits AWT, Swing und SWT.

Wie du siehst, wird dir unter Linux nichts vorgeschrieben, du hast die Qual der Wahl, sowohl bei der Sprache als auch bei den Bibliotheken!

ot:
Wobei ich gar nicht traurig bin, dass es die WinAPI unter Linux nicht gibt. Ist schon ein Kunststück, eine derart miese API zu entwickeln.

Danke, vor allem Lunar, für die umfangreiche Antwort.

Am liebsten programmiere ich in C. (Ich denke das ist unter Linux kein Problem, oder?) Die Grundprinzipien von C sind mir eingetlich recht gut bekannt, vor allem vom AVR programmieren und natürlich der WinAPI. Von den verschiedenen Bibliotheken habe ich aber keine Ahnung.

Am deutlichsten zeigt sich dies an den GUI-Toolkits, wo es mit Qt und Gtk und den dazugehörigen Desktopumgebungen KDE und Gnome zwei inkompatible Platzhirsche gibt. Programme sind zwischen diesen beiden Bibliotheken nicht portabel. <

Wie darf ich das verstehen? Kann man ein Programm das für GNOME entwickelt wurde unter KDE nicht ausführen, oder nicht kompilieren?

Was heißt jetzt genau Bibliothek? Werden die direkt in den Quellcode eingebunden und mitkompiliert (so wie bei AVR) oder sind alle Funktionen schon lauffähig und werden bloß nich eingebunden (so wie bei der WinAPI)?

Da ubuntu ja GNOME verwendet bietet es sich also an Gtk zu benutzen, sehe ich das richtig?

Welches Buch empfiehlt ihr mir? Ich habe schon bei amazon gestöbert, bin aber noch nicht so recht fündig geworden.

mfg appleman

appleman hat geschrieben:

>Am deutlichsten zeigt sich dies an den GUI-Toolkits, wo es mit Qt und Gtk und den dazugehörigen Desktopumgebungen KDE und Gnome zwei inkompatible Platzhirsche gibt. Programme sind zwischen diesen beiden Bibliotheken nicht portabel. <

Wie darf ich das verstehen? Kann man ein Programm das für GNOME entwickelt wurde unter KDE nicht ausführen, oder nicht kompilieren?

Natürlich kann man KDE Programme unter GNOME benutzen und GNOME-Programme unter KDE, man muss allerdings das entsprechende Framework bzw. die Abhängigkeiten installiert haben. Zum anderen lassen sich selbstverständlich Gtk-Programme auf Qt portieren und umgekehrt, nur ist dies mit einem erheblichen Arbeitsaufwand verbunden.

Da ubuntu ja GNOME verwendet bietet es sich also an Gtk zu benutzen, sehe ich das richtig?

Wäre das naheliegendste 😉

Aha, sowas hab ich mir schon gedacht.

Ich hab mir nun dieses Buch bei Amazon ausgeschaut, das ist meiner Auffassung nach das einzige deutschsprachige das hier zur Verfügung steht.
http://www.amazon.de/GUI-Programmierung-unter-Linux-Programmierung-GTK%2B/dp/3934678424/ref=sr_1_1?ie=UTF8&s=books&qid=1203526541&sr=1-1

Kennt jemand dieses Buch? Was sagt ihr dazu?

Außer graphischen Oberflächen sind mir auch Dateizugriffe wichtig, aber ich schätze mal, dass das schon in glibc implementiert ist, oder?

mfg appleman

appleman hat geschrieben:

Am liebsten programmiere ich in C. (Ich denke das ist unter Linux kein Problem, oder?)

Nein. Auch wenn die Wahl C sicherlich strittig ist, imho gibt es für moderne GUI-Anwendung bessere, da objektorientierte Sprachen. Ich bitte auch darum, dass Argument, dass die GLib existiert, nicht vorzubringen. Die GLib ist hat eine abenteuerliche API und produziert ziemlich unlesbaren Code.

appleman hat geschrieben:

Die Grundprinzipien von C sind mir eingetlich recht gut bekannt, vor allem vom AVR programmieren und natürlich der WinAPI.

Wissen um Microcontroller und die WinAPI sind unter Linux nur bedingt bis überhaupt nicht verwertbar, folglich also irrelevant für die Betrachtung deiner Fähigkeiten. Das bedeutet, dass WinAPI-Wissen unter Linux gar nichts bringt, schon allein, weil die Rückgabe über an Funktionen übergebene Speicherbereiche unter Linux weniger weit verbreitet ist als bei der WinAPI, die dieses mehr als seltsame Prinzip ja offenbar zu der Weisheit letzter Schluss erkoren hat.

appleman hat geschrieben:

Von den verschiedenen Bibliotheken habe ich aber keine Ahnung.

Dafür gibt es Dokumentation.

appleman hat geschrieben:

Wie darf ich das verstehen? Kann man ein Programm das für GNOME entwickelt wurde unter KDE nicht ausführen, oder nicht kompilieren?

Weder das eine noch das andere, sofern du unter KDE nicht auch die benötigten Gnome-Bibliotheken installierst. Ganz konkret: Eine Bibliothek, die zum Drucken auf die libgnomeprint zurückgreift, wird unter KDE weder zu compilieren sein, noch wird sie in kompiliertem Zustand laufen. Erst wenn du libgnomeprint installierst, kannst du diese Anwendung übersetzen und ausführen.

appleman hat geschrieben:

Was heißt jetzt genau Bibliothek?

Du behauptest von dir, du kennst die Grundprinzipien von C und stellst dann diese Frage? Wenn jemand von Grundprinzipien spricht, dann erwarte ich eine zumindest rudimentäre Kenntnis von Bibliotheken inklusive der verschiedenen Arten des Linkens. Sorry, aber die Grundprinzipien von sind nicht Schleifen, sofern wir nicht ganz, ganz, ganz unten anfangen. Da gehört schon ein bisschen mehr dazu. Immerhin kann man C ohne zumindest rudimentäre Kenntnis von Bibliotheken kaum programmieren.

appleman hat geschrieben:

Werden die direkt in den Quellcode eingebunden und mitkompiliert (so wie bei AVR)

Beim statischen Linken schon. Das ist aber unter Linux aus verschiedenen Gründen unüblich, u.a. wegen fehlender Abhängigkeitsverwaltung, geringerer Sicherheit und höherem Speicherverbrauch. Wikipedia hilft dir da sicher mit detaillierterer Erläuterungen.

appleman hat geschrieben:

oder sind alle Funktionen schon lauffähig und werden bloß nich eingebunden (so wie bei der WinAPI)?

Aus dieser Beschreibung werde ich nicht wirklich schlau. Deswegen erkläre ich dir jetzt einfach mal das konträre Prinzip des dynamischen Linkens, welches sowohl unter Linux als auch im Bezug auf die WinAPI gebräuchlich ist: Dabei werden die Bibliotheken in der ausführbaren Datei nur mit Namen referenziert. Der eigentliche Code liegt in DLL (Windows) oder SO-Dateien (Unix/Linux) separat auf der Platte. Beim Start der Anwendung sorgt nun der sogenannte Linker dafür, dass die benötigten Bibliotheken dynamisch in den Speicher geladen werden, und die Speicheradressen im Programm entsprechend umgebogen werden. Dadurch können sich unter anderem mehrere Programme den gleichen Code teilen, außerdem ermöglicht das Sicherheitsupdates, ohne die Anwendung selbst erneut kompilieren zu müssen.

appleman hat geschrieben:

Da ubuntu ja GNOME verwendet bietet es sich also an Gtk zu benutzen, sehe ich das richtig?

Ja. Allerdings ist C nicht die geeignete Sprache für GUI-Anwendungen. Obwohl du dich eventuell in Gtk wohlfühlen wirst, wenn du die WinAPI gewöhnt bist. Die APIs sind ähnlich abstrus.

Sorry, aber die Grundprinzipien von C sind nicht Schleifen, sofern wir nicht ganz, ganz, ganz unten anfangen.<

Nicht? Achso, na dann. Aber was will man erwarten von einem, der C nie offiziell gelernt hat und sich alles aus Büchern und dem Internet zusammenstöpseln muss. Also bitte keine Vorwürfe : )

schon allein, weil die Rückgabe über an Funktionen übergebene Speicherbereiche unter Linux weniger weit verbreitet ist als bei der WinAPI, die dieses mehr als seltsame Prinzip ja offenbar zu der Weisheit letzter Schluss erkoren hat. <

Nicht das ich Windows in irgendeiner Weise verteigen möchte, aber wie soll man es sonst anstellen mehrere Werte zurück zu geben (in einer nicht objektorientierten Programmiersprache)?

mfg

appleman hat geschrieben:

>Sorry, aber die Grundprinzipien von C sind nicht Schleifen, sofern wir nicht ganz, ganz, ganz unten anfangen.<
Nicht? Achso, na dann. Aber was will man erwarten von einem, der C nie offiziell gelernt hat und sich alles aus Büchern und dem Internet zusammenstöpseln muss. Also bitte keine Vorwürfe : )

Naja, wenn es so zusammengestöpseltes Wissen ist, ist es schon etwas gewagt, von Grundprinzipien zu sprechen 😉 Vorwürfe würde ich dir deswegen trotzdem nicht stellen, jeder muss mal anfangen. Nichts für ungut 😉

appleman hat geschrieben:

>schon allein, weil die Rückgabe über an Funktionen übergebene Speicherbereiche unter Linux weniger weit verbreitet ist als bei der WinAPI, die dieses mehr als seltsame Prinzip ja offenbar zu der Weisheit letzter Schluss erkoren hat. <

Nicht das ich Windows in irgendeiner Weise verteidigen möchte, aber wie soll man es sonst anstellen mehrere Werte zurück zu geben (in einer nicht objektorientierten Programmiersprache)?

Das kommt darauf an:
Wenn es mehrere Werte zurückgeben muss, die gleichartig sind, dann nimmt man dafür besser verkettete Listen.
Wenn es um mehrere, verschiedene Werte geht, dann muss man sich fragen, ob die Funktion sinnvoll entworfen ist.
Wenn es um Fehlermeldungen geht: Unter Linux gibt man in diesem Fall 0-Zeiger zurück und setzt ein Fehlerflag in der Bibliothek. Das kann man dann auswerten. Das trennt die Rückgabe von Fehlermeldungen und sorgt so für klareres Design.

Die glibc schafft es immer ja auch, Rückgaben über Referenzen zu vermeiden, wo sie nicht gerade zwingend notwendig sind.

Btw, es gibt auch Quote-Tags, was weitaus besser lesbar ist, als deine gegenwärtige Art zu antworten. Drücke doch einfach mal auf die Sprechblase mit dem Ausrufezeichen rechts oben über einem Posting. Das erzeugte Zitat kannst du mit dem Button "Zitat teilen" (die zerrissene Sprechblase mit dem Fragenzeichen drin in der Symbolleiste unterhalb der Smilies) unterteilen, und so nur auf relevante Stellen antworten. Probier das doch einfach mal aus, es gibt ja den Vorschau-Button, der dabei hilft, unangenehme Überraschungen zu vermeiden 😉

Lunar hat geschrieben:

Das kommt darauf an:
Wenn es mehrere Werte zurückgeben muss, die gleichartig sind, dann nimmt man dafür besser verkettete Listen.

Verkettete Listen erfordern dynamischer Speicherallokation, wo evtl. eine einfache, statische Liste reichen würde. Das ist einerseits vergleichsweise langsam (Für Desktop-Applikationen irrelevant, aber Linux soll nicht nur auf dem Desktop funktionieren) und andererseits muss man sich dann drum kümmern, den Speicher auch wieder freizugeben.
Lunar hat geschrieben:

Wenn es um mehrere, verschiedene Werte geht, dann muss man sich fragen, ob die Funktion sinnvoll entworfen ist.

Es gibt genug sinnvolle Funktionen, die structs oder char-Pointer zurückliefern, z. B. strerror_r oder stat. Es gibt überhaupt keinen Grund, dynamischen Speicher zu allokieren, nur weil man mal ein stat machen möchte.
Lunar hat geschrieben:

Die glibc schafft es immer ja auch, Rückgaben über Referenzen zu vermeiden, wo sie nicht gerade zwingend notwendig sind.

Wenn man "große" Rückgabewerte hat (sprich, größer als ein Zeiger), dann gibt es praktsch keine Alternative. static-Puffer wie z. B. bei ctime funktionieren nicht, weil sie nicht threadsicher sind. Dynamische Allokation steht aus o. g. Gründen nicht zur Debatte. Entsprechend verbreitet ist die Rückgabe über einen Puffer auch, siehe ctime_r, pthread_create, stat, fread und viele weitere.

Aber letzten Endes bleibt es dabei, dass C für Desktop-Applikationen (und auch für das meiste andere) Grütze ist.

Hello World hat geschrieben:

Lunar hat geschrieben:

Die glibc schafft es immer ja auch, Rückgaben über Referenzen zu vermeiden, wo sie nicht gerade zwingend notwendig sind.

Wenn man "große" Rückgabewerte hat (sprich, größer als ein Zeiger), dann gibt es praktsch keine Alternative.

Natürlich, aber bei anderen Daten macht es schlicht keinen Sinn. Sorry, aber eine Funktion, die einfach nur den Ort des Systemverzeichnisses (C:\Windows) zurückgibt, muss das nicht per Referenz macht. Da reicht ein ganz normales return, dann braucht man keine vorher allokierten oder meinetwegen auch auf dem Stack angelegten Buffer, die samt expliziter Längenangabe an die Funktion übergeben werden.

Hello World hat geschrieben:

Aber letzten Endes bleibt es dabei, dass C für Desktop-Applikationen (und auch für das meiste andere) Grütze ist.

Es geschieht zwar selten, aber hier sind wir tatsächlich einer Meinung (auch wenn wir verschiedene Sprachen als Alternative wählen würden 😉 )