Avogadro:xxx properties in CML

Development
1

In CML files saved by Avogadro there are all values of its properties. But it seems to be unreasonable to bind such properties as DPI of spectrum image to file. I think only view-related properties should be stored in file

Regards,
Konstantin

2

In CML files saved by Avogadro there are all values of its properties. But it seems to be unreasonable to bind such properties as DPI of spectrum image to file. I think only view-related properties should be stored in file

The problem is that so far, we haven’t been categorizing settings. My suggestion might be to add a QSettings::group() for file-level settings.

This means that some of the plugins will “duplicate” work in the readSettings() and writeSettings() methods. They’d write their default exactly as they have done. But for the particular file-related plugins, they’d also use beginGroup/endGroup and read/write these settings again.

Any other ideas?
-Geoff

3

In CML files saved by Avogadro there are all values of its properties. But it seems to be unreasonable to bind such properties as DPI of spectrum image to file. I think only view-related properties should be stored in file

The problem is that so far, we haven’t been categorizing settings. My suggestion might be to add a QSettings::group() for file-level settings.

O rly? I see settings are already categorized in manner extension_type/extension_name/propertyname. I think properties of engines (alongside with other options from view category) should be saved in file, others - not. Am I right?

This means that some of the plugins will “duplicate” work in the readSettings() and writeSettings() methods. They’d write their default exactly as they have done. But for the particular file-related plugins, they’d also use beginGroup/endGroup and read/write these settings again.

Any other ideas?
-Geoff

–
Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

4

The problem is that so far, we haven’t been categorizing settings. My suggestion might be to add a QSettings::group() for file-level settings.

O rly? I see settings are already categorized in manner extension_type/extension_name/propertyname. I think properties of engines (alongside with other options from view category) should be saved in file, others - not. Am I right?

Some tool options might be useful (e.g., remembering measurements currently on-screen). There’s also been talk about an annotation tool, which would need some properties saved with the file. I can also think of some extensions (e.g., spectra options) which may want their settings saved too.

And that’s not including general QSettings like camera position, etc.

So yes, engines are already categorized and handling those would be a big step. But that doesn’t include everything. :wink:

Cheers,
-Geoff