Create a unified settings model which will eventually remove the need for QucsSettings #533
Conversation
This change implements a QucsSingleton class that can be used to make any class singleton. It also provides a new settingsManager class which uses QucsSingleton to provide a single, static access point to the standard QSettings functionality. A shortcut is provided and a new method for providing a default value if the requested key is not set.
The recent docs list is stored as a * separated string and needs to be converted to a string list when reading from the settings file.
Replace almost all calls in main::saveApplSettings to the new unified settings model.
|
thnx! so, I suggest not changing anything now |
|
Thanks for the contribution. The removing of But I propose to shift the massive refactoring PRs to the next release. I am planning to prepare the |
|
Thank you and that is no problem at all. Of course can certainly save it for the next release and I would be happy to look at the shortcut key closer to the time if you like. |
|
I have merged the current branch with this PR branch but still need to go through #658. I only pushed the latest commit to see if there are other build issues, so please don't start to review yet. |
|
I have finished merging in the changes from #658 for now and I think that this can PR can be merged. There are a few things to bear in mind:
The reason for merging this PR now is to avoid a too big set of files to merge later. As can be expected, the settings items permeate almost all classes in the code, so moving completely to the new scheme will touch a lot of files. My thought is that it would be better to do one area at a time, but of course this is only a suggestion! |
|
@iwbnwif Thanks! I will try to test and merge this within the next 1-2 weeks. |
|
I have tested this PR and found one major issue. The window position and window size resets to default on every application start. The previous version was able to remember window size and position. At least it would be sufficient to always open the main window maximized. |
|
@zergud , Could you check the operation of the Windows version using new settings model provided by this PR? |
I thing we should migrate to new settings at one time, without leaving for later implementation |
|
@iwbnwif does your solution support setting like "gui/showMenuBar" ? |
This feature was never presented in application before and should be a separate PR. This PR doesn't introduce this feature. This PR is about refactoring of the existing settings representation. |
this feature supports by QSettings out of box |
This should be simple to fix. Qt has a function to do exactly this behaviour. I will look into it and update the PR but it might be a day or so. https://doc.qt.io/qt-6/qsettings.html#restoring-the-state-of-a-gui-application |
At the moment I have only tried to replicate settings that are already there. The idea is to replace the QucsSettings object with the inbuilt QSettings. This should allow more flexibility in future and easier to add new settings items. |
Yes, let's restrict by only replication of the existing features in this PR. New features should go in a separate patch. |
Window size and position should now be remembered. In fact, it should be better than previously because also the screen will be remembered in a multi-screen setup, and the maximized / minimized flags should be set in accordance with the state when the previous execution was closed. I have only been able to test this on Linux, but I can't see any particular problems on other platforms because only standard Qt calls are used. |
|
@iwbnwif I have merged this PR. Thanks for the contribution. One improvement could be added. The application window should be started maximized on the first start (check the former QucsSetting.firstRun).. This may be implemented in the future. As far as I can understand the second part of the settings refactoring will follow soon. |
|
Thank you.
This should be trivial I think. For example, add |
This is the first stage of refactoring the settings implementation. Currently the only change is to access the underlying QSettings engine via the new
settingsclass.The motivation behind this change is to support the implementation of the shortcut key feature #368.
The main advantage of this is that it is simpler to create new settings items. If you want to write a new setting, just add
_settings::Get().setItem<T>("key", value); To read it back, it's just_settings::Get().item<T>("key"). If you want to give it a default,just add it in settings::initDefaults.There is also a mechanism to have aliases for old settings names if we decide to update the names in the future.
Ultimately, it shouldn't be necessary to have
QucsSettingsat all - use_settings::Get().item<T>("key")directly in place. I haven't done this part yet though because it means changing a lot of files and I think it's best to exercise the new model a bit first.