[Marble-devel] Not existing map theme properties vs. existing plugins?

Friedrich W. H. Kossebau kossebau at kde.org
Tue Jul 26 00:45:57 UTC 2016


when testing the Marble example apps, I found that in some cases setup calls 
done via the MarbleWidget API did not work. E.g. calling
with the earth/plain map does not hide the compass floatitem, it happily is 
present in the view. And same with overview map and scalebar.


The reason is that the earth/plain map in its dgml does not have a property 
defined for those plugins. And the current code[1] just makes those 
convenience methods for controlling plugin visibility simply noops, without 
any hint even on the console log.
Now, MarbleMapPrivate::updateMapTheme() [2] completes this problem, as it 
iterates over all plugins and only updates the visibilty of those plugins, for 
which the dgml has a property defined, and leaves any other plugin to it's 
default values (or any directly set one).


For some reason e.g. MarbleMap::setShowCrosshairs() [3] does not work via 
properties, but instead iterates over all plugins and sets the visibility 
property directly on the plugin.


As I understood things, render plugins and map themes are independent of each 
other, there can be plugins a theme does not know and there can be themes a 
plugin does not know.
Currently a plugin has a fixed default setting for visibility and does not 
care at all for themes here. While themes can have properties for the 
visibility of plugins, whose values would then overrule the default setting of 
a plugin.

The question seems to be how to control the visibility settings dynamically 
from the code? What is the settings model that should rule the visibility of 
everything? Especially when it comes to not existing map theme properties and 
existing plugins?

BTW, MarbleMapPrivate constructor connects to signals visibilityChanged() both 
of m_layerManager and m_floatItemsLayer. The first relays visibilityChanged() 
signals from all render plugins, while the second relays the same signal for 
all float items. Given render plugins are float items, this should result in 
duplicated signal handling when a float item emits a signal, no? No tested 
yet, but this smells like something is in the middle of rework?

--- 8< ---
void MarbleWidget::setShowCompass( bool visible )
    d->m_map.setShowCompass( visible );

void MarbleMap::setShowCompass( bool visible )
    setPropertyValue( "compass", visible );

void MarbleMap::setPropertyValue( const QString& name, bool value )
// [...]
        d->m_model->mapTheme()->settings()->setPropertyValue( name, value );
// [...]

bool GeoSceneSettings::setPropertyValue( const QString& name, bool value )
// [...]
    QVector<GeoSceneProperty*>::const_iterator it = d-
    QVector<GeoSceneProperty*>::const_iterator propEnd = d-
    for (; it != propEnd; ++it) {
        if ( (*it)->name() == name ) {
            (*it)->setValue( value );
            return true;
// [...]
    return false;
--- 8< ---

--- 8< ---
void MarbleMapPrivate::updateMapTheme()
// [...]
    foreach (RenderPlugin *renderPlugin, m_renderPlugins) {
        bool propertyAvailable = false;
        m_model->mapTheme()->settings()->propertyAvailable( renderPlugin-
>nameId(), propertyAvailable );
        bool propertyValue = false;
        m_model->mapTheme()->settings()->propertyValue( renderPlugin-
>nameId(), propertyValue );

        if ( propertyAvailable ) {
            renderPlugin->setVisible( propertyValue );
// [...]
--- 8< ---

--- 8< ---
void MarbleMap::setShowCrosshairs( bool visible )
    QList<RenderPlugin *> pluginList = renderPlugins();
    QList<RenderPlugin *>::const_iterator i = pluginList.constBegin();
    QList<RenderPlugin *>::const_iterator const end = pluginList.constEnd();
    for (; i != end; ++i ) {
        if ( (*i)->nameId() == "crosshairs" ) {
            (*i)->setVisible( visible );
--- 8< ---


More information about the Marble-devel mailing list