Makes sense. Thanks (and a Happy New Year to You!)
M > On 22 Dec 2017, at 12:14, Sascha Zelzer <[email protected]> wrote: > > Hi Matt, > > sorry for the long wait, but better late than never, I guess. > > I am also getting old and my answers are based on my memories, so you > might have to double-check. > > CTK plug-ins are indeed Qt plugins (they implement the > "ctkPluginActivator" interface). But they make use of the low-level Qt > Plugin API, since they are meant to extend a Qt application, not the Qt > framework itself. > > The provisioning files are only one of many possible ways how to > initially provision an application based on the CTK Plugin Framework. > The provisioning files are an addition on top of CTK, implemented as > part of the BlueBerry application framework. When an application is > deployed, the file typically just lists all the plug-ins shipped by > default with the product and they get installed on first start-up. > During development, however, the provisioning file additionally allows > to selectively enable / disable plug-ins, e.g. when starting an > application with --BlueBerry.clean > > The Qt approach for Qt plug-ins extending Qt itself is based on naming > conventions for sub-directories, and on application start-up all the > plug-ins in those standard sub-directories are loaded unconditionally. > An application is free to implement the same behavior for e.g. a > sub-directory named "ctk". If this application does not allow for other > CTK plug-ins to be installed/started/stopped during runtime (their state > is recorded in a separate sqlite database), then this approach will be > straight forward. Otherwise, it might be a bit more involved regarding > removal of plug-ins from the ctk sub-folder, but not much as far as I > remember. > > Actually, we had discussions about providing such functionality out of > the box and I started to look at implementing something similar to the > Apache Felix File Install bundle [1], which would also be interesting > for CppMicroServices. But it never took off so far. > > > Best, > > Sascha > > [1] > http://felix.apache.org/documentation/subprojects/apache-felix-file-install.html > > > On 11/23/2017 09:48 AM, Clarkson, Matt wrote: >> Hi there, >> >> can someone remind me (I’m getting old..or older at least), why the CTK >> plugins used in MITK are not just like the normal Qt plugins (image formats, >> databases etc), and why they therefore require a provisioning file to load. >> >> It seems that the MITK Autoloaded Modules are great for having nicely >> extensible functionality, with no link-time dependency, where people could >> just add drop in modules etc.. But would it be possible to do the same for >> plugins? Im wondering if it would be possible to provide a pre-compiled GUI >> application, and the user just creates a standalone project for each new >> plugin that they can deploy to their app, much like new Osirix plugins, (or >> Mevis I think). >> >> Just a thought. >> >> Thanks >> >> M >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> mitk-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mitk-users > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
