Gutes Pluginmanagement - Wie?

  • Allgemein

Es gibt 22 Antworten in diesem Thema. Der letzte Beitrag () ist von Nikx.

    Gutes Pluginmanagement - Wie?

    Mittag,

    bezüglich meiners letzten Themas zum auflisten von Plugins in einer selbstgeschrieben ListBox
    bekomme ich immer mehr Probleme damit, die Plugins effizient und dynamisch ins Programm einzubinden.
    Wenn jedes Plugin 2 Funktionen enthält, und auch die Grundfunktionen in Plugins ausgelagert werden,
    dann stellt sich mir die Frage wie man dem User eine gute Möglichkeit bietet, alle Plugins und Funktionen
    gut zu verwalten. Eine Suche wäre möglich, allerdings halte ich das für overkill.
    Wie sollte also eine gute Architektur aussehen, die auch das einbinden von 30-50 Plugins erlaubt,
    ohne dabei den User mit einer überfüllten GUI zu belasten?

    :) <- Smiley zum herstellen einer guten Grundstimmung im Thread.

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Abend,

    habe aktuell genau das selbe Problem erneut.
    Jemand eine Idee?

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Die Schwierigkeit ist hier, dass es wohl keine allgemeine Herangehensweise dafür gibt. Wie die Plugins am effizientesten einzubinden sind, hängt davon ab, was du für ein Programm erstellen möchtest und wie weit die PLugins den Funktionsumfang erweitern können/dürfen.
    @Artentus Die Plugins sind der Funktionsumfang. Generell ist das Programm ohne Plugins unfähig, irgendetwas zu tun.
    Grundsätzlich dachte ich an die Möglichkeit, eine MessageBox anzuzeigen, um Nutzeranfragen zu stellen, was ich allerdings
    für eine grausame User-Experience halte. Ein NotifyIcon, dem ich ein DoubleClick Event gebe, wäre auch möglich, allerdings womöglich nicht
    passend für alle Plugins. Eine Form, die das Plugin selbst definieren kann, wäre auch okay. Aber dann ist die Frage, wie ich die User-Experience beibehalte,
    damit nicht einfach jeder irgendwelchen Ranz in ein Plugin haut.
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Hört sich für mich nicht sonderlich sinnvoll an, aber na gut. :P
    Das "Programm" bestünde ja dann lediglich aus einer einzigen Liste an Plugins, die man alle starten kann. Das wäre genau eine Funktion im Interface, die man per Button oder welche Art der Eingabe dir sonst am besten erscheint, aufruft (außer du willst die Plugins noch kommunizieren lassen), alles andere wäre dann schon Aufgabe des Pluginautors. Imo führt das den Daseinszweck eines Plugins ad absurdum, wäre ja dann quasie nur ne Sammlung von Programmen, die man halt über deinen Manager anstatt wie gewöhnlich startet.
    Wenn du einen Blick hierauf:
    Clip.NET - Link-Handling leicht gemacht
    wirfst, erkennst du hoffentlich meine Absicht. Da ich gerade vom Clipboard-Handler zum
    Clipboard-Manager erweitere, können Plugins beispielsweise auch eine History anlegen, den Clipboard-Text hochladen,
    und so weiter. Daher brauche ich also eine Möglichkeit, all diese verschiedenen Plugins unter einen Hut zu bringen und gemeinsam
    zu verwalten. @Artentus
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Dann hast du offensichtlich deine eigene Problemstellung nicht verstanden. :D
    Du musst dir hier nur klar machen, was dein Programm an die Plugins schickt und was erwartet wird. Sobald es eine Clippboard-Änderung gibt, musst du die Plugins darüber informieren, falls das Clippboard geändert werden soll, muss das Plugin entsprechend antworten. Einzige Schwierigkeit, die ich eventuell sehe, ist, dass du eine Lösung finden musst, wenn zwei Plugins den selben Clippboard-Inhalt handlen wollen.
    Für Upload-Funktionen usw. könntest du dann z.B. den Plugins erlauben, Schaltflächen mit Handlern zu registrieren, die dann in einem eventuell angezeigten Status Feld o.ä. angezeigt werden. Kontextmenü am Systemtray.Icon wäre auch denkbar. Da kannst du theoretisch alles erlauben, was dir in den Sinn kommt.
    @Artentus
    Keineswegs, ich habe meine Problemstellung sehr gut verstanden ;)
    Es gibt absolut kein Problem mit Plugins, die den Inhalt modifizieren. Das Problem besteht bei Plugins, die den Inhalt nur verarbeiten und dazu eventuell eine GUI brauchen.

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Ich denke ich habe eine recht gute Möglichkeit im Kopf. Werde das morgen mal durchgehen. Gute Nacht! :)
    @Artentus
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    @Nikx
    Beachte, dass Forms (ich nehme einfach mal an Du verwendest WinForms, aber das gilt auch für Windows bei Wpf) auch nur Datentypen sind. Und dass Instanzen von Forms auch nur Daten sind.
    Das PlugIn kann einfach eine Funktion haben, die eine Form zurückgibt (ohne sie anzuzeigen) und Dein Programm kümmert sich darum, die Form anzuzeigen und die Daten zwischen dem PlugIn und der Form auszutauschen. (Wobei letzteres nicht mal nötig ist, weil das PlugIn ja den Verweis auf die Form behalten kann.)
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    @ThuCommix Universell - ansonsten könnte ich ohne Probleme eine API bereitstellen.
    @Niko Ortner Das ist mir klar. Es gibt hierbei allerdings 2 Probleme. Zum einen wird der Aufruf einer solchen Form relativ komplex, wenn man mehr als
    10 Plugins hat. Man nehme an, ein Plugin verarbeitet und speichert eine bestimmte Art von Inhalt. Man möchte sich nun eine Liste anzeigen lassen.
    Hierfür wären 6 Klicks nötig - zu viel. Ebenfalls kann ich dann keinen Einfluss auf das Design nehmen.
    Interessanterweise habe ich selbst keine gute Idee - ich frage mich, ob es überhaupt eine gute Möglichkeit gibt.

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!

    Artentus schrieb:

    was du für ein Programm erstellen möchtest und wie weit die PLugins den Funktionsumfang erweitern können/dürfen.

    Nikx schrieb:

    Die Plugins sind der Funktionsumfang.

    Ich denke, hier liegt ein Denkfehler: PlugIns erweitern keinen Funktionsumfang.
    Der Funktionsumfang bleibt genau gleich (und ist vorgegeben), ein Plugin führt dieselbe Funktion nur anders aus.

    Also - zB. Bildverarbeitung: Es ist eine Funktion "ApplyImageFilter" vorgesehen. Und dann ist denkbar, dass beliebige Plugins zugeschaltet werden, die die Pixel einer Bitmap verwüsten.
    Aber was anneres können diese Plugins niemals tun: Nur Pixel einer Bitmap verändern.
    @ErfinderDesRades So kann man es sehen. Man überlege sich aber das selbe Bildbearbeitungsprogramm, dass nicht mal Bilder bearbeiten oder öffnen kann.
    Selbst diese Funktionen sind Plugins. Ich denke das erklärt das Prinzip. Ohne ein Plugin für einen bestimmten Bereich wird dieser eben nicht abgedeckt ->
    Keine Plugins -> Nichts abgedeckt. Klar startet das Programm auch ohne, es tut dann halt nichts.

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Das ist aber genau das, worauf ich hinaus wollte. In deinem Beispiel hätte das Programm dann trotzdem bereits einen Speichern-Dialog mit Format-Liste usw. fertig drinnen, lediglich die tatsächliche Speicher-Funktionalität wird dann durch die Plugins gestellt. GUI-Anpassungen der einzelnen Plugins würden sich dann auch nur auf eventuelle formatspezifische Optionen beziehen, den Rest geht die Plugins nichts an. Und ich denke, es ließe sich hier genauso umsetzen.
    Wo ist jetzt hier der Unterschied zum Bildbearbeitungsprogramm-Beispiel? Dieses muss ja auch keine Filter beherrschen, um eine Schnittstelle für Filter (z.B. Interface mit ApplyFilter-Methode) bereitstellen zu können.

    Nikx schrieb:

    Man überlege sich aber das selbe Bildbearbeitungsprogramm, dass nicht mal Bilder bearbeiten oder öffnen kann.
    Ja - Denkfehler-Unfug!
    Wenn das Bildbearbeitungsprogramm keine ApplyFilter-Funktion als Interface vorgibt, und auch sonst keine Funktionen als Interface vorgibt, dann kann diese dolle Programm eben nix tun, und das bleibt auch so:
    Das Proggi hat einen FunktionsUmfang von Null, und dafür kannst du nur PlugIns für schreiben, die auch Null tun, also ohne Funktionen, oder deren Funktionen überhaupt nicht aufgerufen werden.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Ich fange noch mal von vorn an, um genau zu spezifizieren, was ich will.
    Hier nochmal der Link, den ich oben bereits gepostet habe:
    Clip.NET - Link-Handling leicht gemacht
    Was tut das Programm? Nichts. Bisher hat es das Clipboard überwacht, und Plugins mit dem Inhalt arbeiten lassen.
    Die Plugins haben bisher aber nur den Inhalt geändert, nicht anders verarbeitet. Ich möchte das allerdings ändern,
    sodass es für Plugins möglich wird, beispielsweise einen Clipboard-Verlauf zu speichern und dem Nutzer anzuzeigen.
    Keine Sau hat aber Lust, 6 Klicks zu tätigen, um seinen Clipboard-Verlauf einzusehen. Generell gibt es vielleicht auch noch
    mehr Möglichkeiten. Ein Plugin erhält einen YouTube Link und ist in der Lage, das Video herunterzuladen. Es möchte den
    Nutzer vorher aber darüber Informieren. Eine MessageBox wäre unglaublich penetrant und bietet eine schlechte User-Experience.
    Auch hier fehlt mir eine Idee, wie ich dem Plugin anbiete, seine Optionen zu zeigen. Der letzte Punkt führt wieder vom Thema weg,
    grundsätzlich geht es eben um das Management. Eine schöne Idee wäre, links eine ListBox und rechts ein Panel zu haben, und dem Plugin zu erlauben,
    das Panel zu füllen. Das Ergebnis wird dann allerdings miserabel aussehen, wenn die Entwickler ihre Buttons per Code setzten sollen - auch
    nicht die perfekte Lösung. Ich hoffe hier wird ersichtlicher, wo ich nicht weiterkomme.

    Grüße

    @ErfinderDesRades - Wie stellst du dir obiges Beispiel also vor? Eventuell ist das hier komplett der falsche Ansatz und
    ich mache dumme Sachen, ich kann auch völlig nachvollziehen, warum das so gesehen wird. Ich sehe allerdings keinen anderen Weg, den Plugins
    größtmögliche Freiheit zu lassen.
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!
    Ich hätte an ein kleines Popup oben oder unten rechts gedacht. Ist für den aktuellen Clipboard-Inhalt eine Option verfügbar, wird der ausgescrollt und darauf befinden sich die vom Plugin verfügbaren Funktionen wie Download und dergleichen. Natürlich kann das Plugin kontrollieren, ob das Popup überhaupt angezeigt wird, weil bei einfachem Kürzen eines Links z.B. braucht man das ja nicht.
    Funktionen, die nicht vom aktuellen Inhalt abhängen (wie z.B. History) hätte ich in Form von Einträge im Kontextmenü des Tray-Icons umgesetzt.