Car-PC.info

Developer - Gemeinsamme Plugin-Schnittstelle
motroxx - Di 01 März, 2005 18:29
Titel: Gemeinsamme Plugin-Schnittstelle
Hi,
Dieser Thread hat mich darauf gebracht mal nachzufragen ob ihr lust habt eine programm-übergreifende Plugin-Schnittstelle zu entwickeln.

Das würde bedeuten, dass wir eine art protokoll miteinander aushandeln, damit jedes plugin in jedem unserer programme lauffähig ist.
So bräuchte nicht jeder der ein carPC programm schreibt das Rad neu erfinden..

Meldet euch wenn ihr lust habt.

Gruß, Andy
fuchs - Di 01 März, 2005 22:24
Titel:
*meldmeld* bin dabei Smile

ich würde vorschlagen, dass wir für unterfunktionen wie

- telefon
- gps
- io-Karten
- eingabegeräte
- web cam mit aufzeichnung
- audio steuerung/equalizer
- dvd-player
- media-daten verwaltung
- usw...

universelle schnittstellen definieren, während elementare funktionen wie z.b. der Media-Player im Hauptprogramm bleiben.
motroxx - Di 01 März, 2005 22:33
Titel:
freut mich, dich im boot zu haben Wink
dachte das wir da folgendermaßen rangehen:

1.) Hauptprogramm
2.) Plugin-Server (*.dll)
3.) Plugin (*.dll)

Der Plugin-Server bietet alle möglichkeiten, die zur kommunikation dienen.
Am besten eine art Message Queue, über den sich die programme gegenseitig events hin und her senden.
z.B. wenn der "pause"-Button gedrückt wird muss er den string "mediaPlayer:pause" an den PluginServer gesendet werden.

das Plugin und das Hauptprogramm müssen das jeweils eine funktion (evtl. auch einen timer) integriert haben, die die messages auffangen und verarbeiten.

was hältst du von dem vorschlag?

Bei gefallen bitte weiterdenken Wink


Gruß, Andy
fuchs - Di 01 März, 2005 23:34
Titel:
ich muß zugeben, dass ich mich mit dll's noch nicht so gut auskenne, aber ich verstehe, was Du meinst.

man könnte die plugins allerdings auch als eigenständige programme laufen lassen und den datenaustausch via "sendmessage" erledigen.

ist vielleicht etwas unkomplizierter, weil quasi schon fertig und in einigen programmen schon vorhanden.
bestes beispiel dafür ist WINAMP.

gruß,
fuchs
Shadowrun - Mi 02 März, 2005 11:24
Titel:
Deswegen würde ich ja das Hauptprogramm nur fürs Eventhandeln und das Hauptmenü benutzen.

1. Ist damit das Hauptprogramm denke ich mal groß genug.
2. Wenn modular dann richtig.

Dann liefert auch das Hauptprogramm nur die benötigten Recourcen:

1. Die Lautstärke

Das Hauptprogramm übernimmt die Regelung der Lautstärke.
jedes Plugin kann drauf zugreifen bzw die anderen abschalten aber nur
über das Hauptprogramm und nur über ausnahmen / Prioritäten.
zB: GPS hat eine höhere Priorität als der Mediaplayer.
Wenn GPS etwas sagen will sagts dass dem Hauptproggi und je nach einstellung fährt das dann die Lautstärke runter bzw sagt dem Mediaplayerplugin bitte lautlos zu sein.

Genauso beim Telefon welches die gleiche oder höhere Priorität hat als GPS / Mediaplayer.


So das Hauptprogramm müßte zB

Das Mainform regeln wer wann im Vordergrund steht.
Starten und absetzten der Plugins
Die Lautstärke regeln
Die Helligkeit regeln
fuchs - Mi 02 März, 2005 14:09
Titel:
Zitat:
Deswegen würde ich ja das Hauptprogramm nur fürs Eventhandeln und das Hauptmenü benutzen.

1. Ist damit das Hauptprogramm denke ich mal groß genug.


