Da ichs leid bin laufend das Rad neu zu erfinden,
würde ich gerne eine vorhandene gut strukturierte GUI Engine benutzen für mein Mediaplayer Projekt Xenorate.

Xenorate ?
Das Projekt existiert schon seit 2002 und ist als Multifunktionals Mediaplayer für Windows gedacht.

Es arbeitet für Medienwiedergabe mit Bass und DirectShow (Hardcore modifiziertes DSPack) und nutzt eine eigene Entwickelte GUI.

Der gesamte GUI part ist hardcodet und nutzt als Renderausgabe "Canvas", aber unterstützt Skins.
Muss aber dazusagen, das es wirklich sehr schlampig programmiert ist, aber dennoch erstaunt wie robust es heute noch läuft

Das besondere eigentlich an dem Projekt ist die Benutzerfreundlichkeit, sowie die Scriptgesteuerte DirectShow Video Engine welches auf DSPack basiert.
Damit bietet sich theoretisch die möglichkeit, jedes beliebige format welches mit DirectShow Filter abzuspielen geht, auch abzuspielen.

Mittlerweile ist aber das Projekt extrem überladen und abstürze inform von Zugriffsverletzungen sind keine seltenheit mehr.
Das liegt unter anderem an der "nicht vorhanden" weiterentwicklung an DSPack, sowie unkenntniss in DirectShow und einer Codebasis die seit 2001 exisiert (somit schlecht strukturiert, brutal hardcodet) ist.

Ich möchte das Projekt nicht sterben lassen, somit hab ich mir 2006 damals schon an eine komplett neue Version rangewagt,
welche im grunde eine super basis gewesen wäre für das weitere Xenorate, aber mangels struktur aufgegeben wurde.

Suche GUI Engine

Es hat bisher immer an der GUI bzw Skin Engine gehangen,
deswegen will ich nun das Problem zumindest weitgehend aus der Welt schaffen und mich einer third party GUI/Skin engine bedienen.

Allerdings hab ich einige Vorstellungen was die jeweilige GUI Engine können sollte:

Wichtig:


- Gut strukturierte codebasis

- Skin basierend

- Mehrere Forms

- Unterstützung für controls wie Buttons, Labels, Panels, Combobox, Radiobutton, ProgressBar, TrackBar etc.

- Möglichkeit zur erstellung eigener Controls, abgeleitet von einem Basis control,
z.b. zur nutzung als Renderausgabe für Video oder Peak visualizer.


Wäre cool: (Kann ich selbst machen)


- Render ausgabe getrennt von der Hauptcode basis,
z.b. in form von Libraries oder Abgeleiteten Klassen.

- Unterstützung für controls wie Listbox, Listview

- Unicode unterstützung

- Docking möglichkeit für alle Forms

- Unterstützung für Animationen für alle controls





Das wars zumindest mal grob was ich mir vorstelle.

Falls wer also eine "Freeware bzw OpenSource" GUI Engine schon gemacht die ungefähr meinen anforderungen entspricht,
wäre ich sehr verbunden, wenn der jenige sich hier zu wort meldet. (ICQ Kontakt erwünscht)

Werde mir dann diese GUI Engine anschauen und entscheiden ob diese verwendet wird.

Fairerweise wird derjenige dann auch in der Credits sowie auf der Hauptseite von Xenorate erwähnt.



Für interessierte: http://www.xenorate.com


Danke,
Final

Hmm, kann das sein das meine anforderungen zu hoch sind oder hat einfach niemand interesse seine gui engine mir zur verfügung zu stellen ?

Na ja. Die Anforderungen die du da hast sind nicht gerade klein. Um es vorsichtig auszudrücken.

Das GUISystem besteht in deinem Falle ja auch nicht nur aus Komponenten sondern es muss sich auch noch um die Fensterverwaltung des Betriebssystem kümmern. So weit ich das weiß wurde so etwas bisher nur in der GUI berücksichtigt an der TAK2004 bastelt. Allerdings ist diese noch nicht fertig und ob du sie dann sinnvoll in Pascal benutzen kannst stehst auf einem anderen Blatt.

