GUI Programmierung ohne Toolkit

Marcin

Hallo fluxy
Ich will Dich hier nicht blöd anmachen aber Du scheinst viele grundliegende Sachen nicht zu verstehen

Kann ich unter Linux ein Fenster programmieren, ohne ein Toolkit wie GTK, SDL, QT oder sonstwas zu benutzten? Also quasi high level, so wie die WinApi in Windows...

Also Win API umfasst viel mehr als nur GUI aber wenn man nur GUI in Betracht zieht dann ist das das Gleiche, es ist einfach eine Sammlung von Bibliotheken mit fertigem Code zur Erstellung von graphischen Oberflächen bloß bei Windows wird es mit geliefert
Anscheinend weisst du das nicht, und Du willst GUI ohne Toolkit programmieren, Sorry ich kenne Dich zwar nicht, aber ich traue Dir das nicht zu. Hast Du etwa unter Windows GUI ohne WinApi programmiert?

Explizit will ich nur eine Linuxkonforme Implementation für Linuxfenster erstellen.

Benutzen solche Ausdrücke Profis ??
Wenn ich das richtig verstehe heißt das "Ich will eine Linux-anwendung mit graphischer Oberfläche programmieren". Besonderes dieses "für Linuxfenster" - ja ja Linuxfenster ist ein gutes Betriebsystem.
Fluxy bitte sei nicht beleidigt aber das hört sich ein bißchen merkwürdig an.
Und wie schon hier CarstenJ geschrieben hat, Du wirst schon mit GTK oder QT genug zu tun haben, das braucht man sich die Sache nicht zu erschweren, weli sie schon sowieso schwer.
Außerdem warum willst GPL nicht? Will Du das Dein Programm CloseSource machen?
Weil Du das vielleicht beruflich machst, tja dann muss man sich aber schon etwas mit Linux auskennen, und man müsste eigentlich schon wissen was welche Lizenz hat.
Fluxy es tut mir leid, daß ich zu Lösung Deines Problems nichts beitragen kann, und ich will hier nicht behaupten, daß Du schlechter Programierer bist aber es hört sich alles an als würde ein 11 järiger einen 3D-Shooter programieren wollen.

nman

Marcin schrieb:

Außerdem warum willst GPL nicht? Will Du das Dein Programm CloseSource machen?

Verdammt, liegt es an mir oder könnt Ihr einfach alle nicht lesen?

Viele Libraries stehen unter der LGPL, dh. wenn er ClosedSource Software schreiben will dann kann er das auch ohne Probleme.

rüdiger

habt ihr manchmal auch das Gefühl, ihr sprecht mit einer Wand?

supertux

Hier ein Vergleich:

Ich programmiere meistens nur Shell-Programme, weil ich mehr auf Systemoprogammierung stehe. Aber ich hab mich auch ein bisschen mit Xlibs beschäftigt (hab in dem Thread schon 2 Mal gesagt, mit dem Buch von Adrian Ney) und hab vor kurzem mit GTK angefangen.

Mit und ohne Toolkit habe ich Hello World Programme geschrieben, dass nur ein Fentser hat mit dem Text "Hello World". Naja, in GTK waren das 10 Zeilen Code oder so. Ohne Toolkit, d.h. direkt mit Xlib habe ich eine Datei die 9.9 KB groß ist, und der Code ist nicht so übersichtlich wie bei GTK.

Dafür sind die Toolkits da, damit sie man benutzt, weil sie dir das Leben einfacher machen. Außerdem finde ich, dass GTK-Look&Feel einfach sehr schön ist.

Shade Of Mine

supertux schrieb:

Ich programmiere meistens nur Shell-Programme, weil ich mehr auf Systemoprogammierung stehe.

Kapier ich nicht.

supertux

Shade Of Mine schrieb:

supertux schrieb:

Ich programmiere meistens nur Shell-Programme, weil ich mehr auf Systemoprogammierung stehe.

Kapier ich nicht.

wie, was verstehst du nicht? Oder hab ich was blödes gesagt?

CarstenJ

Shell-Programme != Systemprogrammierung.

Unter Shell-Programm verstehe ich ein Shell-Script. Du meinst wahrscheinlich Konsolenprogramme, also ohne X und son Gedöns.

supertux

CarstenJ schrieb:

Shell-Programme != Systemprogrammierung.

Unter Shell-Programm verstehe ich ein Shell-Script. Du meinst wahrscheinlich Konsolenprogramme, also ohne X und son Gedöns.

Ja, du hast Recht, ich hab mich nicht so gut ausgedruckt. Was ich sagen wollte, ist: Programme, die den X Server nicht brauchen.

wegus

Ich lese schon einige Zeit mit und kratze mich arg am Kopf,
vielleicht kommen wir ja mit grober Vereinfachung weiter:

