Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profiles do not pick up 'default options', even when shown in Options Dialog (eg Help Search Path) #25567

Closed
qgib opened this issue Dec 11, 2017 · 21 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Project

Comments

@qgib
Copy link
Contributor

qgib commented Dec 11, 2017

Author Name: Richard Duivenvoorde (@rduivenvoorde)
Original Redmine Issue: 17670
Affected QGIS version: master
Redmine category:project_loading/saving
Assignee: Alessandro Pasotti


Trying to fix the 'Oops No Help File Found' issue (see also #5844) it appears to me that some 'options' which show up in the options DIALOG are actually not stored in the settings.
This makes that this test to find Documentation paths fail:
https://github.com/qgis/QGIS/blob/master/src/gui/qgshelp.cpp#L44

To check:

  • make sure you do not have any profiles (so remove .local/share/QGIS)
  • start QGIS
  • have a look into Options/System/Documentation paths and see that there is an option:
    http://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/
    there
  • have a look into the Options/Advanced/Advanced Settings Editor and see that there is NOT a key
    "help/helpSearchPath" in the settings.

The options dialog is filled here:
https://github.com/qgis/QGIS/blob/master/src/app/qgsoptions.cpp#L302
so for that reason you see "http://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/" in the dialog.

So Question: how do we make sure that these 'default' options show up both in dialogs AND in the settings, ALSO when a new fresh profile is created
See #25495

Another question: WHEN you start with a clean default profile, should a second clean profile not have the same settings then?
In attached image I start a fresh default (left) and a fresh 'secondprofile' right. As you see the settings are very different.



Related issue(s): #25495 (relates)
Redmine related issue(s): 17598


@qgib
Copy link
Contributor Author

qgib commented Dec 11, 2017

Author Name: Richard Duivenvoorde (@rduivenvoorde)


Just a note that starting with a fresh profile, you will never be able to open the help pages as this settings value is never set it seems (thought the url in the options is ok)

@qgib
Copy link
Contributor Author

qgib commented Dec 11, 2017

Author Name: Richard Duivenvoorde (@rduivenvoorde)


@qgib
Copy link
Contributor Author

qgib commented Dec 12, 2017

Author Name: Nathan Woodrow (@NathanW2)


This is mainly a issue because those defaults are not created until you open and save the options dialog. I suspect this is the same as QGIS 2 so it's not profile related. The solution to anything that is shipped out of the box as a default should not be done in code and setup in qgis_global_settings.ini which is read only and all profiles will get it unless they override. That should be used for anything we want to ship out of the box

It's that or we have a setup config step which can load all defaults in code when the application first runs. That would be easy enough to do really and can just be part of the load process in main.

@qgib
Copy link
Contributor Author

qgib commented Dec 12, 2017

Author Name: Richard Duivenvoorde (@rduivenvoorde)


@nathan: I think a 'load/save all defaults to the settings in this profile' is a good one.

Though still I am afraid that IF people create a setting in some place, and then use it in another place (like with the help path: set in options, and use in help) we should in one way or another 'force' the default into settings?

Like:

  settings.value( QStringLiteral( "qgis/mysetting" ), false )

should set this default in the Settings if it is there not yet? Meaning that in QgsSetting.value(...) we do a small test. In this way during the use of QGIS, at least all settings are set to default values.

I thought of having a qgis_global_settings.ini first too, but the result of this is that the 'default' value is actually defined in two places: code and ini, with all problems of keeping this in sync.

The bigger future plan though should be that QGIS on a fresh install or on a fresh profile should have a well defined default start status. Be it via a master.ini or via a programming step.

@qgib
Copy link
Contributor Author

qgib commented Dec 12, 2017

Author Name: Matthias Kuhn (@m-kuhn)


I thought of having a qgis_global_settings.ini first too, but the result of this is that the 'default' value is actually defined in two places: code and ini, with all problems of keeping this in sync.

Or skip it in code and have QgsSettings load the global_settings.ini if it's missing from the profile?

@qgib
Copy link
Contributor Author

qgib commented Dec 12, 2017

Author Name: Richard Duivenvoorde (@rduivenvoorde)


@matthias and then make it impossible to set/use a default value in code? So devs are forced to set the default in global_settings.ini?

Not sure if that will fly. Sometimes you need a default value for an optional setting for which there is no need to really save into settings.

But being able to define a default setting both in code AND in ini file will result in a messy state in my opinion.

@qgib
Copy link
Contributor Author

qgib commented Dec 12, 2017

Author Name: Nathan Woodrow (@NathanW2)


Global settings are already used this way. They are a fallback if it's not defined in the profile settings. What we really need is a way to generate the default starting global ini file that we have in git. Meaning we update the code, that generates a ini file we check-in into git and that is shipped.

@qgib
Copy link
Contributor Author

qgib commented Dec 12, 2017

Author Name: Nathan Woodrow (@NathanW2)


and if a dev doesn't set a default in code and it's not found in settings then there isn't much else we can do. We could ship a list of "no delete defaults" that you can't override but not sure what stuff you would put in that bucket.

@qgib
Copy link
Contributor Author

qgib commented Dec 18, 2017

Author Name: Harrissou Santanna (@DelazJ)


Ì don't know if it's related to this issue or if I should file a new report but profile doesn't pick its own language: I'd like to have a profile that is in English (eg quickly file screenshots for docs or issues) and a French one where i could do my daily work or find missing or wrong translation.
Currently, both profiles pick the latest status of the "Override system locale" checkbox and not the one I set when using such profile.

@qgib
Copy link
Contributor Author

qgib commented Dec 18, 2017

Author Name: Jürgen Fischer (@jef-n)


To check:

  • make sure you do not have any profiles (so remove .local/share/QGIS)
  • start QGIS
  • have a look into Options/System/Documentation paths and see that there is an option:
    http://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/
    there
  • have a look into the Options/Advanced/Advanced Settings Editor and see that there is NOT a key
    "help/helpSearchPath" in the settings.

The options dialog is filled here:
https://github.com/qgis/QGIS/blob/master/src/app/qgsoptions.cpp#L302
so for that reason you see "http://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/" in the dialog.

So Question: how do we make sure that these 'default' options show up both in dialogs AND in the settings, ALSO when a new fresh profile is created
See this issue: https://issues.qgis.org/issues/17598

Another question: WHEN you start with a clean default profile, should a second clean profile not have the same settings then?
In attached image I start a fresh default (left) and a fresh 'secondprofile' right. As you see the settings are very different.
to Trying to fix the 'Oops No Help File Found' issue (see also #5844) it appears to me that some 'options' which show up in the options DIALOG are actually not stored in the settings.
This makes that this test to find Documentation paths fail:
https://github.com/qgis/QGIS/blob/master/src/gui/qgshelp.cpp#L44

To check:

  • make sure you do not have any profiles (so remove .local/share/QGIS)
  • start QGIS
  • have a look into Options/System/Documentation paths and see that there is an option:
    http://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/
    there
  • have a look into the Options/Advanced/Advanced Settings Editor and see that there is NOT a key
    "help/helpSearchPath" in the settings.

The options dialog is filled here:
https://github.com/qgis/QGIS/blob/master/src/app/qgsoptions.cpp#L302
so for that reason you see "http://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/" in the dialog.

So Question: how do we make sure that these 'default' options show up both in dialogs AND in the settings, ALSO when a new fresh profile is created
See #25495

Another question: WHEN you start with a clean default profile, should a second clean profile not have the same settings then?
In attached image I start a fresh default (left) and a fresh 'secondprofile' right. As you see the settings are very different.

@qgib
Copy link
Contributor Author

qgib commented Jan 10, 2018

Author Name: Richard Duivenvoorde (@rduivenvoorde)


To test:

  • remove ~/.share/local/QGIS
  • start QGIS
  • choose 'I want a clean start. Don't import my QGIS 2 settings.'

Now in Python console type:

QgsSettings().value( "help/helpSearchPath" )
which will return an emtpy list (of search paths)

Open Settings/Options/System properties and see there is:
https://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/
in Documentation paths there.

NOW click OK and NOW we have a saved help/helpSearchPath value:

QgsSettings().value( "help/helpSearchPath" )
['https://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/']

@qgib
Copy link
Contributor Author

qgib commented Jan 10, 2018

Author Name: Alessandro Pasotti (@elpaso)


As Nathan mentioned, global_settings is meant to provide defaults and IMHO it is the way to go, we should move defaults from code to the global_settings and ship it.

The idea is that it is better/easier to keep default values in a single file, that allows for easier customization during packaging and does not force to rebuild the whole binary distribution in order to alter a default setting.

settings.value('whatever') will read the global_settings if nothing is found in the user (profile) settings.

The order in which values are retrieved from value() is the following:

  1. the value in the user profile settings
  2. the value in the global_settings (note that this has precedence over the next)
  3. the default provided inline in the code as an optional argument to value(), like settings.value('whatever', 'default')
  4. QVariant() // empty-invalid

@qgib
Copy link
Contributor Author

qgib commented Jan 10, 2018

Author Name: Richard Duivenvoorde (@rduivenvoorde)


Ok, some additional info:

There IS already an qgis_global_settings.ini file

QgsApplication.pkgDataPath() + "/qgis_global_settings.ini"

which is in my case rightfully installed in my (custom) install directory.
This file contains (with me) currently the xyz-url for osm.
BUT if you start QGIS for the first time, after

rm -rf ~/.local/share/QGIS

this file is apparently not read/handled as the xyz-node in the browser will be empty (see screenshot).
The second time you start QGIS, it is read, as at THAT time the xyz node contains the osm connection.
So this seems to be a bug in the handling of the qgis_global_settings.ini in the first run.

The QgsSettings().value( "help/helpSearchPath" ) though, stays empty untill you OK the Settings/Options dialog.

IF we would put that setting in qgis_global_settings.ini though, it would show up (the second time ;-) )


  • 11925 was configured as xyz.jpg

@qgib
Copy link
Contributor Author

qgib commented Jan 10, 2018

Author Name: Alessandro Pasotti (@elpaso)


The issue with XYZ defaults (that are actually in the global_settings.ini that we ship) is that at the time the global file path to search is generated, QgsApplication.pkgDataPath() is empty because QgsApplication::init() has not been called yet.

This means that the global_settings is not found.

Broken by 00dbc73

@qgib
Copy link
Contributor Author

qgib commented Jan 12, 2018

Author Name: Richard Duivenvoorde (@rduivenvoorde)


Another additional observation: if you create a new profile, it looks like the global_settings.ini are never read. Because multiple opening of QGIS with the second profile will never show the xyz url...

@qgib
Copy link
Contributor Author

qgib commented Feb 6, 2018

Author Name: Alessandro Pasotti (@elpaso)


  • assigned_to_id was configured as Alessandro Pasotti

@qgib
Copy link
Contributor Author

qgib commented Feb 10, 2018

Author Name: Richard Duivenvoorde (@rduivenvoorde)


#6303 is adding the help url to the global settings

@qgib
Copy link
Contributor Author

qgib commented Feb 12, 2018

Author Name: Alessandro Pasotti (@elpaso)


New approach by Nathan: #6317

@qgib
Copy link
Contributor Author

qgib commented Feb 16, 2018

Author Name: Alessandro Pasotti (@elpaso)


  • resolution was changed from to fixed/implemented
  • status_id was changed from Open to Closed
  • pull_request_patch_supplied was changed from 0 to 1

@qgib
Copy link
Contributor Author

qgib commented Feb 23, 2018

Author Name: Richard Duivenvoorde (@rduivenvoorde)


@alessandro and @nathan, in my testing it is still not solved.

Creating a fresh profile, people will have no help and xyz layer.

Only after:

  • opening options dialog + OK'ing it the help url setting will be available
  • shutting down and restarting QGIS will get the user the xyz layer setting

  • status_id was changed from Closed to Reopened

@qgib
Copy link
Contributor Author

qgib commented Feb 24, 2018

Author Name: Alessandro Pasotti (@elpaso)


  • status_id was changed from Reopened to Closed
  • resolution was changed from fixed/implemented to not reproducable

@qgib qgib closed this as completed Feb 24, 2018
@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Project labels May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Project
Projects
None yet
Development

No branches or pull requests

1 participant