All the colour configurations have been reviewed under an operating-system theme
dark theme.
Some hard-coded colours in QScintilla editors and Data Browser have been
replaced by queries of the system palette or reuse of our settings.
New settings for foreground and background colours for QScintilla editors
defaulting to system colours. This is mainly needed because if the user
saves colour settings for a dark theme and then he changes the system theme
back to a light theme, then the foreground colours are preserved while the
background would fall back to the system theme leading to an incompatible
combination. This also gives more freedom to the user in defining his own
colour combinations.
Since only the default colour settings adapt to the system theme, and once
settings are saved this can no longer happen, a 'Restore Defaults' button
is added so the default adapted colour settings can be restored. This is
also useful for restoring default behaviour when wanted.
Other fixes and improvements: waiting cursor while saving; check boxes in
SQL tab for bold, italic and underline when applicable; avoid translation
of hidden colour setting names used in code.
See related issue #1324.
A new setting allows the user to set the text for BLOB data in the cell.
The existing line-edit for setting the NULL text and the new one for BLOB
are updated with the cell background and foreground colors, providing a
preview of the desired changes. An additional preview-only box is added for
the regular fields.
See issue #1263
Settings in Database tab are left-aligned for consistency to other tabs.
See comment in #1173.
When fetching a remote database automatically generate a file name to
save the database as instead of asking the user for a path and name.
Also add a preferences option to set the directory for all cloned remote
databases.
This is obviously a trade-off: on the one hand this makes opening remote
databases simpler (it's just a double click), on the other hand it takes
control away from the users. The main reason for doing this, however, is
to indicate to the user that the cloned databases are going to be
controlled by DB4S. We have to keep track of the local databases in
order to update them from the right place, push them back to the right
place, etc. And because the local copies are under DB4S control we don't
want the user to move, rename, or delete them.
Add a list of all configured client certificates to the preferences
dialog and show some information on them.
Add two button to the preferences dialog to add and remove client
certificates.
Copy configured client certificates to some safe place where they aren't
deleted by accident.
Change the remote code to expect certificate and private key in one
file. The path to this file is still hardcoded, now to client.cert.pem.
Remove the example client certificate as it's not up-to-date anymore
anyway.
Still missing: Option to use a configured client certificate from the
preferences dialog to authenticate.
Change the layout of the preferences dialog a bit.
Remove the server selection combo box from the preferences dialog as it
will probably never be required. The way we do logins using certificates
kind of makes this obsolete, I think.
Restructure the whole remote code a little bit. Also add helper
functions here and there.
Show a list of our the CA certificates built into the application in the
preferences dialog. This list is read only of course but still
informative as it tells the user which sites are supported ny DB4S.
Add an option to remember the location of the last opened or saved file
and use it as the default location for the next file dialog because
always going back to the default location set in the preferences dialog
can be a real hastle.
See issues #224, #276 and #281.
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.
Use a common format for all include guards, make sure each header file
has one and make sure it's named after the file name.
And as a random extra in this commit: Make sure the gen_version.h file
generated by cmake ends with a line break.
Closes#59.
Read and write the settings only from the preferences dialog.
Remove all the copies of some settings which were stored in nearly every
dialog class individually.
Simplify the settings dialog code by removing all those not really
needed slots.
Rename the files and classes for the dialogs to share all the same
naming pattern. This should make navigation in the code a bit easier.
Do not include dialogs not rewritten yet; they'll be edited as they are
redesigned.