Die GUI die ich noch in der Schwebe habe wird für eine recht komplexe Anwendung geschrieben die ich in der Planung habe. Das wird dann vermutlich deinem Problem nahe kommen. Aber das wird erst noch. Wenn ich realistisch sein soll wohl in diesem Jahr nicht mehr.

Alternativ würden mir noch QT und GTK einfallen. Aber so genau weiß ich auch nicht in wie weit die sinnvoll brauchbar sind und ob du da nicht eher noch einen riesen Batzen sonstiger Bibliotheken mit dir rumschleppen musst.

Hallo, Finalspace.

Vorneweg:

1. Ich arbeite derzeit von Tak2004 getrennt - hat irgendwie nicht funktioniert mit der Zusammenarbeit.
2. Trotzdem fühle ich mich an die Vorgaben, die im Wiki stehen und in einem dgl-Thread erarbeitet worden sind, gebunden. Das heißt, ich werde den Code zur Verfügung (und auch zur Diskussion) stellen, und es wird die vereinbarte Lizenz haben.
3. Meine GUI ist im Test-Stadium. Folgende Elemente sind erstellt und funktionieren auch schon, sind aber noch nicht fertig getestet:

// TGUIBUTTON
// TGUICOMBOBOX
// TGUIEDIT
// TGUIIMAGE
// TGUIINDEXITEM (TextItem,ImageItem,CheckItem,TreeItem)
// TGUILABEL
// TGUILISTBOX
// TGUIMENU
// TGUIMENUITEM
// TGUIMOVABLEPANEL (for demonstrating purposes only)
// TGUIPANEL
// TGUIPROGRESSBAR
// TGUISCROLLHORIZBAR
// TGUISCROLLVERTBAR
// TGUISYMBOLBTN
// TGUITABBOOK
// TGUITABPAGE
// TGUITABSHEET
// TGUITREEBOX ("TreeView")

// WORK IN PROGRESS:
// -----------------
// TGUISTRINGGRID (*******************NOT YET READY)

// NOT YET IMPLEMENTED:
// --------------------
// TGUIRADIOBUTTON
// TGUIGROUPBOX
// TGUIMEMO

Dass so etwas wie eine Groupbox oder Radiobuttons noch nicht dabei sind, liegt daran, dass ich nach "Tasks" vorgegangen bin, das heißt, ich habe den Items den Vorzug gegeben, die Ansprüche erfüllen, welche die bereits erstellten Items nicht erfüllen können. Und Radiobuttons kann man ganz leicht durch Checkitems ersetzen. Aber das nur nebenbei.

Allgemeine Info:
----------------------
Betriebssystem derzeit: Microsoft Windows (getestet auf Windows2000, sollte aber auch auf XP laufen)
Gemäß Richtlinien im Wiki soll die GUI möglichst plattformunabhängig sein. Das habe ich in der Struktur berücksichtigt, wo alle Routinen, die eine externe Library/API benötigen, pro Library/API in einer Unit gesammelt sind (eine Wrapper-Unit für die Grafiklibrary, eine für die Windows-API,eine für die Font etc.). Nur für die Texturen habe ich mehrere Units gebraucht. Eine Linux-Unit habe ich derzeit noch nicht. Die Unit für die Windows-API ist klein gehalten (ca. 700 CodeZeilen). Außer fürs Betriebsystem verwende ich nur plattformunabhängige Libraries.

Programmiersprache Object Pascal, aber um Properties erweitert
Derzeit compiliert mit Delphi7, sollte rein grundsätzlich auch (UNVERÄNDERT) mit FPC kompilierbar sein. Habe ich aber schon lange nicht mehr gemacht, daher könnte es sein, dass hier noch die eine oder andere Änderung nötig wäre.

Schnelligkeit: ich habe kein Benchmarking anzubieten - das ist der Testphase vorbehalten - ich kann nur sagen, dass es auf meiner Maschine schnell genug ist, um angenehm damit arbeiten zu können, ich habe aber eine uralte lahme Maschine (nicht einmal ein GigaHertz)