Im wesentlichen ist der X-Server quasi das was unter Windows der Grafikkartentreiber ist ( nur das er viel mehr kann). I/O via TCP/IP z.B. war unter Unix z.B. schon möglich da konnte Windows RemoteDesktop noch gar nicht schreiben - oder gar Terminal-Server.
Mit dem X-Server erhält der User eine API, die die 2D Programmierung von Grafiken ermöglicht. Dieses nette kleine Tool X-Server ist in ca. 15 Büchern von O'reilly beschrieben - es wäre Zeitverschwendung das Rad neu zu erfinden ( zumal es ein einziger wohl zu Lebzeiten wohl kaum bewerkstelligen dürfte). Darauf setzt der Windowmanager auf. Er verwendet diese API um Fenster darzustellen und dem Benutzer eine GUI zur Verfügung zu stellen. Da Linux (oder andere Unices) nicht unter dem Monopolproblem leiden, gibt es mehrere GUI's und deren Frameworks. Wer nun Software verkaufen will, der muß die GPL meiden. QT gibt's als GPL oder eben kommerziell als QT-Lizenz. GTK und Gnome sind, glaube ich LGPL, in jedem Falle kann man sie auch für kommerzielle Dinge frei verwenden.Wer die Wahl hat hat eben auch die Qual und muß Lizenzen zahlen ( oder später draufzahlen).Nur um den Vorgang der Lizenzleserei zu ersparen ein eigenen X-Server zu erstellen hielte ich für den falschen Schluß. Zumal es eben DIE LinuxAPI für Grafik nicht gibt. Neben den freien X-Servern gibt es auch kommerzielle. Jeder bekommt das was er mag, er muß nur die Speisekarte lesen und dann bestellen...

Unter Linux kann man sehrwohl Software verkaufen, nur häufig nicht an Endkunden; da ist das Bewußtsein in der Tat " was für Linux ist ist umsonst - alles andere ist unverschämt ". Es lohnt sich also vorher zu überdenken wer das Produkt kaufen soll. Sollen es Endkunden sein, muß das Produkt schon sehr gut sein und sehr günstig.

Gruß Karsten

Also um hier mal Parallelen von Linux mit Windows zu ziehen:
Linux Windows
----------------------------------------------------------
Linux kernel & console kernel32.dll
X11 gdi32.dll
Linux QT / GTK user32.dll
GTKmm, etc Win QT, MFC, VCL, etc

KDE, Gnome namenlos?

kernel32, gdi32 und user32 werden oft also WinAPI zusammen gefasst, und da sie alle vom selben Hersteller (M$) sind benutzen sie auch immer die gleiche Nameskonvention (ungarische Notation). Desweiteren gibt es ein header windows.h das gleichzeitg sämtliche Funktions dieser Library. Und (was wirklich ein Vorteil gegenüber Linux ist!) man kann sich die Dokumentationen der Libs an einer zentralen Stelle holen (msdn).

Kommen wir nun zu Linux (bitte verbesser mich wenn ich was falsches sage, ich bin noch recht neu auf diesem Gebiet)

Unter Linux kommen aber nicht all diese Componenten aus der gleichen Schmiede (beziehungsweise werden nicht alle mit dem Schlagstock auf die ungarische Notation getrimmt), deshalb haben sie alle ihre eigenen Header die seperate eingebunden werden müssen und sie folgen auch nicht alle der selben Konvention (Beispiel der Linux kernel ist afaik C und QT ist C++).

So nun kommt der Fenstermanager, dies ist ein Program und keine Library. Was er tut ist einem Program (auf Anfrage) eine Region auf dem Bildschirm zuteilen auf das es dann zeichnen kann (mittels X11, bzw gdi32 (vieleicht sagt dir HDC etwas)), desweiteren ist es auch noch zuständig für UserIO, also dem Program zu sagen wann der User erwarte, dass etwas passiert. Zum Beispiel wenn ein Fenster verschoben wird oder in den Vordergrund tritt.

Nun kann das Program reinmalen oder aber auch den Processflow an ein Message-Loop System. Dieses System wartet auf Befehle des Fenstermanagers und ruft dann Callbackfunktionen im Program auf (und gibt nicht gebrauchte Rechnerpower an den Kernel mittels einer Sleep Funktion zurück).

So nun kommen die Widgets (Fensterkomponenten wie Buttons oder Textfelder) ins Spiel. Ein Widget ist eigentlich nur eine Sammelung von Callbackfunktion die aufgerufen werden müssen um ein bestimmte Fenstercomponente dar zu stellen und auf Userinput reagiren zu lassen. So nun sind Fensterkomponenten vom selben Widget nicht immer hargenau gleich (Grösse etc). Deshalb hat jede Komponente auch Data in der solche Details gespeichert sind und jedesmal an jede Callback Funktion übergeben werden.

Wenn ein Program eine Fensterkomponente erstellt dann wird diese in eine Liste eingetragen, hier wird auch die Data der Komponenten gespeichert.

