Tach,

ich würd mich mal gern mal mit dem thema FPC richtig beschäftigen.
Die ganze progge ich unter Delphi 5 bzw. Turbo Delphi, allerdings halt nur unter win

Da gibts paar sachen die mir schleiersaft:

Ist es mit SDL möglich mehrere Fenster zu erstellen ?
Kann SDL kram in ne Library packen, so das z.b. in library 1, 1 fenster ist.
In library 2, 2 fenster, in library 3, 3 fenster.. so das man am ende 6 fenster hat usw.

Ich kenn SDL bisher nur soweit, das es 1 fenster erstellt, der GL context da drauf läuft und fertig.

Was ich eigentlich möchte ist nen GUI Framework bauen, wo Platform unabhängig ist, da bietet sich halt SDL direkt an.

Oder muss doch via $FDEF codepfade für GUI Programmierung für das jeweilige OS bauen ?



Thanks,
Final

Hallo Finalspace,


Ich habe gerade wieder nachgesehen: http://www.libsdl.org/download-1.2.php
Die letzte Version ist immer noch 1.2.11

Die Mehrfensterversion ist soweit ich weiß für die Version 2.0 vorgesehen - wann die kommt, weiß ich nicht. Sie reden allerdings schon ziemlich lange davon. Ich habe gerade die Seite abgesucht nach "multiwindow", aber alle Treffer brachten ein Ergebnis 404 Not Found.


Ich mach das gerade für Windows, und zwar so, dass für den Umstieg auf Linux nur eine Pascal-Unit zu ersetzen ist. Ich baue an einer Mehrfensterversion, und das funktioniert schon; lauffähig mit Delphi und Freepascal, Vorgabe OOP. Ich würde mich freuen, wenn Du Dir meine letzte lauffähige Version ansiehst. Die aktuelle Version ist derzeit nicht lauffähig (siehe Communit-Thread "Brainstorming", mein letzter Beitrag). Wenn Du das willst, stell ich Dir die letzte lauffähige Version (SourceCode) hier rein. Ist aber nur eine Version "in construction", kein fertiges Programm.
Traude

Also ich weiss nicht, welches Projekt meinst du ?

Ich hab nur das User Interface Community gefunden, aber da find ich nix zum ziehen.
Hast dus auf SVN oder so ?

Und ja, ich hab SDL 1.2.11, und laut doku funktioniert das mit den Mehrfenstern noch nicht.
OS = Gentoo Linux 2.6.19 (i686)

Wenn du mir mal erklärem könntest wie du das machst mit den mehreren fenstern, wäre cool.

Was ich mir überlegt habe, wäre z.b. wenn du 5 Fenster haben willst.

5 Threads zu machen und in jedem Thread nen extra fenster, also sprich überall SDL initialisieren pro thread.
Keine ahnung ob das funzen würde, aber so würd ichs machen.

Meld ich mal zu Wort.
SDL1.3 soll mehere Fenster unterstützen, die version ist noch nicht release ist aber im svn ladbar.
Wenn du ne beta nehmen willst, dann kannst du die vom sdl svn ziehen.

Wir entwickeln seit geraumer Zeit eine eigene GUI also für die Community, damit platformunabhängigkeit und Qualität gewehrleistet werden. Wir selber sind aber auch noch im Beta Statdium.
DGKGUI, wie es wohl am Ende heissen wird, hat windows(winapi) und linux(xlib api) support, es werden mehere Fenster und umfangreiche Komponentenset geboten. Dinge wie xml formulare, Scriptanbindung und Themes sind auch geplant.

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

Projekte: https://github.com/tak2004

Bei den 5 Threads hättest du aber trotzdem nur EINE sdl.dll im Speicher. Und darauf kommt es an. Das ist ein Nebeneffekt den ich bei der OpenGL DLL auch ausnutze. Du könntest zwar die sdl.dll kopieren aber davon kann ich dir nur abraten. Vor allem, da die Header das auch statisch einbinden.

Ja, das ist der richtige Thread, aber ich geb zu, da gehts ein bisschen durcheinander. Meine Version der Sache habe ich jetzt grade auf den neuesten Stand gebracht, sowohl auf Taks Server svn://www.linuxprofessionals.org/dglgui/sandbox/traude als auch im Brainstorming Thread, und zwar auf Seite 24 ganz unten. Du brauchst, um das Demo laufen zu lassen, alle drei Attachments und auch den OpenGL-Header und solltest Dir auch den zugehörigen Beitrag durchlesen.


Wir benutzen einfach die Windows API und haben den Windows spezifischen Code auf eine Unit beschränkt. Beim Umstieg auf Linux sollte dann diese Unit einfach durch ein Linux-Unit ersetzt werden. Die Fenster werden also mit dem Windows-Befehl CreateWindow erzeugt, die Events werden aus der Windows-Message-Queue geholt und so weiter.