Folgende Drawbacks habe ich:
-------------------------------------------
--- kein Editor. Also einfach eine Oberfläche mal kurz zusammenklicken geht nicht.
--- Ich habe mich zwar bezüglich des Aussehens an Windows gehalten, aber intern ist das Zeug anders aufgebaut als die VCL. Man kann also nicht hoffen, die VCL einfach mit der PasGUI ersetzen zu können.
--- Der GUI-Baum speichert sich noch nicht (alle Voraussetzungen und auch der nötige Code dafür sind vorhanden, werden aber derzeit nicht genutzt und weil vorgeschrieben ist, in XML zu speichern müßte ich auch da ein Library einbinden, und davor graust mir
--- Man kann zwar verschiedene Shapes erzeugen, aber der Hittest geht immer noch nur auf die Bounding-Box; ich habe noch keinen besseren Hittest eingeführt. Die Voraussetzung dafür sind aber vorhanden und dass es noch nicht passiert ist, ist nur auf Faulheit zurückzuführen
--- Meine ComboBox kann man derzeit nicht am unteren Fensterrand platzieren, weil die Items eine reine Zeichnung sind und keine Fenster-Handles haben und die "Lade" der Combobox dann unterm Fensterand verschwindet. Das (seufz) steht auch noch auf der ToDo-Liste
--- Es gibt noch keine Dokumentation.


Folgende Anforderungen hast Du gestellt, und ich versuche mich mal dran:


- Gut strukturierte Codebasis:
-------------------------------------
ICH GLAUBE SCHON - Die interne Maschine besteht aus einem BasisItem und daraus abgeleiteten Descendants + Beiwerk: ein (ziemlich primitiver) Grafik-Utility-manager, Theme, Font/Image/Shape-Objekt. Die Items stellen nach VCL-Vorbild auch Ereignisse zur Verfügung. Die Items bilden einen Baum. Ein neues Item erzeugt man einfach dadurch, dass man es an ein bestehendes dranhängt. Irgendwelche zusätzlichen Listen brauche ich nicht, alle nötigen Daten stecken in den Items und können auch dort abgefragt werden. Der ganze Baum löscht sich automatisch wenn das Root freigegeben wird.

Die Struktur sollte eigentlich ermöglichen, dass bei nötigen Änderungen möglichst wenig Code tangiert wird. Ich habe nicht selten schon fertigen Code wieder ausgebaut und anders eingebaut, um das Ganze möglichst schlank und gut lesbar zu machen. Ein guter Anzeiger dafür, ob etwas gut aufgebaut ist, ist IMHO die Zeit, die man braucht, um einen Laufzeitfehler zu finden, und die hält sich in Grenzen. Ich habe unten eine Übersicht beigefügt.

- Skin basierend:
--------------------
JA - OpenGL liefert Texturen. Eine Möglichkeit, das Aussehen der GUI von ausserhalb des Programms zu ändern ("Theme"), habe ich eingebaut.

- Mehrere Forms:
--------------------
JA. Das Erstellen von (Microsoft-) Fenstern habe ich inkludiert. Allerdings ist die Programmierung per Windows-API nicht meine Hauptkompetenz - um es jetzt vorsichtig auszudrücken. Aber rein grundsätzlich ist der Aufbau so gedacht, dass ein Root die Betriebssystemereignisse in Empfang nimmt und verteilt, wobei die Items, die unmittelbar dem Root untergeordnet sind, Fenster sind (bzw. sein können); das können auch viele sein. Die Fenster teilen sich miteinander einen Rendering Context.

- Unterstützung für controls wie Buttons, Labels, Panels, Combobox, Radiobutton, ProgressBar, TrackBar etc.
--------------------------------------------------------------------------------------------------------------------------------
JA (siehe oben)

- Möglichkeit zur erstellung eigener Controls, abgeleitet von einem Basis control,
z.b. zur nutzung als Renderausgabe für Video oder Peak visualizer.
-------------------------------------------------------------------------------------------------
JA. Neue Descendants werden einfach vom BasisItem abgeleitet, das System ist unbeschränkt erweiterbar. In der visuellen Gestaltung dieser Items ist man ebenfalls völlig unbeschränkt; man müsste den Grafik-Utility-Managers erweitern, um den Items mehr Möglichkeiten zur Verfügung zu stellen. Es sollte eigentlich alles möglich sein. Schliesslich hat man OpenGL zur Verfügung.

Wäre cool: (Kann ich selbst machen)
- Render ausgabe getrennt von der Hauptcode basis,
z.b. in form von Libraries oder Abgeleiteten Klassen.
-------------------------------------------------------------------
JA. Die GUIItems zeichnen nicht selbst, sondern "ordern" das Zeichnen. In meiner Anwendung übernimmt OpenGL das Zeichnen mittels simpler Displaylisten. Die "Rendering Engine" ist geradezu winzig

- Unterstützung für controls wie Listbox, Listview
----------------------------------------------------------
ListBox: JA, ListView: NEIN. Iich bastel grad an einem StringGrid (weil ich das für meine eigene Anwendung brauche)und sehe keinen Sinn darin, eine Listview zu schreiben, wenn ich ein StringGrid habe, das mehr Möglichkeiten hat als das Listview.

- Unicode unterstützung
-------------------------------
NEIN. Ich verwende FreeType und stelle eine ISO 8859-1 (Latin script; no unicode) Schrift mit 256 Zeichen zur Verfügung (texturbasierte True-Type-Schriften)

- Docking möglichkeit für alle Forms
----------------------------------------------
NEIN. Wie leicht das ist, Docking-Funktionalität einzubauen, kann ich nicht sagen, weil ich mich mit dem Thema gar nicht beschäftigt habe.

- Unterstützung für Animationen für alle controls
---------------------------------------------------------
Jedes GUI-Descendant kann selbst entscheiden, ob es animiert ist oder nicht. Die Animationen die ich eingebaut habe, sind die üblichen, wie z.B. Knöpfe haben im gedrückten Zustand ein anderes Aussehen als im nicht gedrückten; die Items können hovern (sich verändern, wenn die Maus über ihnen ist) usw. Ich hatte zwar schon ganz früh ein langsames Einblenden dabei gehabt, habe das aber wieder eliminiert, weil für die Sperenzchen später immer noch Zeit ist und es notwendig war, sich mal um die wichtigen Dinge zu kümmen - schliesslich hatte sich in der Anfangsphase jemand beklagt, dass wir nicht mal den Windows95-Standard hinkriegen.



Soweit, so gut.

Zu deiner Frage, ob deine Anforderungen zu hoch sind:
Ich arbeite seit mehr als einem Jahr an diesem Zeug und es handelt sich häufig dabei um grundlegende Technologien (Bilder, Schriften), um das ganze professionell zu machen, müsste man sich mit jedem einzelnen Thema viel länger beschäftigen, als ich das machen konnte. Dabei habe ich mich wochenlang mit JPeg herumgeschlagen, Freetype war auch kein Honiglecken, der Debugger ist heissgelaufen. Gerade an den Punkten, wo es wirklich interessant wird, hören die Informationen meistens auf und man ist auf seine eigenen dedektivischen Fähigkeiten angewiesen. Und immer war ich versucht, in ein anderes Gebiet abzudriften. Z.B. bei der Beschäftigung mit Bildformaten ging mir immer die wahwitzige Idee durch den Kopf, ob das nicht Stoff für einen Mediaplayer hergibt, was natürlich Unsinn ist. Dabei geht auch Zeit drauf. Ich habe z.B. ziemlich viel Zeit damit verbracht, die Imagekomponente um ein Wavelet zu erweitern. Für mich ist das schließlich ein Hobby.

Und Unicode - ehrlich, da musst Du zu einem kommerziellen Anbieter gehen. DU selber wolltest auf diesem Gebiet ja schließlich auch nicht mehr weitermachen. Ich kann nicht aufhören, weil ich eine Migration nach Linux plane und nicht meine ganze Programmierumgebung dabei verlieren will. Ich habs mit C++ und auch Lazarus versucht, aber - .....


Und schliesslich: Einen Termin, wann das ganze fertig ist, kann ich nicht wirklich angeben, aber immerhin kann ich sagen dass es wahrscheinlich innerhalb der nächsten drei Monate hier in der Projektsparte auftauchen wird - es sei denn, der Himmel fällt mir auf den Kopf. Ich wollte gerne eine Testanwendung dazu schreiben und habe an einen IconEditor gedacht, und dabei ist mir aufgefallen, dass mir ja gar kein FileOpen-Dialog zur Verfügung steht, aus diesem Grund habe ich die TreeBox geschrieben undsoweiter undsoweiter....Das Zeug ist wirklich endlos. Immer wenn ich glaube, dass ich jetzt alles fertig habe, entdecke ich, dass mir immer noch etwas Wichtiges fehlt und ich rede hier nicht von exotischen Features.

Du sagtest, dass Du den Autor bei Deinen Credits erwähnen willst. Ich bitte Dich, das nicht falsch zu verstehen, aber das ist mir nicht so wichtig. Wenn Du es brauchen kannst, wäre es viel besser, Verbesserungen, die Du anbringst, oder Ideen, die Du dazu hast, ins Projekt einzubringen (wie wärs mit einer Linux-Unit? Ich habe irgendo mitgekriegt, dass du so etwas schon gemacht hast). Wie auch immer, solltest Du Dich an die beigelegte Lizenz halten (Öh, ich muss sie erst ausgraben, ist irgendwo auf meiner Festplatte verschollen). Aber wenn Du es nicht tust, wirds wohl auch nichts machen. Ich bin (bzw dgl ist) schließlich nicht Microsoft.
Traude

Ich missbrauche diesen Thread jetzt einfach mal, um deine (Traude) GUI zu kommentieren.

Mal abgesehen davon, dass ich von der Länge deines Postings geschockt war (nichtmal Phobeus oder so hat mal sowas langes geschrieben glaube ich ) bin ich beeindruckt, was das ding drauf hat.

Wobei ich mich aber Frage, warum du sagst, dass man wegen Unicode zu einem Komerziellen Anbieter gehen müsse. Unicode lässt sich doch wunderbar einfach mit SDL_TTF und den UTF8-Renderaufrufen erledigen. Halten kann man UTF8 Strings wunderbar in normalen AnsiStrings, da sie ja in den meisten Fällen sowieso nur aus einem zeichen Bestehen und wenn man dann doch mal mehr hat ist das auch egal, es sei denn man ist auf Length-Routinen oder so angewiesen. Da muss man sich dann eben selber was schreiben, das prüft wieviele "echte" Zeichen der String enthält (ist ja simpel, alle die zeichen, deren höchstes Bit 0 ist)

Wegen der Linux-Unit wirds interessant. Wie hast du denn die Windows-Fenster erstellt? Native API-Aufrufe oder VCL (wobei bei FPC VCL natürlich schwer wird,
also wirds wohl API sein, oder?) Und wenn es VCL / LCL wäre, gäbe es ja auch kein Problem mit Linux, da die LCL da ja auch einen wunderbaren Wrapper zu GTK oder ähnlichem bietet.
Bei Linux muss man sich dann halt überlegen, ob man auf GTK(2) oder QT zurückgreift oder sich direkt mit X-Server schlägt, wobei ich nicht weiss, wie das dann ausgeht, ich habe mich damit ehrlichgesagt noch nie befasst (SDL rulez ). Apropos SDL, in deren Sourcecode könnte man bestimmt etwas zum Thema Fenstererzeugung und Ereignissbehandlung unter Linux finden.

(Posting mag zwar ein wenig an der Topic vorbeigehen , aber es fehlt eben ein Projektthread )

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich habe an dem Text ziemlich lange rumgefeilt und ich wollte alles Wesentliche unterbringen.

Und ja, ich verwende die Windows API. Dabei sind mir noch mehr graue Haare gewachsen, als ich sie ohnehin schon habe.

Ein guter Grund, warum ich micht um Unicode drücke ist: ich hasse programmieren mit Text. Du kannst mich zu allem kriegen, ich tu alles, wenn ich nur nix mit Text machen muss. Ich bezweifle, ob ich mich je an die MemoKomponente wagen werde.
Viele Grüße übrigens, Lord Horazont.

Nachtrag: einen ProjektThread mache ich erst, wenn ich eine Bespielanwendung beilegen kann.

Erstmal,

respekt, hab mir alles durchgelesen und muss sagen, das klingt alles wirklich super
Scheine doch sehr interessiert zu sein und würde mir gern mal das angucken was du schon hast.

Ich brauch auch kein editor oder so, kann das alles von hand machen.
Würde dann einfach die aktuelle Xenorate GUI nachbauen und gucken wie weit es passt.

Und wegen Unicode, wie Lord Horazont gesagt hat, kann man das via SDL_TTF super realisieren.
Habe sogar schon einiges gemacht in der richtung, habe zumindest ne grobe ahnung wie man Applicationen für Unicode support umbaut.

Ich hab hier sogar ne Xenorate 2 Unicode version rumliegen, wobei diese TnTUnicodeControl benutzt hat
Trotzdem hab ich 70% vom code aufreissen müssen und sämtlichen code umbauen -.- (TextOutW etc.)
Aber is eh egal, da 2.x eh tod ist.

Du hattest das mit Linux erwähnt, also ich habe bisher nur versucht per plain X in fpc, mehrere fenster (dynamisch) zu erstellen.
Ist mir im grunde gelungen, nur hat es noch kein GLX also OpenGL für ausgabe.
Sprich wäre auch nicht abgeneigt eine Linux unit zu basteln, wobei diese auch wiederrum eine eigene render lib brauch.
Dadurch würde ich meine X/XGL kenntnisse erheblich steigern können

Ich fände es gut wenn angagierte DGLer zusammen arbeiten. Ich kann mir vorstellen, dass dadurch die Kompetenz bei der ein oder anderen Antwort fürs Forum gesteigert wird. Ihr seid ja nun beide nicht mehr auf nem Einsteigerniveau. Ich denke da sollte man sehen, ob eine Zusammenarbeit nicht fruchtbar wäre.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

FinalSpace,


Ein gangbarer Weg wäre, das derzeitige Fontobjekt durch ein anderes Fontobjekt zu ersetzen. GENAU DAS soll die GUI können: mit allen möglichen Objekten nach einem Standard zusammen arbeiten können. Und das kann ich nur erreichen wenn sich dieser Standard irgendwie herauskristallisiert. Wenn es mit SDL_TTF einfach geht, ist eigentlich nichts dagegen einzuwenden.



Genau so hätte ich es mir vorgestellt. Meine Unit GraphicSupport braucht ja auch das Betriebssystem. Das Problem mit den vielen zwischengeschalteten Libraries (Stichwort GTK) ist häufig, dass man sich damit die geradlinige Struktur zerstört. Deshalb fände ich es toll, wenn man es in Linux genauso macht, wie ich es jetzt in Windows mache. Das gibt einen schönen cleanen Aufbau und einen sauberen stabilen Code. Wenn Du in dieser Richtung etwas machst, wäre ich Dir sehr dankbar. Eigentlich war es gedacht, das ganze so zu gestalten, dass man die derzeitige RenderLib - die Unit GraphicSupport - auch im Linux verwenden kann. Das Ziel wäre, bei einem Wechsel des Betriebssystems bloß die Unit OSSupport austauschen zu müssen. Was jetzt nicht heißen soll, dass die anderen Units nicht ausgetauscht werden dürfen.

Ich möchte nicht mit Source Code geizen. Aber Du musst mir genügend Zeit lassen, um zumindest ein Hauptprogramm zu basteln, bei dem man sich auskennt. In meinem derzeitigen sind einfach alle GUIItems, die ich bereits gemacht habe, aufgereiht und nur das Element, das gerade getestet wird, ist nicht auskommentiert - rein grundsätzlich wird sich das nicht ändern, aber ich möchte zumindest ein paar Kommentare dazu hineinschreiben. Oder etwas deutlicher: das Testprogramm ist ein unleserlicher Trümmerhaufen und genau das Testprogramm brauchst Du aber, weil dort drin steht, wie man das Ding ordnungsgemäß aufbaut. Wenn Dir genügt, mal einen Blick auf die Performance zu werfen, sollten, na sagen wir, zwei Tage reichen (dh. nicht vor Donnerstag Abend, denn morgen hab ich keine Zeit) um zumindest ein verständliches Hauptprogramm mit Kommentaren zu basteln, bei dem Du Dich auskennst. Die Units sind vom Aufbau her gut gewartet und verständlich geschrieben und brauchen daher nicht geändert zu werden. Es muss Dir aber klar sein, dass vielleicht Fehler auftreten, denn die Testphase hat noch nicht begonnen, und ein paar "known bugs" hab ich natürlich auch

Zwei Goodies habe ich noch gar nicht erwähnt (keine Ahnung ob Du das brauchen kannst):

1. Man kann in die GUI nicht nur Methoden, sondern auch Prozeduren einhängen. Die Anforderung stammt von Tak2004.
2. Mein Trumpf-As und Liebling ist das ImageObjekt. Es hat die Aufgabe, Speicherplatz bereitzustellen und das in den Hauptspeicher geladene Bild ins OpenGl zu verschiffen und hat ein paar Manipulationsmöglichkeiten drin (horizontal flippen, 24bit auf 32 bit erweitern, Bild auf PowerOfTwo skalieren - auch eine Errungenschaft der letzten Woche). Das Laden/Speichern läßt es von dafür spezialisierten ImageProvider-Objekten per Stream durchführen. Der Basis-ImageProvider kann BMP 24bit und TGA 32bit lesen und schreiben (komprimierte TGAs nur lesen derzeit), und letzte Woche (ich war letzte Woche sehr fleissig) ist es mir endlich gelungen, einen JPEG-Provider mit der PasJPeg aufzusetzen (zwar nur lesen, aber bis er auch schreiben kann ist es nur eine Frage der Zeit sag ich mal jetzt etwas großmäulig). Für weitere Bildformate wären weitere Imageprovider zu schreiben.

Viele von diesen Ideen stammen aus der glBitmap (meine Referenz an den Großmeister). Ich verwende aber keine TBitmap, sonst wärs ja plattformabhängig, sondern das Bild sitzt in einem ganz normalen dynamischen Array drin. So etwas wie "ScanLine" hab ich nicht, kann aber nicht schwer sein einzubauen.Wer so etwas nicht haben will: es gilt das gleiche wie oben bei der Font, auch das Image-Objekt sollte austauschbar sein.

Die Stossrichtung ist ganz klar: Programm in Delphi debuggen, es ins FPC stecken und dort unverändert auch kompilieren = die Freiheit, aufzubrechen, wohin ich will (hoffentlich erwischt mich Bill Gates nicht dabei ).

Gerade in dieser Community kommt immer wieder das Problem hoch, dass man es mal gerne mit FPC probieren will, man weiß aber nicht wie. Aber man stößt dort auf Grenzen, die einen zwingen, alles, was man bisher kennt über Bord zu werfen und neu anzufangen. Eine GUI, die sowohl in Delphi als auch in FPC läuft könnte eine Art Brücke bilden. Man kann sich's bequem im altbekannten Delphi ansehen und "beschnuppern". Wenn man es dann mit FPC "aufnimmt" braucht man wenigstens nicht alle Programme neu zu schreiben.

Mich hat immer gestört, dass ich meine Sachen nicht aus dem Delphi hinüber ins FPC bringen kann. Sowohl Borland/Inprise/CodeGear kochen ihre eigenen Süppchen als auch FPC. Und genau da wollte ich ansetzen: man baut eigene Features, die in beiden Welten funktionieren. Warum? Ich mache damit die Straße von Delphi in Richtung FPC ein wenig breiter. Ich möchte hier zart andeuten, dass für mich die GUI auch einen weltanschaulichen Aspekt hat. Das ist eigentlich sogar meine Hauptantriebskraft, sonst hätte ich es bis hierher kaum geschafft, denn der Spaßfaktor beim Stochern in Bits ist endenwollend.

Übrigens: arbeitest Du mit Threads? Könnte das ein Problem geben beim rendern?

Bis Donnerstag Abend
und viele Grüße
Traude

@Flash: Vielleicht wird es eine Art "Keimzelle" halt uns die Daumen

Also generell ist mir eigentlich egal, ob code unkommentiert ist oder nicht.
Denke das ich damit zurecht komme, gerade deshalb weil ich seit nem halben jahr versuch den VLC Source halbwegs zu verstehen O_o
welches eine überaus geniale Plugin und Threading Technologie besitzt.

Und zu deiner frage ob ich mit Threads arbeite, nur wenn ich sie wirklich brauche.
Aber für Xenorate 3 werd ich wohl seine sehr böse thread struktur mir ausdenken,
damit ich das mit dem Parsen/Decoden/Rendern richtig gut verteilt bekomme.

Ob das später beim rendern probleme gibt, weiss ich nicht... aber da wird sich nen weg finden.

Momentan steh ich sogar vor der frage, ob ich nicht versuchen soll richtigen libAVCodec/libAVUtil (ffmpeg) support in fpc zu machen.
Das würde so aussehen, das ich mir ne C Lib bastele die direkt die ffmpeg quellcodes enthält und alles per library exportiert.
Ich kenn da jemand wo schon gute erfahrung mit ffmpeg gemacht hat *g* (In Richtung Aya guck )

*grml* Ich hasse FFMpeg... :p Wenn es nicht die einzige mir bekannte lib wäre die diese ganzen exotischen formate kann, würde ich sie sofort wegwerfen
Aber gegen die geschichte mit der lib spricht nichts, so mach ich es beim Flipbook ja auch

Naja, FFMPEG ist eigentlich schon gut, ansonsten würden Player wie VLC, Mplayer nicht sobeliebt sein
Das dafür keine doku existiert ist schade, aber was will man machen.

Und als wirkliche alternative gibts halt nur DirectShow, welches definitiv nicht schlecht ist.
Aber MS only, somit wäre man z.b. aufgeschmissen wenn man ne Plugin Struktur haben will,
wo die einzelnen parts getrennt sind und abhängig funktionieren.

Es geht halt nicht wirklich, das man einzelne DirectShow Filter benutzen kann ohne die Gegenstücke zu benutzen.
Der einzige mir bekannte player der das kann ist MPlayer, und selbst dieser hat eigene modifizierte DShow dll´s damit das möglich wird.

Ich bin nicht FFMpeg. Und daher würde ich gerne ein paar Kommentare hineinschreiben. Das hat nichts mit Dir zu tun. Ich nehme an, dass sich auch noch andere den Code ein wenig ansehen wollen. Ich bezweifle nicht, dass Du etwas damit anfangen kannst, aber ICH möchte keinen Code-Abfallhaufen reinstellen.

Zu FFMPeg: Neben mir liegt das Buch: Tilo Strutz: "Bilddatenkompression". Das FFMPeg-SVN liegt auf meinen Browser-Favoriten.


NACHTRAG: Hat einer von Euch schon einmal daran gedacht, die Gecko-Engine zu benutzen? Grade FinalSpace hat mir vor ca. einem Jahr, alse er sich meine kümmerlichen Anfänge angesehen hat, gesagt, dass er ein Webinterface bevorzugen würde. Gecko, denk ich mir, ist doch ein Webinterface.

Ähm, Gecko war doch die Renderengine von Mozilla ?
Also zum anzeigen von Webseiten.

Ja, genau. Ich hab es mir nicht angesehen, aber es müßte plattformunabhängig sein. Ich nehme an, in c++ geschrieben. Das bedeutet, man müßte einen Header dafür haben. Leider ist das nicht so einfach. Ich habe beim Einbinden von JPEG folgende Erfahrungen gemacht:

1. Man kann die PasJPeg nehmen, das ist Pascalcode, und es funktioniert (Aya sagte hier einmal, dass sie nur zwei Stunden fürs anbinden von JPeg gebraucht hat, also ehrlich: ich hab VIEL länger gebraucht, vielleicht weil ich Zeiger auf Zeiger nicht gewöhnt bin.)

2. Ich wahr wahnwitzig genug, zu versuchen, einen Header für die JPeg.dll zu schreiben, es hat aber nicht geklappt. Beim Einlesen von JPeg muss man im Header das riesige jpeg_decompress_struct definieren. Wenn man da irgendwo einen winzigen Fehler macht, gehts schon nicht mehr.

Dann habe ich gesehen, dass in der JPeg.Pas von Borland auch keine Dll benutzt wird, sondern obj-Dateien (von denen der Autor ganz genau weiß, wie sie aufgebaut sind, weil er sie selber mit dem Borland-C-Compiler erzeugt hat). Das Header-Basteln hat also seine Tücken.