naja, was ist "groß genug"?
die resourcen, die du im hauptprogramm einsparst , hast du sattdessen im mediaplayer* plug in. dazu kommen noch die resourcen für die datenübertragung.

ich finde, für einen programmteil wie den mediaplayer*, der sowieso IMMER dabei ist, braucht man kein extra plugin.
man muß auch bedenken, dass dafür nicht gerade wenig daten übertragen werden müssen, was recourcen und geschwindigkeit frisst.

Zitat:
2. Wenn modular dann richtig.


wie wär's mit modular aber flexibel:

das hauptprogramm KANN einen mediaplayer* enthalten, alternativ kann dafür aber auch ein plugin genutzt werden.

was haltet ihr davon?

*mit mediaplayer meine ich nicht ausschließlich den windows media player
Shadowrun - Mi 02 März, 2005 14:19
Titel:
Ich meine mit groß dass da schon viel zu programmieren ist.

Plugins sind ja eigenständige programme.
Das Mediaplayerplugin kann zB die Musikdatei öffnen und abspielen ohne dass Hauptprogramm.
Es werden also keine Daten wie MusikStreams zw Hauptprogramm / Plugin übertragen

Da ist es doch viel komlizierter wenn du ein plugin schreibst und dass muß dann den mediaplayer im Hauptproggi steuern.....

Da wird doch jeder schnell selber eine eigene Mediaplayerinstanz öffnen und diese direkt steuern.
motroxx - Mi 02 März, 2005 16:48
Titel:
Zitat:
wie wär's mit modular aber flexibel:

das hauptprogramm KANN einen mediaplayer* enthalten, alternativ kann dafür aber auch ein plugin genutzt werden.


Finde ich einen super ansatz!
---> bitte weiterdenken Wink

das mit der Lautstärke im Hauptprogramm finde ich für nicht sooo toll, was ist wenn jem. gleichzeitig musik und navi laufen hat, aber das navi nur auf den vorderen boxen laufen lassen will?
Das Hauptprogramm währe überhaupt nicht darauf vorbereitet, das mehrere soundkarten benutzt werden können.
Somit währe diese art Lösung ziemlich beschränkt..

Hm, sendmessage -> damit habe ich mich noch nicht groß befasst...
Wie sihets mit der geschwindigkeit aus?
Fände es aber für geigneter wenn nur innerhalb des programms mit den strings hin und hergeschmissen wird, weil ich windows und dessen dienste nicht noch mit all dem belasten möchte...

Gruß
FMode - Mi 12 Okt, 2005 15:28
Titel:
So Leute hier nun mein Vorschlag wie sowas modular bzw. auf Komponenten basierend gebaut werden kann und jeder die Auswahl hat in welcher Sprache er seine Komponente schreibt:
(VB.NET, VC.NET, ... und alle andere Sprachen die .NET unterstützen)

Ist natürlich noch nicht komplett (das Konzept):

(aus dem Radio&TV Subforum:)
So ich konnte es nicht lassen Rolling Eyes noch ein modulares Frontend drunter zubasteln...
Kostprobe:
- MainContainer.exe in \BIN starten
- man sieht den Radio und Mediaplayer Teil - im Mediaplayer Teil tummelt sich der Windows Media Player...
- beenden
- kopiert nun die beiden Dateien von MediaPlayer(WinAMP)\bin nach \bin
- MainContainer.exe in \BIN starten
- Very Happy nun ist ein anderer Mediaplayer drin - eine (eure) Neuerfindung Evil or Very Mad des CI-Frontends (wegen WMP Abneigung) bleibt aus und ihr tauscht nur den Mediaplayer teil ... und habt mehr Zeit wichtigere Sachen die es noch nicht gibt zu entwickeln

Für die Radioentwickler&Co:
schaut euch das Radioplugin mit der Radio-HAL-Klasse (.NET Assembly und COM Objekt)
analog zum obigen Tausch des ganzen MediaplayerPlugins kann auch die RadioHAL(.dll) getauscht werden - eine HAL für Andre, eine andere für WAL's Radio,... (und es können später weitere Radios hinzugefügt werden ohne den Code des Frontends anzufassen)