Ich bin nicht so optimistisch wie Tak: von Beta sind wir noch ein wenig entfernt.


Ich kann Dir leider auch nicht sagen, ob das funktioniert. Müsste man ausprobieren. Ich habe jetzt im Augenblick mehrere Fenster, die in einem einzigen Thread laufen, aber jedes Fenster hat einen eigenen Rendering Context. Die Anzahl der Fenster ist zwar nicht begrenzt, aber ich finde, man sollte damit geizig sein: das Aktivieren/Deaktivieren der jeweiligen Rendering Contexte kostet ziemlich Rechenzeit.

Traude

Also worums mir eigentlich geht, ist die sache das ich in allen neuen Projekten,
die komplette GUI vollständig von der Anwendung getrennt haben will.

Sprich die GUI in ne Library auslagern, aber nicht einfach nur eine GUI und fertig,
sondern dynamisch ladbare Interfaces, das man mehrere Interfaces gleichzeitig haben kann.

Das bietet dir folgende Vorteile:

- Erstmal wird dein code um ein grosses stück übersichtlicher und vor allem strukturierter
- Man kann z.b. nur ne GUI patchen, anstatt das komplette programm.
- Wenn mans richtig macht, lastet die GUI die applikation selber nicht mehr aus
- Integration von Webinterface oder ähnliches ist nen kinderspiel

Im Spiele bereich seh ich da keinen grossen vorteil, das ist eher für normale Anwendungen oder wie meinem mediaplayer Xenorate interessant.

Könntest Du bitte "dynamisch ladbare Interfaces" genauer definieren. Was meinst Du damit?
-- DDL
-- Interfaces wie COM/DCOM
???
Ich weiß nicht genau worauf Du hinauswillst.

Mit interfaces mein ich "User Interface" natürlich, also Grafische Oberflächen.

Also nicht Com oder so.

Ach so. Wenn ich das präzisieren darf, dann meinst Du ein Graphical User Interface, das aus einer DLL geladen werden kann.

Das kann ich Dir nicht liefern. Ich habe Vorgaben zu beachten, z.B. OOP. Ich wüßte nicht, wie ich das in eine DLL kriege. Und bei Webinterface muss ich auch passen: ich mache sicher nichts mit HTML.

OOP mit DLLs geht an sich außer über COM etc. am elegantesten, indem man ne prozedurale API in die DLL packt und dann im Code der Zielsprache (Pascal) dann nen OOP-Wrapper außenrum bastelt.

~ Frase (, der sich auch mal wieder zu Wort meldet *g*)

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Die Frage ist dann was eine DLL bringt? Hast du sowas mal versucht zu übersetzen?

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

COM ist was Windows-spezifisches, oder? Interfaces gibts an sich in FreePascal auch; dh. die Technologie für Interfaces wäre auch für Linux vorhanden, die Frage ist, ob das OS dort so etwas machen kann?

@EDIT:
Ich habe gerade nach "FreePascal"+Interface gegoogelt und komme damit in die Wikipedia. Was unter dem Stichwort "Lieferumfang" steht ist beeindruckend - man schwimmt in Software. Dort steht auch immer "Interface zu" aber gemeint sind offensichtlich prozedurale DLLs, und die sind nun eben mal auf prozedurale Möglichkeiten beschränkt. Und hey - man kommt auch in unseren Brainstorming Thread.

Ich habe auch noch nach "Webinterface" in der Wikipedia gesucht:


Vor kurzem hat jemand die Frage gestellt, wie man denn OpenGL-Code in einem Browser ausführen kann. Er bekam folgende Antworten:
--- es gibt eine Möglichkeit mit ActiveX (=> Internet Explorer),
--- man kann ein Plugin für den FireFox schreiben
--- per JavaApplet (ist nicht auf einen speziellen Browser beschränkt und daher wahrscheinlich die allgemeinste aller Möglichkeiten).

Hier ist man anderweitig beschränkt, und zwar aus einem ganz anderen Grund wie oben bei den DLLs: hier geht es um das Sicherheitsproblem. Ich weiß jetzt nicht, was das FireFox-Plugin tun kann. Aber Ihr würdet mich weder mit der ActiveX-Methode noch mit dem Java Applet erreichen, weil meine Firewall das unterbindet.

Ja COM ist Windows spezifisch. Ob OOP unbedingt Bestandteil der Schnittstelle sein muss halte ich mal auch für Fragwürdig. Fakt ist, dass Pascal nun mal leider eine Minderheit ist. Und eine Schnittstelle zu bauen die ausschließlich nur mit Pascal funktioniert ist in meinem Augen, bei einem Mediaplayer, wohl eher mehr ein Todesurteil als ein Vorteil.

