When the path to the database file given in a project file doesn't exist
try parsing it relative to the path of the loaded project file. This
makes it possible to move project and database file around together
without need to manually correct the path in the project file.
See #36.
Increase the default size of the main window a bit.
Move the SQL log dock to the right side and tabify it with the plot
dock. This way there is much more space for actual information by
default.
The idea behind both changes is to make it easier for first time users
to find their way around and offer them a more appropriate window layout
for the usual tasks. The layout is still entirely configurable and
non-first-time users are not affected at all.
This add support for saving and loading of SQLiteBrowser project files.
As of now these files contain a reference to the used database file,
store some window and widget settings as well as the content of the SQL
tabs.
Note that while working this is a first draft only. Especially the
parsing code still might contain a bug or two and there is a lot more
information to be added to these files later (like filters, plot
settings, etc.).
Also note that the main intention behind these project files was to make
the life of users easier while not getting into the way of those who don't
need them. The program still remains a database browser and doesn't
become a visual database studio thing.
Move the FilterTableHeader object from the MainWindow to the
ExtendedTableWidget class because it actually is a part of the latter,
not the former.
Show sort order arrows in the table header of the Browse Data tab after
clicking it.
Focus the SQL editor of a newly created tab to make sure it receives
keyboard input without need to click it first. On my system this wasn't
the case after starting the application, i.e. the first time the SQL tab
is used.
Add an entry for the CSV export to the context menu of the Database
Structure tab of the main windows as well which preselects the currently
selected table.
When opening the CSV export dialog via the standard menu also preselect
the currently selected table when the Database Structure tab is active.
When called while the Browse Data tab of the main window is selected
also select the current table or view in the ExportCsvDialog.
Sort the table names in the combobox of the ExportCsvDialog.
Also update the table view widget and the status message in the Execute
Query tab of the main window when the query was valid but returned no
results.
Fixes#38.
When multiple rows are selected in the Browse Data tab of the main
window and the delete record button is clicked delete all selected rows
and not just one of them.
When executing multiple INSERT/UPDATE/... statements don't cancel after
the first one. Also don't try to load them into the SqliteTableModel
class - it won't work and just generates a warning.
Use a custom model for the tree view in the "Database Structure" tab in
the main window, i.e. change from a QTreeWidget to a QTreeView and do
all the item management stuff manually. This might add some code and
complexity but also offers some more flexibility for us.
Add two new settings to allow changing the font size inside the SQL log
and the SQL editor.
Increase the default font size from 8 to 9 - better a bit too big on
some systems than too small on others.
Also do some restructuring in the MainWindow to avoid duplicate code to
reload settings.
When creating a new database file for an SQL import load the default
SQLite extensions - just like it's done when creating a new database the
normal way.
Allow multiple savepoints in DBBrowserDB, i.e. setRestorePoint() doesn't
simply return if the DB is already set to dirty but creates an
additional savepoint.
Track the names of all savepoints which have not been either saved or
reverted yet.
Finally, and that's the whole point of this commit, change the savepoint
logic of the EditTableDialog. We used to have a transaction started when
opening a database which was only committed when the file was closed
again. This way the EditFileDialog could savely create a savepoint when
being opened and just release it when OK was clicked or revert to it
when cancel was clicked. Getting rid of the transaction broke this
logic. The dialog still worked but as the savepoint was released when
the changes were applied all changes made via the dialog were
immediately committed to the database. So clicking the revert button had
no effect on those changes. This is at best an unexpected behaviour but
could also be a problem when some changes are reverted while others
aren't. So, having the option now of keeping multiple savepoints opened
this problem can be fixed by just creating a new savepoint every time
the dialog is opened, reverting to it when it is cancelled and _not_
releasing it when OK is clicked.
I hope this works!
