Hi Tangi,
your manifest.cpp file looks fine and the application extension in your
plugin.xml file looks fine too. However, your default perspective must have a
unique id (the id you used is already used by the default perspective for the
CoreApp application). Anyway, this is not related to the problem that the
start-up code does not find your application.
It looks like the framework does not search in your plug-in directory and hence
does not know anything about your bundles. You can either specify bundle
directories in your .ini file or hard-code them in your myApp.cpp file (see
ExtApp.cpp).
To get more information about the extensions found in your system, you can
start your application with the command line switch /BlueBerry.consoleLog, it
will then print many status messages and at the very beginning it prints lines
like:
[BlueBerry] Plugin base directory: <some-path>
There you should find an entry containing your bundle directory.
Hope this helps,
Sascha
Von: Tangi Meyer [mailto:[email protected]]
Gesendet: Freitag, 26. Februar 2010 15:09
An: Zelzer Sascha
Cc: [email protected]
Betreff: Re: [mitk-users] Creating my own app using the bundle generator.
Dear Sascha,
In the berryStarter.cpp Run method, the IConfigurationElement::vector
extensions vector collected on line 66 only contains
org.mitk.gui.qt.application and org.mitk.gui.qt.extapplication. As on line 78,
std::string argApplication =
Platform::GetConfiguration().getString(Platform::ARG_APPLICATION, "") set
argApplication to myApp.mainApp.workbench, line 126 test is always false and my
workbench is not launch.
Is there a mean to extend/modify the extensions in the configuration element
vector?
It seems to me that my plugin.xml file is correct:
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension point="org.blueberry.osgi.applications">
<application id="myApp.mainApp.workbench">
<run class="myAppApplication"/>
</application>
</extension>
<extension point="org.blueberry.ui.perspectives">
<perspective
id="org.mitk.coreapp.defaultperspective"
name="Core App Home"
class="myAppDefaultPerspective">
</perspective>
</extension>
</plugin>
as well as my manifest file:
#include <Poco/ClassLibrary.h>
#include <berryIApplication.h>
#include "src/myAppApplication.h"
#include "src/myAppDefaultPerspective.h"
POCO_BEGIN_NAMED_MANIFEST(berryIApplication, berry::IApplication)
POCO_EXPORT_CLASS(myAppApplication)
POCO_END_MANIFEST
POCO_BEGIN_NAMED_MANIFEST(berryIPerspectiveFactory, berry::IPerspectiveFactory)
POCO_EXPORT_CLASS(myAppDefaultPerspective)
POCO_END_MANIFEST
Best regards,
Tangi
-------------------------------------
Tangi MEYER
Virtual and Augmented Reality
System and Software Engineer
Leuvensesteenweg 325
B-1932 Zaventem - Belgium
Telephone: +32 (0) 2 721 54 84
Fax: +32 (0) 2 721 54 44
-------------------------------------
----- Original Message -----
From: "Sascha Zelzer" <[email protected]>
To: "Tangi Meyer" <[email protected]>
Cc: [email protected]
Sent: Wednesday, 17 February, 2010 21:28:29 GMT +00:00 GMT Britain, Ireland,
Portugal
Subject: Re: [mitk-users] Creating my own app using the bundle generator.
Hi,
the bundle generator certainly has some limitations. I would really like to
have an advanced graphical tool which can generate code using different
templates. Unfortunately, we lack man power for this kind of project.
I am not in my office this week, so I can not look at the code of the bundle
generator right now, but I hope my comments below are still correct.
Am 15.02.2010 17:26, schrieb Tangi Meyer:
Hi Sascha,
Thank you for your answer.
I have some questions regarding bundles generation:
- when I'm creating my mainApp bundle, I cannot uncheck the use GUI_SUPPORT
option and this creates a view class in another repository/bundle ... If I
uncheck the GUI_SUPPORT option then, the generated CMAKE files still embed
references to Qt which causes CMAKE to not work. I will try to post some
snapshots.
It is important to understand that the code for the executable (e.g. for
ExtApp.exe or your own) which is generated by the bundle generator does not
belong to any bundle. It is something "external" to the set of bundles, which
should just be a really small wrapper which calls the berry::Starter::Start
method.
Ok that is how I see it.
The generator is not able to generate code for an executable only. I don't know
right now why you can't switch off GUI_SUPPORT, but once enabled and you run
CMake configure, the files are generated. Turning it off afterwards does not
delete the already generated files. However, you can just delete the generated
bundle.
I did it just after my last email.
You may still include the executable code in a bundle directory and merge the
bundles CMakeLists.txt file and the one for the executable. This is done for
example in the org.blueberry.osgi bundle, which also defines an executable (see
its CMakeLists.txt file). But this is just some CMake stuff.
I have been mixing CMake and bundle generation problems but I'm starting to
improve ... :)
- how are the dependencies in the bundle generator handled? I'm trying to use
the required plugins option but I do not see the impact of it. In particular,
my mainApp requires every include and dependencies repositories to be set by
hand ...
The dependencies you can declare in the bundle generator are dependencies
between bundles only. They do not apply to the executable. Those dependencies
are written into the bundles MANIFEST.MF file and the build system uses them to
set up the include paths and linker dependencies properly. The OSGi runtime
also uses the dependencies when loading a bundle - it ensures that all the
bundles it depends on are loaded before.
Ok.
You should not need to add additional dependencies (in CMake) to your
executable. It should only depend on org.blueberry.osgi, which takes care of
the rest. All other dependencies to other bundles or external libraries should
ideally be handled be some of your own bundles.
This is not the case for the ExtApp so that confused me a little.
Yes, I forgot about the Poco Libraries. They are included explicitly in the
CMakeLists.txt for ExtApp (for Poco::Path etc.). But there shouldn't be any
other libraries (except for some special cases, who knows...)
- concerning the workbench, I will basically have to generate a bundle and then
modify by hand the CMAKE files and C++ files?
Basically, yes. You should not need to touch the CMakeLists.txt file of the
generated bundle. Just add the source files to the files.cmake file and add
your own implementation of IApplication as an extension in your plugin.xml file
(and in the manifest.cpp file).
OK.
I will come back to you if I have other questions that pop to my mind.
Please do so :-)
Here is one!
Is there a mean to specify the use of only a limited number of plugins from the
MITK Bundles repository?
E.g. shall I exclud them from the application toolbar? or specify direct access
to the plugin repository through the Poco datapath management in myApp.cpp?
There is no way right know to exclude specific bundles from a bundle repository
(directory). I can think of the following options:
- In the MITK CMake configuration, you could just enable those bundles you
really want (no compilation/linking step needed). Disabling a bundle just
deletes its MANIFEST.MF file in the binary bundle directory, so the bundle will
not be found at runtime.
- If you do not change the MITK source code itself, you could copy (or better,
symbolic link) the subset of bundles you are interested in to another directory
and add this directory in your MyApp.ini file.
The code in ExtApp.cpp which hard-codes the bundle directories has only been
included for simplicity. Having a ExtApp.ini (or myApp.ini) file listing the
bundle directories is enough (and overwrites the hard-coded settings).
I would advise against removing specific entries in the application toolbar.
You would have to rely on specific bundle ids and would only exclude certain
elements (views) from such bundles. They are still known to the system and may
be started by other means and execute code.
Best,
Sascha
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