Was du aber machen kannst sind stink normale Pointer auf Methoden. Wenn du diese in ein Record packst dann ist das eine Art Objekt und funktioniert problemlos auch mit anderen Sprachen. Aber das sind Details deiner Schnittstelle. Das war nicht deine Frage.

Zum Thema Fenster erstellen. Ich denke auch nicht, dass du mit SDL 1.3 oder 2 glücklicher werden würdest. Der Punkt ist doch, dass die Fenster trotzdem noch einen Rahmen haben oder könnte man diesen entfernen lassen und das Fenster trotzdem mit der Maus in der Größe verändern? Denn eigentlich möchtest du ja über alles auch irgendwan mal ein Skin legen und da kommt so ein Windowsrahmen nicht wirklich gut. Aber das ist auch schon genau das Nächste. Du solltest dem Plugin ja auch die Möglichkeit geben auf das Skin zugreifen zu können.

So spontan würde ich sagen hast du 2 Möglichkeiten.
1. Du übergibst an das Plugin alle nötigen Funktionen um ein Fenster erstellen zu können bzw um Elemente darauf zu bringen etc. So musst du dich aber selber um die gesammte Verwaltung kümmern was in meinen Augen nicht so praktisch ist.
2. Besser wäre, wenn du deinem Player sagen würdest. Erstelle mir ein Fenster. Dann hätte ich gerne hier ein Button, dort ein Button und da eine Liste etc. Wenn du dann überall IDs dran hast dann liegt die Verwaltung komplett in deinem Player. Du würdest dann noch ein Nachrichtensystem benötigen mit dem du dem Plugin dann auch mitteilen kannst, dass Button X/Y gedrückt wurde etc.

Dann hättest du die Fensterverwalttung vollständig in deinem Player und die Plugins würden nur eine abstrakte Schnittstelle benutzen. Dann würde es sich auch anbieten die Systemschnittstelle für jedes OS zu kappseln, da du so auch einfach mehr Möglichkeiten hast. Bzw schau dir mal Lazarus an. Das ist ja doch eigentlich für so was gemacht. Also eine Platformübergreifende VCL. Meine ich zu mindest.

Das ist aber nur so eine Idee. Keine Ahnung ob sie überhaupt praktikabel ist. Bin noch nicht richtig wach.

PS Traude: Ich denke du missverstehst da gerade den Begriff Webschnittstelle. Es geht bei solchen Schnittstellen NIE darum, dass man einen Player im Web hat der genau das kann was auch der echte Player kann. Es geht eher darum eine Webseite zu bekommen bei der man eine Auflistung der Titel hat (Ähnlich wie Mails in einem Webmailprogramm). Und man simple Befehle wie Start, Stop, Pause, Next, Prev an den Player schicken kann. Dazu benötigt es nichts Voodooartiges sondern lediglich einen Miniwebserver bei dem man Webseiten aufruft die dann im Player einen Befehl auslösen. Wenn diese dann noch sagen das hat geklappt oder nicht dann hat man es 100%tig geschafft.

@Lossy: Du weisst doch, ich bin ein Blitzkneisser.
Ich wiederhole mal, wie ich Dich jetzt verstanden habe: Ich habe einen MediaPlayer (ein Programm) auf MEINEM Computer. Der MediaPlayer findet eine Website, auf der Titel aufgelistet sind (heißt: die Musikdateien an MEINE IP-Adresse schicken kann, z.B. per Stream), wo sie mittels MEINEM Mediaplayer auf MEINER Audiokarte abgespielt werden.

Ist das so? Wenn ja, dann muss MEIN MediaPlayer Browserqualitäten haben, dh. Netzwerkfunktionalität (denn er muss mit der WebSite kommunizieren) UND ein GUI (er muss mit MIR kommunizieren).

@FinalSpace: abgesehen davon, dass ich jetzt erfahren habe, dass man das GUI in eine DLL stecken kann - was ich eigentlich nicht machen möchte, ich würde aber keine Einwendungen haben, wenn das ein anderer tut - kann ich keine Netzwerfunktionalität zur Verfügung stellen, weil ich das weder will noch dazu befähigt bin (sagen wir: das stand in meiner Jobbeschreibung nicht drin ). Über eine Schnittstelle dafür kann man diskutieren, aber das Netzwerken selber möchte ich lieber einem Spezialisten überlassen.

@Edit: Lossy:

Damit verkürzt sich die Headerdatei auf eine Art "Klassendefintion". Danke für den Tipp.

Traude