linuxdcpp-team team mailing list archive

[iceman50 <1436111@xxxxxxxxxxxxxxxxxx>]

** Changed in: dcplusplus
     Assignee: (unassigned) => poy (poy)

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1436111

Title:
  Plgins, user interface

Status in DC++:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1436111/+subscriptions