Wenn eine Callbackfunktion im Program aufgerufen wird, dann durchläuft das Program erstmal seine Liste von Fensterkomponenten und ruft für sämtliche Komponenten die ensprechenden Callbacks auf und übergibt das Data das in seiner Liste steht. Nun kann eine Callback (per return value) sagen, dass es entsprechen reagiert hat, in dem Fall brauch das Program nichts mehr zu machen und kann auch die Funktion die vom MessageLoop augerufen wurde returnen. Konnte allerdings keine Komponente etwas mit dem Input anfangen dann muss das Program sehen ob es selbst was damit anfangen kann und dann returnen.

Man beachte, dass oft der MessageLoop und die Widgets aus der gleichen Lib kommen und deswegen der MessageLoop von selbst zuerst die Komponenten fragt und dann erst das Program.

Man beachte, dass man so ein Widget system nur als OO implementiren kann (allerdings heist das noch lange nicht, dass das gutes OO sein muss (siehe user32)).

Man beachte, dass der Fenstermanager auch oft nicht nur Fenster managt sondern auch die Flecken auf dem Bildschirm ausmalt wo sich kein Fenster befindet. Hierfür erstellt er oft einen Thread der dann eine Widget lib nach oben beschribenen Verfahren nutzt.

user32.dll ist nur ein Widget Toolkit und unter Linux gibt es mehere dieser Toolkits die die am bekantesten sind sind QT und GTK. Da diese ja nur Program intern benutzt werden können mehrere dieser Toolkits parallel in verschieden Fenstern laufen. (Ausnahme Windows : Docht kriegt man kein MessageLoop hin ohne user32.dll zu nutzen)

Wenn du CreateWindow und co unter Windows (also user32) als nativ API bezeichnest dann ist das unter Linux QT oder GTK.

So nun um das ganz noch ein wenig komplizierter zu machen kommen wir zu den Widget Toolkit Wrappern. Dies sind Libs die eine nativ API nutzen (oder auch ein andere Wrapper) und dann ihr System darauf aufbauen. Beispiele hierfür : GTKmm baut auf GTK auf, MFC VCL WinQT bauen auf user32 auf.

So Win und Linux sind doch nicht so Grund verschieden oder?

Man kann bei Beiden den Kernel nutzen (ja man kann direkt auf kernel32 zugreifen), die Garfik libs, eine nativ Widget Lib oder eine Wrapper Widget Lib nutzen.

So nun noch zu GPL und LGPL.

Die GPL ist einfach : alles was GPL nutzt muss unter GPL stehen.

Wenn man die LGPL dann steht nur der Teil des Programes den man nicht selbst gemacht hat (also den Lib teil) unter GPL. Das heist, dass jeder Zugriff auf den Librarycode haben muss (du bist verantwortlich dies zu gewehrleisten) und ihn auch in deinem Program verändern können muss. Im klar Text heist das entweder die Library in eine DLL (man entschuldige bitte, dass ich den Linux namen nicht kenne) auslagern oder compilierte Objekt Dateien seines Programes liefern sodass der User dein Program mit seiner Version der Library neuverlinken kann. Du bist in dem Fall aber natürlich nicht dafür verantwortlich, dass das Program dann noch einbahnfrei läuft.

PS:Meine License Erklärungen sind nicht verbindlich und können wegen der Vereinfachung falsch sein und deshalb nicht vor Gericht benutzt werden.

PPS:Ach und wer jetzt auch noch OpenGL und DirectX (seit DX8) einorden will : die befinden sich auf gleicher Ebene wie X11 bzw gdi32 und übernehmen einen Teil des oder gleich den ganzen Bildschirm.

PPPS:Da unter Windows alles vom gleichen Hersteller kommt sind die Grenzen etwas verschommener als unter Linux. Zum Beispiel die Consolen Funktionen befinden sich in kernel32 (wo sie hingehören, das es ja IO ist), wenn Win nun aber im Graphicmodus läuft dann wird das Consolenfenster von kernel32 durch benutzen der standard Funktion von user32 gezeichnet. Dies gehört eindeutig nicht in den Kernel und deshalb kann man eigentlich die drei (kernel32,gdi32,user32) nicht wirklich seperate vonander nutzen, ganz anders unter Linux da nutzt QT/GTK X11 und X11 nutzt den Kernel (welcher dann die Driver nutzt und wir sind bei der Hardware) allerdings nutzt der Kernel zum Beispiel kein QT.

PPPPS:Wer Rechtschreibfehler findet darf sie behalten

PPPPPS:Langer Beitrag nicht?

PPPPPPS:Viele PSs, nicht?

Verdammt, das board macht mir meine schöne Tabelle kaput:

Linux                             Windows
----------------------------------------------------------
Linux kernel & console            kernel32.dll
X11                               gdi32.dll
Linux QT / GTK                    user32.dll
GTKmm, etc                        Win QT, MFC, VCL, etc

KDE, Gnome                        namenlos?