Plgins, user interface
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
DC++ |
New
|
Wishlist
|
poy |
Bug Description
The current most difficult thing for plugins to do is interact with the user interface of DC++, I won't say impossible because just loading a dll plugin on windows opens certain possibilities to hijack the UI, but there certainly is no intentional way to achieve this.
This downside has been discussed few times on DC, but it should have a serious discussion here as well, because right now this one single downside to plugins significantly reduces their usefulness as a development tool.
The way I see it there are four possible ways to address this:
1) Create a window class in DWT that the plugins can bind to directly using DWT.
Pros: probably the least amount of work
Cons: windows only, c++ only, DWT specific, build environment specific (both host and plugin has to use same version of DWT and STL).
2) Create a custom interface markup language, for example with XML definitions, that defines a subset of controls that can defined in a resource then loaded and used by a plugin using stub objects similar to the ones it they use currently.
Pros: environment and operating system agnostic, controls will still appear and behave natively.
Cons: significant amount of work for only a subset of UI or with major dependencies
3) Define a secondary API using pre-existing technologies, such as those commonly used for the Web
Pros: no reinventing the wheel, multi-purpose API, can be used externally
Cons: UI views would not appear native, easier to implement on some platforms than others
4) Host provides UI for the user interface heavy plugins of its choice, checking whether particular plugins are loaded as necessary.
Pros: can be realized entirely with the existing implementation
Cons: everything else
Personally I am a fan of number 3 and only included number 4 because it had to be included. It is fair to say that the way plugins currently interface with the UI is not really extendable much further than how it is right now. Number 2 would be the ideal solution but impractical in the long run, if this was something to build the entire UI with then maybe it would be worth the effort but not just for plugins.
Option 1 has way to many risks associated with it and in the case of user land problems would be even more of a headache than plugins already are, plus it is the least stable of the four in terms of API compatibility.
Changed in dcplusplus: | |
assignee: | nobody → poy (poy) |
one solution is for gui are the activex / ole / com