|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Directfb | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
25.09.2004, 18:09 Uhr Mazze Posts: 263 Nutzer |
Hi, ich bin beim Recherchieren auf folgendes gestoßen: direcfb Es gibt Versionen von GTK und Qt, die auf diese Library aufsetzen. Für mich sieht das so aus, als ob es mit einem gewissen Aufwand möglich wäre, eine Wrapper-Library zu schreiben. Wenn es so einfach wäre, dann hätte es doch bestimmt schon jemand gemacht. Wo könnte denn der Haken sein? [ - Antworten - Zitieren - Direktlink - ] |
|
27.09.2004, 20:43 Uhr Holger Posts: 8116 Nutzer |
Ich nehme mal an, Du redest gerade davon, GTK oder Qt auf dieser Grundlage zu portieren. 1.) Qt ist kein freies Produkt, sondern kommerziell und explizit für Linux frei, was aber Linux-Usern, die sonst immer von "frei/offen" reden, ausreicht. Für Amiga müßtest Du also erstmal nach einer Lizenz fragen. 2.) GTK mag vielleicht gehen (ich habe mir bislang nie die Mühe gemacht, den entsprechenden Aufwand abzuschätzen), aber dann hast Du noch lange nicht Gnome und auch noch keine Software, die darauf aufsetzt. Diese dann zu portieren, kann dann nochmal ein Faß ohne Boden werden. GUI ist halt nicht alles, genau genommen ist es das geringste, weil GUI hat der Amiga schon. So, daß war jetzt der Haken, aber das heißt nicht, daß es deshalb noch niemand versucht hat. Vielleicht hatte bislang nur noch keiner die Idee und das könnte eines der nützlichsten Projekte der Amiga-Neuzeit werden. Also wenn Du Zeit _über_ hast, schau es Dir ruhig näher an. Nur nicht vergessen, der erste Schritt in einem Projekt ist die Planung (und das heißt, Du mußt so oder so selber den Aufwand abschätzen) mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
27.09.2004, 21:16 Uhr Holger Posts: 8116 Nutzer |
Habe die directfb-API überflogen und es scheint, als hätte man sich dort auf's wesentliche konzentriert. Eine wrapper-library könnte also durchaus mit etwas Fleiß zu machen sein. Hat vielleicht wirklich nur deshalb noch niemand gemacht, weil bisher keiner auf die Idee gekommen ist. Nicht, daß es wieder heißt, ich nehme den Leuten den Mut  mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
27.09.2004, 23:22 Uhr kadi Posts: 1528 Nutzer |
> Qt ist kein freies Produkt, sondern kommerziell und explizit für Linux > frei, was aber Linux-Usern, die sonst immer von "frei/offen" reden, > ausreicht. Wieso explizit für Linux? Die GPL Version ist für alle Unixe geeignet und Trolltech hat auch eine MacOS X Version portiert und unter GPL veröffentlicht. GPL ist doch GPL und QT ist frei im Sinne der GPL, oder? Es gibt neben der GPL Version auch eine Kommerzielle Version, die auch für Kommerzielle Projekte genutzt werden kann, damit kommerzielle Entwickler nicht gezwungen sind ihre Projekte unter GPL zu veröffentlichen, was die GPL ja vorsieht. [ - Antworten - Zitieren - Direktlink - ] |
|
28.09.2004, 23:15 Uhr Mazze Posts: 263 Nutzer |
Ich habe ein bisschen gegoogelt und folgenden Artikel gefunden. Interessant ist, dass das Framebuffer-Device ursprünglich für Linux/68k (Amiga, Atari, Mac) entwickelt wurde. Zur Programmierung des Framebuffer-Devices konnte ich noch nicht allzuviel finden. Offenbar wird nach dem Öffnen des Devices die Anfangsadresse des Grafikspeichers ermittelt und dann werden alle Grafikoperationen von der CPU durchgeführt. Ich sehe im Moment zwei Möglichkeiten: a) ein AmigaOs-Device Vorteil: einfache Portierung von Software, die das fb-Device benutzt Nachteil: Vermutlich langsam, wegen CPU-Grafik Offene Fragen: Wie programmiert man ein Device? Kann man direkt in die Bitmap eines Screens schreiben? Funktionieren Posix-Funkionen wie open und ioctl mit einem Amiga-Device? b) eine Wrapper-Library für eine Library, die auf dem Framebuffer-Device aufsetzt. (z.B DirectFB) Vorteil Beschleunigung durch Blitter und Grafikkarte Nachteil: Für eine relativ große Zahl von Funktionen müssen Gegenstücke aus grafix- bzw. intuition.library gefunden werden. Möglicherweise wird hin- und wieder die Library umgangen und direkt das Device angesprochen PS. Ich will keine falschen Hoffnungen wecken. Ich brainstorme nur ein bisschen :-) [ - Antworten - Zitieren - Direktlink - ] |
|
29.09.2004, 02:00 Uhr kadi Posts: 1528 Nutzer |
Amithlon verwendet in irgendeiner Art und weise das Linux Kernel framebuffer device. Mehr weiß ich dazu aber nicht. Vieleicht findest du dazu was bei google. IMO hat Bernie Meyer in diversen Newsgroups und ANN Postings einiges erklärt, aber ich habe die Links nicht mehr. [ - Antworten - Zitieren - Direktlink - ] |
|
29.09.2004, 08:31 Uhr Solar Posts: 3680 Nutzer |
Zitat: Nein. Naja, nicht wirklich. Zunächst einmal ist Qt kommerziell lizensiert, und zwar so, daß Du an Trolltech Lizenzgebühren abdrücken mußt, bevor Du mit der Entwicklung anfängst. (Nicht, wenn Du ein fertiges Produkt hast - also auch gescheiterte Projekte müssen zahlen.) Dann gibt es die Möglichkeit, eine freie (GPL) Lizenz zu erhalten. Diese bekommst Du nur, wenn Du Deine Software ebenfalls unter GPL stellst. Allerding spricht die entsprechende Webseite davon, daß diese Lizenz "geeignet ist für die Entwicklung freier Software unter Linux, Unix, und MacOS". Eine "freie" Entwicklung unter AmigaOS wäre somit Verhandlungssache. [ - Antworten - Zitieren - Direktlink - ] |
|
29.09.2004, 12:34 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nicht wirklich interessant. Zitat:Das framebuffer-device ist eine Möglichkeit, im Notfall Linux booten und die Treiber neu installieren zu können. Kennst Du noch irgendeine andere Anwendung, die direkt auf diesem device aufsetzt und den Aufwand lohnt? Zitat:Das ist stark untertrieben. Zitat:Man kann, wenn man will, Posix-Funktionen lassen sich über die ixemul.library emulieren, das Ergebnis wird Dir aber nicht gefallen... Zitat:So groß ist die Zahl eigentlich nicht, wenn man den realen Funktionsumfang dagegen hält. Verglichen mit den APIs anderer Systeme, die oft "historisch bedingte" Funktionen und "gewachsene Strukturen" enthalten und redundant sind, ist das eher eine Wohltat. Zitat:Definitiv nicht. Eine Schnittstelle, die vom Device abstrahiert, ist keine Einladung zum direkten Zugriff. Das wäre ja schizophren. Außerdem, wieviel Linux-Programme kennst Du, die direkt auf die Grafikkarte zugreifen? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.09.2004, 21:27 Uhr kadi Posts: 1528 Nutzer |
>> GPL ist doch GPL und QT ist frei im Sinne der GPL, oder? > Nein. Naja, nicht wirklich. Und was ist an der GPL-Version von QT nicht frei im Sinne der GPL? Es steht doch unter GPL! Also ist es GPL. Wieso sagst du nein, das verstehe ich nicht. Die GPL verstehe ich, aber was an QT anders sein soll, das verstehe ich nicht. Es handelt sich bei QT ja nicht um eine abgewandelte oder modifizierte Version der GPL. > Zunächst einmal ist Qt kommerziell lizensiert, und zwar so, daß Du an > Trolltech Lizenzgebühren abdrücken mußt, bevor Du mit der Entwicklung > anfängst. (Nicht, wenn Du ein fertiges Produkt hast - also auch > gescheiterte Projekte müssen zahlen.) Das es eine Kommerzielle Lizenz von QT gibt hab ich gelesen, sie soll für die Firmen interessant sein, die die GPL Version nicht benutzen können, da sie ihr Produkt kommerziell als Closed Source vermarkten wollen. Da ja die GPL verlangt das man seine Sourcen auch frei gibt, wenn man seinen Code gegen GPL-Librarys linkt, sind GPL-Librarys für Firmen oft uninteressant. > Dann gibt es die Möglichkeit, eine freie (GPL) Lizenz zu erhalten. > Diese bekommst Du nur, wenn Du Deine Software ebenfalls unter GPL > stellst. Wieso erhalten, das verstehe ich nicht, ich dachte die GPL Version ist im Internet zum runterladen und sofort benutzen. Da muss man doch nicht erst fragen. > Diese bekommst Du nur, wenn Du Deine Software ebenfalls unter GPL > stellst. Klar, so ist das bei allen GPL-Librarys. Das ist aber keine Einschränkung von Trolltech, sondern eine Eigenschaft der GPL. Einen Unterschied macht hier die LGPL, aber die wird hier nicht verwendet. > Allerding spricht die entsprechende Webseite davon, daß diese Lizenz > "geeignet ist für die Entwicklung freier Software unter Linux, Unix, > und MacOS". Eine "freie" Entwicklung unter AmigaOS wäre somit > Verhandlungssache. Das halte ich für eine Fehlinterpretation deinerseits. "suitable" ist hier in dem Sinne gemeint, das für alle OpenSource Projekte die GPL oder QPL Version von QT die "passenden" Versionen sind. Die Auflistung der Betriebssysteme kann meiner Meinung nur als Beispiel zu verstehen sein, weil es QT bereits fix und fertig für diese Unix verwanden Systeme gibt. AmigeOS ist kein posix kompatibles Unix und man müsste QT erstmal aufwändig portieren, was womöglich ein irrsinnig kompliziertes Projekt wäre (bin kein Programmierer, daher kann ich das schlecht beurteilen). Aber legal wäre das - auch ohne eine Lizenz bei Trolltech zu beantragen, GPL ist schließlich GPL und ist frei. Man darf schließlich jede unter GPL lizensierte Software auf jedes OS portieren, ohne erst zu fragen. [ - Antworten - Zitieren - Direktlink - ] |
|
30.09.2004, 02:02 Uhr Mazze Posts: 263 Nutzer |
Zitat: Da bei mir nach dem Booten X11 gestartet wird, habe ich vermutlich außer der Bootconsole noch nie eine Framebuffer-Anwendung zu Gesicht bekommen. Ein kurzer Blick nach Freshmeat zeigt: svgalib 66 framebuffer 119 X11 7191 Die svgalib ist vermutlich am einfachsten zu portieren, aber für die paar Anwendungen lohnt es sich fast nicht. DirectFB ist vor allem deshalb interessant, weil verschiedene GUI-Systeme darauf aufsetzen. X11: Hier wäre es mal interessant zu wissen, wieviele Anwendungen die Xlib verwenden und wieviele das Client/Server-Protokoll benutzen. Für mich ist X11 auf dem Amiga wie mit Kanonen auf Spatzen geschossen. Man könnte das Problem "Portierung von grafischen Anwendungen" auch von der anderen Seite her anpacken und z.B. wxWidgets portieren. wxWidgets enthält allerdings mehr als nur GUI-Elemente und bei Unicode, Threads und Signalen könnte es schnell Dinge geben, die sich nicht so einfach auf den Amiga portieren lassen. [ - Antworten - Zitieren - Direktlink - ] |
|
30.09.2004, 02:09 Uhr Mazze Posts: 263 Nutzer |
Zitat: Hmm, wenn ich in den Framebuffer schreibe, zerstöre ich vermutlich die Workbench. [ - Antworten - Zitieren - Direktlink - ] |
|
30.09.2004, 17:00 Uhr Holger Posts: 8116 Nutzer |
@Mazze: Das Problem beim Portieren von GUI-Systemen, egal welchen besteht immer darin, das man nur das GUI bekommt und sonst nichts. Kaum ein Programm besteht nur aus GUI, deshalb birgt das Portieren der darauf basierenden Programme immer weitere Herausforderungen. Für X11 gibt es bereits Amiga-Portierungen/Implementierungen, allerdings nicht sehr aktuell. wxWidgets ist kein reines GUI-System, sondern ein umfassendes Toolkit, das tatsächlich plattformunabhängige Programme ermöglichen kann. Ich glaube nicht, daß es darin Dinge gibt, die sich nicht auf den Amiga portieren lassen. Es ist nur höllig viel Arbeit, schon durch den Umfang. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 30.09.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Directfb | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|