HI Sascha et al,
I think I have (almost) found the problem when help files are loaded. Hopefully
I can explain (and not bore people too much). If I run my application with a
clean cache, and --BlueBerry.consoleLog, I can see that the framework starts up
with a nice clean cache.
Framework instance 1 : created
Framework instance 1 : initializing
Framework instance 1 : inited
Framework instance 1 : Installed plugins:
[3.490] [BlueBerry] Creating CodeCache with path:
/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/bb-plugin_cache/
and then further along for one of my plugins, it gets registered with plugin ID
= 31.
resolve: "uk.ac.ucl.cmic.snapshot" [ 31 ]
checkRequirePlugin: check requiring plugin 31
resolve: Done for "uk.ac.ucl.cmic.snapshot" [ 31 ]
[3.834] [BlueBerry] Extension found for extension-point: org.blueberry.ui.views
(from uk.ac.ucl.cmic.snapshot)
I can check that this plugin cache entry does exist:
cd /Users/mattclarkson/Library/Application Support/CMIC/NiftyView_36122371/
find . -type f
./data/23/CMICNiftyViewQtHelpCollection_d31e02570c1d6127da15c809a20593a180ab2403.qhc
./data/23/qch_files/31/uk.ac.ucl.cmic.snapshot.qch
./plugins.db
(and a few more plugins).
This snapshot plugin is the last plugin loaded, and the one with the highest
ID, chosen only by virtue of being last. The problem that I am experiencing is
that if I edit a file in eclipse, and recompile my app (for example I edit code
that belongs in uk.ac.ucl.cmic.qt.gui.common, causing 4 plugins to be
recompiled, including the snapshot one). And then when I re-run I get:
Framework instance 1 : created
Framework instance 1 : initializing
Framework instance 1 : inited
Framework instance 1 : Installed plugins:
Framework instance 1 : # 1 "org.commontk.eventadmin" : "0.0.0" location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/CTK-build/CTK-build/bin/liborg_commontk_eventadmin.dylib"
Framework instance 1 : # 2 "org.blueberry.osgi" : "1.0.0" location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/MITK-build/MITK-build/bin/plugins/liborg_blueberry_osgi.dylib"
<snip>
Framework instance 1 : # 30 "uk.ac.ucl.cmic.gui.qt.common" : "0.1.0"
location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/NifTK-build/bin/plugins/libuk_ac_ucl_cmic_gui_qt_common.dylib"
Framework instance 1 : # 31 "uk.ac.ucl.cmic.midasmorphologicalsegmentor" :
"0.1.0" location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/NifTK-build/bin/plugins/libuk_ac_ucl_cmic_midasmorphologicalsegmentor.dylib"
Framework instance 1 : # 32 "uk.ac.ucl.cmic.midasgeneralsegmentor" :
"0.1.0" location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/NifTK-build/bin/plugins/libuk_ac_ucl_cmic_midasgeneralsegmentor.dylib"
Framework instance 1 : # 33 "uk.ac.ucl.cmic.midasnavigation" : "0.1.0"
location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/NifTK-build/bin/plugins/libuk_ac_ucl_cmic_midasnavigation.dylib"
Framework instance 1 : # 34 "uk.ac.ucl.cmic.snapshot" : "0.1.0"
location:
"file:///Users/mattclarkson/build/NifTK-SuperBuild/NifTK-build/bin/plugins/libuk_ac_ucl_cmic_snapshot.dylib"
so, on restart, it looks like the plugin cache has changed such that the
framework thinks that the snapshot plugin is number 34.
Subsequently in QCHPluginListener::processPlugins, we go to addPlugin, the
QFileInfo qchDirInfo is for the wrong file, the qchDirInfo.lastModified() <
pluginFileInfo.lastModified() evaluates to true as qchDirInfo.lastModified() is
blank. So the framework tries to remove the plugin from the cache (as indeed it
should to replace the cache entry as the plugin has been recompiled).
However, in removePlugin,
QFileInfo qchDirInfo = context->getDataFile("qch_files/" +
QString::number(plugin->getPluginId()));
qchDirInfo.setFile(qchDirInfo.absoluteFilePath());
qDebug() << "Matt, in listener removing plugin id=" << plugin->getPluginId()
<< ", exists()=" << qchDirInfo.exists() << ", size()=" << qchDirInfo.size() <<
", path=" << qchDirInfo.absoluteFilePath();
if (qchDirInfo.exists())
{
the exists() fails because it is trying to remove plugin 34, which does not
exist. It should remove plugin 31. So, when the framework is trying to register
help files for plugin 34, it fails because in the qch namespace, the plugin
names is already used. (because it was never correctly removed), and then
finally, if in berryQtAssistantUtil.cpp I remove (comment out) the -quiet
argument, and add some debug statements:
Matt, in listener, localQCHFiles to register=
("/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/data/23/qch_files/34/uk.ac.ucl.cmic.snapshot.qch")
*****
"/Users/mattclarkson/install/qt-4.7.4/bin/assistant.app/Contents/MacOS/Assistant"
("-collectionFile", "/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/data/23/CMICNiftyViewQtHelpCollection_d31e02570c1d6127da15c809a20593a180ab2403.qhc",
"-register", "/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/data/23/qch_files/34/uk.ac.ucl.cmic.snapshot.qch")
Matt, registerFile=1
[1.995] [BlueBerry] Registering Qt compressed help file:
/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/data/23/qch_files/34/uk.ac.ucl.cmic.snapshot.qch
Matt, errorString=
Matt, errorCode=5
Matt, exit=1
Matt, exitStatus=0
Matt, err=
Matt, out=Could not register documentation file
/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/data/23/qch_files/34/uk.ac.ucl.cmic.snapshot.qch
Reason:
Namespace uk.ac.ucl.cmic.snapshot already exists!
so we can see that the framework is doing a -register without doing an
unregister first, and this results in 2 files in the cache:
mclarkson:qch_files mattclarkson$ pwd
/Users/mattclarkson/Library/Application
Support/CMIC/NiftyView_36122371/data/23/qch_files
mclarkson:qch_files mattclarkson$ find . -type f
./10/org.blueberry.ui.qt.log.qch
./17/org.mitk.gui.qt.datamanager.qch
./18/org.mitk.gui.qt.segmentation.qch
./19/org.mitk.gui.qt.imagenavigator.qch
./20/org.mitk.gui.qt.imagecropper.qch
./21/org.mitk.gui.qt.volumevisualization.qch
./22/org.mitk.gui.qt.pointsetinteraction.qch
./23/uk.ac.ucl.cmic.gui.qt.niftyview.qch
./25/uk.ac.ucl.cmic.imagelookuptables.qch
./26/uk.ac.ucl.cmic.midasmorphologicalsegmentor.qch
./27/uk.ac.ucl.cmic.midasgeneralsegmentor.qch
./28/uk.ac.ucl.cmic.affinetransform.qch
./29/uk.ac.ucl.cmic.thumbnail.qch
./30/uk.ac.ucl.cmic.midasnavigation.qch
./31/uk.ac.ucl.cmic.snapshot.qch
./34/uk.ac.ucl.cmic.snapshot.qch
Is this a bug or a user error?
Thanks
Matt
On 9 Jan 2012, at 15:53, Sascha Zelzer wrote:
Hi,
On 01/09/2012 02:46 PM, Clarkson, Matt wrote:
Hi there everyone,
On occasion, I have seen the fact that the help files fail to register,
resulting in the message from berryQtAssistantUtil.cpp line 303 "You may not
have write permission in.." complaining of no write permission in your own home
folder, which in my case is definitely wrong. So, i poked around for a bit,
and have a few questions:
Yes, this error message is probably most of the time misleading. The problem is
that we cannot get a more detailed error message from the registration process
unless we want the QtAssistant program pop up a message box for each
successfully registered help file on start-up. I guess a generic error message
is better than one which is misleading in 99% of the cases...
When the application plugin is loaded, for example the
QmitkExtApplicationPlugin, the CTK plugin framework calls
start(ctkPluginContext *context). This registers a QCHPluginListener, and it is
the pluginListener->processPlugins() that registers the help files.
However, in the QmitkExtAppWorkbenchAdvisor, there is another call to
berry::QtAssistantUtil::RegisterQCHFiles(bundles).
Is one of these redundant, or is one of these duplication of effort?
The QCHPluginListener takes care of CTK plug-ins and the call in the
QmitkExtAppWorkbenchAdvisor registers help files of legacy BlueBerry bundles.
So the two calls should register help files from two disjoint sets of plug-ins.
Starting your application with --BlueBerry.consoleLog should print exactly the
.qch files which are being registered.
The reason I ask is to determine if the possible reason for the above error
message is that the file system sometimes holds locks for too long, and hence
some of the registering/un-registering second time round fails.
We once had a problem with multiple registered QCHPluginListener instances in
the past, which gave very similar errors. I can't remember the actual
constellation of enabled plug-ins though...
Hope that helps,
Sascha
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