...es ist ein VB.NET Projekt kann aber auch mit SharpDevelop (kostenlos!) editiert werden.
flagg - Mi 19 Okt, 2005 19:26
Titel:
Habt ihr schon mal daran gedacht eure Schnittstelle über XML-RPC zu realisieren?

Hab das beruflich in einer Software die Delphi und Java verbindet drinnen und das funktionert sehr gut.

Außerdem habe ich gerade gesehen das für Mambo (CMS) auch eine XML-RPC-Schnittstelle existiert.

Damit ist man komplett Programmiersprachenunabhängig (man muss also kein .NET etc. installieren). So gut wie jede Sprache hat Libraries für XML-RPC.

Sehr schönes Sache so was Smile

Wahrscheinlich ist das aber eher interessant, wenn man für sein Programm Leute hat die Plugins programmieren wollen ...

Würde mich über andere Meinungen freuen,
Reinhard
FMode - Mo 24 Okt, 2005 11:19
Titel:
flagg hat folgendes geschrieben:
Habt ihr schon mal daran gedacht eure Schnittstelle über XML-RPC zu realisieren?

Hab das beruflich in einer Software die Delphi und Java verbindet drinnen und das funktionert sehr gut.

Außerdem habe ich gerade gesehen das für Mambo (CMS) auch eine XML-RPC-Schnittstelle existiert.

Damit ist man komplett Programmiersprachenunabhängig (man muss also kein .NET etc. installieren). So gut wie jede Sprache hat Libraries für XML-RPC.

Sehr schönes Sache so was Smile

Wahrscheinlich ist das aber eher interessant, wenn man für sein Programm Leute hat die Plugins programmieren wollen ...

Würde mich über andere Meinungen freuen,
Reinhard


XML über RPC Calls ?
Das funktioniert sogar über TCP/IP über Rechner hinweg...
Wird ähnlich (für mich als Entwickler) wir Windows Messages gehandelt...

Ich habe .NET (für mich) gewählt weil:
- die Assemblies ihre Members zur Entwicklungszeit der Entwicklungsumgebung bekannt geben (das schöne ". Drücken" und schon sehe ich welche Funktionen etc... mir das Objekt bietet)
- die Assemblies (in den DLL's) lassen sich sich einfach austauschen (und somit lässt sich ein Frontend komponentenbasierend und modular entwicklen)
- Assemblies können ActiveX Steuerelemente und damit GUI enthalten somit kann man einzelne Teile der Oberfläche (Radio, Mediaplayer, ...) schön kapseln.
- .NET interessiert die Sprache nicht (VB.NET, C#, Delphi.NET)
- .NET Assemblies können Events (Callbacks) auslösen

Vergleicht mal (den Aufwand zur Erstellung eines Plugins):
meinen .NET Vorschlag mit dem Pluginkonzept über WindowsMessages von Roadrunner und Frodoplayer (hier werden Komandos über Strings an Frodo gegeben ählich Windows Messages)...

Um klar zu stellen: Frodo und Roadrunner sind klasse Frontends !
ppx - Do 10 Nov, 2005 21:22
Titel:
@fuchs: Also das mit - alles eigene EXEn und dem SendMessage finde ich persönlich etwas kurz gesprungen. Da ist es schon ein Krampf wenn man nur nen String übergeben oder abholen möchte (Mit GlobalSetAtom und so nem Quatsch) Wenn schon alles Exen dann bitte OUTPROC COM - was ich dann aber füe übertrieben halte.
Auch mit dem Austausch von XML ist man bei nem Mediaplayer PlugIn nicht gerade gut bedient. Da will man ja evt. auch mal einen eigenen Filtergraphen haben und mit dem DShow surface der Applikation verbinden.
Kennt ihr zufällig die PlugIn Schnittstelle vom XBOX MediaPlayer bzw. der WindowsVersion von XBMC ?

Das solltet ihr euch mal anschauen. Da braucht man sichein paar Gedanken nicht mehr zu machen.
Alle Zeiten sind GMT + 1 Stunde
Powered by phpBB2 Plus and Kostenloses Forum based on phpBB