Just to make things clear: Are you talking about a packaged MITK application (make package) or just running an application in the build tree?

Probably both...

Ultimately ... both.

For example, if someone running a project using MITK Project Template wants to turn on the CLI module, and use it in a deployed application after having run make package, or make install, the designer plugin needs to be there.

M

Yes.

Does it currently work in your branch when running the application from the build tree?

(In reply to comment #3)

Yes.

Does it currently work in your branch when running the application from the
build tree?

Right now, this minute, I am doing a rebuild - so from memory, the answer is no. With my new CLI VIew plugin, I had to manually create

MITK-build/MITK-build/bin/designer

and manually copy the CTK libraries

CTK-build/CTK-build/bin/designer/libCTK*WidgetsPlugins.so into

MITK-build/MITK-build/bin/designer

So, I would say that we need the MITK standard build procedure to build CTK with the CTK_BUILD_QTDESIGNER_PLUGINS on (if the widgets are on). Then some kind of custom copy command when building MITK to copy the libraries into bin/designer so that people running MITK from the build folder can access the designer plugins.

When "make install" happens there will be no library dependency, i.e. ldd will not list a link time dependency, so that CMake stuff that resolves all the libraries by recursively running ldd on Linux and presumably otool -L on Mac won't work properly.... so we may need to force a compile time dependency some-how. This could be done in the CLI View itself maybe? .... or else another custom copy command that copies those designer libraries to where CMAKE_INSTALL_PREFIX/bin/designer is?

Just my thoughts, as I haven't got round to this yet.

[f990fd]: Merge branch 'bug-12896-ctk-designer-qtplugins'

Merged commits:

2012-08-22 23:52:16 Sascha Zelzer [061a54]
External Qt plug-in find and install support.

So, I would say that we need the MITK standard build procedure to build CTK
with the CTK_BUILD_QTDESIGNER_PLUGINS on (if the widgets are on). Then some
kind of custom copy command when building MITK to copy the libraries into
bin/designer so that people running MITK from the build folder can access
the designer plugins.

I decided to avoid the usage of custom copy commands. Certainly doable, but such a command would need to be executed for each MITK based project and I wasn't sure where to put it (in a way that existing projects don't need modifications).

So, the CTK_BUILD_QTDESIGNER_PLUGINS variable is by default ON. In BlueBerry, I created a BlueBerryConfig.h file providing a method which returns a list of Qt plugin directories from external projects.

The default BlueBerry workbench advisor (from which all Qt BlueBerry applications should derive from) adds these paths for the Qt library search paths. It also adds the default search path <app-dir>/bin/plugins. This is where Qt plugins are supposed to live when installing a MITK application.

The new install code for the CTK Qt designer plugins is in mitkInstallRules.cmake.

[d001fc]: Merge branch 'bug-12896-ctk-designer-qtplugins'

Merged commits:

2012-08-23 15:31:39 Sascha Zelzer [c14007]
Use application .ini files to provide additional Qt plugin paths.

Okay, I totally forgot about our application .ini files. They actually provide a nicer way of supplying configuration information.

I removed the BlueBerryConfig.h file and moved the workbench advisor code to the berry::Starter class. The code now uses the configuration key "BlueBerry.qtplugin_path from the application .ini file.

Installed applications don't have that .ini file and rely on path conventions (Qt plugins should be located in <app-dir>/plugins.

[e3fa3b]: Merge branch 'bug-12896-ctk-designer-qtplugins'

Merged commits:

2012-08-28 14:30:02 Sascha Zelzer [2f36be]
Fixed pattern expression for Qt plug-ins for Windows installer.