Traude, wenn ich jetzt wüsste was ein Blitzkneisser ist.

Aber das mit den Webinterface ist noch nicht richtig. Der Player beinhält einen Webserver und DU kannst mit deinem Browser darauf zugreifen und dem Player Befehle erteilen. Ich habe im Web gesucht aber ich habe kein Beispiel gefunden. Aber hier ein Beispiel von meinem Programm mit dem ich fernsehe bzw Sendungen aufnehmen kann. Das Ding hat auch ein Webinterface. Damit kann ich direkt Programmieren welche Sendungen ich aufnehmen möchte bzw dann auch auch löschen oder die Dateien auf der Festplatte löschen etc etc etc. Sozusagen eine Fernbedienung via Browser.

'Tschuldigung, ein Blitzkneisser ist ein humoriger wienerischer Ausdruck für jemanden, dem man immer alle Infos geben muss, damit er endlich was versteht.

Leute ihr versteht da einiges falsch

Ich wollte ja nur mal paar vorschläge gern hören, wie man mehrere GUIs (Graphical User Interface) in eine Anwendung als Seperate Librarys packt.
Dazu noch von anfang an, an Cross Platform Programmierung zu denken.

Genau das mach ich auch momentan, ich bastel momentan eine Delphi/FPC Applikation welche so aussehen soll:



Bisher was ich gebastelt habe:

- 1 GUI Thread erstellen, Library laden und Refreshen bis ne Taste gedrückt wird.

Funzt bisher ganz ok, habs aber noch nicht auf Mehr GUIś umgebaut, welches ich aber heute mache.
Für meine erste GUI hab ich nen Linux XLib fenster erstellt, da das einfacher ist als der dumme WinAPI kack.

Es gibt eine unübersehbare Anzahl von professionellen GUIs, auch als DLLs, auch mit OpenGL.

Wenn Du ohnehin eine solche Library verwenden möchtest, wo ist dann das Problem? Denn die Threads können wohl nicht das Problem sein.

@ Zu Lazarus: Lazarus verwendet für Windows die native Windows API und für Linux GTK. Das bedeutet, Du kriegst dort die Fensterchen, die für das jeweilige Betriebssystem üblich sind. Gerade weil Lazarus seine Schwächen hat gibt es neuerdings für FPC auch eine andere GUI: http://wiki.freepascal.org/MSEide_&_MSEgui, aber die Anzahl der Möglichkeiten ist ENDENWOLLEND.

Meist gibt es das übliche Zeug: Fenster+Widgets. Spiele haben einen anderen Anspruch als die normalen Anwendungen, und ich versuche, dem gerecht zu werden. MEIN Anliegen ist eine Brücke zu schaffen zwischen dem vorhandenen Delphi - das viele Anhänger hat aber eben nicht plattformunabhängig ist - und dem vorhandenen Free Pascal, das zwar plattformunabhängig ist aber nicht so komfortabel.

Was ich als das größte Problem dabei ansehe, ist nicht der Programmaufbau, auch nicht dass Features fehlen würden. Sondern dass hier (Delphi) wie dort (Free Pascal) verschiedene Features für ein und dasselbe Problem existieren, eine schmerzliche Erfahrung, die man sowohl beim Generieren von Schriften als auch beim Laden der verschiedenen Bildformate macht. Man kann daher nicht einfach leicht eine GUI von hier nach dort portieren. Dieses ist das erste Problem, das man in den Griff kriegen muss.

Zunächst sieht es so aus, als ob das mit SDL gut gehen würde. Aber das täuscht:
-- wir haben zunächst einmal nur den Support für EIN Fenster
-- wir haben die üblichen Fenster des Betriebssystems (mit Balken etc.). Wenn Dir das reicht, OK, dann ist SDL für Dich geeignet.

Aber: Je mehr ich an dem Fenster ändern kann - Form, Verhalten, etc., desto lieber ist es mir (wir sprechen hier von Spielen!). Ein völlig leeres Rechteck (oder auch eine andere Form) ist mir als Fenster daher am liebsten. Also nehme ich für Windows ein leeres Popup-Style-Fenster ohne Balken und implementiere das Verhalten für Verschieben und Ändern der Größe selber. Aber das ist ein langer und mühsamer Weg (das hast Du offenbar schon gemerkt), zusätzlich zu dem oben geschilderten Problem.

Lossy schrieb:

@Lossy: Meine***) GUI ist kein kommerzielles Programm. Und, soweit ich das verstanden habe, ist der Mediaplayer ebenfalls mit Pascal gebaut worden. GUI-DLLs, die für C geschrieben sind gibts genug. Man müsste sich nur einen Pascal-Header dafür basteln. Ich seh das genau andersrum: es FEHLT an einer Schnittstelle, die für Pascal geschrieben ist. Grade DGL ist finde ich dazu aufgerufen, diesen Mißstand zu beseitigen, weil wir hier die Ressourcen dafür haben. Ich brauche diese Schnittstelle selber auch. Man hätte dann die Möglichkeit, mit dem komfortablen Delphi zu entwickeln und das Programm/Spiel einfach mit FreePascal nach Linux zu portieren, ohne irgendwelche Änderungen am SourceCode vornehmen zu müssen.
Traude


