plugin calling code in main app

[Alessandro Bettarini]

I need some help figuring out how a plugin can call code from classes
defined in the main app

I have created a mockup project

https://bitbucket.org/bettar/mockup/src/origin/

to show how far I got. Please clone the git repository and suggest the
proper way for the plugin to use code (C++ classes) defined in the main app.

Alex Bettarini

[Andreas Mohr]

Hi,

side note:

> --
> Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.

This reference is dead.

On Sat, Feb 14, 2026 at 09:02:57AM +0100, 'Alessandro Bettarini' via wx-users wrote:
> I need some help figuring out how a plugin can call code from classes
> defined in the main app

This topically seems to be a layer / scope concern.

I'd say that this is a producer consumer activity.

A main app (*any* main app!! Not "the" main app -
one might easily end up with *several*...) is supposed to
be able to
properly *consume* a wholesale component [functionality] (as provided by
a library).

Thus, it simply is the library scope's job to
specify *what exactly* it expects (read: all requirements)
any consumer to *provide* for it to be able to
function properly (read: fulfill its [scope-limited] purpose).

IOW, proper interfacing (and scoping).




Thus, one will need to
create a proper[ly minimalist!] interface type definition.

That interface[-based object] will then be *parameterized into*
a library-side component (type, factory, or so) [instantiation].

And that interface def obviously will have to be
*implemented* (derived) by the main app scope, simply in order to
actually *have* something to pass (show!) to
the *required* parameterization specialties of
the library component scope. :)




That's at least how I see it
(but I might be off vs.
some special recommendations in various articles,
especially how to handle interfaces *)).

*) e.g.:
"Inject functions, not interfaces"
https://www.hacklewayne.com/inject-functions-not-interfaces




- DI (Dependency Injection)
- DIP (Dependency Inversion Principle)
- ISP (Interface Separation Principle)



Another topically related very good article:
"Composition Root"
https://blog.ploeh.dk/2011/07/28/CompositionRoot/

> I have created a mockup project
>
> https://bitbucket.org/bettar/mockup/src/origin/

"Conventions

Singletons"

Singletons are an anti-pattern. See e.g.:
- "Why Singleton is an Anti-Pattern?"
https://buraaktasci.medium.com/why-singleton-is-an-anti-pattern-f828c186bd3e
- "Why Singletons are Evil"
https://learn.microsoft.com/en-us/archive/blogs/scottdensmore/why-singletons-are-evil
- "Retiring the Singleton Pattern - Peter Muldoon - Meeting C++ 2019"
https://www.reddit.com/r/cpp/comments/f6vwna/comment/fi7o7jv/

> to show how far I got. Please clone the git repository and suggest the
> proper way for the plugin to use code (C++ classes) defined in the main app.

I only quickly mentioned a couple thoughts here, sorry ;-)


Greetings

Andreas Mohr

[Alessandro Bettarini]

Thank you Andreas for your answer. I find what you write too
"theoretical". What I need is a practical example, possibly based on my
mockup project, possibly using wxWidgets macros and idioms, to
illustrate how plugin code can call any C++ class code from the main
host application. This seems to happen "automagically" in Objective-C.

Also, I am not concerned with the usage of singletons, that is not the
issue in my question.

Alex Bettarini

[Andreas Mohr]

Hello Alessandro,

> Thank you Andreas for your answer. I find what you write too "theoretical".
> What I need is a practical example, possibly based on my mockup project,
> possibly using wxWidgets macros and idioms, to illustrate how plugin code
> can call any C++ class code from the main host application. This seems to
> happen "automagically" in Objective-C.

The relevant area appears to be:

+int SamplePlugin::filterImage(wxString & menuName)
+{
+ wxLogDebug("%s %s(%s)", __FILE__, __FUNCTION__, menuName);
+#if 1
+ gui_view2D *currentViewer = nullptr;
+#else
+ // FIXME: @@@ ISSUE 3 @@@
+
+ // How to make this work ?
+ //gui_view2D *currentViewer = new gui_view2D(nullptr);
+
+ // How to make this work ?
+ gui_view2D *currentViewer = this->duplicateCurrent2DViewerWindow();
+#endif
+ return 0;
+}


I am now ignoring the aspect that
this is consuming a whoppin' GUI toolkit dependency in plugin library scope
(===> SoC issue?).


So, given implementation status quo, the simplest way possibly is to
inject an interface [parameter] to pluginBase ctor *),
and that interface would provide a method to
get a view (perhaps existing, or created).

And that interface would then "of course" need to be
implemented for real somewhere (e.g. in app scope, as you said).

*) or, if need be, initPlugin() - but such handling would be awkward (instance-state-confusion-hampered) "two-stage construction" stuff




So (pseudo code):


struct IPluginGetCurrentViewer
{
public:
virtual ~IPluginGetCurrentViewer() = 0;

virtual gui_view2D *GetCurrentViewer() = 0;
};


class PluginGetCurrentViewer_App : public IPluginGetCurrentViewer
{
public:
virtual gui_view2D *GetCurrentViewer() override
{
return new gui_view2D(nullptr);
}
};



std::unique_ptr<IPluginGetCurrentViewer> GetIPluginGetCurrentViewer(App *SomeGlobalStateCraptasticsRefActivityIfOhSoNeedBe)
{
return std::make_unique<PluginGetCurrentViewer>(SomeGlobalStateCraptasticsRefActivityIfOhSoNeedBe);
}



auto plugin = std::make_unique<PluginBase>(GetIPluginGetCurrentViewer(...));






Though this current implementation would do (thus, consume) a million things more than
ideally one would want to have done by
such plain/raw plugin interface mechanics, if one can help it.
(SoC)


HTH & HAND,

Andreas Mohr