Plgins, user interface

Bug #1436111 reported by Crise / MW
6
This bug affects 1 person
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.

Revision history for this message
Gabberworld (gabberworld) wrote :

one solution is for gui are the activex / ole / com

Revision history for this message
Gabberworld (gabberworld) wrote :

oops

iceman50 (bdcdevel)
Changed in dcplusplus:
assignee: nobody → poy (poy)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.