@Edit: ***) Das "meine GUI" ist Blödsinn. Es ist EURE GUI, weil sie hauptsächlich auf Ideen der DGL-Member aufgebaut ist.

Traude: Ich bin generell nicht dafür eine Schnittstelle auf eine bestimmte Sprache festzuzurren. Und ich meine damit ja auch nur, dass man da keine Sachen wie Objekte/Strings (pchar ja) oder so etwas verwenden sollte. Das würde evtl den Aufwand zum Entwickeln von PlugIns etwas vereinfachen aber dafür dann nur noch PascalPlugins zu ermöglichen?? Worin das Programm die Plugins geschrieben worden spielt ja keine Rolle. Sie sollten nur sinnvoll miteinander kommunizieren können. MediaMonkey ist in Delphi geschrieben worden und schluckt Problemlos die Plugins von WinAmp. Bis auf die die Playliste verändern wollen. Aber das wird wohl einfach nicht implementiert sein vermute ich. Das ist aber nicht das worum es Finalspace geht.

Finalspace: Hatte ich im letzten Beitrag geschrieben. Ich empfinde es als das einzig Sinnvolle, wenn die Plugins komplett ohne echte GUI auskommen und nur über eine gewrappte GUI kommunizieren. Diese wird von der Hauptanwendung zur Verfügung gestellt. Du müsstest dir ein Mal eine GUI Schnittstelle ausformulieren und solltest ALLES dann über diese Schnittstelle abwickeln. Nicht mal der Hauptplayer darf dann außen vorbei etwas machen. Und zum Austaschen müsstest du dann die entsprechende Klasse austauschen. Oder du könntest es auch so gestalten, dass du da einen Satz Funktionen aus einer DLL bekommst.

Was das untendrunter angeht hat dann deine GUI Schnittstelle alle Zügel in der Hand. Da könntest du ein ganz normales Betriebssytemfenster erstellen und mit OpenGL etwas hinzaubern oder was dir sonst noch in den Kopf kommt. Falls da etwas Betriebssystemabhängig ist macht das eigentlich auch nichts, weil der Code sich wahrscheinlich in Grenzen halten sollte. Zu mindest sofern du untendrunter etwas unabhängiges benutzt.

Hoffe ich habe dein Problem halbwegs verstanden.

Ok lossy ich glaub ich hab kapiert was mit deinem vorherigem Post gemeint hast.

Im grunde ist es "fast" das was ich haben will.

Aber ich werd mal versuchen das zu verbildlichen was ich machen will, denke das wäre einfacher =)

Was hier gefordert wird ist ein klassicher Software Engineering Fall.
Es sollen GUI,Daten,Logik getrennt vorliegen.
Die Daten sind z.B. Mp3s, Logik sind encoder,playlist,... und GUI ist die Visualisierung der Logik.
Hierzu muss erstmal ein Interface her, also eine Schnittstelle die die gebrauchten funktionen bietet.
Erstelle Fenster, Erstelle Button, zeichne Button, Event Handling(Events sind GUI bezogen und gehören hier rein).
Dieses Interface besteht aus Klassen und ist einfach gesagt tot, kann nichts.
Man muss nun über Module wie z.B. eine DLL oder hinein compilierten Code die Funktionalität an die Schnittstelle knüpfen.

Also muss dir vorher schon klar sein, welche Funktionen du brauchst.
In deinem Fall müsste die DLL also nur im export Funktionen haben, die an dein Interface gelegt werden.
Was du intern dann machst, um die Funktionen zu liefern ist eine andere Geschichte.

Wichtig ist nur das das Interface korrekt konzipiert ist.
DGLGUI verfolgt dieses Konzept auch, es stellt ein Interface(dglgui,dglctrls,..) und erst die includefiles(gpu,cpu,window) bringen die Funktionalität. Wenn man die Includes auswechselt, also z.b. statt sdl nun gtk oder OS API in der Window Include file nutzt, dann ändert dies nichts an der Funktionalität der GUI. Man kann auch z.B. für gpu DX statt OpenGL nehmen oder OpenES am ende ist die GUI die gleiche.

Dein Media PLayer braucht z.B. ne Fensterklasse, welche die Ausmaße besitzt,vieleicht noch ein Fenstertitel und das war es.
Die Klasse ruft dann den vom Modul gelieferten drawbefehl aus und übergibt die 5 Parameter.
Klickst du auf das Fenster, dann wird dein Modul dies irgendwie registrieren und kann dann z.b. ein Stack damit befüllen.
Wenn dann deine GUI Interface dann die funktion zum abruf des EventStacks abruft, kennt es den Event und kann entsprechend drauf reagieren(z.b. ein Logiccode ausfüren der den sound pausiert).

