Added new argument to command line for saving a value for a setting and
not only running it temporarily: -O/--save-option
Fix string lists settings so they are saved as an actual QStringList and
not a string. This assumes these settings are always named "*list".
Currently they, and only they, are.
Together with --quit, this argument allows saving the extensions/list and
other settings after an installation depending on options selected by user
in the installer. For example, running (Linux syntax):
./sqlitebrowser --save-option extensions/list=/path/to/libsqlitefunctions.so,/path/to/libsqlite-formats.so --quit
will save the two extensions to the preferences and they will be
automatically loaded every time DB4S is loaded.
See issue #1224 and PR #1716.
There are cases where the default configuration makes impossible to
use the application, due to some misbehaviour, like in issue #1560. This
new command line option allows users to set any setting to any value.
The setting is not saved unless user enters Preferences and saves the
current values. This allows overriding the preferences for the session
duration from the command line and also overriding the defaults for the
first session to work around problems with those defaults.
See issue #1588
Rename the settings accessor functions from Settings::getSettingsValue()
(and similar) to Settings::getValue() (and similar). The 'Settings' bit
seems a bit redundant and costs a lot of screen space.
Make the reload shortcut (at the moment F5 and Ctrl+R) dependent on the
currently active tab. This way it always performs some meaningful task,
depending on the current context.
See issue #759.
The behavior remains basically as before: when first launched
the application will try to load a translation for the user's
locale, and if one cannot be found it defaults to English.
The difference is that now this is remembered so that upon
further launches the program will go straight to the matching
locale.
See issue #182.
The QTranslator objects need to be stored as class attributes as
otherwise they are destroyed after the Application constructor is done
and translations won't work.
Remove the deactivated MacOS dependent code for reacting on Cocoa events
for file associations from main.cpp
Try to implement the same functionality by reacting on QFileOpenEvent in
the Application class.
Create a new subclass of the QApplication class and move most of the
code in the main function to the constructor of the new class. This
makes the code a bit more consistent in terms of object orientedness,
makes it a little simpler and allows extending the new Application class
in the future.
