Erhard

Hi Rainer,

The original post is quite old and the methods described there were never picked up by the GCS. The way the GCS communicates with the OP board is tightly coupled with the UAV-Objects and right now I don't see an easy way to sqeeze the MK Communication into this system.

Erhard

muralha, on 30 June 2011 - 11:26 PM, said:

Exactly, thats why I say you have to associate the Vbo config with the plugin and not with the gadget. To be more specific:

• Remove the Vbo from the gadget-config an add it as field to the plugin.
  
• Create a new IOptionsPage to change the Vbo
  
• Add the OptionsPage to the Plugin-manager in the initialize() (addAutoReleasedObject())
  
• Make the plugin implement the interface Core::IConfigurablePlugin
  
• Save and load the VBO in saveConfig() / readConfig()

You would have to restart the GCS after changing th VBO to prevent reinitialization, but you can set it from the command line if you want.
See the Notify-Plugin for an example.

muralha, on 29 June 2011 - 09:03 PM, said:

From #48 in this post I was under the impression, that OP-491 was fixed? In my opinion the config has to be related to the plugin and not to the gadget. Then its initialized only once after startup. This should be possible within the configuration system (didn't check lately).

Berkely, on 20 June 2011 - 03:17 PM, said:

It's a little tricky if you want to do it in a consistent way. Right now components are reconfigured by deleting the component (e.g. plugin) and recreating it with the new config. Usually only the component can decide wether there is a (useful) configuration or not, but it is called after the old config has been deleted, which is a little late. Introducing a checkConfig(QSettings*) before deletion could be possible, but quite some work.
But it would be possible for the component to indicate an error after which the user can abort or continue. In case of an abort a flag is set that the new config is not written on exit. Then you should restart the GCS immediately. This is not very nice but would be more of an emergency exit, however reloading configurations is tricky since it was not planned from the beginning.

Quote

To be honest, I don't know. Usually it works without restart, but there are some objects that are not deleted because they might be used somewhere. (Unfortunately there are many direct references in the GCS.) So the whole system is not in a clean state which might cause problems. Maybe one could write something like "If you want to be on the save side, restart the GCS!"

cwabbott, on 02 June 2011 - 09:20 PM, said:

Actually the "with" statement is not supported for Python 2.4 (comes with RHEL5), but at least 2.5 is needed. The script also uses some libs which don't work with 2.4. With Python 2.6.5 (on my Gentoo) the script works.
Compiling the GCS on Linux gets increasingly difficult. Right now neither on RHEL5 nor on my Gentoo system I can compile the GCS without commenting out some plugins or using some local modifications. I think I have to set up a new Fedora system to do development.