Du kannst allerdings noch abstrakter ran gehen und sagen, es gibt eine Klasse GUI und übergibst ihr alle funktionalitäten des Players.
Diese Variante würde ich wählen, wenn es nicht nur bei einem Fenster bleibt, sondern auch mal ein WebService,... sein soll.
Dann muss im Modul wirklich alles gemacht werden also die ganze GUI und dort wird dann auch auf die callbacks zu gegriffen.
In dem Fall betrachtest du den Player als Library und dein Modul als Programm.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Dankeschön Thomas,
für Deinen Beitrag.
Ich wollte gerade eben einen Beitrag in den Brainstorming-Tread stellen und mich aus dem Projekt zurückziehen (das ist kein Scherz). Denn wenn man unser grundsätzliches Konzept für ungeeignet hält, dann ist es sinnlos, sich soviel Arbeit zu machen, wenn es nachher ohnehin keiner verwendet. Aber Du hast ganz recht. Ich habe oben falsch argumentiert.

Aber um es noch deutlicher zu machen:
Lossy schrieb:

GENAU, das machen wir auch, jetzt sind wir d'accord. Man kann über die DGLGUI grundsätzlich verschiedene (Grafik-,Betriebssystem-) Schnittstellen ansprechen. Das wird vom Grundkonzept so verlangt:

@FinalSpace: Die DGLGUI selbst (die eine im obigen Sinne gewrappte GUI ist) stellt nur ein Kommunikationsnetzwerk zwischen dem Anwendungsprogramm und dem Benutzer zur Verfügung, das kann ihr (schon rein technisch) kein Plugin abnehmen, das soll bedeuten: um das Implementieren eines solchen Programmteiles kommst Du nicht herum, das hat auch Lossy bestätigt. Fürs Zeichen und die Kommunikation mit dem Operating System benutzt es leicht austauschbare Schnittstellen, um die Unabhängigkeit von bestimmten Libraries oder Betriebssystemen zu gewährleisten.

Nee mach mal weiter, Traude.
Ich brauchs unbedingt (d.h. falls HQ irgendwann mal soweit ist, ne GUI zu benötigen, ich schreib grade an der map-Klasse, dann kommt der Editor, der wird aber noch mit VCL-GUI).

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Meinen eigentlichen Trost beziehe ich aus der Feststellung, die Tak einmal angesichts meines Programmcodes gemacht hat: er sagte, das sähe ganz ähnlich aus wie jener Code, den J0n0s und er mal geschrieben haben.

Das ist nämlich eine ganz schwerwiegende Erkenntnis: es handelt sich eigentlich immer um Code, der verschiedene Programmstücke zusammenzustöpseln hat; deswegen muss das vielleicht auch ein Baum sein. Und dieser Code schaut wahrscheinlich zwangsläufig immer gleich aus (vielleicht sind wir ja doch nur alle von der VCL beeinflußt ). Und alle implementieren das IMMER WIEDER in ihren Programmen neu - immer wieder ein ähnlicher Code.... Warum nicht ein für allemal das Beste davon als Open Source festnageln? Wir ersparen uns damit eine Menge. Warum soll man sich das antun, das selber zu machen, wenn es schon einer gemacht hat?

Doch eigentlich nur, wenn man was lernen will. In diesem Zuammenhang fällt mir ein guter Werbeslogan der Transportwirtschaft ein: "Mit dem LKW. Oder wollen Sie es selber tragen?"



@EDIT: Sidorion: Nein ich mach schon weiter. Ich brauchs ja auch. Nur weil es ein Community-Projekt ist, ist es vielleicht ein bisschen langsam. Aber ich muss Euch ein Kompliment machen: Dieser Code, den ich jetzt habe, ist qualitativ um einen Quantensprung besser als einer, den ich allein im stillen Kämmerchen geschrieben hätte.

Das weicht gerade doch ziemlich stark von eigentlichen Thema ab. Wenn ihr das weiter disskutieren möchtet dann bitte in einem anderem Thema oder aber wir schneiden es für euch ab. Danke

Nein, es handelt sich genau um die Beantwortung der ursprünglichen Frage.

Was braucht FinalSpace? DU sagtest: einen GUI-Wrapper. Es war finde ich notwendig, dieses Thema zu verbreitern, weil wir hier in einem Forum sind und das vielleicht auch andere interessiert, was das ist: ein GUI-Wrapper, und was auf jemanden zukommt, der so etwas in Angriff nehmen will.

Und ich, der ich so etwas selber geschrieben habe, habe nicht kapiert, was genau jetzt damit gemeint ist. Natürlich kannst Du jetzt sagen, ich bin wieder ein Blitzkneisser aber vielleicht war es doch notwendig. Ich ersuche Dich daher dringend, hier nichts abzuschneiden.

Ich meinte deinen angedrohten Rückzug aus dem GUI Projekt. Bzw. hat sich der eine Beitrag für mich sehr stark nach einem Für und Wieder einer gemeinsamen Spezifikation angehört. Und das geht meiner Meinung nach doch etwas zu weit von der eigentlich Frage weg. Was aber wieder reine Geschmacks und Auslegungssache ist.

PS: Mit abschneiden habe ich nicht löschen gemeint sondern das Abtrennen von Beiträgen in ein neues Thema. Sonst hätte ich ja löschen gesagt.